Thanks Eloy & Kevin,

  So it looks like to have local control of a multi-way switch group, both are needed;

  - A scene that has all controllers and responders.
  - tie_event code on each object that calls a subroutine to sync the scene.

So using a combination of both of these, everything now works; I have local syncing of the switchlinc and micro on/off device and when I set (through MH) the state of one of the scene members.  All scene members are then set to that state.  Seems a little convoluted, but it does make sense.

Does this sound like a terse ‘official approach’ to controlling multi-way devices?

 - link all multi-way switches as controllers and responders of each other.
 - verify that all devices work, and reflect the state of the item when turned on by other controllers. ie Turn on switch A and switch B should show as ON.
 - link each device to the MH PLM
 - add each device as an insteon item in the items.mht file. (Optional, make all but one device hidden so that the web interface isn’t cluttered)
 - create a group scene, add each device and the scene as controllers and responders of each other.
 - add a tie_event action to each item in the multiway group, and add the sync subroutine in usercode: 

$light->tie_event('sync_multiway($light, $myscene)'); # noloop
# Repeat the line above for all controllers in scenes.
# Every time a switch is toggled locally, or every time you run
# get_status or on receipt of remote activations, also update the
# scene containing the light to keep them in sync.
sub sync_multiway
    my ($ref_light, $ref_scene) = @_;
    # avoid unnecessary traffic, like a get_status where status hasn't changed.
    if ($ref_light->state_changed) {
        print_log “Local Sync: sync_multiway called for state_changed on ".
            $ref_light->get_object_name." to ".$ref_light->state." for ".
            $ref_scene->get_object_name." set multiway in 1sec";
        # delay is to avoid collisions. In case we're in this code path
        # due to a remote toggle instead (you pushed the switch), that switch
        # could already be running a scene and you don't want to conflict with it
        # (for local state changes, this is not an issue).
        $ref_scene->set_with_timer('', 1, $ref_light->state);

On Jan 20, 2014, at 7:21 PM, Eloy Paris <> wrote:

On 01/20/2014 06:04 PM, Kevin Robert Keegan wrote:

On Mon, Jan 20, 2014 at 12:03 PM, H Plato <
<>> wrote:

   Stupid question, the scene members have 100% as their on state, i'm
   assuming turning off the scene just works, and i don't have to
   create 0% scene_members, correct?


Indeed. I tripped on this a long time ago.

   I'd also need to add the actual scene as a controller and responder,
   so i'll have 6 scene members for this light:

   Scene_member, garage_light, garage_scene, 100%, 0.1s
   Scene_member, garage_light, garage_light_inside, 100%, 0.1s
   Scene_member, garage_light_inside, garage_scene, 100%, 0.1s
   Scene_member, garage_light_inside, garage_light, 100%, 0.1s
   Scene_member, garage_scene, garage_light, 100%, 0.1s
   Scene_member, garage_scene, garage_light_inside, 100%, 0.1s

Here is where you might discover a hiccup with this option.  I don't
think that state of the scene can be updated by a device.  I haven't
tried this, but it may not work, I would be interested to know what you

Right, as far as I know a device cannot update the state of a scene in 
MH. For this you can use the tie_event() trick mentioned in the INSTEON 
scenes page in the wiki.


Eloy Paris.-

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
To unsubscribe from this list, go to: