As we can see, the log definitely recognizes the event. The configuration value is set to the Default (0). According to the docs, “(Default) Sensor sends Sensor Binary Reports when sensor is faulted and restored for backwards compatibility in addition to Notification Reports.”. I personally don’t have a good grasp on the logs vs the channel references otherwise I would question some kind of mapping issue perhaps ???
Agreed - I didn’t say it was not recognised, and said above it was sending the BINARY REPORT which we can clearly see in the logs.
It doesn’t seem to send the notifications thought (ie the ALARM reports). It may simply be that the database is wrong, and this device doesn’t send notifications. However someone changed this so that it is configured like this, and I’m hesitant to change back and forward each time someone can’t get something working as that just moves the problem to another group of people.
Well, yes, we can just change the mapping so that it uses the binary reports, but as I said above, this likely just moves the problem to another group. Unless this never worked for anyone - I make the assumption that it was working with this configuration.
Another possibility is that it’s linked to association group 2 - can you try configuring this group?
Like I said, my grasp is a bit challenged with a number of elements of this for some reason. It just hasn’t clicked yet, lol. I have not messed with Association Groups. What would you suggest I need to alter? Add the Controller to Group 2 perhaps? Or?.. Thank you!
No problem. Yes, try adding the controller into group 2. The docs are minimal, but maybe group 2 is for sending notification (alarm) reports…
I’m guessing of course, so I also might be wrong 
Well, adding the Controller to Association Group 2 did not improve the situation at all. I’m really perplexed as to why the Door State Channel is Deprecated though. Before I moved to OH3 it had been working flawlessly for years. It’s a bit funny that given the device is a tilt sensor, that the Tamper and Battery channels are the only ones that are valid. Makes the device pretty much useless. lol. It’s a great little device and pretty cheap compared to other devices these days… Regardless, I haven’t stumbled on to the magic sauce that equates zwave logs to thing channels so I’m floundering at the moment 
To be clear - did you confirm this in the logs, or nothing changed in the UI?
This makes no difference, so I wouldn’t worry about this.
It may just be that whoever changed the database screwed it up, and maybe we should change back to using the binary sensor. It does seem strange though that it’s possible to disable the binary sensor notification from being sent if it really then doesn’t send anything else 
The UI now shows Group 2 Association to the Controller as well as Group 1 (Lifeline). The logs look exactly the same line for line other than the payload id of course. Perhaps reinitialize the device and try again?
I think it’s unlikely to help to be honest. You said it used to work in OH2 - can you remember what the name of the channel was? I might add a second channel to avoid upsetting anyone using the current one, but also allow it to work with those that it currently doesn’t. I need it to have a different channel name though…
Below is what I scraped from the Things in OH2 for the entire device:
{
“channels”: [
{
“linkedItems”: [
“GRG_EastDoor_Position”
],
“uid”: “zwave:device:dfdf55a5:node13:sensor_door”,
“id”: “sensor_door”,
“channelTypeUID”: “zwave:sensor_door”,
“itemType”: “Contact”,
“kind”: “STATE”,
“label”: “Binary Sensor”,
“description”: “Indicates if the door/window is open or closed”,
“defaultTags”: [],
“properties”: {
“binding::OpenClosedType": “COMMAND_CLASS_SENSOR_BINARY”
},
“configuration”: {}
},
{
“linkedItems”: [],
“uid”: “zwave:device:dfdf55a5:node13:alarm_general”,
“id”: “alarm_general”,
“channelTypeUID”: “zwave:alarm_general”,
“itemType”: “Switch”,
“kind”: “STATE”,
“label”: “Alarm”,
“description”: “Indicates if an alarm is triggered”,
“defaultTags”: [],
“properties”: {
"binding::OnOffType”: “COMMAND_CLASS_ALARM”
},
“configuration”: {}
},
{
“linkedItems”: [],
“uid”: “zwave:device:dfdf55a5:node13:battery-level”,
“id”: “battery-level”,
“channelTypeUID”: “system:battery-level”,
“itemType”: “Number”,
“kind”: “STATE”,
“label”: “Battery Level”,
“defaultTags”: [],
“properties”: {
“binding:*:PercentType”: “COMMAND_CLASS_BATTERY”
},
“configuration”: {}
}
],
“statusInfo”: {
“status”: “ONLINE”,
“statusDetail”: “NONE”
},
“editable”: true,
“label”: “Garage East Door Tilt Sensor ZW013”,
“bridgeUID”: “zwave:serial_zstick:dfdf55a5”,
“configuration”: {
“action_heal”: false,
“binding_cmdrepollperiod”: 1500,
“config_1_1”: 0,
“config_2_1”: 0,
“wakeup_node”: 1,
“action_failed”: false,
“wakeup_interval”: 14400,
“action_remove”: false,
“group_1”: [
“controller”
],
“binding_pollperiod”: 86400,
“group_2”: [],
“node_id”: 13
},
“properties”: {
“zwave_class_basic”: “BASIC_TYPE_ROUTING_SLAVE”,
“zwave_class_generic”: “GENERIC_TYPE_SENSOR_BINARY”,
“zwave_frequent”: “false”,
“zwave_lastwakeup”: “2021-12-29T11:19:24Z”,
“zwave_neighbours”: “2,3,4,9,14,21,23,24,25,27,28,29,30,31,32”,
“modelId”: “TILTZWAVE2”,
“zwave_listening”: “false”,
“zwave_version”: “2.0”,
“manufacturerId”: “014A”,
“manufacturerRef”: “0001:0003”,
“dbReference”: “139”,
“zwave_deviceid”: “3”,
“zwave_nodeid”: “13”,
“zwave_lastheal”: “2021-12-28T15:06:58Z”,
“defaultAssociations”: “1”,
“vendor”: “Ecolink”,
“zwave_routing”: “true”,
“zwave_beaming”: “true”,
“zwave_secure”: “false”,
“zwave_class_specific”: “SPECIFIC_TYPE_ROUTING_SENSOR_BINARY”,
“commandClass:COMMAND_CLASS_ALARM”: “getSupported=false”,
“zwave_devicetype”: “1”,
“zwave_manufacturer”: “330”
},
“UID”: “zwave:device:dfdf55a5:node13”,
“thingTypeUID”: “zwave:eco_tiltzwave2_00_000”
}
I’ve had the TILTWAVE2 working for quite sometime using OH2 and OH3. My channels are different then yours though. Mine are:
Here’s my working configuration:
Hopefully, this might help a little. It looks like we have the same device modelId = TILTWAVE2, manufacturerId = 014A, manufacturerRef = 0001:0003 so I’m not sure why we have different channels.
@bjsjr thanks for this - I’m not sure it helps, but it’s helpful - if that makes sense
It’s quite strange as it doesn’t look like there’s been any change to this device config for a couple of years - since before OH3, so I’m not sure why your configuration is different unless we’re talking about different devices? Based on the device properties though, that doesn’t seem to be the case, so I’m at a loss as to what is going on and why @bjsjr can be running the same software with different channels 
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_versionzwave_devicetypemanufacturerIdzwave_deviceid
Yes, you are 
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 
).
I want to avoid changing the database channels to work for the guys here, and break it for another group of people.
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 …).
Perfect sense.
@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!
I’d tend to agree …
Yes, this is 100% for sure - guaranteed.
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
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.