core: Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633"
The problem
I had previously configured multiple ZWA012, AeoTec Door / Window Sensor 7 Pros to use the dry contact sensor and serve as bed presence sensors. They were working well with HA 2023.1 and correctly reporting “occupied” or “clear.” Now after running 2023.2.1+ and the latest ZWaveJS, the state of the presence sensor (binary_sensor.sams_bed_occupied) never changes. However, the state of “Door state” (sensor.sam_s_bed_door_state) does change when weight is applied to the sensor, but it changes between “Window/door is closed” and “5633.” It seems like the mapping between ZWave state and HA entities is mismatched? Reinterviewing nodes didn’t help.
The Logbook only shows updates to “door state” and not to the “occupied” sensor. It also shows “5633” instead of a friendly state:
Sam’s Bed Door state changed to Window/door is closed 11:41:10 PM - 9 minutes ago Sam’s Bed Door state changed to 5633 11:41:08 PM - 9 minutes ago
What version of Home Assistant Core has the issue?
2023.2.4
What was the last working version of Home Assistant Core?
2023.1.1
What type of installation are you running?
Home Assistant Container
Integration causing the issue
zwave-js
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zwave_js/
Diagnostics information
zwave_js-31cc309ab9532c1f73754e459f74581e-Sam’s Bed-aee5eea3d42cc10ed623be7c8974627b.json.txt
Example YAML snippet
No response
Anything in the logs that might be useful for us?
You can see the 5633 in the ZWave logs:
Subscribed to Z-Wave JS Log Messages…
2023-02-14T07:41:08.814Z SERIAL « 0x012300a800010f1a9f038c00da4abe2c3a2ad9a37d5b495d8adea96de4ef41ee9 (37 bytes)
62c00ae0a
2023-02-14T07:41:08.817Z SERIAL » [ACK] (0x06)
2023-02-14T07:41:08.818Z CNTRLR [Node 015] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2023-02-14T07:41:08.820Z CNTRLR [Node 015] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2023-02-14T07:41:08.821Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
│ RSSI: -82 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 140
└─[SupervisionCCGet]
│ session id: 43
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
state parameters: Window/door is open in tilt position
2023-02-14T07:41:08.823Z CNTRLR [Node 015] [~] [Notification] Access Control[Door state]: 23 => 5 [Endpoint 0]
633
2023-02-14T07:41:08.829Z SERIAL » 0x011d00a9010f119f030500fcbecf6080751be32060bc76c724000000000044 (31 bytes)
2023-02-14T07:41:08.830Z DRIVER » [Node 015] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 5
└─[SupervisionCCReport]
session id: 43
more updates follow: false
status: Success
duration: 0s
2023-02-14T07:41:08.837Z SERIAL « [ACK] (0x06)
2023-02-14T07:41:08.838Z SERIAL « 0x010401a90152 (6 bytes)
2023-02-14T07:41:08.838Z SERIAL » [ACK] (0x06)
2023-02-14T07:41:08.839Z DRIVER « [RES] [SendDataBridge]
was sent: true
2023-02-14T07:41:10.296Z SERIAL « 0x012200a800010f199f038d00c881d2acc5186d2ec58e01d4a4d2532466c1f3129 (36 bytes)
e00ae33
2023-02-14T07:41:10.298Z SERIAL » [ACK] (0x06)
2023-02-14T07:41:10.299Z CNTRLR [Node 015] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2023-02-14T07:41:10.300Z CNTRLR [Node 015] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2023-02-14T07:41:10.301Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
│ RSSI: -82 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 141
└─[SupervisionCCGet]
│ session id: 56
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is closed
2023-02-14T07:41:10.302Z CNTRLR [Node 015] [~] [Notification] Access Control[Door state]: 5633 => [Endpoint 0]
23
2023-02-14T07:41:10.310Z SERIAL » 0x011d00a9010f119f0306007af7d30328e4828e0cda191f0e240000000000a9 (31 bytes)
2023-02-14T07:41:10.311Z DRIVER » [Node 015] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 6
└─[SupervisionCCReport]
session id: 56
more updates follow: false
status: Success
duration: 0s
2023-02-14T07:41:10.317Z SERIAL « [ACK] (0x06)
2023-02-14T07:41:10.318Z SERIAL « 0x010401a90152 (6 bytes)
2023-02-14T07:41:10.319Z SERIAL » [ACK] (0x06)
2023-02-14T07:41:10.320Z DRIVER « [RES] [SendDataBridge]
was sent: true
Additional information
I have 3 of these sensors - they all seem to have the same issue.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 21 (11 by maintainers)
I would suggest leaving the issue open. At the minimum, the device classes should be assigned for the new sensors.