Just note the on off switches require a neutral in box so if your switch boxes don’t have neutrals you may have to rewire.
Quick note that this thread solved all of my challenges with LED syncing in several 4-way configurations in my house. Thanks!
The last bit that I fixed just now was to address the problem I had of the secondary dimmers not synchronizing with the master when the master was switched on or off via Z-Wave command.
I just wanted to confirm that Group 2 is very much needed for that scenario - I had just 3 and 4 following an earlier note in this thread but wasn’t able to fix that last issue until I also added 2. As soon as I added the mesh of associations for that group, everything is golden.
Is there an official doc now that solves all the above issues for 3-way for LZW31-SN when using Home Assistant? Hard to figure out what is what in all the googling and docs I’m reading.
What are you trying to do? What is the problem?
@stu1811
@iDVB has a fair question. I got my three-way working using wave associations but it’s not clear to me if there is the official documentation on how to do it. To be honest, I feel like I pieced it together through reading a bunch of threads but now I can’t remember exactly how to do it again due to it being so long ago.
Can we confirm this is now in the official, how to do 3 way switching docs and up to date?
@iDVB @BuilderTroy I believe the official documentation is out of date. This is the procedure I’ve done for multiple 3-ways with LZW31-SNs.
- Pair both switches with the same security level
- Associate load switch to non load with groups 3 and 4
- Associate non load switch to load switch with groups 3 and 4
- On non load switch set parameter 12 (association behavior) to 11
Note: In Home Assistant Group 3= Switch Multilevel Set and Group 4= Switch Multilevel Start/Stop
Official docs for reference:
3 Likes
On my associated pair of red and black dimmers I have both set both the manual and Z-wave ramp rates to 0. But, the one not being manually switched on or off will still ramp while the one being manually switched will immediately switch. The one not being controlled is following the dimming speed and not the ramp rate. I noticed this was mentioned earlier in the thread but that comment was basically ignored by all other posters.
So, is this expected behavior or is it an issue that has been solved or is it a firmware bug that has yet to be addressed?
Which Device Driver are you using? Make sure you get the latest from here: https://support.inovelli.com/portal/en/kb/articles/hubitat-device-drivers
The old device handlers had ramp rate and dimming rate swapped. Might be what you are seeing. Easy test for you would be to try setting all 4 rates (both dimming rates and both ramp rates) to 0.
I don’t use Hubitat. I use zwavejstoMQTT.
It certainly is the switches. I’m using 2 dimmers and each has a load. The one manually switched goes off immediately and the one being controlled by association ramps off. Same result controlling at either device.
Ok, but still I suggest you try setting all 4 parameters to 0 just to see if the problem goes away. There was a known issue where dimming rates and ramp rates were reversed (it was an Inovelli issue, not a Hubitat issue). Setting all 4 parameters to 0 would help identify that and you could adjust your hub settings accordingly
If you read what I posted, it is clearly an association issue. I’ll explain it again. Each dimmer goes on and off immediately when turned on and off locally (parameters 3&4 = 0) and each dimmer ramps the dimming when dimmed locally (parameters 1&2 = 3). But the dimmer not being locally controlled uses the parameters 1&2 = 3 second time to both turn on and off and when the dimmer level is being changed. This means it’s an association thing.
I’m going to try associating variations of group 2 and 3, or possible 2 3 and 4.
The dimmer documentation says that group 3 sends a setlevel of 00 or FF when the switch is tapped up or down. I’m thinking this setlevel command tells the other dimmer to dim to 00 = off or FF = on. This would explain why the dimmer not controlled locally always uses the dimmer parameters 1 & 2 and never uses parameters 3 & 4.
Group 2 sends a basicset of 00 or FF, which I think would tell the other dimmer to switch to 00 = off or FF = on. Telling a dimmer to switch on or switch off should use the ramp rate parameters 3 & 4.
Not necessarily. I did read what you posted and based on your symptoms, it still could be an issue with with parameters 1 and 3 swapped in an outdated device handler.
BTW, all my associations are working with proper LED sync and matching dim/ramp rates (after the device handler was fixed regarding params 1 and 3)
Associated devices use zwave commands to communicate with each other and, as you know, zwave dim/ramp rates can be set differently than local dim/ramp rates. Its perfectly understandable that local dimming/ramping works differently than zwave command/association since there are different settings for each.
You stated that you have local and zwave ramp set the same, but that is assuming parameters 1 and 3 are not swapped in the device handler. Your symptoms sound A LOT like the issue I documented in this post from last year:
Consider your scenario IF parameters 1 and 3 were swapped. Local controls (params 2 and 4) work as expected (which you have confirmed) but zwave commands (and associations) dim/ramp opposite of expected (params 1 and 3 swapped)
You have parameter 1 (zwave dim rate) set to 3 and parameter 3 (zwave ramp rate) set to 0. When 1 and 3 are swapped in the device handler (the issue I documented last year) then what you get is zwave dim rate of 0 and zwave ramp rate of 3 - which sounds like what you are seeing.
What you are describing matches what I saw in the older ST and HE drivers and was fixed initially by me hacking my own driver and eventually fixed in updated ST and HE drivers from Inovelli. Unfortunately, I don’t know anything about HA device handlers and it appears Inovelli does not supply them (supplied by community open source I presume? 
) So its certainly plausible that whatever HA driver you have is based on the older ST/HE handlers which had 1 and 3 swapped.
I understand you are convinced this is a different problem, but your symptoms match what I dealt with a year ago. Its not hard to try/test what I am suggesting. Prove me wrong and try swapping the values for parameters 1 and 3 and report back the results 
5 Likes
I am right because it did not work right no matter how I set the settings. So, i have no reason to try and prove anything to you. Changing the dimmer time to zero caused an instantaneous dim up or down. Dimming and on-off were ALWAYS the same on the “slave” device regardless of the time settings. Changing all to zero proves nothing - might as well leave them all at 101 and not customize then.
I changed to using groups 2 and 4 instead of following the advice here and it immediately started working exactly as I expected it to work. Both devices obeyed the dimmer and ramp times and stayed in sync. Both led strips stayed in sync. PERFECT.
Associating 2&3, the “slave” dimmer would only start updating on a dimming level change after the “master” paddle was released. Both devices would use the ramp rate when toggled on of off. So, it didn’t work either.
I never tried 2, 3 and 4.
I apologize if I missed it, but I don’t see where you mentioned trying the combination of settings that I suggested. If you did try swapping parameters 1 and 3 what were the results? There was, in fact, a known problem with older device handlers and the symptoms matched what you were reporting.
My suggestion wasn’t intended to be a permanent solution, just one simple troubleshooting step to identify if this was the same issue or not.
Well, my associations were working and yours weren’t. So… I was just trying to help 
Then I have no reason to try and help you anymore with that attitude. 
4 Likes
You kept telling me to set all the times either the same or to 0, which of course would make the problem I was seeing go away, but wouldn’t actually fix anything and wouldn’t prove the times worked as expected or not.
Except the dimmers do send BasicSet commands when locally pushed. I just verified this last night. The dimmer locally controlled is sending the BasicSet on or off command to the other dimmer which would then also immediately switch on or off using the 0 second ramp times I had set. This did not work until I associated group 2 and then it immediately began working as I expected it to.
Using group 3, on at tap up or down of the locally controlled dimmer it would send SwitchMultiLevelSet to the other one which was telling the other one to dim to the set level.
I’m guessing that for BasicSet 0x00 means “ramp” to off and 0xFF means “ramp” to the previous value. For SwitchMultiLevelSet 0x00 means “dim” to off and 0xFF means “dim” to the previous value.
I want to experiment more to see if group 3 needs to be associated or not to ensure all works through HA as well as locally.
On another note, HA doesn’t seem to ever send BasicSet if you toggle a light on or off, which means the ramp times are never used when controlling lights from it.
Thanks for this @stu1811,
I hope this is still the method.
Does this method also keep the slave smart switch LED in sync as @mamber said his setup does?
Also, if I’m using HA core-2021.9.6 and ZwaveJS (no ZwaveJS-t0-MQTT yet) anyone have an idea on how to set those parameters as mentioned in this method? I have access to a ton of params via the UI, but not sure what the “values” of those are in numbers to match the directions. Do I need to install ZwaveJS-t0-MQTT to set extended params?
This method still works for me.
For the non load switch select all of param 12 except back to the hub. The load should have the default (all options)
Yes, it works.
I checked and still don’t see the associations in HA. I set them in ZWJS2MQTT.
I also have noticed that these (https://support.inovelli.com/portal/en/kb/articles/can-i-install-multiple-smart-switches-in-a-3-way-4-way-etc) instructions are out of date, and don’t reflect the discussion here. I have a question about LZW30-SN stitches. I assumed that they should have their non-load switches’ parameter 12 set to 11, but it looks like their default is 10, not 15. What value should I use for these on/off switches?
Thanks in advance.
No, switches use parameter 4. Same setting 11 instead of 15.
Parameter 12 on a red switch is for energy reports.
2 Likes