PeteK, I have a couple Questions: re: INSTEON

[ddamron]

PeteK, thought I'd ask this in the forum rather than an email so everyone can benefit

I've been doing a bit of research to see how to implement the PLM.

There seems to be a simple way to implement it with GSD & Ruby. (as far as I can figure)

from digging on the wiki, I found that bi-directional support can be added via ruby (correct me if I'm wrong)

and that all commands can be intercepted in ruby.

My question is:

Why would a person write a "Driver" (as you have done for the PLC) versus using Ruby/GSD?

At least for Insteon related devices, I can't seem to find a reason to create a "coded" driver. (command line driver like you have)

Just curious, and thanks again!

Dan

[PeteK]

Ruby/GSD works well for simpler devices, but it becomes quite limiting when more complex behavior is needed.  The Insteon driver needs to do some work to 'manage' the system, such as using an asynchronous thread to monitor light/sensor condition, create/manage goups and handle linking.  This requires a driver that is more flexible than that allowed by the Ruby/GSD interface.

[ddamron]

Gotcha!

Thanks again!

[ddamron]

wait a minute, hmmm let me think about this aloud...

Manage Linking:

I initiate linking by sending:
02 64 03 01

then I press and hold a device (slave)
I get back 02 53 01 01 08 9B 62 04 00 20

broken down I see that:
02 53 = All Linking Completed
01 = Controller (vs 00 slave device or FF deleted )
01 = ALL Link Group Number
08 9B 62 = ID of device linked to
04 = Device Category (only if controller)
00 = device Subcategory (only if controller)
20 = Firmware version | FF (if slave)

with this information, I have all the information I need for a particular device.
Device Category 0x04 = Irrigation Control
Device SubCat 0x00 = Compacta EZRain Sprinkler Controller

(I'm doing this as I type using docklight...)

I should be able to create a new child device in linuxmce for extended configuration (zones, etc)

wouldn't this actually help with integration?

re: Groups
we can get all the Group information asynchrounously by spidering all the device links.. any one we don't recognise, we can add to the IM's database programatically, then continue..

the PLM doesn't have SALad, so that section is ignored / not needed.

Thanks for your input

Dan

[PeteK]

Using button linking, every device you link to gets put in the same group.  I.E. if you have 50 lights, they all get put into group 1.  So your only option at that point is to send a group command to turn on/off all the lights or to address each one individually, causing the 'ripple' delay i'm seeing with, say the current Z-wave implementation.  In order to properly handle scenarios and change lights simultaneously, I think the best solution is associate a group with each scene.  Then the PLC can send a single group on command when the scene/scenario is selected and have all the lights respond immediately.  This requires the ability to link with different group numbers.  The only way this is supported in current devices is through writes to Lamplinc/Switchlinc EEPROM.  This is kind of a cumbersome process that requires the driver to read current link settings in the device and add a new link record at the end of the group heap in each devices EEPROM.  I wrote an extension to the low-level driver I'm using to handle this.  Each device can be linked multiple times, to be a part of several scenarios, with different levels and ramp rates for each scenario.


Edit: corrected default group number

[ddamron]

Thanks again for your reply...

I understand now... I think... LOL

I'll re-read your reply again in about 5 mins, got my brain wrapped around insteon messages right now..