Dean Roddey Wrote:We are coming up on 4.2. I always prefer to leave things alone for a bit after a release, so that if issues come up (and they often do because all the folks that come on board after it's out will generally have different conditions and catch something not caught during the beta phase.) That gives me a chance to do small patches and fixes without splitting code base.
So I'll have some time to do some customization or drivers or or images or whatnot if anyone needs any.
Dean: I'm interested in developing a Zigbee based driver to run a few RCS thermostats. The basic driver commands follow much of the RCS 485 Serial driver in the system pack and are run via comm ports as in that protocol, but now I (we, err, perhaps you

need to assemble a hex based command/response parsing of Zigbee API packets. I have communicated with the thermostats by manually assembling hex packets with checksums, etc using Digi's packet maker
ftp://ftp1.digi.com/support/utilities/di...frames.htm. I have a little work to do to completely understand the packet structure (90% there), but the rest should be relatively straight forward.
The Zigbee devices with the thermostats are Digi Xbee Pro S2B 2.4 GHZ radios running API Mode 1 as Zigbee routers. I pulled a radio from another unit, and used a Sparkfun USB explorer board for a serial interface to configure it as an API Coordinator. This would be the setup to run the system, or perhaps via a USB dongle. I have done a LOT of playing with these in the past few weeks after acquiring a few off of Ebay. I contacted the seller who has around 200 of these units sitting around, and if we develop a driver he could offer them at a VERY good price to anyone interested here (I have no commercial interested in this, nor receiving compensation. Just passing along a good technology and a deal to others here.
So far they work pretty slick and I can run each thermostat independently by designating their 64 bit address, 16 bit network address. They respond to status polling commands as per the RCS protocol, but do communicate asynchronously when status changes occur (change in ambient temp, or keypad presses). These I don't need to capture, as the polling events will pick that up.
I've modified a CML driver or two here, but this might be slightly above my CML pay grade. Please PM me with your thoughts regarding. I have no idea of the cost to develop, so please be kind

.
Cheers,
Bugman