Re: Developing Embedded xAP Devices

["ukusaconsulting" <yahoogroupskh@xxxxxxxxxxxxxx>]

Sorry Neill - it looks like your original message got clogged up
somewhere, anyway here's some thoughts related to how I do this within the
embedded xAP gateway.

--- In xap_automation@xxxxxxx, "nwemail27" <nwemail27@...>
wrote:
>
> Hi All,
>
> I'm developing some hardware that I would like to make xAP compatible.
> So from an embedded perspective, what are people typically decoding in
a xAP message.
> I.e.
> 1. Do you look for and validate the "xAP-header" line of the
message?

Yes

> 2. By the way, how many different header lines are there? I.e. I think
the "xAP-Heartbeat" is one.

Just those two, be aware that case can vary however and some xAP messages
have a preceeding CHR(10) and some don't

> 3. Actually, what is this line called? Header of the Header :-)

Header name

> 4. What part of the header message do you normally pay attention too?

That depends on the role of your hardware. What messages do you need to
recognise and what do you respond to ? Specifically do you only listen to
certain other devices or schema, and do you only respond to messages
targeted at yourself or all messages.

> 5. Do you normally just use the UID field as an address or do you also
attempt to validate the target.

Bear in mind that in messages being sent TO another device the UID of the
recipient is not present so UID recognition can only be used for an
originating device. So the 'target' you mention above can't be validated.  
You cannot send target=<UID> as that breaks wildcarding. If you can
validate on the source address I strongly recommend you do.

I do however use UID's for identification because I am so short of memory
space and also because the HomeVision hardware that I attach to can only
hold 16 character names for its devices. Hence to support xAP devices they
are entered by UID in the HomeVision software.  This is sufficient for me
to identify messages from the devices however if I want to send messages to
them (target=) then I need to use the full address. I do this (for BSC) by
a reverse lookup type arrangement by listening for heartbeats and then
querying all the I/O on that device for the full name. This allows all
addresses to be known within one minute of startup.

> 6. What about wild cards? Do you handle them?

I fully resolve wildcards for any messages targeted at me.  I do not need
to resolve wildcards for devices I am listening to because I perform no
'eavesdropping' function in my gateway.  I only need to listen to messages
from other devices, not messages sent TO other devices.

> 7. What about the class field? If the address/target is correct do you
then ignore the class?

No - you definitely need to validate the class.

There's a couple of approaches here, based on what you're listening to and
what messages might be targeted at you - eg do you respond to a xAPBSC.cmd
message targeted at yourself ?

If you are tracking devices say via BSC then you can immediately filter
based on UID and class=xapbsc.event and class=xapbsc.info which is all
pretty fast as there are no wildcards.  If you are eavesdropping and
therefore need to validate a target= then it could be wildcarded and
therefore I would recommend filtering on class= first as wildcarding is
more processor intensive and requires long strings.

To validate messages targeted at you - again I would pre filter based on
class (and maybe the presence of a target line) and then if these match you
need to validate the target=line against your address. This maybe
wildcarded of course.    Wildcarding support is not essential but is
strongly recommended.

I also validate the body header but that is less necessary.  One thing
about BSC is that there can be several bodies within one xapbsc.cmd message
- ie several coincident commands.   The easiest way to handle this is to
loop through the bodies treating each one as a separate subsequent message
with the same xAP header.

Also bear in mind that if you are implementing BSC and supporting
xapbsc.cmd that there is an ID= field within each body that needs to be
validated against the sub address portion of the UID.  IT is effectively
another part of the wildcard matching .  It is simple however in that it is
either ID=* and therefore can be ignored or it is ID=XX and will be an
exact match.


>
> I know in an ideal world, we would decode and validate every response
but in an embedded device there is only so much programming space and
static memory space.

Tell me about it  :-)
UID's help substantially especially if you are implementing BSC.

I have found that the speed of embedded is well able to process xAP
messages - indeed the PIC based xAP Netiom can process messages faster than
almost any xAP device/application I know.
When sending messages do be considerate and pace outgoing messages say
100mS apart to avoid flooding other devices.   UDP buffer space is very
sparse for embedded designs.

What language are you coding in btw ?


K


> Regards,
>
> Neil Wrightson.
> Skype : Neil_Wrightson
>




------------------------------------