Guy Lavoie Posted Tuesday at 02:09 PM Share Posted Tuesday at 02:09 PM 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. Quote Link to comment
larryllix Posted Tuesday at 02:21 PM Share Posted Tuesday at 02:21 PM 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 Quote Link to comment
Guy Lavoie Posted Tuesday at 04:33 PM Author Share Posted Tuesday at 04:33 PM 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. Quote Link to comment
larryllix Posted Tuesday at 04:53 PM Share Posted Tuesday at 04:53 PM 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. Quote Link to comment
Techman Posted Tuesday at 06:26 PM Share Posted Tuesday at 06:26 PM @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. Quote Link to comment
Guy Lavoie Posted Tuesday at 07:40 PM Author Share Posted Tuesday at 07:40 PM 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? Quote Link to comment
Techman Posted Tuesday at 07:49 PM Share Posted Tuesday at 07:49 PM (edited) 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 Wednesday at 01:33 AM by Techman Quote Link to comment
Guy Lavoie Posted Wednesday at 12:18 AM Author Share Posted Wednesday at 12:18 AM 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. Quote Link to comment
Techman Posted Wednesday at 01:46 AM Share Posted Wednesday at 01:46 AM @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. Quote Link to comment
Javi Posted Wednesday at 01:03 PM Share Posted Wednesday at 01:03 PM 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. 1 Quote Link to comment
Guy Lavoie Posted Wednesday at 01:11 PM Author Share Posted Wednesday at 01:11 PM 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! Quote Link to comment
IndyMike Posted Wednesday at 06:10 PM Share Posted Wednesday at 06:10 PM 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. 1 Quote Link to comment
paulbates Posted Wednesday at 08:33 PM Share Posted Wednesday at 08:33 PM (edited) 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 Wednesday at 08:39 PM by paulbates Quote Link to comment
IndyMike Posted 13 hours ago Share Posted 13 hours ago 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.