Problems with directly paired Zigbee bulbs (setting color, etc.)

🛎️ Get Help
1

I'm experimenting with a Hubitat hub dedicated to Zigbee bulbs as a possible alternative to the Hue Bridge I have been using. To that end, I've been directly pairing a bunch of Zigbee bulbs of various types directly to this hub. Has anyone else tried this, and if so, have you run into any problems? I've run into a few that I'll explain below (but to save you from jumping to conclusions: if you've read anything I've posted before, you know that I am aware of Zigbee bulb routing issues, so that is not what I'm talking about here with "problems," and that's why I'm using a different hub).

The biggest problem I seem to have is that calling setColor from an app does not change the color. Sometimes I have to click setColor twice on the driver page to get it to actually change, but the problem seems to be even worse in apps. I'm passing a map like [hue:99, saturation:79, level:2], which I'd expect to change to a pinkish red, but instead it stays at whatever the last color/color temperature (and I think level) were. I've noticed something similar when setting color temperature.

Similarly, sometimes when activating scenes, I have to turn them "on" or "push" twice to achieve the desired color/color temperature.

I've seen hints of others having similar issues and possible talks of a driver in testing that may fix this problem, but I can't find any official word on the subject. Has anyone else tried something like this and had a similar experience? For what it's worth, most of my color (and CT) bulbs are various generations of Hue, but I also have one Sengled and a few cool- and warm-white Cree Connected bulbs.

Speaking of the Sengled, I'm also having an interesting issue with it: startLevelChange(up) often turns on the bulb, at least for a portion of the change, even if it wasn't already on. None of my other bulbs that I've tried this on do this (though I think they were all either Bridge or directly connected Hue bulbs). Interestingly, I think this only happens if the last-used level before it turned off was less than 100, possibly fairly low (mine are often around 10% because I have them dim before turning off).

I might go back to the Hue Bridge; the lack of support for "reading" Hue scenes is one of few drawbacks for me there. I was hoping putting them on Hubitat and being able to leverage group messaging natively might improve speed and save me from needing to define scenes/settings in two places (Hue scenes and...often the same settings in Hubitat again for various purposes). Since Hubitat's scene support is currently mostly just a software "emulation" of real scenes (albeit a more powerful one that allows you to include any type of device), I'm not sure there's a huge advantage here right now, either, but I have heard talks of that becoming a possibility in the future.

I'd appreciate any advice anyone may have (especially Mike or whoever knows a lot about Zigbee bulbs and drivers), but I thought I'd at least share my experiences to see if anyone has had similar experiences. If so, I guess anyone considering this should think twice before getting rid of their Hue Bridge. :slight_smile:

2

I haven't seen anyone report this other than in Europe, but it sounds similar. Probably best to tag @mike.maxwell as he's the one that will know. What exactly are the make and model of your lamp's?

3

Various, but mostly Hue White and Color Ambiance bulbs or however they are marketed now, but also a few White Ambiance bulbs and one or two Whites, plus a Lightstrip Plus: LCT016, LTW015, LCT014, LCT007, LWT004, LCT001, and possibly others I'm forgetting. :slight_smile: I have the Osram/Sylvania A19 RGBW and one Sengled Element Color Plus RGBW bulb (the one I mentioned above), plus a few cool white and warm white Cree Connected LEDs and one white-spectrum Trådfri, but (aside from the Trådfri which I haven't played around with much yet) those aren't really of concern due to their more limited capabilities. The Hue bulbs are mostly what I'm playing with now.

4

I can confirm this behavior with my Sengled Element Color Plus bulbs as well. It would seem to me that this behavior is most likely a function of the bulb's firmware, not something Hubitat is doing. Personally, I like this behavior. If someone uses one of the Pico remotes in the house to brighten a bulb, I would expect it to turn on and start adjusting the dim level.

5

See, I would expect it to not to because that's how my other bulbs work. :laughing: I guess neither is necessarily right or wrong, but it would be nice if they were at least consistent. But if it's the bulb and not the hub, I guess there's not much we can do (except work around it in my case by checking to see if the bulb is on first; I'm trying to avoid any extra processing since Hubitat is already slower than Hue at all of this, and using a Pico--nice as they are--is nothing like using a Hue Dimmer paired natively on a Hue ZLL network, though I guess this small check when dimming would be the least of the contributing factors).

The "need to set scenes twice" problem is much more annoying, however, and I don't know of a workaround besides sending the scene on() command multiple times. (I don't have enough Sengleds to test scenes, but it's happening with any Hue bulb I've tried.)

EDIT: Now that I think about it, I seem to remember Hue Bridge bulbs reporting a change to switch: on when calling startLevelChange (I think on up), despite the bulbs actually not turning on, and the switch status remaining (incorrectly reported) that way until maybe the next refresh. This caused me some problems before when trying the "is it on?" check I suggested above. This makes it very difficult to win in this situation (but if none of the logic ever touches anything that wasn't on--and any app/automation that might be doing the same also does this--then that seems like it should work, assuming the states are accurate to begin with).

1 Like