Difference in tilt sensor performance between ST and HA

Configuration Z-Wave
1

I am gradually switching devices over from ST to HA, which I have running all by itself on a NUC. I have a HUSBZB-1 for Z-wave.

My problem is with an old Vision ZG8101US (looks like the gen1 Ecolink) that has worked perfectly on ST for 6 years.

On HA, it reports the door opening quickly, but always has a 5-7 min delay in reporting the garage door closed. This difference has persisted over 3 rounds of switching from ST to HA and back. It also behaves identically when the tilt sensor is next to the hub or controller and tilted by hand.

Any suggestions, other than the obvious one of keeping it on ST?

2

Which add-on are you using? Which version?

Download the Device diagnostic file and post it to a pastebin site, link back here. Make sure you are using the correct entity, sometimes a disabled binary_sensor works better.

Make sure your Z-Wave network is in good shape, e.g. a USB extension cable is required. https://zwave-js.github.io/node-zwave-js/#/troubleshooting/first-steps.

Post driver debug logs that include interaction with the device.

  1. https://www.home-assistant.io/integrations/zwave_js/#how-do-i-access-the-z-wave-logs
  2. or https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs
3

Z-wave JS–latest
Driver version: 13.10.3
Server version: 1.39.0

Any issues with shape of the network have been controlled for, as the difference is identical when the device is right next to either the hub or the HUSBZB-1.

The log shows an immediate change, but the status on my dashboard does not:

4

That doesn’t look like the device diagnostic file. The download is available from the device page. https://www.home-assistant.io/integrations/zwave_js/#network-devices

5
6

Well, that seems to have the contents of a diagnostic file, but has lost all formatting and is nearly impossible to read. Would be nice to have the original file.

Which entity are you using, binary_sensor.garage_door_tilt_sensor_sensor_state_any?

8

Turns out I used to own this device but it stopped working a couple years ago.

It’s not uncommon for older Z-Wave devices to be poorly designed, like this one is. Often the “modern” notification sensors don’t work but the legacy binary report sensors do. Z-Wave Certification is a low bar, and it doesn’t guarantee devices don’t have buggy implementations. Especially true for old devices.

I’m assuming you were using binary_sensor.garage_door_tilt_sensor_intrusion. You can see from your driver logs it doesn’t report status correctly, it always reports intrusion (see NotificationCCReport). The “any” sensor is reliable (BasicCCSet reports). The Z-Wave JS driver has to work around such bad behavior with compatibility flags. https://github.com/zwave-js/node-zwave-js/blob/b42dec2a4472509ba153f2b174401f4c048cbaff/packages/config/config/devices/0x0109/zg8101.json#L28-L31

	"compat": {
		"mapBasicSet": "auto",
		// The device does not idle its own notifications
		"forceNotificationIdleReset": true

The 5 minute delay you see with the intrusion sensor is the idle notification reset compat flag.

Z-Wave JS / HA get a lot of blame for bad device behavior when it’s the devices themselves are poorly designed. If the notification report was working properly this wouldn’t have been an issue.

SmartThings, or 3rd party developers typically, take on the burden of handling bad devices with custom code, which is why you might see less problems on ST, they are just hidden from you. Z-Wave JS and HA have chosen to follow the Z-Wave specifications as close as possible, instead of having a development burden of creating workarounds for the high number of non-compliant Z-Wave devices out there. There aren’t enough Z-Wave developers on this platform to support such a path.

2 Likes