search

zwave-js / node-zwave-js

Z-Wave driver written entirely in JavaScript/TypeScript
https://zwave-js.github.io/node-zwave-js/
MIT License
750 stars 600 forks source link

When toggling relay of ZEN16, reported currentValue ends up not being targetValue #1748

Closed thespooler closed 3 years ago

thespooler commented 3 years ago

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

Installation information How did you install node-zwave-js?

To Reproduce Steps to reproduce the behavior:

  1. Go to 'Control Panel'
  2. Select node
  3. Expand Binary Switch
  4. 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

blhoward2 commented 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.

GrizzlyAK commented 3 years ago

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.

GrizzlyAK commented 3 years ago

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.

ZEN16_V104.zip

thespooler commented 3 years ago

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.

GrizzlyAK commented 3 years ago

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.

blhoward2 commented 3 years ago

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.

GrizzlyAK commented 3 years ago

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.

blhoward2 commented 3 years ago

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.

GrizzlyAK commented 3 years ago

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.

zwave-js-assistant[bot] commented 3 years ago

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.

GrizzlyAK commented 3 years ago

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!

DayRunner131 commented 3 years ago

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?

blhoward2 commented 3 years ago

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.

DayRunner131 commented 3 years ago

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.

DayRunner131 commented 3 years ago

Zen16 Firmware v1.04 and ZwaveJS V7.0.1 fixed all of the issues on my end. Thanks!