Zooz ZSE43 Doesn't Report Tilt and Acceleration Correctly

[brimmasch]

The problem

The device supports acceleration and tilt. Because of this I would expect to see an acceleration entity and one or two tilt/position entities. Instead, when the device is tilted the events show up as two contact entities. So if a decision was made to make tilt show up as contact... that's fine I guess. However, it doesn't need to be two contact entities. Just one. I would prefer it to not use contact though. It's not a contact device. It's a tilt and shock sensor.

When the device is accelerated it shows up as a tamper. There are two entities meant for acceleration, "${name} Window/door is open in regular position" and "${name} Window/door is open in tilt position", but they aren't updated. Instead, acceleration events just show up as tamper events. So, the two entities for acceleration should probably either not exist or be used instead of the tamper entity.

What version of Home Assistant Core has the issue?

core-2023.11.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

zwave_js

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zwave_js

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I have removed and reincluded the device many, many times. It always ends up like this which is wrong.

[home-assistant]

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 Renames 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]

I've commented on this device before: #98738 (comment).

FYI, when you submit an issue please provide this information that is being asked for:

It would be easier to explain the quirks of this device with a diagnostic file. You can download the diagnostic file by going to Settings -> Devices & services -> Z-Wave "Devices" -> The Device -> Device info -> ... -> Download diagnostics.

Since you have a good idea of how you think this device should work, let me explain in detail why it currently works the way it does. Keep in mind that I'm just explaining how this device and the integration work, and I am not arguing for any specific position.
I'm just another community member who helps out with Z-Wave issues, I am not a decision maker.

So if a decision was made to make tilt show up as contact... that's fine I guess.

There's no intent on the part of HA here. The device reports that it supports door sensor notifications, that's all. The door sensor notifications are part of the Z-Wave specification (Notification CC), which is what those door sensor entities are based on. It sounds like Zooz implemented tilt using open/close notifications. If a device reports that it supports door open/close, HA creates the appropriate entities.

However, in your list of disabled entities is an actual binary_sensor for tilt, this is based on the Binary Sensor CC. You can enable and use that instead and disable the door sensors, if that's your preference they are essentially the same. That entity is disabled by default due to an integration design decision: Binary Sensor CC is disabled by default when a device also supports Notification CC, as the former is deprecated and the latter is its replacement.

When the device is accelerated it shows up as a tamper.

There is no acceleration or shock notification/sensor values provided by the Z-Wave specification. So presumably Zooz re-purposed the tamper sensor for this purpose (you can confirm with their support). Similarly to the door sensors, the tamper sensor entity exists because the device reports a tamper sensor, and HA has no way to know the functionality has been changed.

There are two entities meant for acceleration, "${name} Window/door is open in regular position" and "${name} Window/door is open in tilt position", but they aren't updated.

This is a known issue: zwave-js/certification-backlog#23, but these entities are not intended for acceleration, they are for door sensors that also can report their position based on tilt. The Z-Wave specification does not provide any means for the application to know whether a device with a door open/close sensor also supports tilt position, so they are always provided. See also #88060 for more discussion.

The device supports acceleration and tilt. Because of this I would expect to see an acceleration entity and one or two tilt/position entities.

Yes, that would be ideal, but to setup the device in the way you've proposed would require logic that is tailored specifically for this Zooz device. This is common in some other automation systems like SmartThings, which re-implement entire "device handlers" for many different products. In comparison, Z-Wave JS and HA have fairly generic implementations that are based on the Z-Wave specification, so device-specific customization is rare. (Again, I'm not a decision maker, so I can't say whether this could be added or not.)

I have removed and reincluded the device many, many times. It always ends up like this which is wrong.

Since the device information never changes, re-including the device will have no effect, it will be configured the same way every time.

[brimmasch]

I've commented on this device before: #98738 (comment).

thanks, i'll try to be more aware of previous issues.

Since you have a good idea of how you think this device should work, let me explain in detail why it currently works the way it does. Keep in mind that I'm just explaining how this device and the integration work, and I am not arguing for any specific position. I'm just another community member who helps out with Z-Wave issues, I am not a decision maker.

appreciate your help

There's no intent on the part of HA here. The device reports that it supports door sensor notifications, that's all. The door sensor notifications are part of the Z-Wave specification (Notification CC), which is what those door sensor entities are based on. It sounds like Zooz implemented tilt using open/close notifications. If a device reports that it supports door open/close, HA creates the appropriate entities.

i understand that. i'm coming from the world of smartthings and hubitat where i wrote many community drivers... and also being a zigbee2mqtt user i was incorrectly expecting a quirk or device specific customization to exist to fill in the gaps between what the device reports it can do, what it reports and how the user expects it to operate. that's the job in other integrations and other platforms' device drivers so i assumed it was also common with zwave-js. if it's not... apologies for assuming. and, well, zwave-js has an uphill battle for full user adoption, satisfaction, sign-off, etc. because the z-wave spec is sort of weak when it comes to some device capabilities. on top of that, the manufacturers don't implement it consistently. i'm sure i'm preaching to the choir but without device specific customizations i don't know how we can "win" on this device. we're just barely starting to see z-wave manufacturer's that will even release firmwares let alone release them perfectly initially. zooz is one of the better manufacturers for sustained support but they're not keen on changing anything for this device. i've around the block with them on it and other devices and the result is always the same. for this device, they don't even have some of the parameters documented and won't document them for some reason when asked. you just have to reach out to their support or find older documentation or look up the parameters in databases and drivers from other platforms.

Since the device information never changes, re-including the device will have no effect, it will be configured the same way every time.

assuming the device completes interview that's correct. however, being a battery powered device this device struggled to complete interview for a lot of reasons. most of them just due to the nature that a long sequence of commands is difficult for z-wave because of encryption, supervision, latency, volume, etc. and it only gets worse with a lot of nodes which i have maaaaaannnny. that's why i called it out explicitly. i should have been even more explicit to say that it did finishing interviewing the capabilities of the device each time so it wasn't an impartial view of what the device thinks it can do.

since it sounds like there won't be a device specific implementation for this and there are issues about the other oddities mentioned i'll close this issue. i appreciate the comments and insight.