Jump to content

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


Recommended Posts

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. 

Link to comment
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

Link to comment

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.

Link to comment
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.

Link to comment

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?

Link to comment

@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.

 

Link to comment

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.

  • Like 1
Link to comment
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! 

Link to comment

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.

  • Thanks 1
Link to comment
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 by paulbates
Link to comment

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.  

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...