Z-wave JS Add-On Issues Every Update

Configuration Z-Wave
#1

Every time I update the Z-wave JS add-on; I have to fight to get my Aeotec Door/Window sensors to work again in Home Assistant.
I can open/close the sensors & see data updating in the Z-wave JS add-on logs but I do not see the sensor values updating in Home Assistant specifically.
It only affects 2 Aeotec Door/Window sensors; I have Aeotec plug switches that updating does not break & it also does not effect my ZCOMBOS ironically. Just the door sensors.
I am only using the Z-Wave JS Add-on; as of this moment I am not using Z-wave2mqtt. I was using that but I was having the same issue then so I switched to just using the JS add-on.

Z-Wave JS: Current version: 0.1.76
Home Assistant 2023.2.5
Supervisor 2023.01.1
Operating System 9.5
Frontend 20230202.0 - latest

#2

Subscribed to Z-Wave JS Log Messages…
2023-02-22T00:50:35.543Z SERIAL « 0x01220004000e1a9f033100a5d5aff91f0725d07be5562cc9811e1cbe60deac28e (36 bytes)
bc100ab
2023-02-22T00:50:35.547Z SERIAL » [ACK] (0x06)
2023-02-22T00:50:35.547Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmType
propertyKey: undefined
internal: false
secret: false
event source: undefined
2023-02-22T00:50:35.548Z CNTRLR [Node 014] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2023-02-22T00:50:35.548Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:35.548Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmLevel
propertyKey: undefined
internal: false
secret: false
event source: undefined
2023-02-22T00:50:35.549Z CNTRLR [Node 014] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2023-02-22T00:50:35.549Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:35.549Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
└─[Security2CCMessageEncapsulation]
│ sequence number: 49
└─[SupervisionCCGet]
│ session id: 0
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
state parameters: Window/door is open in regular position
2023-02-22T00:50:35.550Z CNTRLR [Node 014] [handleNotificationReport] notificationName: Access Control
2023-02-22T00:50:35.550Z CNTRLR [Node 014] [handleNotificationReport] valueConfig:
label: Window/door is open
type: state
variableName: Door state
2023-02-22T00:50:35.551Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: Access Control
propertyKey: Door state
internal: false
secret: false
event source: undefined
2023-02-22T00:50:35.551Z CNTRLR [Node 014] [~] [Notification] Access Control[Door state]: 23 => 5 [Endpoint 0]
632
2023-02-22T00:50:35.551Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:35.555Z SERIAL » 0x011800130e119f03450013ccb7fdc6779f355466849caa240018 (26 bytes)
2023-02-22T00:50:35.555Z DRIVER » [Node 014] [REQ] [SendData]
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 69
└─[SupervisionCCReport]
session id: 0
more updates follow: false
status: Success
duration: 0s
2023-02-22T00:50:35.557Z SERIAL « [ACK] (0x06)
2023-02-22T00:50:35.564Z SERIAL « 0x0104011301e8 (6 bytes)
2023-02-22T00:50:35.565Z SERIAL » [ACK] (0x06)
2023-02-22T00:50:35.566Z DRIVER « [RES] [SendData]
was sent: true
2023-02-22T00:50:37.384Z SERIAL « 0x01210004000e199f0332008c084c55fefd32623c91460971b411dfc81f2b64b8b (35 bytes)
c00d8
2023-02-22T00:50:37.387Z SERIAL » [ACK] (0x06)
2023-02-22T00:50:37.387Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmType
propertyKey: undefined
internal: false
secret: false
event source: undefined
2023-02-22T00:50:37.388Z CNTRLR [Node 014] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2023-02-22T00:50:37.388Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:37.389Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmLevel
propertyKey: undefined
internal: false
secret: false
event source: undefined
2023-02-22T00:50:37.389Z CNTRLR [Node 014] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2023-02-22T00:50:37.389Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:37.390Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
└─[Security2CCMessageEncapsulation]
│ sequence number: 50
└─[SupervisionCCGet]
│ session id: 7
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is closed
2023-02-22T00:50:37.391Z CNTRLR [Node 014] [handleNotificationReport] notificationName: Access Control
2023-02-22T00:50:37.391Z CNTRLR [Node 014] [handleNotificationReport] valueConfig:
label: Window/door is closed
type: state
variableName: Door state
2023-02-22T00:50:37.392Z CNTRLR [Node 014] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: Access Control
propertyKey: Door state
internal: false
secret: false
event source: undefined
2023-02-22T00:50:37.392Z CNTRLR [Node 014] [~] [Notification] Access Control[Door state]: 5632 => [Endpoint 0]
23
2023-02-22T00:50:37.392Z CNTRLR [Node 014] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2023-02-22T00:50:37.395Z SERIAL » 0x011800130e119f034600c4357db1bd5829aee395a0c7f12400aa (26 bytes)
2023-02-22T00:50:37.396Z DRIVER » [Node 014] [REQ] [SendData]
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 70
└─[SupervisionCCReport]
session id: 7
more updates follow: false
status: Success
duration: 0s
2023-02-22T00:50:37.398Z SERIAL « [ACK] (0x06)
2023-02-22T00:50:37.404Z SERIAL « 0x0104011301e8 (6 bytes)
2023-02-22T00:50:37.405Z SERIAL » [ACK] (0x06)
2023-02-22T00:50:37.405Z DRIVER « [RES] [SendData]
was sent: true

#3

Diagnostics

Driver Version:10.10.0
Server Version:1.26.0
Server URL:ws://core-zwave-js:3000

The only error messages that I can see in the log viewer are such as but I don’t understand how my switches & zcombos are working then.

2023-02-21 18:45:26.985 WARNING (MainThread) [homeassistant.config_entries] Config entry ‘Z-Wave JS’ for zwave_js integration not ready yet: Failed to connect: Cannot connect to host core-zwave-js:3000 ssl:default [Connect call failed (‘172.30.33.6’, 3000)]; Retrying in background

2023-02-21 18:54:25.070 WARNING (MainThread) [homeassistant.config_entries] Config entry ‘Z-Wave JS’ for zwave_js integration not ready yet: Failed to connect: Cannot connect to host core-zwave-js:3000 ssl:default [Connect call failed (‘172.30.33.6’, 3000)]; Retrying in background

#4

Are you sure your problem is “every time you update”? How often has this been happening?

At least in this particular case, it’s only something that would be seen in the latest add-on version, 0.1.76, not any version before (Z-Wave JS v10.6.0 and later). Maybe just bad luck. Anyways, here’s the relevant log:

2023-02-22T00:50:35.549Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
└─[Security2CCMessageEncapsulation]
│ sequence number: 49
└─[SupervisionCCGet]
│ session id: 0
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
state parameters: Window/door is open in regular position

HA does not currently support the state "Window/door is open in regular position", which was added recently to Z-Wave JS. This currently affects at least the Aeotec Door Sensor 7 Pro. The HA binary sensor will be stuck in the “closed” state. See this issue and related discussion for cause and workarounds, which involve using other sensors than the one you are likely using now. After reviewing those, if you are unable to workaround it, let us know. Be sure to do the re-interview to get the new sensors.

These errors will always occur when you update the add-on. In order to update the add-on, it downloads a new version, installs it and restarts it. When the add-on is restarted, HA loses connection to the web socket server and will reconnect later. As long as the integration is currently connected, those past errors can be ignored.

#5

Thank you for the response; usually in most cases I have seen this issue present after a z-wave.js update. I’ll note that prior to this update I was using the zwave2mqtt plugin but I figured that I would troubleshoot item-by-item. Previously the issue would surprisingly just go away after a bit or sometimes I would have to go thru & exclude then re-interview the devices.
You may be right & this is just an anomaly that ironically has presented specific to that sensor that seems to have been up to this point a culprit.
I will review that discussion doc & work thru the re-interview process also.
Thank you kindly

#6

I have the same issue after the last update of Zwave JS UI. The Aetoec Door Sensor 7 zwave categories have changed. I had to change the event to “Window/door is open in regular position” in my automations. Before it was “window_door_is_open” but this one is not anymore updated after the update. Indeed the values for window_door_is_open changes but are not well mapped by the zwave ui to generate the off/on values.

#7

0.1.76 was a complete fail for me. All things Zwave stopped working and no amount of reloads/reboots/unplugging USB dongle could get things working again. I rolled back to 0.1.75 and it immediately started working again.