I paired my Ecolink Z-Wave Garage Door Tilt Sensor to the system fine. Everything went well (after a few tries at inclusion). It is shown as “TILTZWAVE2” model. Problem is, there are 3 channels, and the main channel for the “Door State” is shown as Deprecated. And sure enough, when I operate the garage door, I get the Battery Level sent back just fine, but nothing shows up on the Door State (always NULL).
Is there supposed to be a new non-deprecated Point here? Database error?
Hi all, anyone have any suggestions on this? Thanks!
The fact that it has deprecated in the title will not in any way change the way the channel works. I don’t know this device so I’m not sure what else it sends - have you checked the debug logging to see what is coming in (if anything)?
@chris I’ll be happy to pick up where this left off. I have very recently moved to OH3 by fresh install of OpenHabian and simply inserting my dongle which already contained my devices. I too am seeing the device defined as depicted above. Looking at the logs, it appears that it is indeed sending the update but does not seem to be recognized any longer.
2022-01-22 16:32:52.813 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:DONE)
2022-01-22 16:32:52.814 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: resetResendCount initComplete=true isDead=false
2022-01-22 16:32:52.815 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-01-22 16:32:52.816 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2022-01-22 16:32:52.817 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-01-22 16:32:52.818 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 13: Sensor Binary report, type=Unknown, value=255
2022-01-22 16:32:52.819 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-01-22 16:32:52.820 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SE NSOR_BINARY, value=255
2022-01-22 16:32:52.821 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2022-01-22 16:32:52.822 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPay load@1b4a678.
2022-01-22 16:36:02.326 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:DONE)
2022-01-22 16:36:02.327 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: resetResendCount initComplete=true isDead=false
2022-01-22 16:36:02.328 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-01-22 16:36:02.329 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2022-01-22 16:36:02.330 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-01-22 16:36:02.331 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 13: Sensor Binary report, type=Unknown, value=0
2022-01-22 16:36:02.332 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-01-22 16:36:02.333 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SE NSOR_BINARY, value=0
2022-01-22 16:36:02.334 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2022-01-22 16:36:02.335 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPay load@13d4404.
Your device seems to be sending the SENSOR_BINARY reports. My guess is that there might be a configuration option that changes this so that it sends the ALARM reports that the binding is expecting.
The only way to enable notification reports seem to be to send a NOTIFICATION_SET command (parameters: type=0x06 and status=0xFF) to the device - AFAIK this cannot be done with the Z-Wave binding.
And the binary sensor type reported is 0xFF:
… and sensor type 0xFF is “Unknown” to the Z-Wave Binding.
This is a very old device, so I would be very surprised if this is the issue.
The device seems to have the ability to enable different reports, so I assume this is how it’s done (at least looking at the database there is a command to enable and disable the binary sensor report). This is quite common that devices can send different reports, and have a config parameter to configure which one to use.
Factory resetting the device might enable notification reports (the manual is silent on this), but according to the manual there is no way to disable/enable notification reports by setting configuration parameters.
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 
