Scene State - is there a way to check

[mjcumming]

Since the ISY knows that status of all devices, is it possible to determine the state of a scene?

Ie is the Scene On, Off or Ambiguous (some devices on/off or at a different level than programmed).

 

[paulbates]

Scenes are one way broadcasts and can be to many devices.  Because that's how Insteon designed scenes, no, its not possible to know scene state directly.

You can approximate it by writing a program like: 

If 

            'device a' is on
   and 'device b' is on
   (etc)
Then
    (no statements)

else
    (no statements)

You can check for the above program to be true (in another program's if), as a way to approximate it. I would not put more than 3 - 4 devices in this program though

Paul

[mjcumming]

Hi Paul

I am aware of how scenes work and that isy doesn't definitely know the state of scene without polling the members of the scene. However, the isy does keep track of the state of all devices and when a device in a scene is seen to change state, the isy would know if all the devices in that scene are in the correct state or not.  This would make it very easy to keep keypadlinc buttons in a state that reflects the scene rather than programs with long if statements....

[lilyoyo1]

25 minutes ago, mjcumming said:

Hi Paul

I am aware of how scenes work and that isy doesn't definitely know the state of scene without polling the members of the scene. However, the isy does keep track of the state of all devices and when a device in a scene is seen to change state, the isy would know if all the devices in that scene are in the correct state or not.  This would make it very easy to keep keypadlinc buttons in a state that reflects the scene rather than programs with long if statements....

That's where the if statements come in. It allows you to change the state of the kpl based on specific conditions you set forth. 

Due to the nature of scenes, it would be impossible for the Isy to ascertain on its own what a person wants. For example, a room has 3 lights. Turning button "B" on turns on all lights. That would be a scene. However, what if the lights were all turned on individually? That would not be the scene.

While the Isy does keep track of everything, it doesn't know what your intentions are unless you tell it what you want to happen hence the "if" statements. Programs is what allows for customizing your scenes.

[mjcumming]

agree, but the isy could generate an event that reflects the state of scene. this would greatly simplify programming.

[lilyoyo1]

1 minute ago, mjcumming said:

agree, but the isy could generate an event that reflects the state of scene. this would greatly simplify programming.

There are too many variables at play when it comes to devices to ensure everything is kept up properly. If anything, it would require constant polling which would impact system performance. The likelihood of detrimental behavior increases exponentially the larger the install.

[mjcumming]

I disagree. There is no need to constantly poll. In most instances, the ISY will know the state of all linked devices. Its not perfect as sometimes the ISY might not see local changes if a message gets dropped. But the ISY will have in general an excellent idea of the state of the devices, it knows how the scenes are programmed and therefore could generate an event that represents what it thinks is the state of the scene.

[paulbates]

The suggestion I provided would require only one 'scene state program' per scene, to most closely approximate that scene's status.  I've used it and typically include a few key devices that are only on together when the scene is activated. I have scenes with 20+ devices and only need 3 or 4 to make this work.

Those "scene programs" T/F state would be used on the If clause of other programs.... like an event. 

Unless you are doing this for dozens of scenes, its not that difficult or have high impact on the ISY, the latest ISY state would be queried as you mention.

Maybe this was a feature request and I misunderstood.

 

[lilyoyo1]

There can be a multitude of scenes involving the same exact devices in a single room let alone the whole house. All of which can be setup in different ways as well as controlled by different devices. 

Less programming is great for any and everyone. However, ease of use/less work doesn't necessarily mean it's better. In the case of most systems, the use of programs actually gives more capabilities which allows one to dial their system in perfectly.

 

[paulbates]

Right, but no details were provided and the question posed "is it possible"?. Yes.  A recommendation was asked for, this is one way that can work.

At this point, I'm not clear on what's needed so will definitely step aside
 

[Goose66]

I think there is also the question of program model consistency. If all the elements of a scene were in the prescribed state (which the ISY could certainly track), does that mean the scene is "On" according to the programming model. In my mind, the answer is no. The scene is On when the scene is switched On, and the scene is Off when the scene is switched Off. An interim status of the Scene just doesn't really make any sense. But approximating the status of the scene, i.e. having a program that has an if statement that checks the state of each of the devices as paulbates suggest, makes the most sense here to me, from a programming model standpoint. Putting an actual state or trigger even in when the devices come in line with the scene configuration may be convenient, but it breaks the programming model, IMO.

[mjcumming]

This is a feature request. I am not sure why you would say that trying to track the state of scene doesn't make sense. I actually had this setup with a different software package that could track the state and report the state of a scene.

For example at my front, back and side doors I have a keypadlinc with an All button. I only want the All button ON when a light in the house is ON. Since I have about 125 devices, that becomes an extremely long IF statement to control the ON/OFF state of that button. However, the ISY would know if any light is ON and therefore I could update the state of that button with ease. 

[lilyoyo1]

2 minutes ago, Goose66 said:

I think there is also the question of program model consistency. If all the elements of a scene were in the prescribed state (which the ISY could certainly track), does that mean the scene is "On" according to the programming model. In my mind, the answer is no. The scene is On when the scene is switched On, and the scene is Off when the scene is switched Off. An interim status of the Scene just doesn't really make any sense. But approximating the status of the scene, i.e. having a program that has an if statement that checks the state of each of the devices as paulbates suggest, makes the most sense here to me, from a programming model standpoint. Putting an actual state or trigger even in when the devices come in line with the scene configuration may be convenient, but it breaks the programming model, IMO.

I agree completely. For me, if I walk into the family room and hit the relax button it sets my lights to the preset brightness. If I increase or decrease it  a little bit for whatever reason, its still my relax scene. Certain aspects will change things such as turning on the overhead lights (which will then turn off my relax button). 

[lilyoyo1]

6 minutes ago, mjcumming said:

This is a feature request. I am not sure why you would say that trying to track the state of scene doesn't make sense. I actually had this setup with a different software package that could track the state and report the state of a scene.

For example at my front, back and side doors I have a keypadlinc with an All button. I only want the All button ON when a light in the house is ON. Since I have about 125 devices, that becomes an extremely long IF statement to control the ON/OFF state of that button. However, the ISY would know if any light is ON and therefore I could update the state of that button with ease. 

From your specific description yes tracking could work. However, for most situations, tracking scene states can prove detrimental to the system. For example, my relax scenes has 2 functions. A single tap sets the room up for my girl while a dbl tap sets it up for me. 2 completely different actions involving the same exact devices. Late night, my motion sensors kick in. Same exact devices but different results. 

If you dont mind me asking, which controller were you using that had this feature? I've used a lot of different insteon managers and havent seen one with that feature.

Depending on what your intended use of this button, there could be other ways to achieve your desired results. There is more than 1 way to skin a cat. 

[mjcumming]

Tracking should not affect anything - I would just like to see events that could be caught and then used to update (or not) keypadlinc buttons as you see fit. 

I did this in the Girder Insteon component - I wrote all the code that supported automated management of keypadlinc buttons based on the state of a scene. Scenes had 4 possible states: ON, OFF, LEVEL (devices are on but not at the expected level for the scene) and AMBIGUOUS (some devices ON some OFF etc). Based on that event you could decide to turn ON or OFF a keypadlinc button.

[TrojanHorse]

I’m no expert here but I feel the need to jump in and say that I understand why this feature does not exist. In addition to the reasons already mentioned I didn’t see anything about how to handle dimmed states (or, how did you handle that in your code in another Insteon controller?) . It’s one thing to consider ON /OFF and another to consider what if the local dimmer was used and it’s within x% of the scene-defined level. Is it on or off then? I think with ISY as capable as it is, you’ll either need to write a program to track a handful of devices’ local control as suggested and/or have a program that triggers a variable whenever a scene controller is changed and similarly track any programs that trigger the scene using (the same?) variable.

It’s not clear to me the use case and what you are trying to accomplish so maybe I’m wrong. That said, I would just suck it up and write some programs once rather than expect the ISY to be constantly guessing at the status of a 100+ member scene.



Sent from my iPhone using Tapatalk

[larryllix]

I’m no expert here but I feel the need to jump in and say that I understand why this feature does not exist. In addition to the reasons already mentioned I didn’t see anything about how to handle dimmed states (or, how did you handle that in your code in another Insteon controller?) . It’s one thing to consider ON /OFF and another to consider what if the local dimmer was used and it’s within x% of the scene-defined level. Is it on or off then? I think with ISY as capable as it is, you’ll either need to write a program to track a handful of devices’ local control as suggested and/or have a program that triggers a variable whenever a scene controller is changed and similarly track any programs that trigger the scene using (the same?) variable.

It’s not clear to me the use case and what you are trying to accomplish so maybe I’m wrong. That said, I would just suck it up and write some programs once rather than expect the ISY to be constantly guessing at the status of a 100+ member scene.



Sent from my iPhone using Tapatalk

I don't believe ISY even knows if a 'scene on' command is successful in the first place.

If another device issues a further 'scene command' that controls the involved devices. The devices do not respond with statuses of any of the involved devices. ISY may have no idea what those presets are set to. This is to prevent an Insteon data storm with multiple devices being controlled at one time and an Insteon feature and development.

Insteon scenes are presets set by the user ahead of time, and were never made to be modified or monitored.

Instead of people always trying to change the design Insteon was famous for, just send the same scene on again every few minutes or do it with ISY programs properly.

That's the power of ISY when you want to do something out of the ordinary.
People need to use it.

Sent from my SM-G930W8 using Tapatalk

[bpwwer]

23 hours ago, mjcumming said:

Tracking should not affect anything - I would just like to see events that could be caught and then used to update (or not) keypadlinc buttons as you see fit. 

I did this in the Girder Insteon component - I wrote all the code that supported automated management of keypadlinc buttons based on the state of a scene. Scenes had 4 possible states: ON, OFF, LEVEL (devices are on but not at the expected level for the scene) and AMBIGUOUS (some devices ON some OFF etc). Based on that event you could decide to turn ON or OFF a keypadlinc button.

Just so you're not feeling completely alone, I agree with you. In my HomeSeer plug-in, I track scene state and allow for state change events. I do it based on the Insteon definition of a scene which is a set of devices set to specific values.  The ISY knows that information as my plug-in gets that info from the ISY. Then any time a device changes state, I check to see what scenes that devices is a member of and check each of those scenes to see if all the devices in the scene match the "scene definition". If they do, the scene is ON and if one or more don't, the scene is OFF. 

As far as I'm concerned, it doesn't really matter how the scene got turned on or off.  I you went around and set each device manually to the values specified in the Insteon scene definition, then the scene is ON. But that's just my opinion.

Not everyone has the same definition for what a "scene" is and thus we see many different interpretations of how to handle various cases and events. Because all of these different interpretations are neither wrong or right, UDI has no clear direction for how implement scene status/state.  Seems like about once a year someone brings this up.

[mjcumming]

Imagine this use case.

Large room, 3 entries into the room, 6 different lighting loads in the room, all controlled by SwitchLincs, 3 KeypadLincs at each entrance. Each KeypadLinc to be set exactly the same, 6 button mode, ON = all lights 100%, A = 80%, B= 60%, C= 40%,D = 20%.  KeypadLincs do not have a local load.

With a standard scenes on the ISY, there is no way for the KeypadLincs to be setup so that they represent the lighting scene last selected. Ie the only button that should be on would be the button representing the current scene. So if all lights are at 60%, only the B button should be lite. 

Or imaging this case.

At the front, back, and side entry doors, there is a KeypadLinc with 1 button set to represent all the interior lights. So if any light is on in the house that KeypadLinc button should be ON and it can be used to turn off all the lights. In my situation, that becomes an IF statement checking over 100 devices. Yuck. And difficult to maintain that code.

Now imagine if the ISY generated events for scenes. Events could be of 3 types, all devices in the scene correctly match the scene (ON event),  all devices in the scene are off (OFF event), devices are in some state that does not match the scene (AMBIGUOUS event). Using these events, you can easily program button behaviour.

And one other question, why do we have the create scenes to control buttons? Yes, you needed to do that for old I1 engine devices, but the I2 and I3 devices have a direct command to set the KeypadLinc buttons you want on/off. 

[lilyoyo1]

30 minutes ago, mjcumming said:

Imagine this use case.

Large room, 3 entries into the room, 6 different lighting loads in the room, all controlled by SwitchLincs, 3 KeypadLincs at each entrance. Each KeypadLinc to be set exactly the same, 6 button mode, ON = all lights 100%, A = 80%, B= 60%, C= 40%,D = 20%.  KeypadLincs do not have a local load.

With a standard scenes on the ISY, there is no way for the KeypadLincs to be setup so that they represent the lighting scene last selected. Ie the only button that should be on would be the button representing the current scene. So if all lights are at 60%, only the B button should be lite. 

Or imaging this case.

At the front, back, and side entry doors, there is a KeypadLinc with 1 button set to represent all the interior lights. So if any light is on in the house that KeypadLinc button should be ON and it can be used to turn off all the lights. In my situation, that becomes an IF statement checking over 100 devices. Yuck. And difficult to maintain that code.

Now imagine if the ISY generated events for scenes. Events could be of 3 types, all devices in the scene correctly match the scene (ON event),  all devices in the scene are off (OFF event), devices are in some state that does not match the scene (AMBIGUOUS event). Using these events, you can easily program button behaviour.

And one other question, why do we have the create scenes to control buttons? Yes, you needed to do that for old I1 engine devices, but the I2 and I3 devices have a direct command to set the KeypadLinc buttons you want on/off. 

The way you explain things sounds much more complicated than needed. My away buttons and all off buttons accomplish what you are trying to do without going through all that you say. I simply have a program that turns off all the lights when pressed and turns off the backlight on the button a few seconds later. While the button isnt lit up if a light is on, it doesnt matter since it will automatically turn off anything that is on. 

For smaller things such as my outdoor lights, I do have it setup in the isy to turn the outdoor light button on should any of them be on (floodlights dont count). 

Scenes is simply a term used to define what you are doing with insteon devices and yes, mine follows what I am doing. For example, some of my buttons are in single device scenes which allow me to control the backlights individually with the ISY. My KPL's are also set up to turn on and off when I move from scene to scene. For example, If I hit my relax button, it will turn off the other buttons on the kpl. If I turn on the can lights it will turn off any of the other buttons that was in use at that time. Scenes also work outside the ISY. For the most part, should my ISY die, I will not lose control over my house. I lose the convenience controls but everything else will work as normal. This is why we have scenes.

[mjcumming]

I understand how scenes work already.. Good grief.

The addition of the ISY generating events for scene states would not affect what you are doing in anyway. All it would allow is an easy way to keep Keypadlinc buttons in a state that makes sense. If you don't want to do that then fine. 

So me an easy way to solve for the room with 3 KPL without a bucket of extra code. 

[mjcumming]

Interestingly the REST interface generates scene ON/OFF events. If any light of a scene comes ON there is an ON event for that scene. If all devices are OFF then there is an OFF event for that scene.

[larryllix]

1 hour ago, mjcumming said:

Interestingly the REST interface generates scene ON/OFF events. If any light of a scene comes ON there is an ON event for that scene. If all devices are OFF then there is an OFF event for that scene.

Only if ISY knows the scene changed. Many operations do not change  the scene and are not reported. I have overlapping scene device lists and some scenes may change the status of a device and yet the scene is still reported as on. 

eg. I just activated my Gathering Room Off scene to 'On'. All lights went off and MobiLinc reported the scene to ON. ISY handles it and operates the scene anyway. Then I operated my kitchen bar lights on from the switchlinc. ISY is aware of it but no programs are triggered. This was a device operated in the OFF scene but the scene still reports ON in the REST interface to mobilinc.

Scenes created outside of ISY will not report their changes to ISY. Study the scene protocol in the SH white papers.

[lilyoyo1]

1 hour ago, mjcumming said:

Interestingly the REST interface generates scene ON/OFF events. If any light of a scene comes ON there is an ON event for that scene. If all devices are OFF then there is an OFF event for that scene.

Is it showing the event based off the scene itself being triggered or any light being triggered? I ask because it may be capturing the controller doing it's job rather than knowing the scene itself is on. This ties into what Larryllix is saying. 

[mjcumming]

The ISY will report changes it detects for any members of a scene and turns that scene "state" ON if any devices in that scene are ON.

Agave &  OpenHAB show this behavior and it is the ISY generating the state of a scene and publishing it via the REST interface.

I am well aware of how the Insteon protocol works having programmed thousands of lines of code around it since the days of the PLC.