For which groups, why group 3 to the bulbs? That seems conflicting with the guidance at the beginning of this thread (groups 2 and 4). I’m super new to this so would love to understand.
For the other thing, I redid the associations and it didn’t help. I’ll try excluding and re-including the dimmers and see if that sorts it.
Edit: to clarify a little further there is no “load” connected anywhere. Those terminals on the dimmers are empty and the bulbs are hardwired to power.
I followed the below guide in the past. Also make sure the two switches and bulb are joined S0
Yeah I found that too, which is what led me to understand G3/4 between dimmers and G2/4 from the “master” switch to the bulbs (master having P12 left at 15 and slave having P12 set to 11).
@EricM_Inovelli can you comment as to what you believe are the correct associations to make for virtual 3-way dimming and zwave bulbs?
I’d try it myself by smartthings won’t let me join my bulb s0 waiting for @EricM_Inovelli 
to release a firmware update to only join s0
This is usually what I advise people to do for those two scenarios.
Any idea about why the 1.48 firmware seems to have broken association from Hubitat control for me? They follow each other from physical presses, but don’t follow if I turn them on or off from Hubitat.
It should work if you control the master, but not the slave (since p12 was set to 11). This is to prevent a z-wave loop from occuring.
Is it acting that way or do they not keep in sync when controlled from the master either?
@EricM_Inovelli Hi Eric, Wondering if you can help with my association woes too!
I have 2 LZW31-SNs (fws 1.35 & 1.47) using your 2021-01-28 driver on a hubitat C7 hub. One is installed at each end of my garden and each has it own bulbs as connected load.
I want to be able to sync the two (on/off & dimming) in a bi-directional configuration. I have installed the drivers for the z-wave association tool dated 2020-04-16 and setup up 4 associations,
I found that the dimmers are fighting each other in a loop and as I hold the down paddle I can see the level in the notification bar being set higher again as it starts to drop down.
As per your comment on this thread, I have since set the Association Behaviour one of of the dimmers (fw1.47) to #11, but I’m still having the same problem.
What am I missing?
TIA.
Jon.
Update: I just removed the Associations and the app, and deleted the Association Behaviour option as my dimmers were pretty much unusable (scenes not even triggering reliably) however it looks like the two dimmers are still linked and still unusable.
What should I do?
So my current situation is I can turn either master or slave dimmer on from Hubitat, but when doing it like that they do not follow each other (e.g., turn master on and slave does nothing, and vice versa).
Operating them from the physical paddles works exactly as expected (save for an odd delay sometimes, but I’ll post about that once I get fully migrated, disconnect ST, and repair the Zwave network).
You can look at the state variables to see the node ids that are currently associated and remove them with the set association command:
@Aegwyn11 can you verify that only one of the devices has parameter 12 set to 11? Maybe even set them to something else and then set them back.
@EricM_Inovelli I tried changing parameter 12 on the slave to 15, verified it took, changed it back to 11, and verified it took. Behaviour is still the same as I described before. Honestly it’s only a minor annoyance, if I need to have something in the hub turn the switches off or on I just have to remember to turn them both off or on. Honestly the more annoying part is that dimming works the same… Operating the physical paddle on either makes the other follow, but setting a level via Hubitat on either one results in no change on the other one.
I just tried excluding the switches, including them again, setting P12 to 11 on the slave, and redoing the associations. Same behavior. Physical presses they follow each other all day long, but on/off/level set from Hubitat makes them operate separately.
I moved another pair of dimmers (still on 1.35 firmware) over to Hubitat today and played with this more. The behaviour I’m seeing is on the 1.35 firmware as well… I SWEAR hub commands sent to the master used to affect the slave too. I’m so confused. Sending commands from the hub to the master should update the slave too, right? Any ideas I can try to remedy?
Which firmware level were you on before? I just tested again. This time with one on 1.48 and one on 1.52, and it worked when I controlled the master through Hubitat as well as at the switch. One thing to note is that “setLevel” as working the way described, but “on” / “off” was not because of how the driver is written. I had to enable group 2 to get on / off to work from Hubitat.
FYI: I don’t recommend 1.52 right now for association group 3. An enhancement to it makes it a little wonky (not related to this issue though).
All dimmers started on 1.35 and got updated to 1.48.
So I tested it again just now and indeed, setLevel to the master does affect the slave. I don’t know what I was doing wrong before but it’s working as expected now. Since the last test I’ve fully migrated off ST and repaired my Zwave network, so maybe that helped somehow.
I also added group 2 associations and now on/off works as expected.
So it seems to do “virtual” three way, associate G2/3/4 and set P12 to 11 on the slave.
Thanks!
Yeah, I’ll have to remember that. The driver used to send setLevel with on/off so it used to work with 3/4. So that the ramp rate worked, I had to switch it to on / off so I guess that is when it stopped.
It seems that adding G2 association broke something… The switches started locking up a lot (not responding to paddle presses, not telling the hub or the other switch when it was turned on/off). I removed the G2 associations (had to twice on the master because I didn’t realize it was locked up the first time, so I had to reboot it, readd the association, and remove it again).
Operation is still sometimes slow, often taking 2-4s for my hub to see the command and tell the Zigbee lights to turn off after pressing the off paddle. Sometimes the dimmer doesn’t seem to even tell the hub that it was turned off (paddle press does nothing and hub shows the wrong switch state). Even for the dimmer associated with Ilumin bulbs, operation is sometimes unpredictable. I’m not sure if these “wrong state” and slow operations are due to Zwave issues or the dimmers failing to send messages. At this point I’m not sure what else to try (other than Wifi switches, or dropping $$$ on Lutron switches).
We are more than happy to help you get a better experience. My associations are so fast I literally can’t perceive a delay, so we can definitely get you fixed up.
Remember that associations are completely outside the hub (meaning if the hubitat is unplugged this will all still work).
So I would remove all associations, ensure that they are removed via software, then go to the hardware and ensure that they are air-gapped or power is cut for a solid 30 seconds or so before starting up again and ensure that no control is happening between previously associated devices.
Perform a z-wave repair on your home. Not sure if map is available on Hubitat, but confirm that it was successful and there aren’t any “ghost” or “dead” nodes in your system. Confirm Hubitat operation of switches and bulbs are happening quickly after the heal. Correct any issues from logs. Basically make sure you have a well-functioning z-wave mesh. Reset any parameter 12’s that you might have set different than default 15.
Add an association for group 2 from master to slave. Confirm that the master controls the on/off state (don’t worry about level right now) of the slave. Confirm delay is gone (or post back up!).
Add an association for group 4 from master to slave. Confirm that the master level is synchronized to the slave effectively. Confirm delay is gone (or post back up!).
Add an association for group 3 from SLAVE back to MASTER. Confirm that a SLAVE level change results in a MASTER change. Confirm delay is gone (or post back up!).
To be honest, post back up at this point, because I am unsure why people are getting a feedback loop in a 3-way (not 4+ way, I get that) and I personally want to understand more related to this.
When I finished the migration from ST and pulled that hub out, I did a Zwave repair. I actually did two because one node failed on the first one (no nodes failed the second repair). All Zwave devices are connected at S0 (which was in itself a PITA).
Ignoring my virtual 3 way setups, let’s talk about a different place I have four Ilumin bulbs and a single black dimmer. These bulbs -usually- respond quickly, but not always nd they’re never perfectly in sync. Typical would be they all turn on/off within a single second (popcorn style), but sometimes one or two take several seconds longer. In rare cases, one seems to miss the command outright and is stuck in it’s previous state.
I’d love to hear your thoughts. I love these dimmers and all the flexibility they bring, but the inconsistency is killing the WAF.
