Red series dimmer and ilumin bulb association doesn't always respond

Hey all,
I have a red series dimmer (firmware 1.52) set to smart bulb mode and 2 ilumin bulbs (both firmware 2.31) associated on groups 2 and 4 using openhab as my system and I’ve noticed that a about 1 in 5 or so times one of the bulbs (we will call it bulb 2) doesn’t always respond to the tap on the switch like it missed the association signal. Usually both bulb 1 and bulb 2 come on as expected but sometimes only bulb 1 does or if both are on and I tap the switch “off”, bulb 1 turns off as expected but bulb 2 stays on. In cases like this I can normally get bulb 2 to finally turn off if I tap the switch “on” and then “off” again but not always on the first try and a lot of the time if I tap the switch “on” in that case, bulb 2 will turn off and then back on to match the switch state. This happens whether or not I actually have openhab running so that’s why I’m thinking it’s something on the zwave side of things directly and it’s been happening for quite a while, possibly since I put them in - I just haven’t had time to try to troubleshoot or post. Does anyone know how I can go about troubleshooting this?

Did you set each bulb to no security or at least match both bulbs and switch to same security level? Also recommend group 3 and 4. Not 2.

Both bulbs and the switch are set to no security and i’ve switched from group 2 and 4 to 3 and 4 but still noticing the same behavior

I have noticed the same thing on occasion, but I have not yet been able to fully determine the root cause. In my setup, I have a LZW36 Fan+Light dimmer controlling 4 Ilumin bulbs. Sometimes when trying to turn them off, 3 of the bulbs will turn off, and 1 will remain on.

The bulb reports that it has turned off (so my hub thinks it is off), but the bulb remains lit. Attempting to turn the lights on and then back off sometimes resolves the issue, but not often. Holding the dimmer down button (as if I am trying to lower the brightness) and then releasing it will get the light to turn off.

I tried swapping bulbs around to see if it could be a particular bulb, or maybe a particular location. If I unscrew the bulb that has the issue, and the problem eventually moves to a different bulb.

The bulb that experiences the issue always appears to be a bulb that has a lot of commands routed through it. For some reason my hub likes to set up routes through the Ilumin bulbs, even when a direct route should be possible (instead of the hub communicating directly with a switch, it goes hub → Bulb → switch, even if the switch is 6 feet away and the bulb is in another room. I suspect the bulb is receiving too many routed commands at once, but again, I have not been able to confirm anything.

What ended up helping significantly in my own testing was to unscrew the bulbs that are giving me trouble, then performing a zwave network heal. This causes the hub to reassign all routes without the bulbs (because it will not assign routes to nodes it cannot communicate with). Once the network heal is complete I screw the bulbs back in, and everything appears to work.


That makes sense now that you mention it. I took a look at my zwave network map and it appeared that I had a lot of nodes routing through the bulbs for some reason too so I’ll give your tip of unplugging them and doing a heal a try, hopefully it will help. I’d be curious if all the routes come back at the next nightly heal though, i’ll have to keep an eye on that.

I dont think nightly network heals are recommended any more. It might be worth turning that feature off if you are able to.

Good point. If there’s no change and no problems to the network it seems redundant to heal nightly anyway, thankfully I can turn that off

Just reporting back, even after leaving them unplugged and forcing a heal plus disabling the nightly heal I still have the issue. It’s less frequent at least but I get a feeling that’s the best I’m going to get

Mine are 100% accurate. I recommend removing the associations and redoing them. This is hub agnostic, so the Hubitat has no effect on this.