Re: Xap and homeseer

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Ian Davidson wrote:
>
> Hi All
>
>
>
> Slowly getting a little further with Xap, I now have my pic board
> sending H/beat and info packets and responding to xapbsc on/off
> commands via homeseer xap interface.
>
That's great - well done !
>
>
>
> I then added a level parameter to the pic device and re-detected it in
> HS and assigned it again to bsc.
>
>
>
> I was impressed to find this time in the status screen of HS I had the
> usually on/off and now also level control.
>
>
>
> However when I change the level with the tab on the status screen only
> about 1 in 4 operations actually generate an xap message. (using xap
> viewer watching messages from HS)
>
> Also when the message is generated sometimes it is the correct level
> i.e. Level=10/100 but other times it may be Level=39/100 when I had
> selected 70%?
>
>
>
> I can carry on with my programming for now but if anyone knows if this
> can be fixed I would appreciate it.
>
>
>
> My only other request would be if the xap HS interface could send out
> its info messages one at a time. At the moment I get 71 xapbsc.info
> messages in just under 1 second and this seems to happen every minute.
> One message every few seconds would be ideal. if I watch the netiom
> this seems to send an info message about every 4 seconds. On a PC this
> is not an issue but in a little PIC with limited memory etc it is an
> awful lot to try to handle.
>
I'll leave the HS plugin Q's to James but remind me Ian - is this being
received over a serial interface by your PIC or Ethernet ?

If it's Ethernet then it's quite interesting that the xAP Netiom is PIC
based and is one of the fastest xAP devices around both on receive and
transmit.  It is well capable of sending over 100 xAP messages per
second, which is far faster than most Windows based applications can
process.  And yes, the xAP Netiom throttles its periodic updates back to
the 1 every 5 secs or so I believe and in my C-Bus/HV gateway I send
mine at 2 or 4 per second IIRC as I have much more I/O to report.   This
spreading of the periodic updates seems beneficial and I chose this rate
to cycle through all I/O every 10 minutes.

A good way to handle high volume traffic is to use some aspect of the
message header (class or target perhaps) to drop messages asap.  I for
example drop all untargeted messages as well as non BSC ones. This is a
debatable approach as it means I need target=>:> or similar to hear a
message intended for everyone cf with others who accept all messages
without a target line as the same .  As I only respond to BSC (and BSC
requires a target line) this seems acceptable though.

An exception is responding fast to a xAPBSC.query (even when sent to
vendor.device.instance:> ie everything) as this can be used for initial
synchronisation and discovery.  I don't think developers should just
send them as fast as possible as that is just asking for some to be
missed but certainly maybe around 10 - 20 per sec I think is to be
expected.  Some devices have bucketloads of I/O to report - eg a
HomeVision has perhaps 1000 endpoints so that would take well over a
minute even at that rate.

K
>
>
>
> Thank you
>
>
>
>
>
> Ian D
>
>
>
>