The usual workaround has been to use the Virtual plugin to create a device that only gets turned on or off by scene commands, to detect that a scene trigger has occurred. Would it be possible to add a "If Scene <scene name> ON/OFF" command to make this directly detectable as a Control event, to then do other actions, etc? It sure would make programming more direct, and faster because it would avoid needing to detect the status change of the virtual device, etc. It certainly would fill a hole in the suite of programming commands.

The issue is groups and scenes have no status, and each scene (controller > responder links) within a group may perform a different action (e.g. https://wiki.universal-devices.com/ISY994i:INSTEON_Device:FanLinc-KPL_FanLinc_KeypadLinc_Configuration#Firmware_5.x) This leads to confusion about what is "on". Both UDM and eisy-ui provide and estimate/mean status of a group, but this is equally frustrating to some users as it leads to states were the scene appears "on" but the controller is off, e.g. when a non-controller responder responds to a physical event or command from another scene.

The simplest approach I've seen is to use the status of the most prominent indicator in the group e.g. one of the controller. In the case of the fan link example this would be the keypad button, in a lighting scene it would be any one of the controllers.

3 hours ago, Javi said:

The issue is groups and scenes have no status, and each scene (controller > responder links) within a group may perform a different action (e.g. https://wiki.universal-devices.com/ISY994i:INSTEON_Device:FanLinc-KPL_FanLinc_KeypadLinc_Configuration#Firmware_5.x) This leads to confusion about what is "on". Both UDM and eisy-ui provide and estimate/mean status of a group, but this is equally frustrating to some users as it leads to states were the scene appears "on" but the controller is off, e.g. when a non-controller responder responds to a physical event or command from another scene.

The simplest approach I've seen is to use the status of the most prominent indicator in the group e.g. one of the controller. In the case of the fan link example this would be the keypad button, in a lighting scene it would be any one of the controllers.

Yes, I know. We've discussed this a few times before and the "no scene status" thing has been mentioned. But I'm only looking for the control event: that a scene on or scene off command has been issued or received. IoX already does that internally, allowing (for example) zwave devices to be included in an Insteon scene, What I'd like is to have that event available for an "If" statement, to then do other things, use Wait statements, set variables, etc.

If I wanted to track the status of a scene, I'd do that as you say, with And statements, variables, etc.

1 hour ago, Guy Lavoie said:

Yes, I know. We've discussed this a few times before and the "no scene status" thing has been mentioned. But I'm only looking for the control event: that a scene on or scene off command has been issued or received. IoX already does that internally, allowing (for example) zwave devices to be included in an Insteon scene, What I'd like is to have that event available for an "If" statement, to then do other things, use Wait statements, set variables, etc.

If I wanted to track the status of a scene, I'd do that as you say, with And statements, variables, etc.

There is a slight misunderstanding about scenes and groups, we use the term scene for both but they are very different. Each group of devices can have multiple one to many scenes (a single-controller to multiple-responders). To trigger a program the condition would still rely on the controller's On and Off not the groups (as a group is a collection and doesn't have controls/status).

For a group with a single switch, where the switch is a controller and responder there are actually 2 scenes. The "A" scene where eisy is the singular controller, and the "B" scene where the switch is the singular controller. A distinction is eisy is not a responder in the "B" scene, the switch is a responder in the "A" scene, so eisy (the controller "A") is not updated in any way.

A Program it would need listen to each controller individually, controller "A" and controller "B". The controller for "B", the switch, is already exposed, "A" is not as this is triggered from self. This could just as well be triggered by variable or program (from self). It might be possible to expose eisy as a controller when "A" is triggered, but likely does not solve the problem.

The reason this works from the virtual switch is the virtual switch is a responder to both "A" and "B" scenes in the group where both scenes issue the same on commands. However if one scene was to issue the off command instead of the on command the virtual switch would be out of sync, or if the virtual switch was only a controller and not a responder there would be no status change (same as eisy-controller) and no control observed.