Inconsistency with Scene tracking - Potential bug

In the attached image, you can see all devices in my scene are off. When my scene is activated, this is the state it should be in. In the past, the scene would automatically report if the scene is active or not, and the activator switch would track the scene state. I don't know when this started, but all my member devices of my scene in are in correct state, yet the scene is reporting "Not Set" and the activator button is off.

There are no restrictions for my scene.

In the application state, I see that even though all my devices were captures in the off position, there are color mode, as well as HSV and CT values for the bulbs, and maybe dimmer levels for dimmers too. Every device in the event subscriptions list is set to call checkScene with Filter = true.

Looking at my End Table light and Floor Lamp (CM=CT, HSV = 50, 100, 10), the scene has a CM=CT, and CT = 5500. But both are in the "off" position.

This appears to be a parsing bug. If the scene wants the device off, none of the other attributes should matter. I suspect this may also be the source of the slow scene performance -- setting all the unnecessary attributes for a device that should be in the OFF state.

When I force the bulb into the correct color mode that the captured state has stored, then the scene turns back on just fine. Again, this is for bulbs that should be off.

@gopher.ny @bravenel Not sure if you saw this.

I'm seeing something similar.

From what I can tell, there are at least 3 ways to activate a scene:

  1. Activate command
  2. "Switch On" the Scene's switch device
  3. "Push Button" the Scene's button device

From what I'm seeing, the "push button" and "activate scene" methods never cause the scene's "switch" to register as "on"--thus, when using those methods, you can't tell when the scene is active or not.

It appears the only way to be able to verify the scene's status via the ON/OFF state is if you activate the scene using the on/off switch (I also assume that it won't register as "on" if all the devices happen to be otherwise/manually set to match the scene).

Additionally, it doesn't seem like the "(Not Set)" in the name/app list is replaced by "(On)" in a predictable fashion (although switching the switch on is the only way I've seen the scene marked as "(On)"--but not every time.


So, I tried using scenes, with 60ms metering.

I set up a scene, switched it on, then refreshed my devices, waited a bit for things to settle down.

Then, checked the switch device for the scene.

I thought that should be a reliable way to know if everything was in the desired state but that clearly wasn't a good way to tell if the scene is activated and properly set.

You can see that the test was successful

But, when I looked at 3 devices that were part of that scene, they were NOT properly set:

Double checking, the scene device still thinks it is on

Looking at the screen itself, it's showing those devices not set

It's frustrating, because I can't figure out how to reliably ensure my devices are set.

When I go to sleep, I want all my inside lights off--there are always about 2 to 4 that don't get set properly (or get set, but their status never reflects back to the hub).

This is true as well when I wake up and turn lights on. Also, when I adjust lights for working.

There are always several lights that are messed up.

I've been manually redoing the scene activations (once, twice, sometimes 3+ times) to get the lights set properly.

It seems that any time I act on more than 5-10 lights together, things just don't work right.

I was hoping that using scenes would give me a way to make sure things got set.

I'm happy to help try things to figure out what's causing this.

This morning, on my "Set at home" routine, the process seemed to work.

It took several tries, but the "scene on" test worked.

BTW: the "Stop repeating actions" command prevents the next "END-REP" from looping back. What's the recommended method for stopping the repeating actions and exiting the loop? Can you have "End-Rep" commands on conditionals in addition to at the end of the loop?

It looks like it took 5 pairs of refresh() actions and scene redrives to properly update:

The state of the activator switch is independent of how the scene is activated. It will reflect the condition of each device matching its captured state (except when the activator switch is turned off, see below). One thing that can throw people off on this is that some bulbs will not actually set to every possible value, but will go to a slightly different level, thus making the scene not quite match.

The app maintains an internal state value reflecting whether or not the scene is fully set. When activated, this is set to true. As each device in a scene reports events, no matter what the source of those events might be, including manual adjustment of a device, the app compares the new value with the captured value for that device, and sets the activated state accordingly. This in turn sets the state of the activation device to "on" or "off". It does not look at every attribute when it does this, only the specific attribute reported in an event.

Note that the act of turning off the Scene Activator switch turns off every device and sets the internal state to not activated, and this is a different action than activating a Scene with all devices captured to off, even though the real world outcome is almost the same. In the case of a Scene with all devices set to off, turning off the Activator switch should result in the Activator switch itself being set to off, even though the devices are all in their captured state. After this, only activating the scene would return the internal state to activated.

In the case where a device is captured as off, all of its attributes are also captured. However, when activated it is turned off, and no other attributes are set. The other attributes current state does not affect the activation state of the scene unless one of these attributes changes while the device remains off (see above for what happens).

I see that you have posted many screenshots and logs. Do not expect me to study these.

The short synopsis:

Last night, an activated scene registered as "on" even though the impacted devices never were set to the "captured state" (and they never reflected the captured state in their own state).

This morning, things seemed to work more as expected--but it took 5 attempts at setting the scene for the devices to properly align.

The logs are just there because the first question is almost always "where are the logs?".


So, if I understand what you're saying--if I "push" or switch-on a scene, it should immediately go to the state=ON (before any devices are set or return state).

Then, it will only flip back to state-OFF if devices start sending back events that don't match the scene's capture values?

So--if the scene is activated and 4 devices never respond--it will stay set "On" even though it never reached them or got confirmation they were set?

If so, that might explain what happened last night with that scene.

Would it be safer/better to have the scene state remain at "OFF" until all the devices reported back with a match (when the scene is "not optimized")? In a non-optimized scene (which I'm using since I have issues with reliability), all the devices should be getting commands and, thus, should report back, right?

It depends. The internal state goes to true. What the switch does depends on how the scene was activated. Any device reporting in a way that is consistent with the capture state will cause the switch to be 'on'.

It's not a normal switch.

1 Like

So-- If I want to use the "Scene=On" state as a method to determine that the devices are all really in the desired state (e.g., looping through "set scene/wait/refresh devices/check scene state" until the Scene=ON), what is the recommended method for activating the scene? A "push" or "activate scene" rather than manually setting the scene=on?

It's not ideal--but this approach might help me deal with the oddities I'm seeing by at least ensuring some of the key situations are handled.

For me, when I manually set all devices to the exact hue, sat, color mode, color temp, level, etc, then set the switch state to in or off (in my case they should all be off) then it registers as the scene being on. To me, off is off, regardless of the other values, so a scene that shuts down the home lights should not need to adjutant the attributes and turn off to be registered as the scene being on.

Yes. What happens when you activate the Scene? It does not set any attributes, it just turns the switches off. Nor does it care about the captured attributes unless you go changing them with the scene already activated (doing so would turn on the device, and then clearly the scene is no longer set).

Agreed. To address this, I set the desired state, then recapture the scene (or manually adjust the scene to match). This is common for hue, because of the scaling mismatch.

Agreed. This is my understanding. Is it normal for the scene to expect other attributes to match in addition to the off state, though? As reported in my original post, it is this specific scenario that I am concerned about. I happy to experiment with this.

I am not sure @rob9 and I are referring to the same issue.

The scene only looks at those attributes that are reported in events. For example, turning a device on or off does not send any other attributes (level, hue, etc), so Scene doesn't really care about those. But when the device does report some other attribute, it has to match the capture state for Scene to show that the scene is activated.

Probably not, But, it's your topic...

So, if I turn off every device manually, the scene activator button does not show the on state, and the scene app does not report the scene is active. But if I change every device to the color, level, etc, then I turn them off, then the scene reports being on, and the activator button shows as being on.
I just recaptured the devices in my scene, and the problem still exists.

This is now a minor annoyance, because I also noticed all my scene problems only occur when I activate the scene from sharp tools using the activator button. Only a couple lights turn off. If I tap every device on sharptools to turn them on or off, I can trigger every one of them to change state almost immediately โ€” in less time than using the activator button takes to turn iff just 2 or 3 lights. And if I use the activate scene button inside the scene app, then every time the scene successfully changes state of all devices quickly โ€” it pauses on one, and I donโ€™t know why, but I can figure that out later.

I guess the new question is, how does the activator differ from the scene appโ€™s activate button? And by extension, why would using the activator button through sharptools have different results than using the activate scene button in the scene app directly?

They both run the exact same code. Using the activator also generates a switch.on or pushed.1 event, and possibly a log entry.

No idea. What happens when you activate the scene from the activator's device page?

I will play some more tonight, and see if this is unique to the SharpTools integration. I did not use the activator button from the HE GUI. I should have, but I wonder if there is something in the way SharpTools integration triggers the actions. I will play more with it today.

It's just a virtual switch or virtual button, depending on how you use it. Both do the exact same thing. There is no reason that SharpTools would change how it works. It either flips the switch on or pushes the button; then the exact same code runs irrespective.

1 Like

Here is the link to what I observed.

When I use "Active Scene" or the scene's activator button device, the scene is activated quickly. When I push the activator button via the sharp tools interface, is runs extremely slowly, and never to completion. So it appears this may not be a scenes issue so much as something with SharpTools. Can you think of anything else before I reach out the SharpTools for assistance on their end?

Also, I will record what I observed originally in regards to the original bug report.

Do you have logging turned on for the activation device and for the Scene? This is not a SharpTools issue, unless you have other things going on with it.

yes. For the activation button:

For the scene:

The results are typical all the way down the log. Nothing out of the ordinary.