The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Xap and homeseer


  • Subject: RE: Xap and homeseer
  • From: "Ian Davidson" <ian@xxxxxxxxxxxxxxxx>
  • Date: Sun, 22 Jul 2007 09:26:09 +0100

Hi Kevin

I am currently using a PIC18F8722 running at 40Mhz to develop with. I use
b=
oth serial ports, one to debug etc and the other connects to Tibbo
Ethernet=
module. The module is told to forward all UDP traffic on port 3639 to its =
serial port. I run both serial ports at 115200 baud both with 250 byte
buff=
ers and interrupt controlled. It performs quite well, if I enable debug
and=
capture the output even during the deluge from HS I only get two or three =
corrupted packets which is actually the Tibbo module feeding the PIC
althou=
gh it may be it can not get the data out quick enough at 115K although
that=
is its maximum baud rate. I just like things to be as reliable as possible=
and knowing once a minute this high volume traffic comes along the chances=
of a missed message happening due to it is quite high.

The parser does indeed start reading the message and stop as soon as it
kno=
ws it is not valid for itself. I still have quite a lot of work to do on
th=
e parser but it is working and as time permits I'll keep adding.

When I have progressed further I intend to split the development up. At
the=
moment the PIC board and Tibbo cost over =A350 which is far too much for a=
simple module. The idea is to use the PIC board and Tibbo to read the Xap =
messages and only if the vendor ID matches forward it onto a RS485 4 wire
b=
us. Then use some smaller PICS to read the RS485 bus and make some
lighting=
and appliance modules. I have already purchased some of these cheap remote=
controlled light and appliance modules. My aim is to turn them into Xap co=
ntrolled modules all linked via a RS485 bus connected to the main unit and
=
onto the network. It is likely to take a while as my time is limited but
ho=
pefully get there in the end. When the Xap code is written it would then
be=
easy to add on other things as and when I need them. I wonder what you thi=
nk to this approach and if it breaks any of the Xap protocols?

Thanks

Ian
=20

=20

-----Original Message-----
From: xAP_developer@xxxxxxx [mailto:xAP_developer@xxxxxxx] =
On Behalf Of Kevin Hawkins
Sent: 22 July 2007 05:00
To: Ian
Subject: Re: [xAP_developer] Xap and homeseer

Ian Davidson wrote:
>
> Hi All
>
>=20=20
>
> Slowly getting a little further with Xap, I now have my pic board=20
> sending H/beat and info packets and responding to xapbsc on/off=20
> commands via homeseer xap interface.
>
That's great - well done !
>
>=20=20
>
> I then added a level parameter to the pic device and re-detected it
in=20
> HS and assigned it again to bsc.
>
>=20=20
>
> I was impressed to find this time in the status screen of HS I had
the=20
> usually on/off and now also level control.
>
>=20=20
>
> However when I change the level with the tab on the status screen
only=20
> about 1 in 4 operations actually generate an xap message. (using
xap=20
> viewer watching messages from HS)
>
> Also when the message is generated sometimes it is the correct
level=20
> i.e. Level=3D10/100 but other times it may be Level=3D39/100 when I
had=20
> selected 70%?
>
>=20=20
>
> I can carry on with my programming for now but if anyone knows if
this=20
> can be fixed I would appreciate it.
>
>=20=20
>
> My only other request would be if the xap HS interface could send
out=20
> its info messages one at a time. At the moment I get 71 xapbsc.info=20
> messages in just under 1 second and this seems to happen every
minute.=20
> One message every few seconds would be ideal. if I watch the netiom=20
> this seems to send an info message about every 4 seconds. On a PC
this=20
> is not an issue but in a little PIC with limited memory etc it is
an=20
> awful lot to try to handle.
>
I'll leave the HS plugin Q's to James but remind me Ian - is this being=20
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=20
based and is one of the fastest xAP devices around both on receive and=20
transmit.  It is well capable of sending over 100 xAP messages per=20
second, which is far faster than most Windows based applications can=20
process.  And yes, the xAP Netiom throttles its periodic updates back to=20
the 1 every 5 secs or so I believe and in my C-Bus/HV gateway I send=20
mine at 2 or 4 per second IIRC as I have much more I/O to report.   This=20
spreading of the periodic updates seems beneficial and I chose this rate=20
to cycle through all I/O every 10 minutes.

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

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

K
>
>=20=20
>
> Thank you
>
>=20=20
>
>=20=20
>
> Ian D
>
>=20=20
>
>=20=20



=20

xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.