search

zwave-js / node-zwave-js

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

Security S2 bootstrapping failed: a secure inclusion timer has elapsed - During manual and SmartStart inclusion #7085

Closed baudneo closed 1 month ago

baudneo commented 1 month ago

Checklist

Deploy method

Docker

Z-Wave JS UI version

9.16.4.394bd02

ZwaveJS version

13.0.2

Describe the bug

This is my first experience with zwave so I am unsure if I am missing something obvious. I have tried asking for help on other platforms and have not been able to solve my issue, so I figured I would come here. Apologies if this isn't the correct place for this.

Controller: ZooZ ZAC93 GPIO 800LR (Serial connection)

Device: Weiser (KwikSet) Home Connect 620 Lock

I only have 2 zwave devices, both are the same make/model door locks, and both are exhibiting the same issues when trying to add them to the zwave network. The same error occurs when manually adding or using SmartStart.

When the lock is added, it has no encryption (meaning no lock/unlock abilities) and shows up as 'Unknown Product/Manufacturer'. If it is added using SmartStart, the controller keeps trying to add the node, leaving dead nodes in its wake. zwave-js

I have tried different config options (the increased node report timeout) without success. I upgraded the controller firmware from 1.00->1.10->1.20 using zwavejs-ui, so I don't think it's a hardware or comms issue, but not counting it out.

At first, I was using the HASS add-on. I switched to the docker method, so I could open an issue. The same error is occurring on both.

To Reproduce

For me, it's as simple as try and add a device manually or using SmartStart.

Expected behavior

I am hoping that the locks will be added with encryption so I can add them and use them via HASS as locks.

At the moment the locks are useless as they require at least S0 encryption to expose lock/unlock entities.

Additional context

zwavejs_2024-08-04.log node_7_dump.json node_7.json

baudneo commented 1 month ago

I'm wondering if this is a device issue? I have no reference for what a successful S2 negotiation looks like (and what a device should be replying with) so I can't really say.

Both locks have the same symptoms, which means either both locks have firmware/hardware issues or there's something going wrong on the controller end and I am absolutely unsure.

Most info I have been able to find doesn't show this error. I am aware that there is a SDK issue that causes stalled tx, but this doesn't seem like a stalled tx as the controller seems to be working after the timeout failure.

ATM, I have the ZAC93 in a ser2net set up. I have an esp8266 nodemcuv2 board as the host running a serial TCP server. The ZAC93 is connected to a hardware UART and is the only thing attached, no other sensors or processing is occurring on the esp8266.

I may try an esp 32 c3 (or s3) just to see if anything changes. I can also hook the ZAC93 up to a pi 0 w2 or use a usb-ttl adapter and connect the ZAC93 to a desktop for testing.

Just looking for any advice, I have posted to other places (HASS forums) and not received much insight. I have not contacted zooz yet. I do see that the USB version of the 800LR controller also seems to have the same issues I am experiencing and just seems to randomly fix itself/come back: https://community.home-assistant.io/t/why-is-z-wave-inclusion-so-hard/735858/52

Thanks for any advice or insight into my problem!

danielsza commented 1 month ago

it doesn't look like zooz has released a new firmware for the GPIO version of the 800 controller yet.. hopefully they do soon.

I'm running my controller PoE as well using this kit https://tubeszb.com/product/z-wave-poe-kit/ which is a ESP32 and it works well. I'm using it with the Razzberry Pro 7 though. Which has newer firmware.

I have the same HC620 locks. They can be a bit of a pain to get included. But they do include. I had to exclude / reinclude a few times, and try to keep the lock awake during the interview.

it was about a year ago, so I can't recall what I did, if it was only pressing the zwave button or removing / re-inserting the batteries.

either way it took a few times, and one lock was worse then the other to get working correctly.

AlCalzone commented 1 month ago

The only odd thing I see is that during the key exchange, the device asks for a nonce twice in short succession while the first response is still being sent.

The confirmations from the controller about sending the frames are also a tad slow 300-500ms after initiating the transmit, where I'm more used to single-digit ms. Maybe the serial over IP bridge artificially slows down the communication to the point where it interferes with Z-Wave traffic. When you are saying esp8266 HW, do you mean you connect to the controller over Wifi or Ethernet?

baudneo commented 1 month ago

The only odd thing I see is that during the key exchange, the device asks for a nonce twice in short succession while the first response is still being sent.

The confirmations from the controller about sending the frames are also a tad slow 300-500ms after initiating the transmit, where I'm more used to single-digit ms. Maybe the serial over IP bridge artificially slows down the communication to the point where it interferes with Z-Wave traffic. When you are saying esp8266 HW, do you mean you connect to the controller over Wifi or Ethernet?

As it turns out, it was the esp8266. I am unsure why it acts that way (seems fine but is secretly having issues)

I switched to an esp32-s3 super mini and all is well now. The esp8266 only showed z-wave as an available protocol, with esp32-c3, it shows z-wave and LR. The first attempt ata Yale.inclyaion worked for both locks after switching.

I had the esp8266 using its hardware UART and turned esphome logging off on the HW uart, so it shouldn't be having any bg noise on the UART. Very strange behavior, but all is well now!

Thanks!