Found my answer in another thread…putting it here in case someone else needs it. I don’t have Z-wave bulbs here yet but I’m assuming I’ll just need to add groups 2/4 associations to one of the dimmers when that happens.
You want groups 3 and 4
To clarify, I want to associate both dimmers with each other with groups 3 and 4, then I want to associate one dimmer to the lights with groups 2 and 4. Right?
A different question - I associated the two dimmers with each other in groups 3 and 4, then I updated firmware on the two switches to 1.48/1.41. Association from physical presses seems to work, but if I turn the switch “on” or “off” via Hubitat, the other one doesn’t follow. Is this expected? I thought association still worked even with on/off from Hubitat prior to the firmware update, but I’m not 100% certain.
Everything sound be group 3 and 4. I’m calling load switch primary.
Setup the following for groups 3 and 4.
First association:
Source - primary
Destination- secondary and bulb
Second association:
Source - Secondary
Destination- primary and bulb
Primary zwave association behavior (param 12) - 15
Secondary zwave association behavior (param 12)- 11
Edit: Regarding your second question… I think I had to delete and receate the association to fix that issue
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
1 Like
This is usually what I advise people to do for those two scenarios.
2 Likes
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,
- Patio > Pergola Group 2
- Patio > Pergola Group 4
- Pergola > Patio Group 2
- Pergola > Patio Group 4
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!
1 Like