Unreliable Association behavior between Red Dimmer and RGBW Bulbs

Switches General Discussion
, , ,
#1

Hi,

I recently made a fairly significant investment into the inovelli ecosystem because I love the configurability, and my understanding was that the best performance for associations would be between Inovelli products.

My use case is that in my living room I have one Red Series dimmer which I want to control three lamps in the room, all with Inovelli RGBW bulbs. The dimmer does not actually have a load connected, and it is in “Smart Bulb Mode”, I essentially ONLY want it for association, not controlling a load. It is installed with a Neutral wire.

The three Inovelli RGBW bulbs are associated to the switch on Groups 2 and 4.

What I find is that one of the lamps (the same one, more on this later) is very unreliable. It misses the on/off command between 25-50% of the time, which is essentially unusable as I’m sure everyone would agree. The other two have not once missed.

In trying to narrow down if it was the bulb or switch, I tried a few different things. But in my testing, I ultimately discovered the following behavior:

Whichever bulb which was added to the dimmer FIRST, is the one which has this problem. If I for instance remove the “defective” lamp and re-add it, then the issue will now persist on the NEXT bulb I associated. If I remove ALL associations, and then re-add them, it again will have the issue on the FIRST one I add. So this seems clear to me the issue is something weird with the dimmer.

I have other dimmers setup with ONLY one bulb associated, and these do not have issues.

Right now the only solution I see is to remove all associations and just do it through automation instead, but I just replaced my old system with these because automation was slow and the wife NEEDS instant on… (another reason I like Inovelli dimmers – disable scene control for instant on). I will probably just go back to my old setup if I can’t get association to work, since it was the main thing I wanted.

Any thoughts on troubleshooting or workarounds? I tried associating the bad bulb twice to trick it into maybe sending a repeat signal, but it seems it just doesn’t add a repeat association.

Here are some logs that show the issue in action. Node 33 is the bulb which is currently experiencing the issue.

2021-11-17 13:32:20.386 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:20.399 INFO ZWAVE: Node 33: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:20.415 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:20.446 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 99 => 99
2021-11-17 13:32:20.694 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:20.758 INFO ZWAVE: Node 28: value notification: 91-0-scene-002 0
2021-11-17 13:32:22.623 INFO ZWAVE: Node 33: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:22.636 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:22.680 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:22.860 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:22.964 INFO ZWAVE: Node 28: value notification: 91-0-scene-001 0
2021-11-17 13:32:24.099 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:24.113 INFO ZWAVE: Node 33: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:24.182 INFO ZWAVE: Node 33: value updated: 38-0-currentValue 99 => 99
2021-11-17 13:32:24.209 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:24.268 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:24.371 INFO ZWAVE: Node 28: value notification: 91-0-scene-002 0
2021-11-17 13:32:25.706 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:25.721 INFO ZWAVE: Node 33: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:25.769 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 0 => 0
2021-11-17 13:32:25.791 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:25.881 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:25.982 INFO ZWAVE: Node 28: value notification: 91-0-scene-001 0
2021-11-17 13:32:27.224 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:27.236 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:27.389 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 0 => 99
2021-11-17 13:32:27.491 INFO ZWAVE: Node 28: value notification: 91-0-scene-002 0
2021-11-17 13:32:30.724 INFO ZWAVE: Node 31: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:30.736 INFO ZWAVE: Node 32: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:30.891 INFO ZWAVE: Node 28: value updated: 38-0-currentValue 99 => 0
2021-11-17 13:32:30.994 INFO ZWAVE: Node 28: value notification: 91-0-scene-001 0

Also I am noticing these dimmers aren’t respecting associations when triggered through Z-Wave (i.e. turning on the switch through the home assistant, it doesn’t turn on the associated devices.) I do have the setting allowing z-wave hub association enabled, so I’m not sure what the deal is there. But I am mainly concerned with the reliability issue.

#2

Try Group 2, 3, and 4.

#3

Groups 2,3, and 4 didn’t work for me :man_shrugging: Mine are setup with groups 3 and 4. Dimmer is 1.61 and bulbs are 2.31.

1 Like
#4

I originally started with 2/3, same issue. I think having just 3 may be been better results (no group 2), but I don’t recall. I could test that again.

#5

I will try with 3 / 4 later and see if that has an effect. For some reason I thought the associations were supposed to be 3 OR 4, not 3 AND 4, so I will try that.

I really like the instant on behavior of group 2 though… If there was a way to maybe adjust the ramp time on the bulbs (there is on the dimmer) then that would be fine. Still, slow ramp is better than not turning on. I will test your configuration.

Also I have the same firmware, just updated to 1.61 to see if that was the issue, it wasnt.

#6

I’ve experienced the same issue recently. One bulb, the same one each time is also having issues 10% of the time, usually related to not turning off. For reference I’ve had the same configuration for 2 years now and this just recently started happening. Oddly the issue happened following a firmware upgrade on the bulb and switch and migration to Home Assistant. I was previously on hubitat, and the association never had issues until I added the association once everything was paired to the new hub. I’ve been meaning to try deleting the association and recreating it or possibly factory resetting the devices. My other associations haven’t had issues once they were re created, only this one instance

1 Like
#7

Interesting, let me know how it goes. I am running the latest firmware on everything, and these are brand new OOTB. If a factory reset and even a downgrade of firmware works, I would be happy with that. I would also be curious if you are seeing the same strange behavior that only the first node added to group 2 is having issues.

#8

I went ahead and tried the various permutations suggested regarding which groups to include, and the exact same behavior was observed. My best results imo are with just groups 2 and 4.

I also did another full factory reset on the dimmer, and this does appear to have helped. I will update this topic if I find it becomes unreliable again.

#9

I’ve been dealing with something similar but assumed it was related to zwave-js. But your log looks like Hubitat.

In my situation, I’ve got a red-series dimmer with 4 bulbs in a fixture. About 80% of the time all 4 bulbs will turn on/off. The other 20% of the time bulb 1 was either not turning on or off. A 2nd or 3rd press on the dimmer would get it though. So I went into zwave-js, removed all associations to bulb 1, and then re-added them. Bulb 1 has been solid ever since. But now bulb 2 was doing the same. So the next weekend I did the same. Removed all associations from bulb 2, re-added. Bulbs 1 and 2 are now solid, but 3 is doing the same. I ended up going full circle and bulb 1 is back to missing 20% of commands.

I’m wondering is there a limitation in zwave association or are the commands sent in order instead of multicast and whichever is the last one in line sometimes ends up getting dropped?

#10

I am in zwave-js. These are logs from zwavejs2mqtt on home assistant. And that behavior is identical to mine, so long as the one which keeps failing is the first one you added. I have no idea why, but I have repeated this test a dozen times and the failing bulb is always whichever the oldest association is (i.e. first one added).

I may actually grab some unused device to sacrifice as the first association to trick it into always working. Lol

#11

Sadly this issue is only occuring in one situation and not another for me. My living room association consists of 4 bulbs and one Inovelli LED strip and it’s solidly consistent. I checked in zwaveJSmqtt and I have bulbs in the first two association slots.

#12

The factory reset worked for about 24 hours and now it has started having issues again, same symptoms. I will see if I can pair a sacrificial device to the first slot to see if that works lol.

Edit: I don’t have a suitable sacrificial device, I would need to get a cheap smart plug to use or something. I did realize that I performed a network heal earlier, I wonder if that is what triggered it to stop working. Did another factory reset and it seems to be working again. But obviously having to factory reset after every network heal is… not ideal.

#13

I just want to add that I have a similar setup but with only two bulbs and have noticed the same issue with associations set up on groups 2 and 4, which I saw in a different thread was the recommended configuration. At first I thought it was a network level issue since I was also having intermittent command timeouts on a few devices but this thread has me thinking it may not be after all. After reading through this thread I realized that I have a seemingly identical (same 1.52 firmware, but purchased months later) red dimmer just a few feet away and it seems that if I associate both bulbs to that switch instead they both respond as you would expect but if I re-associate with the original switch the behavior returns so I almost wonder if there’s something wrong with the switch itself, at least in my case. I did try an exclude/re-include with no luck but I think I may try a full on reset to factory defaults to see if I see any changes.

#14

I have observed that a full factory reset seems to fix the issue, but not permanently. Performing a network heal, for whatever reason, causes it to start happening again.

I eventually plan to set up zniffer and get to the bottom of it.

1 Like
#15

I am having this same issue on my zwaveJS2mqtt/HA install. I have a switch with 2 bulbs and recently it has been “missing” one of them about 10% of the time. It was 100% for a couple of YEARS, so I’m going to assume it is a ZJS2M issue that we need to figure out.

#16

This hints to me a marginal connection somewhere. My understanding is that heals can produce some “optimistic” routes that don’t really work well in practice, and that over time through the process of recovering from dropped messages the network should start using routes that are less optimal on paper, but actually are more stable.

Hmmm… you’d think the controller wouldn’t matter when the communication is happening device to device with associations.

1 Like
#17

Data is power, and I’m noticing the same behavior in my setups.

Here’s the catch — I’m using this setup with Inovelli Red & Black Dimmers, Inovelli Fan/Light controller, Zooz remote paddles, an RGBGenie RGBW wall controller, an RGBGenie Remote, motion & contact sensors. All vía association (group 2, usually). All of my bulbs are Inovelli. I’m running enough of these where I have to be choosy how many devices I keep adding so I don’t break the limit, and am seeing it across most groups, but not all. Some groups have worse behavior than others, but it’s always the same bulbs that experience the issues. Not sure which number they are for the queue of devices on the associated dimmer/remote. Maybe it’s the way ZWJS is assigning the associations or something? I see it on groups 2, 3, and 4.

Didn’t have this issue on Hubitat (just other ones lol).

@Eric_Inovelli, I’d love to hear your team’s thoughts, and get them any data that could help.

1 Like
#18

Yeah let me get @EricM_Inovelli on the case as well.

I will be back at my house tonight from Thanksgiving travels, and planned to get caught up on a few things (mainly associations actually!)

2 Likes
#19

Thanks! My wife never goes back and turns the lights off if they’ve been left one from an associated pair, so it’ll be nice to work on getting it fixed :joy:

1 Like
#20

Are all of the devices included “non-secure” or is there security involved?