I noticed today that when I control my Red Series switch via association, the switch does not send a status update to the hub (via lifeline association), and instead sends the status update to the device that issued the command.
Here we can see that node 26 sent a Basic Set command to the Red Series Switch (node 14), but then the switch sent a Basic Report back to node 26 instead of sending it to Node 1 (the hub).
Is anyone else experiencing this issue?
@EricM_Inovelli I’m not sure if you saw this post (I think I posted it in the wrong category), but it may be a firmware bug.
If a switch is being controlled by another device via association, shouldnt it still send status reports back to the hub?
It should. Can you confirm that the hub is in association group 1?
Also, is this the latest firmware for the LZW30-SN?
I have confirmed that the hub is in Association Group 1. I have 2 LZW30-SN switches, and both of them experience this behavior. I am currently on firmware 1.22 for both switches. I can try reverting back to an earlier firmware version to see if the issue still occurs if you would like.
Question: What is your Parameter 12 set to?
P12 controls what kind of commands are forwarded. So for example, if you’re doing a virtual 3-way or 4-way using associations, you have to pick one switch as the ‘master’, and then the ‘slaves’ you set P12 = 11, which makes them not forward commands received by associated devices. Otherwise, dimming causes an update loop as the switches keep updating each other.
My guess is your answer lies in Parameter 12.
I think you mean Parameter 4 (this is the Red switch, not the dimmer). I did look into this though, but I don’t think it is the cause of the problem.
I have 2 switches, both of which experience this issue, and both have Parameter 4 (Association Behavior) set to a value of 15.
Regardless of the value of Parameter 4, I believe the switch should be sending unsolicited status updates to the Lifeline group (group 1). Instead, it appears that status updates for local button presses are sent to the Lifeline group, but status updates after receiving a Basic Set command are sent to the device that sent the command instead of the Lifeline group.
Ah yes, I was thinking of the dimmer.
That said, I agree that the switch should always send lifeline notifications regardless of what parameters are set.
I’m seeing the same behavior with 2x lzw30-sn. The primary and secondary are associated with groups 1 and 2 in both directions. @EricM_Inovelli I do not see an option in the association tool to add the hub to group 1. I have parameter 4 set to 11 on the Secondary.
This is the behavior in seeing…
Turn on primary:
Secondary switch turns on and light turns on. Smartthings shows primary as on and Secondary off.
Turn off primary
Secondary switch turns off and light turns off. Smartthings shows primary as off and Secondary off.
Turn on Secondary:
Primary switch turns on and light turns on. Smartthings shows primary as off and Secondary off.
Turn off Secondary:
Primary switch turns off and light turns off. Smartthings shows primary as off and Secondary off.
It should be parameter 12 that is set to 11.
Edit: You are correct, it should be parameter 4 on the on/off switch.
AFAIK it’s parameter 4 on the lzw30-sn and parameter 12 on the lzw31-sn. This application is for the lzw30-sn. In my dining room I have 2x lzw31-sn associated and it works fine.
So I have been testing this on Hubitat and I am getting reports from both switches regardless of which one I control. Which version of firmware are you using on them?
Edit: NM, I see what you are saying. Did someone report that this is not the case on the lzw31-sn? Also, as a workaround I believe you will have to create an automation that does a refresh on the other device when the primary receives a state change.
I don’t have any issues with the lzw31-sn. It’s associated with group 3 and 4. The lzw30-sn is associated in groups 1 and 2. I also tried just group 2 and it didn’t work either.
I havent noticed this issue with the LZW31-SN. I have only noticed it on the LZW30-SN
@jtronicus I got this working. Posted solution in link below.
I have the same issue here. I have a LZW30-SN (primary) directly connected to a load (my room light). The LZW31-SN is a no-load switch (secondary) that is used exclusively for controlling the primary switch directly via Group 2 (on/off control). When I toggle the secondary, the primary turns on/off the light, but does not report back to the controller what the status of the light is. I would never use the primary switch directly (it is tucked away in an inaccessible place due to wiring issues). How can I force the primary switch to send a report back to the controller when its status is toggled by the secondary switch? Both nodes have their association parameter set to 15.
Make sure you only have the association setup from the secondary to the primary. Group 2. It does not work when you associate primary to secondary. Use a rule to change the status on the secondary switch.
Thanks for the suggestion! It is set up one way (secondary to primary).
I do not need a rule to change the status on the secondary switch because the primary switch is never toggled manually (it is in the attic crawlspace).
The primary does not send status updates to the controller when the secondary triggers a change in state. My Honeywell switches do, so this seems to be an Inovelli specific problem.
If I understand correctly, what you are showing me is a work-around for a bug in Inovelli devices. While the thought crossed my mind to implement a similar work-around, I would rather just return my Inovelli device and purchase a different brand that works with minimal hacking on my end.
The whole point of direct associations is to speed up the Z-wave network. The LZW30-SN (primary) should be sending a status update to the controller when it is toggled by a secondary devce. For some reason, no status update is being sent. My non-Inovelli devices which use direct associations do just fine in reporting their status updates without needing work-arounds in the controller software.
Correct, this is a workaround. The direct association works as expected on the dimmers lzw31-sn just not the lzw30-sn.
