Re: Xap and homeseer

["Lehane Kellett" <g8kmh@xxxxxxxxxxx>]

Ian,
Good to see someone else working with the PIC.

I'm using the Modtronix boards - around =A345 each. My personal view is
that even at that price you can use them for everything - the costs of
developing anything else (especially in time) start to make it a no
brainer. I'm even using them as 4 button light switches since they are
cheaper than the badged commercial stuff. Same code as the LCDSwitch
but with no LCD attached. They've now been running a year and had only
one hiccup when we had a power glitch. If you want more info let me
know, though I'm out in Gujarat at the moment so don't have good
access to my servers (though FP works nicely over the VPN!).

You will need to filter the traffic bridged across from the Ethernet
to the RS-485 if you are running at something like 19k2 on the RS-485
side and have a number of xAP devices running in the place. You'll
probably want to keep a list of attached devices, including discovery
via received heartbeats on the RS-485 side, and filter on sending and
target nodes. Even then, a lot of traffic is wildcard targetted.

Lehane

--- In xAP_developer@xxxxxxx, "Ian Davidson" <ian@...>
wrote:
>
> Hi Kevin
>=20
> I am currently using a PIC18F8722 running at 40Mhz to develop with.
I use both 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 buffers 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 although 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.
>=20
> The parser does indeed start reading the message and stop as soon as
it knows it is not valid for itself. I still have quite a lot of work
to do on the parser but it is working and as time permits I'll keep
adding.
>=20
> 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 bus. 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 controlled 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 hopefully 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 think to
this approach and if it breaks any of the Xap protocols?
>=20
> Thanks
>=20
> Ian
>=20=20
>=20
>=20=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
>=20
> 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 ?
>=20
> 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.=20=20
This=20
> spreading of the periodic updates seems beneficial and I chose this
rate=20
> to cycle through all I/O every 10 minutes.
>=20
> 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
>=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.
>=20
> K
> >
> >=20=20
> >
> > Thank you
> >
> >=20=20
> >
> >=20=20
> >
> > Ian D
> >
> >=20=20
> >
> >=20=20
>=20
>=20
>=20
>=20=20
> Yahoo! Groups Links
>



=20