Android

48 replies [Last post]
magill
Offline
Joined: 27 Apr 2012

Complete novice here.

I have recently written an app for my Android phone which sends UDP packets (for another project I'm working on)

Adapting this app what is the best approach to controlling the Livebox. Do I have to write LUA scripts to intercept incoming messages?

What about responses? Forgive me if I am approaching this from the wrong direction.

John

BoxingOrange
Offline
United Kingdom
Joined: 11 Jun 2010
Brett's the coder here. but

Brett's the coder here. but you could do worse and read this http://www.xapautomation.org.  Kevin, who wrote the Joggler software may also be able to help.  The framework that Brett has built the HAH on makes it VERY flexible, unlike a lot of commercial products out there.  

So implementing XAP is probably the best way to go, but, I'm sure Brett will give you a more complete/better answer,

 

Karl

garrydwilms
Offline
United Kingdom
Joined: 31 Mar 2011
I do something similar on the

I do something similar on the iPhone. I tend to send alias style messages over udp as they are simpler to program into an app and then use a modified version of the alias interpreter script fit actioning. 

eg I send alias messages such as "thermostat 17C" or "boost 2hrs" and the script then does the relevant action. 

For feedback i use the web server script to supply HAH data and set the app to poll the http address and then use the returned value to set the relevant switches and sliders to the current condition/value. 

There are probably hundreds of ways of doing this but this works for me. 

For interest, the iOS app I use is MOTE. 

 

Garry

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
There's a xaplet for that!

This is really interesting. Lots of folks that I talk to about the HAH project are surprised that we don't have mobile 'apps'. I can run the native HAH browser UI very nicely on my HTC One X, but it does seem that people want a dedicated app. 

Brett would indeed know how best to architect this. I'm definately thinking of a Lua script that is watching for a UDP message from the Android app and re-broadcasting a xAP message on the home LAN based on what is needing to be controlled. Authentication might need a bit of thinking about - but this needn't be hugely complex.

I don't know enough about mobile apps to know about how any 'incoming' message might be handled, but I'm betting that Lua can send a response to the socket that carries the original message.

With apps, the feel of the UI is everything. http://www.vivint.com/
Hmm, how about $0/day?

Derek.

 

BoxingOrange
Offline
United Kingdom
Joined: 11 Jun 2010
GUI's on Mobile Devices

I recently had a look at the LightwareRF app on the iPhone, loved it.  Would love to do something similiar for the HAH.

brett
Offline
Providence, United States
Joined: 9 Jan 2010
There are two aspect to an

There are two aspect to an xAP client - if you just want to send information its pretty easy you just contruct an xAP payload and broadcast it on port 3639 job done.  There are python samples for you to look at for a high level overview of the most basic client you can construct.   Easily doable in most languages really.

If you want to deal with incoming information its only slightly more tricky.  There are two sub-aspects to this.  If you run a single xap application on the android then you can simply listen for UDP broadcast packets on 3639.  If you want to run multiple xap applications as the same time then you need a hub.

I'm not sure what language you program up on the android is this C, Java, what?

I've already written logic in C and LUA for decoding xAP packets and I'm sure this would be easy enough to port into yet another language if required.  I have an android tablet - well its my wifes and she is very protective of it however I'm sure if I indicated that it was in her interest I might be able to use it.  I could always flash up my webos tablet for android and use that I guess - I've been keen to look into this but I'm short of time.

Let me know how I can help out and I'll be happy to provide information where I can.

Brett

garrydwilms
Offline
United Kingdom
Joined: 31 Mar 2011
 Karl,  I know I keep going

 

Karl,  I know I keep going on about it but if you like lightwaveRF then mote is very similar. And before you ask, no I'm not on commission ;)

Heres a screenshot of one of my control screens. Switches and sliders move real time to match HAH settings. 

Temps via 1wire

I like it!

 

Garry

 

magill
Offline
Joined: 27 Apr 2012
UDP
Probably a very silly question but..
I run up xfx viewer on a pc on my network (10.0.0.29) and using a bit of VB.net send a UDP packet to it on port 3639. It gets recognised.
Livebox is sitting on 10.0.0.30. I send same packet to it and get no response on the XFX viewer.What am I missing?
John
derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
xAP uses broadcast

Are you sending the xAP payload to the broadcast address on your subnet?

Derek.

magill
Offline
Joined: 27 Apr 2012
Not sure I understand the

Not sure I understand the question.

I'm sending the payload to the IP where the Livebox resides and on port 3639

John

garrydwilms
Offline
United Kingdom
Joined: 31 Mar 2011
John, I think the point is

John, I think the point is you don't send xap messages to an ip. They get broadcast on the subnet and a particular port. All listening devices will pick up the message. XFX viewer sorts the messages as per the sender and target in the script, not by the ip address it was sent to or indeed even what device sent it!. Is that any clearer, not the best explanation I know but I only just about understand it myself!

 

 

Garry

BoxingOrange
Offline
United Kingdom
Joined: 11 Jun 2010
Broadcast Address

John,

If your IP is 10.0.0.30, and we assume a subnet of 255.255.255.0, you're broadcast address will be 10.0.0.255.  If your subnet is 255.0.0.0, your boardcast address will be 10.255.255.255.  xFxViewer picks up the broadcast messages.

Karl

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Garry that was spot on.   xAP

Garry that was spot on.   xAP is not a UNICAST protocol its a BROADCAST protocol.  So there should not be any discussion of IP addresses as ths is an IP-LESS protocol.  A packet on the wire is picked up by every device "target=" and sometime just the "class" will determine if the packet is used by a process.  The great things about being IP-LESS is that you don't have to worry what IP address you're devices have that are hosting the XAP programs in order to send them a message - its not relevant.

I will make mentioned of the fact that there are two types of broadcasts; one for your subnet and a global one.

If you're LAN was 192.168.1.0/24 then its broadcast would be 192.168.1.255 whereas the global broadcast is 255.255.255.255 either should work.  The xaplib2 library on the livebox will use subnet based broadcasts so if you run multiple subnets you could run 2 separated livebox networks on the LAN if you required.

Brett

magill
Offline
Joined: 27 Apr 2012
Thanks guysI understand it

Thanks guys

I understand it now and am now seeing packets on the subnet

John

andy
Offline
United Kingdom
Joined: 17 Mar 2012
Android UI.

I just thought I'd let a few of you know what I have been working on for a few weeks, its early days but it may be interesting to some, but first a short background:

I saw the lightwaveRF app a few months back (i have some LWRF kit), but it was not really a prime time android app, buggy and imho could have been implemented more elegantly, but I thought it may be a nice interaction model for HAH. I did not have a joggler at the time so could not take advantage of this nice kit, but did have android phones in the house, and wanted a UI (with widgets) for my newly built HAH.

I descided to start the design of an android app that used HAH-iServer but was NOT flash based, but that also included aspects of the sequences concept of the lightwaveRF. I extended iServer a little to integrate some crontab interface, and tried to keep as close to the xAP flash config, but had to fork this a little. The end goal is to have an extendable native android UI based closely on the Flash concept. I also have built a little plugin to 'Locale' so that the HAH can know when someone is 'home' or 'away' and informs the HAH, this can be then acted on by PBv2. I am currently in the process of refactoring the app to include xAP over UDP as an alternative transport. 

I will be on leave next week recuperating after a small knee op. on TUE, so will have more time to complete this work.

When it gets to a human-usable point again, i'll post the HAH and Android binarys/code with instructs here for the intrepid to try out. I'll post some screenshots shortly.

 

ps: Has anyone decoded LightwaveRF protocol, I see some partial attempt on the wiki but do not know if it can be completed, I am not electronics expert and do not have o-scope. Was looking to buy a USB one, but it may be more cost effective for me to post some kit to one of you guys as a 'gift' for your efforts, I have a spare 4-button remote with a-b-c-d channels and a RF on/off socket I can spare - any takers, pm me.

 

--Andy

garrydwilms
Offline
United Kingdom
Joined: 31 Mar 2011
Andy, this sounds really

Andy, this sounds really interesting. Excellent work!

Actually makes me a little bit gutted I have an iPhone :( which I must say is a first for me 

would love to help with the decoding but I'm in the same boat as you regarding a scope. Have tried the audio jack on laptop method in the past but I get way to much noise and not had much success ( actually No success!)

 

Keep up the good work and I may consider switching to android ( did I actually just say that!)

 

 

Garry

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Andy the only reason the

Andy the only reason the iServer exists is to work around the fact that Flash cannot do UDP.  I would not bother integrating with this component from the android as it should be able to handle native UDP broadcasts.  Unless of course your intention is that it can also operate outside of your LAN which would mean it would need to use a TCP relay like the iServer.

Note: there is a nasty bug in the iServer that I need to address but it will require me to rewrite the lexer.  FLEX doesn't quite cut with a well crafted and timed packet it will drop stuff on the floor (not crash mind you) just not process a command.  I only mention this as you have created a personal development fork.

If this change compatible with the mainline code?  If so we should merge it in once you are done.

Brett

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Lightwave is getting there

Andy,

Great to hear about your Android work. My HTC One X is sooo ready for this!

I did make a start on the Lightwave RF protocol. Turning a bulb on and off is totally solid. I need to do more research if we are to be able to do smarter stuff. I'm very impressed with the quality of the Lightwave kit.

Paul did some work too and was good enuff to let me publish this. All we have is on the wiki.

Derek.

andy
Offline
United Kingdom
Joined: 17 Mar 2012
iServer and native UDP.

Brett,

 

I am trying to design the app as a 3 tier system,a 'core' with plugins for 'communication' like iserver(TCP) and UDP, and plugins for 'Features'. TCP Comms is great as you know for (mobile) comms (over your Cell network) (outside your LAN (routable, securable) ) as well as inside your 'house', and UDP is great for fast simple comms that does not need much in the way of infrastructure support. 

I am hoping any/all iServer changes are non-breaking and can be merged. (I'll remember to keep dummy merging here).

One of my main problems so far is battery (phone/tablet) usage, but I am starting to understand how to keep this in check whilst still having a responsive (aware) device - may hours spent head scratching and testing here...

As for intelligent use of screen real-estate, well thats also a headache also...my transformer TF101 is huge, my phone (DROID2&Desire) so small (well larger than a nokia classic (you know what i mean). The same UI does not always look good on both form factors. More ongoing experiments....

 

--andy

 

andy
Offline
United Kingdom
Joined: 17 Mar 2012
LWRF Collab

Derek,

 

Paul's been in touch, and am hopeful his work will provide a needed boost on this front. B.O. has also been intouch and i'll see if we can get some sort of research/verification process underway with them both. I really like the LWRF & Siemens branded kit, its very modern and up to date, and my wife/kids really likes how the dimer kit works, both the wallplates (siemens) and the CFL (lwrf).

I used both of your wiki input, but it quickly took a back seat to the above project, but now I am getting things running, I have found that I want to integrate more of my lwrf kit into the HAH to keep it all central (and use plugboard) - my aim is to ditch my lwrf iLink (or keep as backup). Now I have some new data from Paul, I can move on this front also - hopefully there will not be too many obstacles. I know I should buy a o-scope (perhaps USB) (and learn to use it!!) - but I promisedd my O.H that I would keep costs 'reasonable' and £200+ mark is a stiff drink away. I know I could get a cheaper scope but would that be money well spent in long run.?

Anyhow, I also now just won a Joggler on fleabay so that should also help with some compatability testing.

--andy

magill
Offline
Joined: 27 Apr 2012
novice here again
Hi Guys I've been reading the posts and realizing how basic is my knowledge of UDP/TCP protocols. I have enjoyed learning how to get an app running on my Android phone and am keen to try and send an XAP payload via cell/Wan using TCP. I see Andy is planning a "proper" app and I look forward to seeing it, but I would love to have a go myself. Given that I'm a novice at XAP have you any guidance on how to achieve 2 way comms. I assume I will need to implement iServer. John
derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Training the lightwave

The bit that I stopped at was getting the HAH to 'train' a CFL bulb. I used a lightwave remote to do this piece. 

As for a USB 'scope - it needn't cost the earth. Brett picked up one from eBay - kinda basic, but certainly up for the job. Perhaps he can provide a link to the one that he has?

Derek.

paulsbiz
Offline
Rugby, United Kingdom
Joined: 19 Apr 2012
Training the lightwave

I've tested training to the HAH and it works OK.

Andy, if you have a CFL bulb you could enter Derek's example strings and use them to train your bulb to.

It doesn't matter that the ID used is different from your own remote as long as you don't exceed the limit on the number of remotes associated with the CFL.

Paul

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Great that training is good

Thanks for the testing. I just didn't get to trying this.

Further, I hadn't thought of the 'multiple transmitter' support that is built into the Lightwave units. This makes dual HAH/handset control easy to do, with a 'standard' set of codes from the HAH.

My Lightwave bulb control from the HAH is very solid. I really must add Lightwave support to the RF Rx unit.

Meanwhile, the LightwaveRF prices at B&Q still seem a lot better than most anywhere else (eBay included).

Derek.

magill
Offline
Joined: 27 Apr 2012
confused
Hi Guys
My last post got a bit lost amongst "lightwave" stuff so I shall ask again.
My main goal is to have control of the system remotely using my Android phone. I have a little experience in writing simple apps for Android. I want to switch outputs and interrogate inputs.
I am still confused as to whether to send UDP packets (as per Garry's Iphone Mote app) or to implement Iserver via TCP.
I've seen reference to this latter method in the posts but don't know how to do it.
John
andy
Offline
United Kingdom
Joined: 17 Mar 2012
Lightwave Thread?

Shall we start a new thread under Hardware for LightwaveRF.

The multiple transmitter support has come in handy, my HAH is now mimicking 2 * 4 button remotes already.

@Derek - my CFL's control is rock solid, just experimenting with @paulsbiz data, and looking ok. Will share my new info next few days.

 

--andy

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Multithreading

Is fine.

I've got other stuff to burn time on just now, but I'll aim to get all proven LightwaveRF details onto the wiki.

Derek. 

andy
Offline
United Kingdom
Joined: 17 Mar 2012
John,UDP is a fire and forget

John,

UDP is a fire and forget protocol, with any ack needing to be built in at the protocol level. Imagine a fast two wheel drive car.

It cannot go over ditches and banks (its not routable in the normal sense)

Whereas TCP has lots of goodies, and built in support for ack and routing etc. Imagine a 4 wheel drive with bullbars, high ground clearance and lots oftorque. Its can traverse most anywhere.

At a basic level, your (smart)phone operates in two environments, over cell network, and over Wifi. Cell best using TCP, Wifi can be TCP OR UDP. You need to sit a 'high level protocol' on either. For UDP you would use xAP for obvious reasons. HAH listens for xAP over UDP by default so support is out-of-box. For TCP you must have a listener (just like a webserver listens for HTTP/HTTPS, something needs to listen (and reply) over the TCP network to communicate with your phone and broker for the HAH. The iServer operates as a TCP->UDP(xAP) broker/proxy/router (call it what you will).

So, if you want to talk back to your house in UK from spain using your phone, you really need TCP. If you want to talk to HAH from phone only in your own home via your android mobile, the UDP is good choice.

I have reasons to using both protocols, but also plan on using other listeners as well as iServer - I am experimenting. For example you could try looking at a message queueing system, like AMQP or XMPP etc. You could try implementing a 'restful' interface and you could stick to HTTP over TCP. There are lots of options, and lost of considerations, like resources on LB/HAH (or offload onto other CPU), battery on mobiles etc, responsiveness etc etc.

--andy

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Just a little on iServer - I

Just a little on iServer - I wrote this purely to interface with the xapflash program that was already written and available on the joggler.  I had to reverse engineer the protocol from wireshark traces as both the windows iServer and xAPflash are closed source, so my iServer just represents what I could see and also why there isn't any documentation.  There wasn't any and I never wrote any up.

Another option would be to use a websocket and use this as a transport for the xAP protocol.  I have done a little prototyping along those line using LUA and some C for the heavy lifting but I haven't got anything fit for release (yet).  For a busy network you would still want to implement some sort of filtering mechanism to reduce traffic in the pipe.

Andy you have a good handle on this I see  :)

Brett

magill
Offline
Joined: 27 Apr 2012
UDP/TCP
Hi
Andy I hope your knee op went well.
Thank you both for the very comprehensive answers. I understand that I am a lightweight in matters relating to networking and transport protocols etc, but I have had success in communicating TCP and UDP to other devices.It was Garry's Iphone Mote app that caught my attention. His app sends UDP over 3G and is fairly robust. I thought if I could just emulate this I was in business. Andy you are discouraging this approach and suggesting maybe even another CPU. (BTW what is LB/HAH) When you say "stick to HTTP over TCP" do you mean the normal web interface on the HAH. The purpose of my endeavour is to monitor a remote location and to "boost" heating etc . I have a lightweight working model based round Nanode which is an Arduino clone with ether support. ...."I know wash your mouth out" and all that. I have enjoyed discovering and playing with HAH and would prefer to use it.
John
andy
Offline
United Kingdom
Joined: 17 Mar 2012
John, Knee op ok, no pain

John,

 

Knee op ok, no pain (dosed up!).

LB=LiveBox

HAH=PCB attached to LB, with an ATMEGA cpu (prob 328P).

First, no discouragement...experiment. Delivery reliability is a TCP inbuilt, you must add to UDP.

Another CPU - well, this was in relation to listeners/additional processes that you may want to use that may not 'fit' in the frugal contraints of the LB memory/filesystem/cpu, especialy if you dont have a 'dev' livebox you can compile into for testing. 

Brett has used kloned web server for supply of a UI, with frugal resources. One can see where a web server can be even more useful if it had more capability (read:feature creep), and I was referring to a restful interface (see bretts other work on a plugboard v2 script for xAP value caching as that could be useful to you also), so when i say 'stick to HTTP over TCP', the context was to use a RESTful interface and get your phone to talk to that, and because of its 'simplicity' (http) you can use TCP as transport and you have cell network and home WIFI lan covered.

Nanode - on contrary, I also have nanode's, and jeenodes, and seeeduinos and arduino's - (all purchased since I came accross HAH PCB - which opened up a thirst to learn more - dont tell wife - she not aware of spend ;) . The nanodes/seeeduino/arduinos i use to experiment, the jeenodes I use mostly with my HAH. (btw: imho the support and modular approach of jeenodes is light years ahead of nanode, but luckily are based in same CPU - I am so glad hahnode is based off jeenode concept - still waiting for derek to sell me one or two ;) ).

My goals (maybe different to yours), is to keep all 'control' logic on LB(main cpu) where possible, and to provide additional 'device' control via android. I want to be able to control both inside and outside my home, as well as my holiday home. I want to be as compatable with the main LB development code as possible - eventually feeding my changes to trunk to be vetted/accepted by team (i.e I dont want to cause a fork, nor do I want to add unneeded 'bloat'), so I have opted for a pluggable aproach. PS: I also dont want to run power hungry PC's etc to achieve any of this either.

So, dont take any of my comments wrong way, no discouragement intended, if you want to use UDP on your 3G, go for it. If you just want to turn your heating on/off remotely and get statuses, use twitter interface ;) - but if your like me and others here, you have other motives like learning and thats almost as important to me than controlling my house.

--andy

 

 

 

 

andy
Offline
United Kingdom
Joined: 17 Mar 2012
TCP vs UDP

John,

(I am sure you googled) But this small page sums up some of the pro's/con's of tcp/udp and may serve to help make a refined choice as to how to proceed.

btw: I have chosen initially to use both here, but may not always finish up with using both.

http://tunnel.mrq3.com/explain/node2.html

There are lots of other pro's/con's and security of data could be another that may be important to you (especially outside your homes).

--andy

magill
Offline
Joined: 27 Apr 2012
googlecal or cron?
Garry made mention of sending alias messages to "boost" the heating for 1 or 2 hours. He uses Googlecal and it seems to work for him. I'm wondering if it's possible to use cron to do the same, can you use script to write events to it? What about "timer" or is it not suitable for long events. thanks John
kevin
Offline
Huddersfield, United Kingdom
Joined: 17 May 2010
xServer / iServer protocol

A dual topic thread ... :-(

Although iServer Windows  is closed source the protocol that is used for connections is pretty simple and I'm happy to disclose any aspects of it for people wanting TCP connectivity onto xAP. Unfortunately xServer was closed source so my iServer fork of that app has to remain that way.  The protocol isn't documented as such but I know it should be.

Aside from the guaranteed delivery and sequence ordering that TCP offers there are other aspects that iServer assists with.   Notably a device attaching to iServer can create filters such that only traffic of relevance to the device (perhaps the xAP devices that match buttons on the device or certain schema) traverses the socket.  This filtering helps significantly with lighter devices in terms of their parsing load.   The iServer also automatically synchs (queries) all registered BSC devices when a client connects and handles pacing of traffic.  There are additional aspects in the Windows iServer that add a security level to restrict a connected user to certain devices.

On the upcoming iOS application I have implemented xAP using both UDP and TCP / iServer and my experience is that TCP is preferable and recommended.  UDP works fine with strong WiFi signals but in weak situations I see packet loss.  Because there is no pre filtering with UDP the app has to work significantly harder parsing all incoming traffic.   Also as you switch an app in and out of background you can easily lose traffic meaning your state model is inconsistent, this might be avoidable with TCP depending on how background buffering is implemented in the OS.

Just to clarify a xAP connection via TCP to iServer maintains the full broadcast nature of xAP where all devices hear all messages from everyone.  However filtering , if used, can reduce this at the iServer client.  Messages specifically targeted at all devices e.g. target=>:> can be configured to traverse a Windows iServer link regardless of filtering as can certain schema e.g. message.display used in CallerID display.  xAP wildcards can also be used in filters.

The features differ between the various iServer's that exist although a core feature set provides compatibility.    Windows iServer derived from an application designed to bridge xAP networks and so has better security and device protection as well as supporting several different client connection protocols.  HAH's iServer has slightly better device filter wildcarding. 

magill
Offline
Joined: 27 Apr 2012
TCP connection IServer
Hi Kevin
I have been progressing with my Android app and have a working model, sending UDP payloads and interrogating http via the webserver applet. It's a bit messy I agree. I would be very interested in using the IServer as conduit. Given that I am a bit of a lightweight programmer and knowledge of TCP is limited, is there any chance of a few snippets/examples of code I could try?
thanks
John
kevin
Offline
Huddersfield, United Kingdom
Joined: 17 May 2010
Basic iServer protocol

In order to use iServer you have to connect via TCP , logon and then setup filters for the types of xAP messages that you want iServer to pass back to you from the xAP network. If you use the Windows iServer then these filters can be associated with a profile set up in iServer but the HAH iServer requires they be setup each time a connection is made.  During a session you can create filters on an ad hoc basis (if your profile permits this).

Messages you send to iServer are of two types 'command' and 'xAP' and each are enclosed in XML type tags .   Control messages use <cmd>......</cmd>  and xAP messages <xap>... </xap>.   The data between the <xap> tags is exactly the same as a normal xAP message and all such messages sent to iServer will be forwarded onto the xAP UDP network verbatim.    xAP messages received by iServer will be compared against the filters in place for each attached client and forwarded to you when matched,  enclosed within <xap>...</xap> tags.   Bear in mind that in your TCP listener because of buffering, multiple xAP messages may be concatenated and also truncated, any such partial messages should be retained and prepended to the next data arrival.  No data will ever be lost but you lose the natural behaviour of UDP where one datagram arrival always represents one complete xAP message.

Where there are differences between HAH and Windows iServer I have tried to mention them.

On opening a socket to iServer (TCP port 9996) it will respond

<ACL></ACL>

You need to logon using log<code>  and sending a password that matches a profile configured in iServer - which could be blank if passwords are not enabled.  On Windows iServer the password is really just a secondary code that determines the priveledges and preset filters associated with a profile .  HAH iServer just implements the password as a logon credential granting full access. There is a more advanced challenge response authentication but that is not used here.

<cmd>log<code>password</cmd>

 A successful logon is not acknowledged although some versions of Windows iServer may return the name of the profile in use.  <ACL>Joggler</ACL>

You should now immediately send a heartbeat message from your application which iServer uses to establish your source address.

<xap>

xap-hbeat
{
v=13
hop=1
uid=FF.2122:00
class=xAP-HBeat.Alive
source=ERSP.Barix.Barionet
interval=60
}

</xap>

Windows iServer has additional security to restrict messages to avoid clients spoofing source addresses and can also restrict classes e.g. to block incoming xAPBSC.cmd messages meaning a client can monitor but not control certain devices on your netowrk. HAH iServer does not implement this additional security as it is intended for intranet use or password protected (full access) security only.

Now you need to create your filters using <flt+> to tell iServer which xAP messages to pass to you. As soon as you create a filter any matching xAP messages will be forwarded to you. Typically this involves adding the specific source address for each device you wish to hear messages from. This creates the most efficient traffic flow between iServer and your client and is the recommended approach. Filters are case insensitive.

<cmd><flt+>acme.controller.house:heating.override</cmd>

<cmd><flt+>acme.controller.security:PIR.Hall</cmd>

However you can use wildcards too e.g.

<cmd><flt+>acme.controller.house:*</cmd>

this latter one would pass all sub addressed messages from acme.controller.house to your application, but not heartbeats for example as they do not originate from a sub address.  If you were passing all endpoints from one specific device this is an efficient way of setting the filters up.

You can also create a filter based on the xAP class using <cflt+>.

<cmd><cflt+>xapbsc.*</cmd>

There are also the reverse <flt-> and <cflt-> options to create filters blocking device messages from being passed.  These are really only useful when you have other previous wildcard filters in place.

BSC specific feature:   When you create a filter using <flt+> iServer will automatically on your behalf issue a xAPBSC.query command to that device address and pass any xAPBSC.info response back to you . This ensures that your application is immediately synched with the current status value of the device.  Although the HAH iServer usage is typically passing xAPBSC class messages it is not in any way restricted to this and will pass / filter any class of message. Windows iServer has a 'BSC only' configuration option.

iServers  buffer/pace messages to avoid a sudden burst of messages flooding the network when filters are created.  This can be most useful to avoid overflowing buffers in limited memory devices.  

  K

 

 

 

 

 

 

 

 

magill
Offline
Joined: 27 Apr 2012
TCP connection IServer
Hi Kevin This is excellent stuff. I now have a TCP client app (vb.net) communicating with the Livebox. Very basic for now, just push and pull. Next job is to rewrite my Android app to implement TCP. thanks again for all the info. John
AndrewJ
Offline
United Kingdom
Joined: 22 Nov 2012
Hi All, any updates? :)

.

mark_baldwin
Offline
Blackburn, United Kingdom
Joined: 19 May 2012
It did go a little quiet on

It did go a little quiet on this post Andrew but a good post for information

magill
Offline
Joined: 27 Apr 2012
Android app
Hi Guys
Unfortunately I didn't progress any further in developing the android app. My goal was to boost/monitor heating (also to monitor oil tank level and temperatures in and out) in my holiday home. My app manages to do that by sending alias message via UDP and monitoring responses from webserver applet. I experimented with Kevin's iServer protocol with some success but had difficulty parsing the XAP responses and gave up. I will maybe have another crack at it in the new year.
John
AndrewJ
Offline
United Kingdom
Joined: 22 Nov 2012
Hi John,Thamns for the

Hi John,

Thamns for the update, sure would be good to see a custom Android app for the HAH that didnt rely on the xAPFlash (not that thats a bad thing) just something that talked with iServer direct

I normally mess around with Android dev with MIT / Googles App Inventor but realising its limitations have now installed the SDK... still early days :)

thanks

Andy

magill
Offline
Joined: 27 Apr 2012
parsing incoming xap messages
Hi Andy
My problem was parsing incoming data. My method was to examine the string and look for say "relay1" and then extract the "on/off" section at character position 75 or whatever. Works OK but very messy. Maybe if Brett reads this he could point me to a proper customised parser.
John
AndrewJ
Offline
United Kingdom
Joined: 22 Nov 2012
Hi John,Wouldnt some XML

Hi John,

Wouldnt some XML Android parsing do the trick? 

http://developer.android.com/training/basics/network-ops/xml.html

Andy

magill
Offline
Joined: 27 Apr 2012
AndyUnfortunately there is no

Andy

Unfortunately there is no similarity between XML and XAP, but thanks anyway

John

AndrewJ
Offline
United Kingdom
Joined: 22 Nov 2012
Hi John,i dont really have

Hi John,

i dont really have any experience in xAP - i was reference Kevins comment above, i wondered if an XML parser could be adapter for xAP

"Messages you send to iServer are of two types 'command' and 'xAP' and each are enclosed in XML type tags"

Andy

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Writing an xAP parser is

Writing an xAP parser is pretty simple there are two available in source format for you to examine.  One written in C inside xaplib2 and one in LUA both are written from scratch by me.

I've not looked at a Java xAP parser but based on either of the code samples from above it wouldn't take long to sling one together.

Patrick has a java parser: http://patrick.lidstone.net/html/dev_tools.html

Having said that I rewrote his C parser so it would work on the livebox as his has LARGE memory requirements and was not suitable for embedded devices - HAH nor Arduino.  So your mileage may vary on his Java parser too. I've not looked as his source so I can't say for sure but if its anything like his C parser its  in need of some love.

I really have to get around to writing some Android xAP stuff.  Its definately on my do to list.

Brett

magill
Offline
Joined: 27 Apr 2012
Brett thanks for the

Brett
thanks for the pointers. I took fear of the "C" stuff and just went with my own messy parsing. Anyway I now have a working app on my Galaxy phone. It remotely controls my heating with boosts for the 3 zones. Unfortunately it is too customised and hard coded to be of use to anyone else, but I am happy to give guidance to anybody who is interested. I attach pic.
John

AttachmentSize
Galaxy.JPG 31.67 KB
AndrewJ
Offline
United Kingdom
Joined: 22 Nov 2012
Nice screenshot John, looks

Nice screenshot John, looks good i hope we can all make use of an Android app someday.

What version of the SDK did you create in?

magill
Offline
Joined: 27 Apr 2012
I developed it in "Eclipse"

I developed it in "Eclipse" on windows 7

Hardware Info