search

zwave-js / node-zwave-js

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

Zooz ZSE42 water leak sensor shows no sensor in HA after S2 inclusion #5247

Closed madbrain76 closed 1 year ago

madbrain76 commented 1 year ago

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

YES, BUT a Home Assistant developer has told me to come here

Is your problem within Z-Wave JS UI (formerly ZwaveJS2MQTT)?

NO, my problem is NOT within Z-Wave JS UI

Checklist

Describe the bug

What causes the bug? Unknown. Could be a Z-Wave JS bug or device bug. Zooz support thinks it's the former.

What do you observe? If I include the device with S0 security, the "Water leak detected" sensor shows up in HA, and the device works.

If I can include my ZSE42 with S2 security (either authenticated or not), the "Water leak detected" sensor does not appear in HA, making the device unusable. If I then try to re-interview the device, the process for re-interview is broken, but the sensor eventually does show up.

What did you expect to happen? 1) "Water leak detected" sensor should have shown up with S2 security in the first place, without a need for further re-interview. 2) Interview process should not be broken (see steps).

Steps to reproduce the behavior:

  1. Go to Settings / Devices / Z-Wave JS / Add device
  2. Press the Z-wave button 3 times on the ZSE42
  3. When prompted, type in the 5 digit PIN for S2 auth
  4. After inclusion, look click "View device". See that that "Water leak detected" sensor is missing
  5. I have included 3 log files for this inclusion scenario .
  6. Click the vertical | menu under "Device info" and "Re-interview"
  7. Press the Z-wave button 4 times on the ZSE42 to wake it up
  8. Wait about 20 seconds. See that the re-interview process does not complete.
  9. Press the Z-wave button 4 times on the ZSE42 again
  10. Repeat steps 6-9 , since these are not very reliable. Eventually the "Water leak detected" sensor will show up.
  11. I have attached 2 logs of this re-interview process.
  12. Go to Settings / Devices / Z-Wave JS / Remove device
  13. Click "start exclusion"
  14. Press the Z-wave button 3 times on the ZSE42
  15. Go to Settings / Devices / Z-Wave JS / Add device
  16. Click "How do you want to add your device"
  17. Click "Legacy secure"
  18. Click "search device"
  19. Press the Z-wave button 3 times on the ZSE42
  20. Click "view device"
  21. Notice how the "Water leak detected" sensor shows up, unlike in step 4
  22. I have attached a log for the S0 inclusion in steps 15-19

Device information

Manufacturer: Zooz Model name: ZSE42 Node ID in your network: changing, see logs for inclusion/interview

How are you using node-zwave-js?

Which branches or versions?

Not sure. Here are the versions info I see Driver Version: 10.3.0 Server Version: 1.24.0

Did you change anything?

no

If yes, what did you change?

No response

Did this work before?

No, it never worked anywhere

If yes, where did it work?

No response

Attach Driver Logfile

zwave_js_ZSE42_S2_inclusion_3.log zwave_js_ZSE42_S2_inclusion_2.log zwave_js_ZSE42_S0_inclusion.log zwave_js_ZSE42_S2_re_interview.log zwave_js_ZSE42_S2_re_interview_3.log zwave_js_ZSE42_S2_inclusion.log

zwave-js-bot commented 1 year ago

👋 Hey @madbrain76!

It looks like you attached a logfile, but its filename doesn't look like it a driver log that came from Z-Wave JS. Please make sure you upload the correct one.

madbrain76 commented 1 year ago

zwave-js-bot, I renamed the log files to make it clear which test cases they were for.

Ikcelaks commented 1 year ago

I was able to reproduce this issue by including an old ZSE42 with S2 security (firmware 1.10). I then performed a firmware update to version 1.40. This worked fine with the S2 inclusion. After the update completed, I performed a re-interview. This was successful, and the leak sensor appeared immediately.

You will need to use four rapid presses on the internal button to wake the device immediately after initiating the firmware update and again immediately after initiating the re-interview. The blue light will flash to verify the device woke up.

My guess is that your interview didn't immediately succeed because the device either didn't wake up right away, or it went asleep before it finished. re-waking the device should allow the interview to complete, which would explain why the sensor eventually showed up for you.

Needing to manually wake up battery devices to complete interviews is undesirable but pretty common.

madbrain76 commented 1 year ago

Ikcelaks, FYI, my two ZSE42 are both on firmware 1.40.1 .

I then performed a firmware update to version 1.40. This worked fine with the S2 inclusion.

No, it does not work "fine", even on firmware 1.40.1 . The "Water leak" sensor should appear in step 4 of my test case, after S2 inclusion. It does not appear for me, and your comment indicates that it does not appear for you either, even with the latest firmware. That's undeniably a bug. The subsequent re-interview (steps 6-10) is a workaround for this bug. Steps 15-21 show that this bug does not appear when doing inclusion with S0 security, also. Ie. the bug is specific to S2 inclusion.

I filed this issue because I want this bug fixed. I don't know if it's a bug in the device firmware, or a bug in Z-Wave JS. I was hoping someone could determine that, so that the bug could be fixed in the right place. I have been corresponding with Zooz developers and pointed them to this defect and logs as well.

If the issue is, as you suggest, that the device went to sleep in the middle of the initial interview during inclusion, then it sounds like a firmware/device bug to me - the device should stay awake a little bit longer once the inclusion process has started. Can that theory be confirmed from the logs I provided ? I own a number of battery-powered devices from Zooz - 7 ZEN34, 2 ZSE11, 2 ZSE42 and the ZSE42 is the only one on which I have seen this problem. On all other devices, if the interview failed during inclusion, I would restart inclusion, and it eventually would work. The ZSE42 stood out as S2 inclusion never worked - in the sense that it gave me an incomplete device without the sensor.

kpine commented 1 year ago

I submitted #5251 for the interview "hang". That's an entirely different problem.

The missing Notification CC water sensor value is 100% repeatable for me, using S2 inclusion. Reproduced on both firmware v1.30 and v1.40 (updated earlier). The inclusion is always missing the notification value, and the re-interview always fixes it.

First inclusion:

2022-12-14T07:25:15.008Z SERIAL « 0x011a00a8000117119f039900587d294ade2e08f98b8280a58a00c56b          (28 bytes)
2022-12-14T07:25:15.009Z SERIAL » [ACK]                                                                   (0x06)
2022-12-14T07:25:15.010Z CNTRLR   [Node 023] [+] [Notification] supportedNotificationEve [Endpoint 0] [internal]
                                  nts[5]: 0
2022-12-14T07:25:15.010Z DRIVER « [Node 023] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -59 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 153
                                    └─[NotificationCCEventSupportedReport]
                                        notification type: Water Alarm
                                        supported events:
                                        · Unknown (0x00)

It reports the "Unknown" event, which is incorrect. I captured via Zniffer and confirmed it. (My server and PC clocks are ~4 seconds off).

image

Here's the re-interview where it gets corrected.

2022-12-14T07:31:35.768Z SERIAL « 0x011a00a8000117119f03cf00aadd6de8ca1da7ee7fc251984f00c18f          (28 bytes)
2022-12-14T07:31:35.769Z SERIAL » [ACK]                                                                   (0x06)
2022-12-14T07:31:35.770Z CNTRLR   [Node 023] [+] [Notification] supportedNotificationEve [Endpoint 0] [internal]
                                  nts[5]: 2
2022-12-14T07:31:35.771Z CNTRLR   [Node 023] [Notification] Water Alarm[Sensor status]: metadata up [Endpoint 0]
                                  dated
2022-12-14T07:31:35.771Z DRIVER « [Node 023] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -63 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 207
                                    └─[NotificationCCEventSupportedReport]
                                        notification type: Water Alarm
                                        supported events:
                                        · Water leak detected

Now it's reporting "Water leak detected", which results in the value being created (entity in HA). Corresponding Zniffer entry to confirm.

image

This is a clear cut device bug, isn't it? I have also reproduced this without S2 security inclusion, however the one time I did was a re-interview, not inclusion.

Attaching my driver debug logs and decrypted (I hope) zniffer file.

zwavejs_current.log zse42-s2-inclusion.zip

Ikcelaks commented 1 year ago

@kpine Do your Zniffer logs show what's happening when zwave-js is showing the device as asleep between the "protocol info" and "node info" interview stages? My guess was that the driver was assuming the device was asleep due to missing ACKs. But, missing ACKs don't seem to be the issue in these logs... the device is sending the wrong info with correct communication.

@madbrain76 My apologies for coming off as dismissive in my previous reply. The first three lines of my comment were simply a log of exactly what I did and what I observed. My "this worked fine with S2 inclusion" was simply a note that I was able to perform the firmware update while in S2, so communication was working even though the sensor didn't show up.

I didn't realize that you were on 1.40.1 at the time, so the one improvement I thought I experienced was that my re-interview after the update completed normally, and the leak sensor appeared immediately after it completed. My reading of the initial issue made me think that your re-interview initially failed, and that the sensor only showed up sometime later (presumably after the node re-awoke and completed the interview). Since I always expect to need to re-interview a Zooz 700 series device after performing a firmware update, I made the bad assumption that things were now normal. Sorry about that.

madbrain76 commented 1 year ago

@Ikcelaks , no worry. As far as the re-interview sometimes failing, that is correct. It didn't always work on the first try. It isn't reliable for me, even on firmware 1.40.1 . It never completes unless I press the Z-Wave button to wake up the device again in the middle of the interview, and the success or failure seems very dependent on timing. This is not a good user experience to be sure. and it's probably not something an average user would be able to figure out, IMO.

kpine commented 1 year ago

I submitted that as issue #5251. It's a bug somewhere, not expected behavior.

madbrain76 commented 1 year ago

@kpine, thank you for doing that ! This still leaves the question as to why the initial inclusion fails to find the sensor - the subject of this issue. Is it conclusively a firmware bug ?

kpine commented 1 year ago

I posted why Z-Wave JS does not find the sensor in https://github.com/zwave-js/node-zwave-js/issues/5247#issuecomment-1350552127. I would say it's a device bug. What could Z-Wave JS be doing that would influence the device to report a wrong value? We will probably need confirmation from Al, sometime in 2023.

madbrain76 commented 1 year ago

@kpine , thanks ! I have passed this on to Zooz support.

AlCalzone commented 1 year ago

Anything new from Zooz? I'm inclined to close this in favor of the wakeup issue, which is something we can fix unlike temporarily incorrect device reports.

madbrain76 commented 1 year ago

No news from Zooz.

AlCalzone commented 1 year ago

Ok. Let's close this issue then until there's news that points towards a driver issue.