Z-Wave Garage Door Tilt Sensor - Deprecated Point?

Add-ons Bindings
21

I might be wrong, but:
@cj179 's device reports

NODE 13: Sensor Binary report, type=Unknown, value=255

and

NODE 13: Sensor Binary report, type=Unknown, value=255

… in accordance with the manual (sensor type 0xFF, values 0 and 255), but the Z-Wave binding doesn’t accept sensor type 0xFF (valid sensor type, see Z-Wave Garage Door Tilt Sensor - Deprecated Point? - #6 by Ap15e), hence type=Unknown(?).

OTOH, @bjsjr 's Binary Sensor seems to be of type sensor_door (Z-Wave sensor type 0xA?).

@krishkal/@cj179 and @bjsjr should compare

  • zwave_version
  • zwave_devicetype
  • manufacturerId
  • zwave_deviceid
22

:+1:

Yes, you are :wink:

The issue is that the binding is configured to look for the ALARM (aka NOTIFICATION) messages - not the BINARY SENSOR messages.

No - it’s not. You are mixing up the channel type (which is sensor_door - this is not related to the ZWave messages at all.

The issue is easy to resolve - I can simply change the database to make it work here. My problem is that it has been this way for a long time - someone presumably configured it this way, and presumably it worked (I know - I’ve made a few assumptions :slight_smile: ).

I want to avoid changing the database channels to work for the guys here, and break it for another group of people.

23

I do understand that @krishkal 's OH Thing is configured to consume Z-Wave alarms/notifications and that @krishkal 's Z-Wave device doesn’t send any Z-Wave notifications and that OH doesn’t support sending the NOTIFICATION_SET command to enable Z-Wave notifications on @krishkal 's device.

My final conclusion:
If there is someone out there whose device is compatible with the Z-Wave database entry as it is now, then her/his device must be on a different firmware version (or she/he must have managed to enable Z-Wave notifications, outside of OH …).

24

Perfect sense. :+1:

@chris I looked at the xml you referenced and was wondering if you could answer a quick question? I installed the device several years ago probably while still using OH1. My current OH3 Thing properties matches @cj179 OH2 Thing he posted earlier, including the “label”: “Binary Sensor”.

I noticed in the OH3 xmls you referenced that the label is always

<label>Door State [Deprecated]</label>

My question is when I moved from OH2 → OH3 why didn’t my new Thing label pickup the "Door State [Deprecated] label from the OH3 xml?

I’m a bit concerned that if I would delete my current Thing and rescan I could end up in cj179’s situation.

Thanks!

25

I’d tend to agree …

26

Yes, this is 100% for sure - guaranteed.

27

So @chris, what are your thoughts on where we go from here? Given a couple of other ecolink tilt sensors came online over the years, I wonder if things didn’t get confused in the mix. Just passing thoughts. Would love to know the history of the demise of this particular device but I don’t think that will ever happen. lol

28

If you have an Ecolink Z-Wave Tilt Sensor v2, the definition has been corrected in OH3. Bob Eckhoff provided a modified Z-Wave binding for OH 3.2.0 (https://community.openhab.org/t/ecolink-tilt-zwave2-no-longer-working/105551/73?u=nh905) that confirmed the necessary changes and these were rolled into OH 3.3.0.

I do not know enough about the OH upgrade process to determine if a straight OH 3.3.0 upgrade will modify the previous definitions. In my case, I uninstalled the 3.2.0 Z-Wave binding, installed the modified binding for testing, uninstalled the modified binding, upgraded to 3.3.0, and reinstalled the stock Z-Wave binding. I did not need to rediscover any Z-Wave devices or modify any definitions.