Activating Scene Sends Different Signals Than Configured

I've migrated from ST this weekend and have most of my more advanced automations and such running well.

Oddly my main issue is with some scenes. The main one being where I activate a scene and the signal sent doesn't match what's in the scene.

In the below example, I have a light called "Couch Light - Living Room". As shown, the scene is set to turn this on, set the dimmer level to 90, with a color temp of 3003.

When I run this scene however, we see this is being set to azure in color. It's shown below in the logs several times since I activated the scene a couple times in a row to see if something would change.
Logs - Google Chrome 2021-03-08 13.49.32

I should note that there are other scenes that set this light to azure - but clearly this scene is not one of them.

I've had this happen with various lights on multiple occasions. There is no rule/automation that controls this light (so there aren't conflicting things happening at once), I'm running the latest firmware, and have restarted the hub.

Any guidance would be appreciated, as the issues I'm having like this are really making a somewhat involved setup inconvenient.

What type of light is "Couch Light - Living Room" (e.g., what brand/model) and what driver ("Type:" on the device page) are you using for it with Hubitat? does it work as expected when you run the "Set Color Temperature" command manually--assuming you see one there at all?

If all else looks good, one thing I did see recently is that "Set Color Temperature" and "Set Level" commands issued in quick succession, as a scene might do, may cause of of them to be lost. Nothing should really set this to "azure" unless that was the last color you were using on the bulb and it's simply reporting that after being turned on but not set to the correct CT.

What type of light is "Couch Light - Living Room" (e.g., what brand/model) and what driver ("Type:" on the device page) are you using for it with Hubitat?

It's a Sylvania Smart+ LED strip, showing as a Generic Zigbee RGBW Light. All of these strips are using the same driver. It's worth noting I've seen this behavior on some of my other bulbs (Sylvania Smart+ bulbs, same driver).

does it work as expected when you run the "Set Color Temperature" command manually--assuming you see one there at all?

I have several of these, and most are working fine. One sometimes isn't set right - but that seems like a scene issue as well. I just tested sending the color temp manually, and this light indeed showed azure on the setColor area. When I entered 3003 in the setColorTemperature box, then clicked the button, the light changed. This further points to some issue with the scene - and not the light itself (or seemingly the driver).
Couch Light - Living Room - Google Chrome 2021-03-

If all else looks good, one thing I did see recently is that "Set Color Temperature" and "Set Level" commands issued in quick succession, as a scene might do, may cause of of them to be lost.

What would even be the fix here, other than a special driver. I have the exact light in my bedroom and so far it's never had an issue. The only difference? It's on a different scene.

Nothing should really set this to "azure" unless that was the last color you were using on the bulb and it's simply reporting that after being turned on but not set to the correct CT.

That may have indeed been the last color set. If I enable debug logging on this device will I see the signal that's actually being sent? My only other thought is to delete and re-create the scene (which will be fun since it's referenced quite a few times, but oh well).

Thanks

One thing to be aware of here--which I suspect is ultimately unrelated, but just good to be aware of regardless--is that many Zigbee smart bulbs have been shown to be bad repeaters, "eating" messages they're supposed to pass on and causing hard-to-troubleshoot problems for your Zigbee mesh. They are reported to work fine on a network of only bulbs, with the issues appearing on "mixed" (bulb and non-bulb) networks. So, if you have other kinds of Zigbee devices--like sensors, smart plugs, switches/dimmers, etc.--on the same network, I'd be cautious.

This is touched on in Hubitat's Zigbee tips section of this document, https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Zigbee_Mesh#Tips_for_designing_your_Zigbee_mesh, but you can also find a lot of forum posts on similar issues. One user did note that the newer version of these (I forget how you can tell from the branding) does seem to behave better, but I'm not sure anyone has formally examined the traffic (e.g., with a sniffer). This may or may not be a problem for you--but again, good to know.

In case you don't already know, color and color temperature "tracked" as separate attributes in Hubitat's driver/capability model, so the fact that you see a blue-ish color isn't alarming on its own. (The "colorName" attribute is poorly documented, but typical behavior is that it will report a human-friendly English color name representing the current color or color temperature, depending on whether the bulb is in RGBW or CT mode--and when it is, attributes corresponding to the non-active mode can be ignored but may display their last value. I have never seen apps depend on this value for anything.)

I agree with your conclusion: if "Set Color Temperature" works as expected here, it's probably not an issue with the device or driver.

One fix is a workaround: use a rule instead of a scene, then in your rule actions you can run "Set Color Temperature" and "Set Level" as separate actions and insert a small delay between them if needed (if I can find the post I read before again, I'll link to it, but the suspicion was that just making them separate actions would give enough time, so you may not need an actual delay). Alternatively, if you just activate the scene twice in a row (again with, perhaps, a small delay between), that has been reported to work more reliably for some people in the past.

Enabling debug logging will show you the commands being executed in some drivers, but I don't think the driver above is one. (Usually this will show what's coming in from the device and how the driver is choosing to parse it, but I think it's really helpful when it does both, and I've seen some newer stock drivers show commands being executed, too--and I always like to do this in drivers I write. But, again, I don't think these are like that.)

However, it won't hurt to enable debug logging anyway. While it could ultimately do anything the driver author wrote, if you see anything at all for commands being run (and again I don't think these will do that), generally just what you'll see if it does is what command and parameters were used--e.g., setColorTemperature(3003)--not what this boils down to in "raw" Zigbee commands if that's what you were looking for.

Finally, for the "Generic Zigbee" light drivers you are using, it's worth nothing that hub firmware 2.2.5 introduced new "Advanced Zigbee..." drivers that should work for most devices that could also use the "Generic" drivers. This may work better for you--or not. :slight_smile: But you can try it if you want to see if it helps regardless. Just change to this driver, save, then hit "Configure" (you may see the lights turn on and off after you run this command; the driver is testing a few things). If you don't like it, change back and hit "Configure" again after saving. And in any case, if my original suspicion is your problem, it looks like staff are aware and a fix will be coming in the future, though not necessarily soon.

1 Like

Thanks so much for the all the info and background.

I actually thought about some potential Zigbee interference (since I have my ST hub right next to the HE running HubConnect for some ST-specific devices), and changed channels yesterday - but I'd not considered that perhaps signals were being relayed differently than they were previously. That said, I tried two things:

  • Disabled color pre-fetch
  • Switched to the advanced driver

On initial run all is looking good. Since there were some others having issues, I'll adjust them individually (pre-fetch vs new driver) to see what the root cause was, but if this sticks, I'll be a very happy guy.

Thanks!

Wait, did you have color prestaging (assuming that's what you mean) enabled? If you were not aware, prestaging allows you set a value for color (or level for level pre-staging) but not turn the device on if it's not already on. Then, the next time it is turned on, it should go to that value. This is problematic for many apps that don't accommodate this behavior (assuming, for example, that a "Set Color Temperature" command will also turn the device on, per standard behavior)--and confusing for many users who stumble upon the settings without knowing the effects. I still don't really see how it could cause this problem since the device was still ultimately getting turned on, but I'm also not sure I've ever seen a case where turning this setting on made things better for anyone. :slight_smile:

The "Adavnced" drivers changed the way this works (moving to commands you can call on demand instead of preferences that affect the "standard" commands at all times), but there are also lots of other changes that may--or may not--work better for your devices. Hope you find something that helps!

Yeah, pre-fetch - sorry. I'd read about what it did before setup, and like that it would prevent the color-flash phenomenon that sometimes happens, but it's not the end of the world if that feature isn't working out.

The "Adavnced" drivers changed the way this works (moving to commands you can call on demand instead of preferences that affect the "standard" commands at all times), but there are also lots of other changes that may--or may not--work better for your devices. Hope you find something that helps!

I just changed a scene again and this light stayed on the previous color...but then when I ran the scene again it worked - so it could be there is a second issue at play, but working eventually is better than not at all. Will take what I can get at the moment :slight_smile:

The advanced driver definitely has a few interesting things going on and I'm going to dig around that more. You can't give me MORE options and not expect me to experiment and potentially break things.