Perhaps a clue? I just noticed that I tapped the paddle on a “master” switch and although the slave switch followed it, the hub did not. As I stand here, the switch LED on both master and slave indicate they are off, but Hubitat reports they’re on at a level of 99 (and obviously the Zigbee lights set to mirror the master are still on). I tried toggling the master several times and the hub just continues to be convinced it’s on. After the fourth toggle, the hub finally got the message and turned the lights off.
Ironically this master dimmer is very close to the hub, only maybe ten feet straight line (the hub is in the basement nearly directly below this dimmer).
I remember WAY back when the ilumin first came out there were reports of this. Essentially there is a group that casts the command to ALL of the bulbs at the same time or a group that commands them in sequence. I’d have to do some digging.
I believe group 2 and 4 FROM switch TO bulb is all that is required since you never want the bulb controlling the switch (or at least I dont!).
I haven’t watched it with logging turned on…just watching the device page for the dimmer. When it works, the page updates (e.g., paddle press for off and the page says the switch is off). When it doesn’t work, the page never updates and even a refresh of the page still shows the switch in the wrong state. The slave always follows, though, regardless of whether the hub does or not.
Any thoughts on troubleshooting this would be appreciated. Don’t get me wrong…I want these dimmers to work. I already own them and they’re in the walls. Changing to either wifi switches or Lutron would cost money and time…
Indeed, I have the master sending groups 2/4 to each bulb. I didn’t create a group for the bulbs, as I thought “grouping” was a Zigbee specific thing and the concept didn’t exist in Zwave.
That sounds like parameter 12 did not take. It is creating a loop and bogging the switches down.
For the bulbs, make sure you have the beta firmware as it makes them much more responsive. It should be 2.31.
With 2.31 you could also use the 3x toggle pairing method to get the bulb to pair non-secure. Then choose no security for the switches (uncheck the check boxes on the C-7 or have the secure option only enabled for locks and garage doors for C-3, C-4, etc). This will reduce traffic and make the setup faster.
How to I fix this? On the slave switch, I see * parameter12value : 11 and I verify that every time I change anything, so I’m not sure what else to do.
I put 2.31 on the bulbs a few weeks ago, but Hubitat is reporting them as 2.28 still. Odd. I’ll try updating them again I guess. Is non-secure pairing going to make them respond to commands noticeably faster?
I’m not sure other than trying to reset it and verifying it took in the logs. I don’t see how group 2 could cause the switch to become unresponsive unless there is some kind of command loop.
You might have to click on “Save Preferences” for the bulbs to update the version number. Removing security essentially removes 66% of the traffic to and from the bulbs. S0 commands and reports send 3x the amount of packets.
I am using firmware 1.48 for my red dimmers, LZW31-SN, I have params 1, 2, 3, and 4 on both set to 2, 2, 0, 0. I have param 12 on the master set to 15 and param 12 on the slave set to 11. I have associations going both ways on groups 2, 3 and 4.
Can I/should I remove the association for both on group 2?