Closed thespooler closed 3 years ago
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.
Thanks for working this problem! If the update changes anything in the Configuration CC, you might ask that they send along a new XML file that we can use to make the necessary changes.
Zooz sent me an update to test (v1.04) and I installed it on both devices but, unfortunately, both behaved even worse than they did before, i.e., they switched back to the opposite state more often than they did before with v1.03. I let them know. Has anybody else tested? I've attached the file here.
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.
YOU ARE RIGHT!!
BUT, I tested with the same parameters that worked for me before, using the "normally closed (relay reports off when it's open / switch is on and on when it's closed / switch is off)" setting. It was bad. It does NOT work as expected, with lots of flipping back and forth. You might check those to see if you get the same bad behavior.
HOWEVER, I changed them to Normally Open (which is the way I should be using them), and it DOES seem to work reliably so far! I'll follow up with Zooz so they can check the other settings. I think they still have problems.
Yeah, good call. I didn't think to test the normally closed setting. On the flipping it may be necessary to reinterview the device and ensure it's rediscovered (restart HA). I'm not sure what that changes in the payload but that could be the cause.
This was after a clean reboot for me. I have to move my stick to my Win7 machine to do the OTA upgrade, so it's a complete shutdown and restart for my Pi.
Maybe they ignored or removed the additional functionality they added in v1.03 and the normally closed settings no longer matter. But they are still there for me because I add the XML data manually to HA. If that's the case, no telling what was going on. It seems the Normally Open is now working tho.
This was after a clean reboot for me. I have to move my stick to my Win7 machine to do the OTA upgrade, so it's a complete shutdown and restart for my Pi.
Maybe they ignored or removed the additional functionality they added in v1.03 and the normally closed settings no longer matter. But they are still there for me because I add the XML data manually to HA. If that's the case, no telling what was going on. It seems the Normally Open is now working tho.
If you're using zwave2jsmqtt you can update the firmware right from the UI fyi.
Yeah, I'm still on zwave 1.4, but looking to upgrade soon. Just waiting and trying to decide which zwavejsX to move to as I'm going to have to rename everything.
This issue has not seen any recent activity and was marked as "external". Closing for housekeeping purposes... 🧹
Feel free to reopen if the issue persists.
Just for completeness, I got the following response from Zooz on what the new FW update fixed. It only fixed the Normally Open use case, which is what most of us will want. There are still issues with any other use case, in the event anyone needs them. They will continue to diagnose.
I'm sorry that I didn't clarify that with 1.04 the reports will work well with default settings. There's no reason to change the setting to NC since in reality what it does, it actually reverses the reports to imitate NC behavior. If you're using the ZEN16 in a standard application, you're using it as a normally open relay and this setting should be left at the default (as normally open).
We'll do some more testing on the NC settings on our side as well but please do not change this parameter in the future unless you have a special type of application for it.
Thanks everybody for working this so quickly!
In my case, I have configured the following: All switches are Toggle, Relays are NO. I update this particular unit to Firmware V1.04 which was provided on this thread.
When actuating from HA or ZwaveJS2MQTT, Relay 1 operates and displays correctly, but I continue to receive the same multiple value reports in the debug log.
2021-03-31 16:35:24.039 INFO ZWAVE: Node 12: value updated: 37-1-currentValue false => true 2021-03-31T20:35:24.109Z CNTRLR [Node 012] Mapping unsolicited report from root device to first supporting end point #1 2021-03-31 16:35:24.113 INFO ZWAVE: Node 12: value updated: 37-1-currentValue true => true 2021-03-31 16:35:24.129 INFO ZWAVE: Node 12: value updated: 37-1-currentValue true => true 2021-03-31 16:35:25.105 INFO ZWAVE: Node 12: value updated: 37-1-currentValue true => true
Then when I select either RLY2 or RLY3, a value for RLY1 is also sent in duplicity.
2021-03-31 16:35:43.430 INFO ZWAVE: Node 12: value updated: 37-2-currentValue false => true 2021-03-31T20:35:43.484Z CNTRLR [Node 012] Mapping unsolicited report from root device to first supporting end point #1 2021-03-31 16:35:43.486 INFO ZWAVE: Node 12: value updated: 37-1-currentValue false => true 2021-03-31 16:35:43.506 INFO ZWAVE: Node 12: value updated: 37-2-currentValue true => true 2021-03-31 16:35:44.190 INFO ZWAVE: Node 12: value updated: 37-2-currentValue true => false 2021-03-31T20:35:44.202Z CNTRLR [Node 012] Mapping unsolicited report from root device to first supporting end point #1 2021-03-31 16:35:44.204 INFO ZWAVE: Node 12: value updated: 37-1-currentValue true => false 2021-03-31 16:35:44.218 INFO ZWAVE: Node 12: value updated: 37-2-currentValue false => false 2021-03-31 16:35:44.489 INFO ZWAVE: Node 12: value updated: 37-2-currentValue false => false 2021-03-31 16:35:45.428 INFO ZWAVE: Node 12: value updated: 37-3-currentValue false => true 2021-03-31T20:35:45.504Z CNTRLR [Node 012] Mapping unsolicited report from root device to first supporting end point #1 2021-03-31 16:35:45.506 INFO ZWAVE: Node 12: value updated: 37-1-currentValue false => true 2021-03-31 16:35:45.523 INFO ZWAVE: Node 12: value updated: 37-3-currentValue true => true 2021-03-31 16:35:46.266 INFO ZWAVE: Node 12: value updated: 37-3-currentValue true => false 2021-03-31T20:35:46.312Z CNTRLR [Node 012] Mapping unsolicited report from root device to first supporting end point #1 2021-03-31 16:35:46.314 INFO ZWAVE: Node 12: value updated: 37-1-currentValue true => false 2021-03-31 16:35:46.326 INFO ZWAVE: Node 12: value updated: 37-3-currentValue false => false 2021-03-31 16:35:46.484 INFO ZWAVE: Node 12: value updated: 37-3-currentValue false => false
Is this what everyone is continuing to see?
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.
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. #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.
Thanks! I'm running ZwaveJS2MQTT v0.9.0 on HA core-2021.3.4. It appears I'm still operating on ZwaveJS 7.0.0 per the add-on info. I'll ask for the update on their end.
Zen16 Firmware v1.04 and ZwaveJS V7.0.1 fixed all of the issues on my end. Thanks!
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,
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)
[x] Previously working device (other platform)
Installation information How did you install
node-zwave-js
?zwavejs2mqtt
(latest) docker imagezwavejs2mqtt
(dev) docker imagenode-zwave-js
branch:zwavejs2mqtt
branch:To Reproduce Steps to reproduce the behavior:
Additional context Add any other context about the problem here.
Logfile: zwavejs_1.log