Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633" #88060

neilbrencode · 2023-02-14T07:45:59Z

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.

home-assistant · 2023-02-14T07:46:02Z

Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zwave_js can trigger bot actions by commenting:

@home-assistant close Closes the issue.
@home-assistant rename Awesome new title Change the title of the issue.
@home-assistant reopen Reopen the issue.
@home-assistant unassign zwave_js Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

zwave_js documentation
zwave_js source
_{^{(message by IssueLinks)}}

kpine · 2023-02-14T07:53:19Z

Have you already tried re-interviewing the devices? If not, can you re-interview, see if it's still an issue, and if so, include a new device diagnostic?

neilbrencode · 2023-02-14T07:59:02Z

Thanks for taking a look @kpine. I already tried reinterviewing the nodes before I filed the issue, and it didn't help. So the attached diagnostic log is from after reinterviewing.

kpine · 2023-02-14T08:11:28Z

There are two sensors related to this notification, sensor.sam_s_bed_door_state and binary_sensor.sams_bed_occupied. Is the latter one working? Are you reporting an issue only for the former?

For sensor.sam_s_bed_door_state in particular, I think you should report an issue to node-zwave-js. The current design in HA is that Z-Wave JS provides all the labels for the state values. Here's what your diagnostic shows:

          "endpoint": 0,
          "commandClass": 113,
          "commandClassName": "Notification",
          "property": "Access Control",
          "propertyKey": "Door state",
          "propertyName": "Access Control",
          "propertyKeyName": "Door state",
          "ccVersion": 8,
          "metadata": {
            "type": "number",
            "readable": true,
            "writeable": false,
            "label": "Door state",
            "ccSpecific": {
              "notificationType": 6
            },
            "min": 0,
            "max": 255,
            "states": {
              "22": "Window/door is open",
              "23": "Window/door is closed"
            }
          },
          "value": 23

Notice there is no state label for value 5633, it should be "Window/door is open in tilt position". Without that metadata, HA doesn't know what to show, so instead you get the raw value. Which is why I asked about the re-interview, which re-creates metadata.

Does the binary sensor work? HA doesn't not recognize 5633 for that either, so I think it may not report the state change to "open".

neilbrencode · 2023-02-14T08:23:04Z

The binary sensor binary_sensor.sams_bed_occupied is not working. Its state never changes. It's the sensor I use in my automations that was previously working. I had disabled the door state entity but reenabled it as part of my debugging when I could see that applying pressure to the sensor was generating traffic in the Zwave logs even though I couldn't see binary_sensor.sams_bed_occupied changing in HA.

neilbrencode · 2023-02-14T09:27:55Z

It sounds like there were recent changes in ZWaveJS to parse additional states (like that of a tilt sensor) and include that in the sensor status:
zwave-js/node-zwave-js#5453 (comment)

kpine · 2023-02-14T16:28:09Z

Yes, the addition of those new event-based states is the root cause.

Until now door sensors were only off (23) and on (22). The notification-based binary sensor design does not currently accommodate multiple states, and they also only look for "on" states. Since your device's on state has changed (from 22 to 5633), it's no longer recognized.

kpine · 2023-02-14T17:01:37Z

Also, would it be an option to disable tilt detection, and if so, can you try it (parameter 15)? It doesn't sound like tilt detection is necessary for your application? I'm curious if disabling it changes the notification at all.

Another option is to switch to using the binary_sensor.sam_s_bed_sensor_state_door_window sensor. I would expect it to be unaffected by the tilt state, is that true?

kpine · 2023-02-14T18:38:41Z

Thanks for taking a look @kpine. I already tried reinterviewing the nodes before I filed the issue, and it didn't help. So the attached diagnostic log is from after reinterviewing.

Please confirm you properly re-interviewed the device. If it's on batteries, you need to wake it up. According to the discussion post, the missing metadata is being reported to HA after a re-interview.

kpine · 2023-02-14T19:44:16Z

In summary:

Users need to re-interview the device to pickup the new door sensor state values
The original binary sensor for the door state notification no longer functions, because these devices no longer report the value 22, instead they report the tilt-state encoded versions, 5622 and 5623.
It isn't possible for Z-Wave JS to determine whether a device supports these new events or not, so they are created unconditionally
HA creates new binary sensors for the new states (open in regular position and open in tilt position), but they don't have any device classes set, because the new state values aren't included in the door sensor state mappings.

HA should include the new values in the notification mapping so the device classes are defined.

This still leaves the non-functioning binary sensor for state 22. It is undocumented, but these kinds of values are two-bytes, vs. the normal one-byte, and are encoded with the original state value in the upper byte, so HA could simply shift the values to support the original sensor (5633 >> 8 == 22, 5632 >> 8 == 22). Without supporting this behavior, door sensors that support tilt functionality no longer have a true "door open and closed" binary sensor, so users would be required to combine the two tilt sensors via a template binary sensor, or if the device supports it, use the disabled-by-default binary sensor for Binary Sensor CC. These binary sensors do not have device classes assigned either, but that could be supported.

Unfortunately, the states that are unused by a device can't be known ahead of time, so this introduces entities that never change, similar to door lock door sensors.

neilbrencode · 2023-02-15T05:43:59Z

Thanks for the investigation @kpine ! I was able to reinterview all of the impacted sensors (I had to exclude & include one as it got stuck being unable to interview). Then Binary sensors for the new state values appeared in HA. I disabled the tilt sensor and made the binary "open in regular position" sensor my presence sensor.

kpine · 2023-02-15T05:46:06Z

I would suggest leaving the issue open. At the minimum, the device classes should be assigned for the new sensors.

stickerbob · 2023-03-04T16:21:05Z

Thanks for the investigation @kpine ! I was able to reinterview all of the impacted sensors (I had to exclude & include one as it got stuck being unable to interview). Then Binary sensors for the new state values appeared in HA. I disabled the tilt sensor and made the binary "open in regular position" sensor my presence sensor.

I have done the same thing. After reconfiguration, my automations are working again. Unfortunately, this has broken the ability of my alarm panel to alert when the door is opened when armed.

kpine · 2023-03-04T16:22:03Z

Unfortunately, this has broken the ability of my alarm panel to alert when the door is opened when armed.

In what way? You'll have to elaborate.

stickerbob · 2023-03-04T16:26:03Z

Unfortunately, this has broken the ability of my alarm panel to alert when the door is opened when armed.

In what way? You'll have to elaborate.

The alarm does not trigger when the door is opened. Previously, when the door was opened the alarm entered the "triggered" state, which kicked off additional automations. The alarm remains in the "armed" state and never enters the "triggered" state when the door is opened. I am using the manual alarm control panel from the docs found here.

kpine · 2023-03-04T16:27:28Z

You'll also need to update your manual alarm control panel template to use the new entity.

stickerbob · 2023-03-04T16:28:55Z

You'll also need to update your manual alarm control panel template to use the new entity.

I'll investigate that. The strange thing is I didn't have the old entity in the configuration. I'll report back if I figure it out.

kpine · 2023-03-04T16:30:23Z

Then it seems you are missing some entity change somewhere, Whatever is responsible for triggering the alarm state hasn't been updated.

stickerbob · 2023-03-04T16:36:24Z

Then it seems you are missing some entity change somewhere, Whatever is responsible for triggering the alarm state hasn't been updated.

You are 100% correct. You got me thinking about how my trigger was set to fire. I quickly found an automation that uses a sensor group to enter the alarm into the "triggered" status. After updating the entity in the group, the alarm began functioning as expected. Thanks for the push. I have configured so much in the past two months since putting this together it's all running together on me. Once I re-interview my additional doors/windows and update my group entities, I'll be back in business. Thanks for everything you do!

kpine · 2023-04-09T21:24:39Z

With Z-Wave JS v10.13.0 there is now a "simple" value that restores the previous behavior, where the entity state will be "on" if the door is open no matter which state it is (open, regular position, tilt position). There is no change necessary in HA to support this, and I don't think you even need to re-interview.

However, HA does not have any special discovery logic or naming for this new sensor, so it will appear identical in naming to the existing one (original name). Therefore, there will be a total of 4 entities. Depending on the device, some will have duplicate functionality (open/close and simple), and some not work at all (regular position, tilt position). You can just disable the entities that aren't useful. To determine which entity corresponds to the "Simple" value, you can download the device diagnostic and find the binary_sensor entity that maps to "Door state (simple)".

issue-triage-workflows · 2023-07-08T22:06:00Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

home-assistant bot added the integration: zwave_js label Feb 14, 2023

neilbrencode closed this as completed Feb 15, 2023

neilbrencode reopened this Feb 15, 2023

kpine mentioned this issue Mar 2, 2023

Doorsensor Aeotec ZWA011 working incorrectly since last update zwave-js/node-zwave-js#5517

Closed

11 tasks

kpine mentioned this issue Apr 9, 2023

Duplicate Aeotec Door / Window Sensor 7 (Pro) zwave-js/zwave-js-ui#3042

Closed

issue-triage-workflows bot added the stale label Jul 8, 2023

issue-triage-workflows bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 15, 2023

github-actions bot locked and limited conversation to collaborators Aug 15, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633" #88060

Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633" #88060

neilbrencode commented Feb 14, 2023 •

edited

Loading

home-assistant bot commented Feb 14, 2023

kpine commented Feb 14, 2023

neilbrencode commented Feb 14, 2023

kpine commented Feb 14, 2023 •

edited

Loading

neilbrencode commented Feb 14, 2023

neilbrencode commented Feb 14, 2023

kpine commented Feb 14, 2023

kpine commented Feb 14, 2023 •

edited

Loading

kpine commented Feb 14, 2023

kpine commented Feb 14, 2023

neilbrencode commented Feb 15, 2023

kpine commented Feb 15, 2023

stickerbob commented Mar 4, 2023 •

edited

Loading

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Apr 9, 2023

issue-triage-workflows bot commented Jul 8, 2023

Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633" #88060

Aeotec ZWA012 using dry contact sensors no longer updates occupied state and instead sets "door state" to "5633" #88060

Comments

neilbrencode commented Feb 14, 2023 • edited Loading

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Diagnostics information

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

home-assistant bot commented Feb 14, 2023

kpine commented Feb 14, 2023

neilbrencode commented Feb 14, 2023

kpine commented Feb 14, 2023 • edited Loading

neilbrencode commented Feb 14, 2023

neilbrencode commented Feb 14, 2023

kpine commented Feb 14, 2023

kpine commented Feb 14, 2023 • edited Loading

kpine commented Feb 14, 2023

kpine commented Feb 14, 2023

neilbrencode commented Feb 15, 2023

kpine commented Feb 15, 2023

stickerbob commented Mar 4, 2023 • edited Loading

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Mar 4, 2023

stickerbob commented Mar 4, 2023

kpine commented Apr 9, 2023

issue-triage-workflows bot commented Jul 8, 2023

neilbrencode commented Feb 14, 2023 •

edited

Loading

kpine commented Feb 14, 2023 •

edited

Loading

kpine commented Feb 14, 2023 •

edited

Loading

stickerbob commented Mar 4, 2023 •

edited

Loading