No way to detect/trigger on scene events in IoX?

[Guy Lavoie]

I'm a bit surprised that there seems to be no way to detect scene commands as a way to trigger programs. This would be handy to have the controller "participate" in a scene and control additional, non Insteon devices when a scene command is initiated by a device. Is this a limitation of Insteon (ie: can't have the PLM as a responder)? 

Also, is there a workaround I could reasonably use? One possibility would be to detect the status of a device that is only controlled by a scene, and never as an individual device. But that isn't always the case. 

[larryllix]

I'm a bit surprised that there seems to be no way to detect scene commands as a way to trigger programs. This would be handy to have the controller "participate" in a scene and control additional, non Insteon devices when a scene command is initiated by a device. Is this a limitation of Insteon (ie: can't have the PLM as a responder)? 
Also, is there a workaround I could reasonably use? One possibility would be to detect the status of a device that is only controlled by a scene, and never as an individual device. But that isn't always the case. 

If really needed I would write a program to detect several devices' ranges and consider True as the scene being activated.

My method would be to define a state variable with a program that detects the variable to be non-zero and controls the scene with that.

Now you can detect the state of the variable and turn it on and off via the variable. Of course this doesn't work for controls done outside of your ISY box. The program mentioned above would though.

Remember levels are not always reported as exact numbers so a range of detection is required fir each device.

Sent from my SM-S711W using Tapatalk

[Guy Lavoie]

Yes, that's the "guess from responder's status" method, which might be good enough if the devices are only set to those levels by the scene. I'm also thinking of using a few spare lamp modules without loads that are mostly strategically placed as signal repeaters/bridges for that purpose. Enlist one into a scene and look for it's status change as a program trigger.

It would still be interesting to know why direct detection of scene commands isn't or can't be done.

[larryllix]

15 minutes ago, Guy Lavoie said:

Yes, that's the "guess from responder's status" method, which might be good enough if the devices are only set to those levels by the scene. I'm also thinking of using a few spare lamp modules without loads that are mostly strategically placed as signal repeaters/bridges for that purpose. Enlist one into a scene and look for it's status change as a program trigger.

It would still be interesting to know why direct detection of scene commands isn't or can't be done.

First, scenes responders do not send out any acknowledgements. Only program commands get ACKed, so there is no way to even know if they were successful. or the device even exists.

Is another device sends out a new scene no monitoring would know about it without a distinct new query for status. Scenes were only ever meant to be a one way comm. I don't use them hardly at all, anymore. However most of my lights are WiFi bulbs.

There is likely a complex way the PLM could tell ISY when a device has been fiddled with but it was never implemented due to too many errors that could occur.

[Techman]

@Guy Lavoie

You can verify the integrity of a scene by running a scene test on a particular scene. Right click on a scene, then click on scene test. 

[Guy Lavoie]

Oh yes, that and other test/troubleshooting features are really handy, like the ability to run the "then" portion of a program by itself. Well thought out.

Back to triggering on scenes... I do notice that it's possible to add non-Insteon devices to scenes. I see it for X10 and Zwave devices. I'm only able to add a X10 device as a controller (adding as a responder tries to set it and gives an error). I haven't test it, but this is something we could also already do (trigger a scene command) with a program. More interestingly, if I add a Zwave device to a scene, it allows adding it as a responder, and does respond to the scene on and off commands. We know that Insteon cannot talk to Zwave... so the Eisy is definitely receiving the scene command and is able to do something in response such as control a Zwave device... but not trigger a program. Could this be added as a new feature?

[Techman]

If you want to trigger a program when a scene changes state, you could select a device in a scene and have a program trigger when that device changes state.

Edited September 18 by Techman

[Guy Lavoie]

4 hours ago, Techman said:

If you want to trigger a program when a scene changesa state, you could select a device in a scene and have a program trigger when that device changes state.

Yes, if it's a device that's only ever controlled by a scene, as discussed above.

[Techman]

@Guy Lavoie

"so the Eisy is definitely receiving the scene command and is able to do something in response such as control a Zwave device... but not trigger a program"

The eisy doesn't know the state of a scene, only the state of the devices within a scene, as a scene does not report its state to the eisy.  A scene can function without the eisy, i.e. if the eisy was disconnected, the devices that are members of a scene would still function as a unit. If you had several devices in a scene as controllers/responders and one of the devices were turned on or off the other members of the scene would respond accordingly.

I'm not sure what it is that you're trying to do.

 

[Javi]

Scenes do not have a status so the Program Status condition will not work.  Scenes do not have a physical control (i.e. is switched on/off) so Program Control condition will also not work.  Scenes accept commands (on/off/etc), which is not the same as Control (physical switching).

The same can be achieved by adding the Scene's Controllers to the Programs if Condition.

[Guy Lavoie]

11 hours ago, Techman said:

@Guy Lavoie

I'm not sure what it is that you're trying to do.

 

Well, just add more non-Insteon functionality when a scene is triggered. For sure, scenes don't have states, but they do have on/off control events, which is what I'd like to be able to test for. The Eisy is in fact executing a hidden program of sorts when it sees the scene control command (both on and off) and controls the zwave device as I mentioned in my test above.

I looks like the design philosophy for multiple action events is to have your initial event trigger a program, which can then initiate a scene along with other actions, so it's always possible to work around it that way. It's just that some types of macros (especially those that involve lighting) are more easily thought of in terms of triggering a scene. It might be because I'm just getting familiarized with keypadlincs at the moment! 

[IndyMike]

This discussion has been going on since scenes were implemented by Smartlabs.  The bottom line is Insteon does not support either Scene "Status" or "control states" and creating an architecture for this has been LOW PRIORITY for UDI.

 

 

One workaround that I have found is to use the Home Assistant integration for the ISY.  Home Assistant treats scenes as "switches" or "relay devices".  They are either ON or OFF.  

Curiously, I noted that Home Assistant shows scenes as active (ON) if ANY scene member has a Level > Off.  Conversely, all scene members must be Off for a scene to be shown as Off. 

I use this functionality for triggering programs on Home Assistant.  I seriously doubt that Home Assistant is divining the scene status on it's own.  Unfortunately, we don't have access to the information on the ISY platform.  Seems a little ridiculous, but there are far worse things in life.

[paulbates]

2 hours ago, IndyMike said:

Curiously, I noted that Home Assistant shows scenes as active (ON) if ANY scene member has a Level > Off.  Conversely, all scene members must be Off for a scene to be shown as Off. 

Thanks Mike So it sounds like this can be replicated in iox programs in a scene of Insteon devices:

scene1 contains 3 switches in this example

If
  Status switch 1 is (on or >0)
 Or Status switch 2 is (on or >0)
 Or Status switch 3 is (on or >0)
Then
   $scene1 = "1"
 

... then programs function off of $scene1, or other actions. And a converse version of the program to turn it off using "and"s and setting $scene1=0

I see why it is that way, and don't know how else it could be approximated

Edited September 18 by paulbates

[IndyMike]

Thank you Paul.  I am familiar with the switch monitoring technique.  I've been using it since my first ISY26 back in 2007.  It most certainly does work.  

The technique allows me to monitor each floor of my house (1st, 2nd, basement) and display the status on keypads so I can turn monitor/turn off sections of the house as I am leaving or going to bed.

It is also, unfortunately, very easy to break.  Devices moving in/out of scenes, devices being replaced by dissimilar devices, naming issues all contribute to broken status programs over the years.  With IF statements of 25 to 75 devices, it's easy to miss things.

This maintenance issue could be avoided if we had access to the scene state (on/off).  Somehow the ISY is communicating this information to Home Assistant (very nicely). 

As @Guy Lavoie stated, this is a feature request - not a problem to be solved through a work around.  

[Guy Lavoie]

This has a happy ending! From reading and searching, I discovered the plugin called "Virtual" which seems to be exactly there for this purpose. This forum reply will also help anyone looking for this functionality in the future. Virtual allows you to create virtual switches (and other devices) which can then be added as responders to scenes. Turn on a scene and the virtual switch turns on too, and same for off. Then you can use the virtual device in a IF statement just like an actual device. Because the device only exists as a responder for the scene, no need to "guess" the status of several devices as suggested earlier.

Having this capability helps maintain the optimum failure mode for an Insteon setup, since Insteon is peer to peer. So if the eisy/PLM/whatever ever fails, the generic scene will still function, and only the additional functionality provided by the eisy will be lost. This is different than relying on eisy to launch the scene just because you also want added functionality in a program.

[larryllix]

10 hours ago, Guy Lavoie said:

This has a happy ending! From reading and searching, I discovered the plugin called "Virtual" which seems to be exactly there for this purpose. This forum reply will also help anyone looking for this functionality in the future. Virtual allows you to create virtual switches (and other devices) which can then be added as responders to scenes. Turn on a scene and the virtual switch turns on too, and same for off. Then you can use the virtual device in a IF statement just like an actual device. Because the device only exists as a responder for the scene, no need to "guess" the status of several devices as suggested earlier.

Having this capability helps maintain the optimum failure mode for an Insteon setup, since Insteon is peer to peer. So if the eisy/PLM/whatever ever fails, the generic scene will still function, and only the additional functionality provided by the eisy will be lost. This is different than relying on eisy to launch the scene just because you also want added functionality in a program.

Does this "virtual" respond to external devices initiating a scene, say from a Switchlinc dimmer button press?

That was always one of the problems with attempting to detect the status of a current Insteon scene. Perhaps another Switchlinc sends out a different Insteon scene command that modifies one of the devices to a different level?

I believe these reasons may be why a status flag has never been successful to detect whether a scene is still intact. They are not binary statuses with just True and False....sort of.

[Guy Lavoie]

1 hour ago, larryllix said:

Does this "virtual" respond to external devices initiating a scene, say from a Switchlinc dimmer button press?

That was always one of the problems with attempting to detect the status of a current Insteon scene. Perhaps another Switchlinc sends out a different Insteon scene command that modifies one of the devices to a different level?

I believe these reasons may be why a status flag has never been successful to detect whether a scene is still intact. They are not binary statuses with just True and False....sort of.

Yes it does. I tested it by adding the virtual switch as a responder to a simple "3 way" circuit scene. I press the slave switch to turn on the light, and the test program looking for the scene "on" command sets a variable. Now you can add anything to an Insteon initiated scene, allowing true macros. Imagine starting up your home theater, lighting and all, from a button on a keypadlinc or a mini remote. It all becomes possible. Or a good night routine that also locks the doors, etc.

[IndyMike]

@Guy Lavoie, nice find and good job realizing the possible applications.  This is what happens when a new set of eyes looks at an old problem.  Rather than enumerating all the ways the problem can't be solved, the new eyes provide a solution.

If I could figure out a way of running this on my ISY994, I'd be all over it.  I guess it's one more vote for upgrading to the Eisy...

[Guy Lavoie]

1 hour ago, IndyMike said:

If I could figure out a way of running this on my ISY994, I'd be all over it.  I guess it's one more vote for upgrading to the Eisy...

Well one workaround is if you have otherwise unused physical modules. For example I have two Lamplincs (that I obtained when buying a lot of used devices) with nothing plugged into them. They're placed to act as signal boosters/bridges. You can add those to a scene just so that your ISY994 can track their status as triggers. That's the thing with Insteon, you need to turn on "something" by establishing a scene link. The aptly named "Virtual" plugin just makes that easier if you have no spare devices. 

[carealtor]

40 minutes ago, Guy Lavoie said:

Well one workaround is if you have otherwise unused physical modules. For example I have two Lamplincs (that I obtained when buying a lot of used devices) with nothing plugged into them. They're placed to act as signal boosters/bridges. You can add those to a scene just so that your ISY994 can track their status as triggers. That's the thing with Insteon, you need to turn on "something" by establishing a scene link. The aptly named "Virtual" plugin just makes that easier if you have no spare devices. 

Before the Virtual plugin came along I was doing this with an unused keypad.  This gave me 8 virtual switches in one physical device.

[larryllix]

I am not sure either of these techniques will work for many situations though.

If I add a spare device or a pseudo device to a scene and turn it on, and then rest the level of one (or more) device(s) with another scene with the monitoring techniques actually see the original scene is not in effect anymore? With the spare Insteon device, I know it will into indicate properly, but with the pseudo device inside ISY, who knows how many smarts they put into it?

[IndyMike]

10 minutes ago, larryllix said:

I am not sure either of these techniques will work for many situations though.

If I add a spare device or a pseudo device to a scene and turn it on, and then rest the level of one (or more) device(s) with another scene with the monitoring techniques actually see the original scene is not in effect anymore? With the spare Insteon device, I know it will into indicate properly, but with the pseudo device inside ISY, who knows how many smarts they put into it?

This is precisely the thinking that led to where we are now.  We could never agree on what constituted the status of a scene.

In trying to please everyone, UD did nothing - and pleased no one.  If they had tried something, it would have been a starting point that could have been built upon...  

I am quite pleased by the scene status that HA currently gives me.  If I upgrade my ISY994, I will try the Virtual plugin.  I'm quite sure I could find applications for it.  

[larryllix]

30 minutes ago, IndyMike said:

This is precisely the thinking that led to where we are now.  We could never agree on what constituted the status of a scene.

In trying to please everyone, UD did nothing - and pleased no one.  If they had tried something, it would have been a starting point that could have been built upon...  

I am quite pleased by the scene status that HA currently gives me.  If I upgrade my ISY994, I will try the Virtual plugin.  I'm quite sure I could find applications for it.  

It may have been slow to come (as most UDI improvements) but the pseudodevice was an improvement made by UDI after much discussion over the years. Perhaps they just don't brag enough when they produce updates?

However, it still doesn't solve all the scene monitoring possibilities that I can foresee. Now you have me interested to experiment with the technique (now that I am aware of it). I do not use many Insteon Scenes anymore, now that my lighting is almost all WiFi, ISY programs, and three MS IIs with buggy firmware in them.

[Guy Lavoie]

Well I prefer to see scenes as a control event (trigger), not as a status. ie: launching a macro. Homes aren't static environments. In fact the program editor would need to offer conditional scene commands only under the "control" condition. Having it available in programs just allows more possibilities, some of which could also involve wait statements, such as stepping through a sequence of IR commands to turn on a home theater. Arming an alarm system could also be a scene, that includes shutting off or disabling things. Lots of possibilities.

[carealtor]

IMHO, a Scene should be Executed (turned "on" if you will) and nothing else...  Launching a macro, as @Guy Lavoie said.  Controlling a bunch of things together (on, off, dim, etc) is a Group.  The beautiful thing about IoX is that you can do both/either with the Scene functionality.  It's up to us how we use it.

Edited Friday at 04:27 PM by carealtor
typo