Re: UID, Source and Heartbeat Questions

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

twitty_davis wrote:
> Hi,
>
> Forgive me if I'm asking questions that have been answered somewhere
> else, I did search...
>
NP They always help others as well so ask away ...
> I have a few basic questions about the UID, source elements and
> heartbeats.
>
> The spec seems geared towards embedding xAP with a hardware device.
> I'm creating software and I'm not sure how to go about assignment of
> UIDs and sources.  I know that there are changes coming with the 1.3
> spec, but I don't think that they materially affect the questions.  I
> just want to make sure that I conform to whatever everyone else is
> doing or expects.
>
The bias towards embedded xAP isn't intentional - it's maybe over
emphasised only because embedded devices tend to be restrictive and
hence need special consideration and become the lowest common
denominator. PC based applications have enough resource to be able to
handle almost anything.
> I'm using a totally custom xAP stack and custom applications, all of
> which is written in Ruby, for those who are interested.  I would
> appreciate feedback and any suggestions as they relate to either the
> library or apps.
>
> 1) Since I'm developing software that will interface with a hardware
> device and send and/or receive xAP messages, the software could be
> deployed anywhere, the only thing I know is what kind of hardware it
> is intended to interface with.  All of my xAP Apps have a
> configuration file that allows the user to set the UID.  Currently I'm
> not really doing anything with it other than including it in my
> messages.  Should I be doing anything with it?  Perhaps validating and
> only processing messages that start with FF?  Should I try to do
> anything to control the sub-address?
>
The FF only gives an indication on whether the message was sourced on
the local network.  It's really to resolve issues where two separate
networks with their own devices and hence UID's become joined - which
could potentially cause UID conflicts if a network ID isn't included.

Allowing the user to set a UID is the norm - we don't have an official
UID allocation/arbitration system as yet - as most networks are user
manageable. However we do have proposals/intentions in xAP v1.3 to
recommend a way to calculate UID's based on a hash of your source
address and maybe even a standalone application that will perform this
for you  (like a DHCP server you ask it for your main application UID),
it will ensure there are no conflicts in the very unlikley case the hash
is not unique.

Can yuo expand on the sub address 'control' question ?
> 2) Regarding the source element - here I'm also allowing the user to
> define the source in a config file.  Currently I'm not doing anything
> to enforce anything here either.  Since I know that I'm the vendor and
> what the intended device is, should I only allow the user to define
> the instance and sub-address part of the source?  That seems logical.
>  Is there a standard for this?
>
Yes - you should fix the vendor and device name segments and leave the
rest configurable -although you may have preset sub address names should
you wish eg input.1 input.2 output.analog output.digital or something
> 3) Heartbeats - I understand the purpose of heartbeats and how they
> relate to the apps that are representing hardware devices, but I'm not
> sure about the applicability to some other types of apps.  My overall
> system architecture consists of a bunch of small xAP apps that send or
> receive messages, with a centralized controller or processor that
> listens for xAP messages, takes action upon them and could generate
> xAP messages.  It could also generate xAP messages as a result of
> other actions not related to receiving a xAP message.  For example it
> receives caller id message, looks up a friendly name in a database and
> sends a speech message.  Or it receives a trigger from an event
> scheduler or human interaction and sends a xAP message.  Should my
> controller send heartbeats?
Yes definitely .. it indicates to all other applications that it is
alive and well - and is the mechnaism by which a xAP hub builds it's
client connections.      It also permits tables to be built if required
that show mappings between UID's and source addresses, and following on
from that - if you use BSC , a form of endpoint discovery.
>  It uses heartbeats to "inventory"
> devices, but I'm not sure that it should send them, it's not
> representing a piece of hardware that can be removed or lock up or
> otherwise disappear.
>
Could the PC application not crash or the PC lose power ?   Also at some
later stage you might consider some redundnacy where a second duplicate
application acts as a 'slave' but steps in automatically should the
'master' fail.  Idratek do this currently with Cortex for example.
Alternatively you might implement another controller that might just be
a simple fallback  for certain functionality allowing limted interaction
between devices - for example a light and a switch should it notice your
more complex controlling application die.
> I based my Ruby library's functionality primarily on the Java library
> that I believe Patrick created, if not forgive me, but it was a
> relatively straight forward library.  It's been several years since I
> looked at it so I don't know if it's still available or if it's been
> enhanced.  But from some of the messages on these groups I get the
> impression that
> other libraries do quite a bit more than the message handling.  Is
> there any consensus on what a library should do?  My Ruby library does
> a few more things than the Java one, it has actual classes to support
> the different message schemas, but doesn't go any further than that
> and handling the sending/receiving via ethernet.
>
Let me leave that one for someone else as I haven't used the fuller
libraries....

Cheers K
> Thoughts would be appreciated!
>
> Thanks.
>
> Mick Davis
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>