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.
1 Like
I havent noticed this issue with the LZW31-SN. I have only noticed it on the LZW30-SN
1 Like
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.
Wow, really? So this is a bug?
@EricM_Inovelli are there plans to fix the bug in which a LZW30-SN fails to send a status report to the controller when controlled by a direct association?
Edit: Firmware is 1.21 if that helps.
I did some debugging using Zwave JS to capture the information being transmitted. When I toggle the primary ON (Node 12, LZW30-SN connected to the load, the following messages are transmitted (timestamps stripped):
Node 12: value notification: 91-0-scene-002 0
Node 12: value updated: 37-0-currentValue false => true
Node 12: value updated: 50-0-value-66049 0 => 161
Node 12: value updated: 50-0-deltaTime-66049 0 => 0
When I toggle the primary OFF:
Node 12: value notification: 91-0-scene-001 0
Node 12: value updated: 37-0-currentValue true => false
Node 12: value updated: 50-0-value-66049 161 => 0
Node 12: value updated: 50-0-deltaTime-66049 0 => 0
When I toggle the secondary ON (Node 15, LZW31-SN, no load, Group 2 associated with Node 12):
Node 15: value updated: 38-0-currentValue 0 => 99
Node 15: value notification: 91-0-scene-002 0
Node 15: value updated: 50-0-value-66049 0 => 4.6
Node 15: value updated: 50-0-deltaTime-66049 0 => 0
Node 12: value updated: 50-0-value-66049 0 => 160.7
Node 12: value updated: 50-0-deltaTime-66049 0 => 0
When I toggle the secondary OFF:
Node 15: value updated: 38-0-currentValue 99 => 0
Node 15: value notification: 91-0-scene-001 0
Node 15: value updated: 50-0-value-66049 4.6 => 0
Node 15: value updated: 50-0-deltaTime-66049 0 => 0
Node 12: value updated: 50-0-value-66049 160.7 => 0
Node 12: value updated: 50-0-deltaTime-66049 0 => 0
When I toggle the primary (Node 12), it consistently sends a value updated notification of the currentValue changing from false to true or true to false (indicating status of light). It also sends messages about power consumption (e.g., 160.7W). However, when I toggle the secondary (Node 15), Node 12 only sends messages about power consumption. It fails to send a message about the status of the light.
Is this expected behavior?
The zwave JS logs only capture information sent to the hub or from the hub. It does not capture information send directly from one device to another.
Node 12 is actually sending a message about the status of the light. However, it is sending the information to Node 15 instead of the hub (which is why you dont see it in the logs) because Node 15 is the node that issued the command to Node 12.
Node 12 should send all status updates to the hub, but it does not appear to be behaving as expected.
Agreed, it should change the light and tell both the slave switch and hub that it made the change.
Yeah. Do we know if Inovelli has any plans to fix this issue in the near future? If not, I may just request a RMA and/or exchange for a LZW31-SN. @EricM_Inovelli seemed to acknowledge the LZW30-SN bug a while back, but has been silent on the matter ever since. It looks like there have been a few firmware updates to fix other bugs (they are now on 1.22).
I do like their dimmers, though. Are there any downsides to using replacing the LZW30-SN with an LZW31-SN as an on/off switch? It sounds like there’s ways to set the config parameters of the LZW31-SN (e.g., ramp time, etc.) to make it act as an on/off switch.
Yes, there are plans to fix this firmware issue. I do not have an ETA on it, but it will likely be in the next batch of changes that get applied to the LZW30/LZW30-SN.
I discovered a work-around. I added the hub as a direct association in node 12’s group 2. The controller now gets a report from node 12 whenever node 15 sends a command to 12 to turn on or off.
As a brief summary:
Node 12 - Load switch - LZW30-SN
Node 15 - No load - LZW31-SN
Node 15 group 2 → Node 12 (node 15 can now turn node 12 on/off)
Node 12 group 2 → controller (controller now knows when Node 12 turns on/off).
1 Like
New update! After further testing, I discovered that you can get the LZW31-SN LED (no-load) to sync with the LZW30-SN (load) on/off status.
The problem is that the LZW31-SN is a dimmer switch, so it only receives multilevel Z-wave command class from the controller and will broadcast this via groups 3 and 4 (group 2 is for on/off and nothing gets broadcast via this channel when node 15 receives a Z-wave command from the controller).
Since node 12 is a basic on/off switch, it should be able to broadcast an on/off command to node 15 and node 15 will respond appropriately. We need to add node 15 to node 12’s association group 2. We also need to set parameter 12 on node 15 to 11 (i.e., trigger association groups only for timer + local events, not Z-wave events). The final set-up:
Node 12 - Load switch - LZW30-SN
Node 15 - No load - LZW31-SN
Node 15 group 2 → Node 12 (node 15 can now turn node 12 on/off)
Node 12 group 2 → controller (controller now knows when Node 12 turns on/off).
Node 12 group 2 → Node 15 (node 15 LED now updates based on changes to node 12 driven by other node associations or the controller).
Node 15 parameter 12 set to 11 (so that we don’t trigger a on/off cycle between node 15 and node 12).