From: Bill S. <bs...@vi...> - 2000-05-11 21:08:46
|
Hi, Thanks for the response. I have a few more starter questions (if I may). First, if anyone is interested the protocol docs for the Compool unit are at http://www.compool.com/support/protocol.txt. The annoying thing about the protcol is that there is no ability to generate a 'turn on pool' command, one a 'toggle pool state' command. There is a heartbeat packet ever 2.5 seconds which gives you the current state of the equipment. So, to code a 'pool on' you must have received at least one heartbeat to know the current state and then send the 'toggle command' if the current state is off. So, with that new wrinkle, does extending Serial_Item still make sense? Is there an example of a serial device which generates traffic which is 'saved' automatically (e.g. not in response to some user action). I presume there is in the homebase and other controllers, I just need to dig a bit more. Thanks (again!) Bill > I started a new post as this is unrelated to the weather questions I had. > What is the recommended/preferred way of creating a new device/hardware > 'type' in the system. I want to create a class to interface MH with my > Compool pool equipment (Compool has a RS485 interface, I have there > RS485/232 adapter on order, and the protocol specification from > them). The > protocol lets me do things like set spa and pool temp and turn on/off > auxiliary equipment relays. > > I suspect I want to build ontop of the serial class, like the X10 > code does, > but from looking thru the various sources it's a bit unclear to > me where the best starting point actually is. Yep, extendin Serial_Item with an Compool.pm (or whatever) module, like X10_Item.pm does, should work well. You then would inherit the state, state_now, said, and set methods. If other methods make sense, just add them to your new module. Or you can just use Serial_Item directly, if you don't need extra methods. For an example, see mh/code/bruce/irman.pl |