Illumin RGB bulbs get stuck on Color Temperature changes

I’ve been fighting the good fight in a portion of my setup lately and I seem to be losing pretty hard.

I have two of the Illumin RGB bulbs in a bathroom vanity fixture that I’m controlling with an LZW31-SN switch. I have the association configured and working correctly for on/off and dim functions. I’m using Hubitat as my hub platform.

Typically the bulbs are set at a color temp of 2700 and 60% brightness.

I’m trying to configure the double tap scene control to set the bulbs to 5500 and 100% brightness. This works most of the time. However, when I attempt to revert the bulbs back to the previous setting either one or the other seems to get stuck at the 5500 temp. The affected bulb reports back to the hub that it’s at 2700 but it’s very visibly not. Once the affected bulb gets out of sync it will not respond to additional commands from the hub for the temp change.

I’ve tried excluding and re-including both bulbs several times as well as well as reworked the actions I’m using to set the values from the hub in a number of different ways with no success. There doesn’t seem to be any definite pattern as to which one of the bulbs will get “stuck” so I don’t really suspect a hardware issue.

Has anyone else experienced this or have any suggestions to offer on how to get this working correctly?

Have you had any luck with this? I’m on SmartThings but having similar issues (along with some others like extremely long delays, holding up is not increasing the brightness, and a few others). I know it’s different hubs, but maybe it’s something in common with the issue.

Unfortunately I did not. I wasn’t seeing the extreme delays that you are or the unresponsive “on” from the switch though. I ended up swapping these out for Hue bulbs in that location.

Have you verified that your switch parameters are set correctly for the neutral/non neutral and the load type? Others have reported issues where the switches were incorrectly reporting these values until they were manually set at the switch. Also, disabling the local relay at the switch is key.

If you have power reporting disabled on your switch I’d also recommend checking those settings as there is a confirmed firmware issue that causes the switch to send constant reports when the parameters are set to “0”. According to the documentation, the setting of “0” should disable the reports but it has the opposite effect and could be flooding your network with traffic. I’d suggest setting them to their maximum values.

I’ve had the best luck with the Illumin bulbs in locations where I only have a single bulb. (Hallway, lamp, etc.). In those instances the behavior isn’t as noticable. Once I have the association created with the switch the on/off and dim work great. Color change is hit or miss. Hopefully they can resolve this either through drivers or firmware. These bulbs were a throw in for me since I got them as part of the BF package and was really interested in the switches.

Thanks for the suggestions! I had initially set the parameters through ST, I hadn’t come across the issue where the values may not actually be set correctly. I’m not able to get into configuration mode on the switch itself, holding the button as per the directions isn’t working. I was able to do the 8x tap on the Config button to ensure the local relay was disabled, and that worked. Figured I would try the factory reset steps but that’s not working either, so maybe I’m dealing with a defective dimmer.

I was working through this today. It looks like sometimes the message gets sent to the bulb to set a different mode, but it doesn’t properly update in the Hubitat database that it was sent. In my case I found commenting out the if statement (//if ((device.currentValue(“colorMode”) != “CT”) || (device.currentValue(“colorTemperature”) != temp)) ) that checks the current color mode and temperature so that it always sends the command to the bulb instead of trying to decide if it would be a duplicate event “fixed” my situation.

1 Like

Brilliant! I didn’t think to see if the driver was doing a status check before sending the command. The status check makes sense from an efficiency/best practice perspective but I’m willing to sacrifice that for reliability. I’ll try to test this later today.

Going to check for something similar in ST to see if that helps my issue at all. Thanks for sharing!!