node-zwave-js: When toggling relay of ZEN16, reported currentValue ends up not being targetValue
Describe the bug
When toggling a relay of a Zooz ZEN16, currentValue gets misreported at some point. It first gets the correct value then changes to the wrong value. ie. Toggling targetValue cause currentValue to toggle as expected reflecting the actual state of the relay, but will then toggle again, thus reporting currentValue incorrectly. The physical relay actually only switches once. To actually toggle the state and report the correct value, the targetValue needs to be clicked twice (without toggling, just the same value).
In attached log file,
22:15:45.027 DRIVER » [Node 010] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 86
└─[MultiChannelCCCommandEncapsulation]
│ source: 0
│ destination: 1
└─[BinarySwitchCCSet]
target value: true
...
22:15:45.058 CNTRLR [Node 010] [~] [Binary Switch] currentValue: false => true [Endpoint 1]
...
22:15:45.132 CNTRLR [Node 010] [~] [Binary Switch] currentValue: true => true [Endpoint 1]
...
22:15:45.135 DRIVER « [Node 010] [REQ] [ApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 1
│ destination: 0
└─[BinarySwitchCCReport]
current value: true
...
22:15:46.062 DRIVER » [Node 010] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 87
└─[MultiChannelCCCommandEncapsulation]
│ source: 0
│ destination: 1
└─[BinarySwitchCCGet]
22:15:46.113 CNTRLR [Node 010] [~] [Binary Switch] currentValue: true => false [Endpoint 1]
...
22:15:46.117 DRIVER « [Node 010] [REQ] [ApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 1
│ destination: 0
└─[BinarySwitchCCReport]
current value: false
Only one BinarySwitchCCSet is sent.
Switching the relays with the physical switches do correctly report the currentValue.
Device information
Zooz ZEN16 Multirelay
Node 10
This is a device with 3 relays and 3 switches, my switches are configured as [10-112-0-2] Switch Type for Relay 1 (Sw1): Toggle switch (follow switch).
This did not occur with ozw.
Last Known Working Configuration
-
New device
-
Previously working device (node-zwave-js)
- Which library version/docker image/adapter version?
- Have you made any recent configuration changes to the device? Describe.
-
Previously working device (other platform)
- ozw
- Have you made any recent configuration changes to the device? No
Installation information
How did you install node-zwave-js?
-
zwavejs2mqtt(latest) docker image -
zwavejs2mqtt(dev) docker image - ioBroker.zwave2 adapter
- Pkg
- Manual Docker build
node-zwave-jsbranch:zwavejs2mqttbranch:
- Manually built (as described in the docs)
- Other:
To Reproduce Steps to reproduce the behavior:
- Go to ‘Control Panel’
- Select node
- Expand Binary Switch
- Toggle targetValue. currentValue will then report the current value, before switching a second time.
Additional context Add any other context about the problem here.
Logfile: zwavejs_1.log
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 65 (25 by maintainers)
All, Zooz provided me with a test firmware which fixes this issue. They were hoping to release it as soon as tomorrow. I’ll update when they do.
I am seeing this EXACT behavior with this device right now (actually two of them I’ve just added to my network) on the zwave 1.4 integration which uses the OZW 1.4 library. That points to a HW issue, I would think. I will report to Zooz as well. I’ve a pretty good relationship with them, as I own a LOT of Zooz products.
After reading #1532 I’m not sure the solution as described will solve this particular problem, if I’m understanding what the fix does. It sounds like that you will decide NOT to do a poll if you receive an update following a set. But the problem I’m seeing with my device is a BinarySwitch report showing the CORRECT state, followed by a second BinarySwitch report showing the WRONG state, which gives the application the opposite impression of the true state. And, it appears to be random as to when I receive that spurious second report.
I’m in touch with Zooz and their initial response was to try upgrading to zwavejs and see if that fixed it. Being on OZW 1.4 in HA, that’s not an easy feat for me. But I think this issue report (which I sent them) is a good indication that it doesn’t work here either. I’ve asked that their engineers assess the situation.
So some of this, maybe all of it, but at least the entire second half, is fixed by a recent PR about mapping reports. When you’re operating relay 2 or 3 a report is being sent by the root endpoint and mapped to endpoint 1. This makes relay 1’s state change when it shouldn’t. We’ve changed that. https://github.com/zwave-js/node-zwave-js/pull/2160. Try upgrading to 7.0.1 or wait until whatever setup you’re using has updated.
Also try this, as we’ve seen a similar issue with an Inovelli device: remove node 1 from the first association group and readd it. OZW set some of these up without using multi-channel associations which causes all sorts of issues. We’re going to check for that and fix it in the future but we don’t do so yet.
If you’re using zwave2jsmqtt you can update the firmware right from the UI fyi.
I can confirm that the firmware 1.04 fixes the issue for me. With the settings as they should have been, that is “follow” for the switch and “normally open” for the relay.
I think that I do. I was able to guess it from the one I had. I imagine they’d provide a new link anyway as Zooz is pretty good about providing upgrades. If you can hold off for a few days until we know more, they seem pretty responsive so far and I think we’ve given them a pretty good lead. They offered to change whatever we needed so long as it doesn’t break another integration.
I’m using zwave only. Changing the normally close/open works fine but it reverses the auto on/off behavior and I’m not sure what else. Less than ideal on a fireplace.
They were added in the version 1.3 firmware. They aren’t in the older manual. https://www.support.getzooz.com/kb/article/471-zen16-multirelay-ver-1-03-advanced-settings/