I’m running zwavejs2mqtt in HA. Both switches are associated to each other with group 2. The non load switch has association behavior set to 11. Locally the switches work perfectly in the 3-way. In HA their states are not reflected properly. If I toggle the non load switch, neither switch updates in HA. If I toggle the load switch, the load switch updates in HA. Any ideas? This problem has existed for a while but didn’t matter. Now I’m working on a dashboard and would like to see the proper states.
When you set the non-load switch to association behavior 11, you disable the association with the Zwave hub. This means you can’t control it via the hub and it doesn’t update the hub. So, that device not working from HA is perfectly understandable. You should disable the non-load switch entity in HA.
Do you mean toggling it via HA or toggling it at the switch? I’d have to check to see what happens on my system if you mean toggling the non-load switch locally doesn’t reflect a change of the load switch in HA.
Locally toggling the non-load switch turns the light on/off. In HA I do not see the state change of the load or non-load switch.
Locally toggling the load switch turns the light on/off. In HA the load switch toggles but the non-load switch does not change states.
Toggling either switch in HA will change the local state or the single switch
I’ll check what my associated pair does tonight.
Still, control of the non-load device from HA won’t be right so you should not use it.
My automations only use the load switch. We primarily use the non load switch locally.
I just checked. I have dimmers but mine works as expected. Maybe you have an association problem. Did you set “[31-112-0-12-4] Association Behavior: Z-Wave Hub” to disabled on the “slave” switch only?
My dimmers work fine. It’s my switches lzw30-sn that have issues.
Weird. The load switch begins working as expected if you only delete the association and change nothing else?
Load switch works fine locally and in HA if that’s the only switch I use. Problem is using the non load locally and in HA neither switch updates to the new state.
Setting Association Behavior to 11 does not disable association with the hub, and you can still control it from the hub.
With Association Behavior set to 11, the switch can still receive commands from the hub but it will not notify any other associated devices of the commands it receives via z-wave. This means that you IF you control it from the hub, those commands will only execute on that switch alone and not be repeated to any associated switches.
Sure, the hub can control it. But, it also won’t update back to the hub correctly making it’s current state wrong. You simply should not use the “11” switch on the hub. If you can, disable it so it’s not available.
Is this fact? My understanding was that the switch reports to the hub bidirectionally but does not FORWARD the message to associated devices.
Sorry, I didn’t mean to imply exactly when it won’t update, just that it won’t always. I did watch both devices a while back when I first tried associations but I didn’t keep track of when the “11” device was synchronized and when it wasn’t. I just know for sure it didn’t always stay synchronized and shouldn’t be expected to be properly useful on the hub. And with the association, the master is available for hub use so there is no need to be trying to control it.
BUT… it DOES report to the hub (when things are working correctly). Association Behavior 11 does not disable reporting to the hub.
I have dimmers in association groups with the ‘slaves’ set to Association Behavior 11 and they report their state to the hub. @stu1811 had reported the same thing with his Dimmers.
Its only the LZW30 Switches that he’s having and issue with and from everything he explained, I agree with him that it sounds like a bug with the switch firmware or possibly HA. The switch (lzw30) firmware updates have not kept up with the dimmer (lzw31) firmware.
@stu1811 I agree with your assessment. Unfortunately I have all Dimmers so I am not able to try and duplicate what you are seeing. My Dimmers, like your dimmers, all work as expected where the slaves send state updates to the hub (and update the dashboard as well).
I agree we should not use the slave switches in automations where you want to control the association group.
However, there are other reasons one might want to control just the slave switch from the hub. I do this with LED notifications where each dimmer can have a different LED notification even though they are all in the same association group.
Yes, that is my understanding too. Extensive research and troubleshooting backs that up as well.
EDIT: that is what it should do (and it does with the LZW31 dimmers). But @stu1811 seems to have found an issue with the LZW30 switches where its not reporting back to the hub.
Here is debug from zwavejs2mqtt when toggling the non load switch
While locally toggling non load switch neither switch in HA change state.
This is toggling the load switch
While locally toggling the load switch only the load switch updates in HA
I was able to force the updating of the switches using automations (in addition to associations). Tagging @EricM_Inovelli. Have you tried associating two LZW30-SNs and had their local state match their remote state?
This is a bug in the LZW30 firmware. It is supposed to send a report to the lifeline group when the state is changed locally or via association, but it does not. The problem doesn’t exist on the LZW31.
Is it on the to do list for the next firmware update?
Yes, this issue is in with the manufacturer and we are working to get them to resolve it.
Just wanted to check if there is an update on the fixed firmware? I think I’m having the same problem where when my switch it turned on/off via an associated open/close sensor the updated state is not reflected in HA.