I am using Ikea E26 1000lm bulbs in my scenes. However, whenever I switch between scenes, I noticed that the Ikea bulbs don't dim when if they are also switching colour temperature. I have to press twice for the scene to work properly.
Does anyone know why this is happening, and how I can fix this issue? Do I have to change some settings on the lightbulb? Or can I add some kind of code in my scene for it to send first change the colour temperature and a second later change bulb brightness?
Or maybe there is some kind of workaround with the Rule Machine?
This is a problem I noticed with a lot of directly-connected Zigbee bulbs on Hubitat. It's one of the reasons I went back to a Hue Bridge after experimenting with this setup on a "second" Hubitat hub for a while (mixing bulbs and non-bulbs on the same Zigbee network is often recommended against; see How to Build a Solid Zigbee Mesh - Hubitat Documentation for more--though it's possible the Ikea bulbs are new enough to be unaffected by this problem, something some have proposed). Activating the scene twice is an annoying workaround but one that did work for me. If you're using rules instead, setting the level and then setting the color temperature as separate actions with a delay in between may also work. With RGBW bulbs, something that I noticed that helped was modifying the driver (this was fortunately one of the public ones) to increase the delays between some commands. My suspicion is that these bulbs receive commands too fast and it overwhelms them, and slowing things down helps a bit. For RGBW bulbs, my modification is here: Hubitat/Generic-Zigbee-RGBW-Light-Tamed.groovy at master · RMoRobert/Hubitat · GitHub. Something similar could be done to create a "tamed" CT bulb driver, though you could probably use this one for testing and ignore the color-related commands if you wanted to see.
Another thing in general that helps: if you have multiple bulbs and you're changing them all at the same time, try using a Zigbee group. The Groups and Scenes app can set one up for you (create a group and check "Enable Zigbee group broadcasting"). When you send color, level, etc. commands to a group, it will send one command for all bulbs (one per action needed) instead of separate commands to each bulb, which tends to keep them happier. "True" Zigbee scenes would also work here (similar to groups, the bulbs store some sort of "scene ID" and their necessary settings onboard, then receive a command to recall the scene and already know what to do; Hubitat emulates this with an on/off, color/color temperature, level, etc. command to each device or group; Hue supports scenes natively and is again another reason I went back to that setup--the Ikea bulbs work with the Bridge, BTW).
So...a few workarounds. Seems to be a quirk some people just have--not sure if I was unlucky or just did more experimenting that most people in this regard. Others may have other ideas. Hopet his helps a bit!
Thanks for your feedback. I'll give it a try. I am brand new to Hubitat, so I am not sure what to do with your script. How would I use it inside Hubitat? Is there a place I can upload it? Also, how would I get the original driver code if I want to modify a CT bulb driver?
I originally noticed this problem on Hue Hub - the temperature and brighness not changing in the same time. I thought Hubitat would fix this problem. And I agree about the bulbs receiving the commands too fast, I think that should fix the problem.
This page explains how to add custom drivers into Hubitat: How to Install Custom Drivers - Hubitat Documentation (but basically go to "Drivers Code" and copy and paste either the raw code into the text box or the URL for the same into the "Import" button dialog). Ignore the second set of directions on that page that have you add a virtual device; that isn't what you want to do here; you want to change the driver on your existing device to this one (go to the device page and see the options under "Type"). Again, this isn't quite the driver you'd want since it does both color and color temperature, but it should at least give you a clue as to if the "slowing down commands" solution would work for you.
I've noticed that Ikea's Trådfri bulbs are kind of slow to change in general. Changing color/color temperature takes longer than Hue bulbs and most other Zigbee bulbs I've used. I can't remember how they worked if I tried to change level and CT right in a row (they'd be separate commands, so you can't really do them at the same time) except that, like many other bulbs, they'd often just entirely "miss" one of the command (not usually the on() if it was first or implied via another action--e.g., a setLevel() on a bulb that is off will also turn it on). Hubitat staff have described these as being written with "budget firmware" or something along those lines. I can't disagree. Keeping them paired to Hue provided the best experience for me, but yours may vary. There wasn't much I liked about them except that their 1000 lm CT bulb was brighter (and cheaper) than a Hue White Ambiance.
Thank you. I tried using your driver, but it is not working. I am just trying to understand how it works right now, see if I can make a tweak. Maybe increase the time. Of top of your head, do you have a recommendation for a variable to change, to make wait time longer?
Also, I am would like to see the Generic Zigbee CT Code, but I don't know where to find it. Do you have any recommendations where I can find the code - so that I can tweak the CT code?
When you see the driver sending commands that include things like "delay 250", those are prime candidates for increasing (maybe "delay 400" or "delay 500" or more). Even if you're not familiar with Groovy or Hubitat's format for sending Zigbee commands, a find-and-replace approach should work for this.
Alas, Hubitat has not made any of their CT drivers public. Creating one would likely be easiest as simply paring down this driver to eliminate the RGB functionality, but if this one doesn't work (ignoring the color commands and some extra information it will try and probably fail to receive if refreshed, they should be pretty similar), one like that hypothetical driver would be unlikely to perform much better.
I will say again that if you still have a Hue Bridge (and especially if you're using it for other purposes still), my Ikea bulbs worked better on their than when directly paired to Hubitat. I at least never had the "missed commands" problem that way, but the slowness seems to be inherent to the bulbs no matter where they live. Hubitat has a nice, native Hue Bridge integration (and I'm quite partial to one I wrote for my own use, too ).
Thank you for your help Bertabcd1234. I tried your code but I still could't get it to work. Will continue trying. I'll update this conversation if I do manage ti figure it out. In the meantime, I just wrote a rule that resend the signal 0.5 sec after a rule is triggered.
Is there something in particular that isn't working? (Since you said you're new to Hubitat, I should mention that there are two steps to using a custom driver: first installing it under "Drivers Code," then going to the device page and choosing this new driver under "Type:" if you want to use it on a device that has already been paired.) If the driver otherwise works as expected but is subject to the same issues you originally found, then the only guess I have for something that might help would be increasing the delays I mentioned. If you tried that and it's still not working, then...I'm not sure. I guess even more delays might help, but some of these help the bulb report changes back to Hubitat, so you'll notice slower attribute/event changes for this device (not necessarily a problem unless you have rules or other apps that trigger off something here).
Have I mentioned the Hue Bridge yet? They're still slow (Ikea's bulbs just don't seem to be very good, no matter how you use them--I've even tried them with a Trådfri Gateway), but I've never seen them flat-out miss commands on Hue. And again, Hubitat has a native Hue Bridge integration that will work well. But adding a delay and repeating also works--I lived with that for a while, too. (Oh, and if you have other Zigbee devices, it's a good idea to keep most bulbs off of that same network. A Hue Bridge would help with that too. These particular bulbs may or may not be one of those, but many are.)
I'm currently experimenting with the different TRADFRI setups.
One thing I found is that if an Ikea bulb is in a group with another group (it is Hue in my case), it works well. All you have to do is group them in HE (in my case HE is connected to HUE hub so might work differently if they are paired to HE directly), and turn off group messaging.
So I discovered a nice solution with the scenes. It works on Ikea bulbs but might work with Ikea Bulbs that are paired directly to Hubitat.
I was able to fix this issue by changing the scenes fading time to 0. For some reason, anything bigger causes them to fail. My Ikea lightbulbs are paired directly to the Hue hub. I was able to reduce the fading time by using 'All 4 Hue' app and then going to scenes, edit (by clicking on a scene, clicking on "Upgrade stored..." in "Lights configuration", and changing the number to 0. You have to change every scene individually.
Others may have other ideas. Hopet his helps a bit!
I can't disagree. Keeping them paired to Hue provided the best experience for me, but yours may vary. There wasn't much I liked about them except that their 1000 lm CT bulb was brighter (and cheaper) than a Hue White Ambiance.
