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.

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.