We can certainly do that, it would be easy to implement.  The question becomes, is it both more convenient and more user friendly to do it that way.  I wonder how many options like this would we like to add into the read_table_a.

There is also another option, going back to the PLM Scene structure.  The issue for Howard, and likely others, is that the state of a PLM Scene can only be changed from within MH, there is no way (absent tie events and set_receive) for a device to update the state of a PLM Scene.  This prevents us from using a PLM Scene as a master object that represents a series of "3/4 way switches."

Within MH there is a routine called set_linked_devices.  When you turn on a light from the light switch, the switch sends a message to MH.  When MH receives this message it looks through all of the links that you have defined in MH for that device.  MH then updates each device that is linked to the first device within MH to reflect what its real life state.  So for example, if I have a link from A->B defined in MH and synced on the devices.  When I press A, A sends a message to MH and B.  MH never receives any message from B notifying MH that B is now ON, but MH updates the "status" of B inside MH to ON because is "deduces" that B must now be ON.

Currently, this routine ignores PLM Scenes.  If you have a device linked to control a PLM Scene, MH will not update the status of that scene inside MH.  I can easily change this, but the question is, does this accurately represent what is actually occurring?  In order for this to work, the user needs to link not only the device to the scene, but also needs to define all of the relevant scene states on the device as well.  Let me explain.  If Scene_1 turns A, B and C on.  Then A needs to have the following links:

Simply linking A->Scene_1 will not do it.  If the user only does that, MH will represent Scene_1 as being ON even though B and C are not ON.  This could become a very long list for complicated scenes.

I was initially opposed to this idea because it had the potential for a PLM Scene to be out-of-sync with real life.  But then this morning I realized that we already have a similar behavior with keypadlincs.  You can program KPL_A to turn on B & C.  When I press KPL_A the light behind the button turns on and B&C turn on.  But I can also program B to turn on the light behind KPL_A as well.  In doing so, this will only cause the light on KPL_A to turn on, but will not turn on C unless I have defined the appropriate link from B->C.

Essentially, my proposal would treat PLM Scenes as a virtual button.  The status of the Scene could be turned on and off from a device.

What does everyone think?

(apologies for being wordy, this is an abstract concept and I wanted as many people as possible to understand it)

On Tue, Jan 21, 2014 at 7:56 AM, H Plato <hplato@gmail.com> wrote:
I've been thinking a little around this...it seems like the sync subroutine is somewhat generic -- when an item changes, just set the scene to the same state.

This question is more for the insteon gurus, would it make sense to incorporate this subroutine into the Insteon object and make it an option for the ICONTROLLER?  So something like;

#PLM Scene Controller  CtlNum,     Scene Name,          Group,       ,Options
INSTEON_ICONTROLLER,   10,         accent_scene,        All_Lights,     localsync

with the localsync option, then there would be a flag to add a tie_event('localsync($<member>, $accent_scene) to each item?  Might be beneficial for anyone who need this functionality to use a similar approach.  Just a thought, don't know if this adds massive complexity for a rare need.

On Mon, Jan 20, 2014 at 9:12 PM, H Plato <hplato@gmail.com> wrote:
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 <peloy@chapus.net> wrote:

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

On Mon, Jan 20, 2014 at 12:03 PM, H Plato <hplato@gmail.com
<mailto:hplato@gmail.com>> 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: http://sourceforge.net/mail/?group_id=1365