Aeotec Window/Door Sensor Pro 7 / ZWA012 HA Issue

[jdiegmueller]

Hello! I'm having trouble with Aeotec Window/Door Sensor Pro 7 / ZWA012 sensors, and am not sure which component to report the problem on (ZwaveJS vs Homeassistant). Could someone point me in the right direction? At the moment I'm running ZWaveJS 10.10.0+ZWaveJS-UI 8.8.5 on a Pi4, and HA 2023.2.3. HA talks to ZWaveJS via WS integration.

So I have fourteen of these ZWA012s, but I am only having trouble with the newer sensors that run the 2.x firmware. Aeotec's firmware page has a warning advising that there are two different hardware revisions, and that 1.x and 2.x are not compatible with one another.

The issue I'm having is that the sensors running 2.x do not reflect open/closed in Home Assistant on the typical "window/door is open" entity.

When a 1.x device opens, ZWaveJS logs the following + the "window/door is open" entity changes to open:

2023-02-11T00:07:43.082Z SERIAL » [ACK]                                                                   (0x06)
2023-02-11T00:07:43.084Z CNTRLR   [Node 140] [~] [Notification] alarmType: 0 => 0                   [Endpoint 0]
2023-02-11T00:07:43.091Z CNTRLR   [Node 140] [~] [Notification] alarmLevel: 0 => 0                  [Endpoint 0]
2023-02-11T00:07:43.095Z DRIVER « [Node 140] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -92 dBm
                                  └─[NotificationCCReport]
                                      notification type:   Access Control
                                      notification status: 255
                                      notification state:  Window/door is open
2023-02-11T00:07:43.098Z CNTRLR   [Node 140] [~] [Notification] Access Control[Door state]: 23 => 2 [Endpoint 0]
                                  2

When a 2.x device opens, ZWaveJS logs the following + the "window/door is open" entity changes is unchanged:

2023-02-11T00:09:12.659Z SERIAL » [ACK]                                                                   (0x06)
2023-02-11T00:09:12.662Z CNTRLR   [Node 192] [~] [Notification] alarmType: 0 => 0                   [Endpoint 0]
2023-02-11T00:09:12.666Z CNTRLR   [Node 192] [~] [Notification] alarmLevel: 0 => 0                  [Endpoint 0]
2023-02-11T00:09:12.669Z DRIVER « [Node 192] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -88 dBm
                                  └─[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-11T00:09:12.684Z CNTRLR   [Node 192] [~] [Notification] Access Control[Door state]: 23 => 5 [Endpoint 0]
                                  632

The "open in regular position" does flow back to an entity in HA, but that still isn't enough to make the "window/door is open" entity state change. I've tried disabling the tilt sensor, but no change in behavior. While the 1.x devices do all show in ZWaveJS-UI as having the tilt sensor enabled, I am not completely confident there even is one in the 1.x hardware because I can't get the 1.x sensors to tell me if they're opened normally or tilted.

Does this sound like something I should pursue here, or over on the HA side of the house? Or given the difference in 1.x and 2.x hardware capabilities, maybe both?

Thanks.

[AlCalzone]

Have you tried re-interviewing the 2.x device? I very recently added support for parsing these kinds of state parameters, and the information that the value exists may not be stored yet.
If that doesn't help, I think this needs a fix on the HA side of things.

[AlCalzone]

entities which represent states that are impossible not get created

Which requires knowing that they are impossible. #5453 (reply in thread)

[AlCalzone]

HA could solve it by simply toggling the default binary sensor (for state 22) to "on" when value >> 8 == state (22). However, there's no way to how and when to shift w/o knowing the implementation details.

This isn't documented, but all enum values which share the same base event have the same high byte: 0x16, 0x1600, 0x1601. All 1-byte values are the actual notification events, the 2-byte ones are a combined event+enum. So a "window" open state can be determined by looking at the high byte, even if the value has a different byte size.

[jdiegmueller]

Probably related: I also now see a motion sensor entity showing up in HA on Node 192?: Outside Garage Wall Cabinet Door Sensor Right Motion detection (location provided). I do not see this in HA on Node 140.

I have a better understanding that omitting the "impossible states" is a bigger problem than I realize with regards to open/closed/open regular/open tilt .. but what about this motion sensor bit I mentioned started showing up on the ZWA012 v2.x firmware devices?:

[AlCalzone]

but what about this motion sensor bit I mentioned started showing up on the ZWA012 v2.x firmware devices?

That's because the device reports that it supports event 7 for notification type 7, not event 3 like the manual claims:

010e00a80001c005710207018000a7cf
                    ^^  ^^
                    ||  bit mask 0b1000_0000, bit 7 = Motion detection (location provided)
                    notification type 0x07 = Home Security

[jdiegmueller]

but what about this motion sensor bit I mentioned started showing up on the ZWA012 v2.x firmware devices?

That's because the device reports that it supports event 7 for notification type 7, not event 3 like the manual claims:

010e00a80001c005710207018000a7cf
                    ^^  ^^
                    ||  bit mask 0b1000_0000, bit 7 = Motion detection (location provided)
                    notification type 0x07 = Home Security

Ok, cool. I'll see if I can get Aeotec's attention on this, perhaps we can get it fixed in a future v2.x firmware.

Thanks again, everyone who weighed in here.

[jdiegmueller]

Thank you both for weighing in on this. Appreciate it.

[matthijsvdr]

And I just ran into the same problem 😑 any chance you have an update ? 😄

[Jusdem]

Is this an issue with Aeotec firmware or an update to HA integration? Im also having this issue.