Can't include Hank HKZW-SO01 smartplug securely

Configuration Z-Wave
,
1

I bought three of the above smartplugs. They have firmware revisions 1.5, 1.5 and 1.6 . The manual is at blob:https://homeassistant.localdomain:8123/db34864a-b72e-46b8-b2df-f401710e2481 .

This is an older device that supports S0 encryption, not S2. There is no DSK or Smartstart code.

Last week, I was able to add one of the three smartplugs, with rev 1.5, securely.

Today, I tried the other two, and I am not having any luck with the security. It works fine if I include in non-secure mode with the triple tap of the button.

If I set Z-Wave JS UI in default mode + prefer encryption, and hold the button for over 3 seconds, ZUI reports that the inclusion failed after 30 seconds. However, the device thinks inclusion actually succeeded. Its LED no longer blinks, indicating it has been successfully included in a Z-Wave network. ZUI does not show the device in the list of nodes, though. But after restarting the add-on, it does show it. Unfortunately, without security.

I have tried repeating the inclusion process using the “S0 encryption” inclusion option, but I did not get any better results. I’m banging my head against the wall on this one. I don’t know why the first smartplug worked last week and what I did differently. I was on ZUI 3.x, though, and I just upgraded to ZUI 4.0.

Here is a Z-Wave JS log of today’s many tribulations with the Hank devices.

Edit: it looks like the following error is likely the issue :

2025-03-24T07:15:09.919Z CNTRLR   [Node 204] Timed out while waiting for a response from the node (ZW0201)
2025-03-24T07:15:09.920Z CNTRLR   [Node 204] The node was not granted the S0 security class. Continuing intervie
                                  w non-securely.

As I mentioned, one of the 3 smartplugs did add securely.
It is node 185. It was added on 3/21. Here is the log that has its successful S0 inclusion.

It looks like it was started with strategy “default”.

2025-03-21T17:09:30.740Z CNTRLR Starting inclusion process with strategy Default...

And then shortly after, I see :

2025-03-21T17:09:59.572Z CNTRLR [Node 185] Security S0 bootstrapping successful

I’m going to reset the 2 problematic plugs and try one more time with the “default” strategy, without checking the “force security” box.

2

It’s really hard to read your logs because you’ve enabled Silly mode. Just a reminder:

S0 is generally not recommended for non-security devices. It’s why the Default strategy will never use S0 encryption on these devices. The “force encryption” option turns it on. So either you need to turn on the flag or use the S0 inclusion method, result is the same.

You need a really strong mesh to use S0, as there are 3x as many messages compared to insecure or S2. I’d recommend either leaving these as insecure and using with non-security devices, or upgrade to plugs that support S2.

1 Like
3

Thanks for your reply.

I don’t believe I’m using silly mode logging. I changed it to debug mode weeks ago when you told me to do so.

I was trying to add the 3 plugs 3-5ft from the stick. I wasn’t expecting a signal issue. One of them worked fine in S0. The other 2 only worked in insecure mode from the exact same location.

Good to know about the traffic requirement for S0 devices. What are the implications of running in insecure mode ? Can basically anyone with a Zwave radio with range gain access to the device ?

Screenshot_20250324_143159_Home Assistant
Screenshot_20250324_143159_Home Assistant1440Ă—3088 267 KB

4

Your logs have a bunch of these translateValueEvent messages, which are only added for Silly mode. These basically make it harder to pick out the interesting and relevant parts.

2025-03-24T07:01:36.183Z CNTRLR   [Node 200] [translateValueEvent: value added]
                                    commandClass: Node Naming and Location
                                    endpoint:     undefined
                                    property:     location
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined

Then maybe something else is happening. Would be better to have logs that are focused on a single device during inclusion, in Debug (not Silly), so we don’t have to sift through everything.

Yes, theoretically possible. Ever heard of it happening? It’s super easy to sniff the traffic with a Zniffer. It’s much harder to send commands, but possible. The likelihood that both 1) someone has crafted a Zniffer (z-wave sniffer) that is also capable of sending commands and 2) they are monitoring and controlling your traffic is near 0%. I don’t have any problem including a light insecurely (I do it in one case for associations). I would never do that with my Garage door opener though.

5

Hi,

I am continuing to get these “translateValueEvent” messages in my logs, despite setting the log level to Debug weeks ago. It is definitely not set to Silly. Is there more than one place where it needs to be set ? Perhaps once for the UI part, and another for the driver part ?

There is definitely something else happening with the inclusion. I will provide the required logs once I figure out how to disable Silly mode.

No, of course I haven’t heard of it happening, but I’m not sure if I would have if it happened. My garage opener relay, a Zooz ZEN16, uses S2 auth security. However, the two TILTZWAVE2 sensors, which report the open/close status of each garage door, don’t support any security at all. ZUI reports them as TILTZWAVE1, without Z-Wave + or security. Whereas the box clearly said they are Z-Wave +. I also have not figured how to convert the status from On/Off to Opened/Closed, despite doing quite a bit of reading on the template sensor. My template says both doors are always closed, sigh. Anyway, I have wanted to create an automation that would close the doors automatically if left open for too long. But if the sensor state could be spoofed to mark the door as open instead of closed, the automation would then open the door rather than close it, despite the relay using S2. Maybe it’s a contrived attack case, but 28 years developing network security code (mainly PKI & TLS) can’t help but make me paranoid.

In any case, I want to use these smartplugs to turn network devices on and off. This is primarily due to various bugs in them that require a reboot to clear. Things like Wifi AP mesh priorities not being ignored. Major changes to the DHCP table requiring reboots of all the unmanaged switches. Rebooting the cable modem or wired router when needed. I cannot use any IP-based smartplugs, whether wired or wireless, to power all these devices on and off. I still have some old X10 stuff that I retired due to the PLC signal just not being reliable enough with all the electronics I have. Z-Wave is an order of magnitude more reliable, though still problematic in some cases. So, I wanted to use these smartplugs. But turning off my cable modem, router and all Wifi APs would mean that even my battery-backed alarm would drop off from Wifi. It’s got cell backup, but the cell signal inside the house is spotty and weather dependent, so that backup could fail. I’m far more concerned about fire than about theft, though. I know we have repeatedly left many of our 11 outside doors closed but unlocked, for untold periods of time, probably days or even weeks, I just have no idea, since we don’t go through each door every day. We installed 7 HC620 Smartlock mainly so that we can know that all these doors are actually locked, not really to control them remotely, although that feature is nice to have while already in the car if some are unlocked. Same reason we want to detect and turn off any lights that might have been left on accidentally.

While it’s rather unlikely somebody is going to compromise my insecure tilt sensors, or turn off all of the network equipment during a fire, it still isn’t impossible, and I would prefer to have the level of security at least a notch above plain-text. It’s too bad that S0 creates too much traffic. That will definitely be problematic in my large Z-Wave network. I expect to run into the 256 Z-Wave node limit some day. Z-Wave LR lifted the node limit, but unfortunately is less reliable for me, due to not supporting mesh. There are many spots where the direct connection to the controller with LR is just too weak, and nodes go dead.

6

I still get these translateValueEvent messages in the log even after switching to log level of “Error”. What am I missing ?

7

Are you sure you’ve configured it in the right place?

8

I’m doing it under settings / general in ZUI.
I have log enabled checked , and log level at Error. Is there another place I’m missing ?

9

Settings → Z-Wave

10

Thank you very much ! That was it.

I just couldn’t find it by browsing the UI. I use large fonts due to macular degeneration, and the log options are at the bottom, after the keys. The scroll bars used by HA / ZUI are also the thin kind, which makes them difficult for me to notice due to the same vision problems. I wasn’t certain there was another log setting, but even guessing that there was, I didn’t know to scroll down to find this setting, and would not have found it without your help. I think there is at least one accessibility issue here with the thin scroll bars. And perhaps the organization of the settings could use some review, but I’m by no means a UI/UX person.

Now, coming back to the subject of this thread, how would I go about collecting the logs just for a specific device I’m trying to include with S0 security ?

11

I never noticed the scroll bars were so thin. As someone without much vision problems, I still find them barely usable. I would prefer the normal scrollbars myself. You might consider submitting an issue at GitHub - zwave-js/zwave-js-ui: Full featured Z-Wave Control Panel UI and MQTT gateway. Built using Nodejs, and Vue/Vuetify.

For the logs there’s a node filter, but if you’re looking for assistance from others it’s best to just collect all the logs.

1 Like
12

Thank you ! I will open a ticket on the thin scroll bars. It’s a really difficult issue not specific to ZUI, though. I face it in a lot of programs. Likely driven by the use of mobile devices with small screens. There should be a choice or adjustment.

Back to this device issue, I tried it again.

  1. plugged in the device
  2. started inclusion with force security in ZUI
  3. tapped the device button 3 times, per the instructions in section III at https://opensmarthouse.org/zwavedatabase/570/reference/hank-z-wave-plus-smart-plug-HKZW-SO01-manual.pdf .
  4. the device LED stopped blinking, indicating that it had joined the network
  5. ZUI reported that inclusion failed, and the new device / node did not appear in ZUI
  6. at that point, the z-wave js log also had no trace of any new node or interview . See zwavejs_current-9.log - Google Drive for the state of the log at that point.
  7. in HA, I restarted the ZUI add-on
  8. in ZUI, there is now a new node showing for the Hank device, node 223, but it has no security
  9. after inspecting the updated log, there is discovery of node 223, and an interview of that node . See zwavejs_current-10.log - Google Drive .

I am also adding one more log for the non-secure inclusion.

  1. I first excluded node 223.
  2. I then requested default inclusion in HA
  3. I unplugged and plugged the device back in
  4. It included successfully, insecurely, and became node 224. This time, no restart of ZUI was needed to see the node/device. It showed up instantly in the UI and log : zwavejs_current-11.log - Google Drive

The last test was to request S0 encryption inclusion in ZUI
14. I excluded node 224
15. I unplugged and plugged the device back in
16. I requested S0 encryption inclusion in ZUI
17. I tapped the device button 3 times
18. ZUI inclusion got stuck in the browser for several minutes on the screen “Inclusion is started. Please put your device in INCLUSION mode”.
19. I opened a separate HA/ZUI window, and downloaded the log once again at this step. A copy is at zwavejs_current-12.log - Google Drive
20. I restarted ZUI
21. The device now showed up as node 225, but still without security, just the same as in step 8 .
22. A copy of the final log is included at zwavejs_current-13.log - Google Drive .

There are several problems here.

a) the failed inclusion in steps 1 through 7, the device inclusion was mangled, and it only appeared after I restarted ZUI.

b) in steps 1 - 7, the node still did not get included with S0 security, despite the requested secure inclusion, and following the manufacturer instructions

c) in steps 16 - 19, the device inclusion was mangled, and it only appeared after I restarted ZUI

d) in steps 16 - 19, the node still did not get included with S0 security, despite the requested secure inclusion, and following the manufacturer instructions

Most likely, the 2 separate secure inclusion procedures I followed for steps 1-7 and 16- 19 result in similar if not identical behavior in Z-Wave JS.