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)