Ecolink Tilt-zwave2 No longer working

Here are two different XML versions. The last digit (1 or 2) was just so I could keep them separate. They will need to be changed to “0” prior to merging (They need to overwrite the file that is in there now). It would be great to be able to run the same tests as above with each modified jar. For reference the current XML
tiltzwave2_0_0.xml (4.4 KB)

  1. This XML was changed to use the Binary like the window/door 2.0 device. (I had the 2.5 eco versions of both the tilt and the door and configuration-wise they were identical so this should work)
    tiltzwave2_0_1.xml (4.3 KB)
  2. This version removed a property that looked odd and still tries to use the more modern Notification process. I’d be more comfortable with this fix, if it works.
    tiltzwave2_0_2.xml (4.3 KB)

Since @chips basically outlined the jar modification command that might be the easiest path. This is an old thread, but has more detail (note replace ESH-INF with OH-INF like @chips did)

I’d grab the latest binding from here. Do the mods then follow the steps here to uninstall the UI binding and add to the Addons folder.

Good luck

Bob

I guess it’s not “wrong” as there seems to be two versions - so it seems to be correct for one version, and incompatible with the other - we need to have two database entries to resolve it.

Do these two versions have different version numbers? They should do - so we should be able to add both to the database which would solve the issue - but we need to know how to identify the two versions…

Since you are back :wink: I have a question re this line in the DB xml for the Tilt 2.0. Could this potentially be suppressing the device from sending the Notification (Alarm)? One of my XML’s above took it out (to see what would happen). But it is easier to just ask. :smiley:

<property name="commandClass:COMMAND_CLASS_ALARM">getSupported=false</property>

Bob

No - changing the XML will not impact what the device does. If the device isn’t sending data, then it’s a device configuration issue most likely.

@nh905 Based this

Your task is cut in half, just try the first xml. assuming that works (I expect it to) we’ll have to figure out how to get two entries in the DB.

Bob

Thanks. I tried to follow isSupported logic (for version 2) in the Alarm CC but could not, so just figured it might be worth a try (with a willing tester) to keep the rest of the DB for the device as is. With my limited knowledge, it is a little unusual to see that line. It’s not in any of the other Eco devices I checked.

Anyway thanks again

Bob

@chips thanks for the confirmation and the streamlined instructions - I read the full instructions and got lost in the weeds.

@apella12 I decided to stick with the current binding to avoid making too many changes at once. I created a newbinding folder, created the OH-INF/thing/eco subfolder structure, and saved your first XML file as tiltzwave2_0_0.xml. I returned to the newbinding folder, copied over the current org.openhab.binding.zwave-3.2.0.jar, then ran

jar -uf org.openhab.binding.zwave-3.2.0.jar OH-INF/thing/eco/tiltzwave2_0_0.xml

I unpacked the updated .jar file and verified that the tiltzwave2_0_0.xml matches your first XML file. It looks like you moved sensor_door before alarm_tamper, changed the sensor_door label and OpenClosedType, and deleted the following later in the XML:

<property name="commandClass:COMMAND_CLASS_ALARM">getSupported=false</property>

To install the modified binding and pick up the new XML definition (updated 2022/06/02 based on Bob’s input and testing):

  • uninstall the current Z-Wave binding (follow steps to add the Z-Wave Binding but click on REMOVE)
  • copy the modified Zwave binding in the addons folder (for me, /usr/share/openhab/addons)
  • wait for OpenHAB to automatically install the modified Zwave binding
  • in Things, find the tilt sensor, and “Delete Thing” at bottom of screen
  • remove the tilt sensor battery
  • in Things, click on the Add button, select the Z-Wave binding, and click on Scan to enter inclusion mode
  • install tilt sensor battery to include the sensor
  • wait for the tilt sensor to appear in the Inbox
  • add the sensor (the existing channels and item links were still defined)
  • set up Z-Wwave debug logging
  • tilt the sensor

Sounds right.

I didn’t have to move the sensor door, but was trying to visually line up with the 2.0 window/door.

Bob

edit: Fine to stick with the 3.2 binding. The 3.3 snapshot has some enhancements re: battery device inclusion that could help, but understand trying to mimimize change here.

edit 2: Read the steps too quickly last night. You most likely will have to go into karaf to;
feature:install openhab-transport-serial
I like to add before I drop the binding in the addons folder, to avoid an error message. (The feature is added automatically when the binding is installed via UI, but not when dropped in.

Also run both options on parameter 2 in debug mode.

Thanks for your efforts on this.

@apella12 Success! I followed the instructions above, adding the “feature:install …” step. “Remove device from controller” did not remove the sensor Thing - I did a “Delete Thing”. I scanned and added the sensor - it appears as the original node and all existing channels/items/links are already there. The tilt test was successful - I could see the Binary Sensor/Door State (Deprecated) change as expected. I am going to repeat the procedure for the second sensor and then update the instructions above.

I left Parameter 2 as 0x00 - is there any point changing it to 255 and testing again? I have sent an email to Ecolink Support for the detailed TILT-WAVE2 sensor to see if that helps clarify how the v2 tilt sensor should be defineed in the device database.

Thanks for your help!

2022-06-02 15:04:39.157 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 FF 39
2022-06-02 15:04:39.161 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 15:04:39.163 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 15:04:39.168 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 15:04:39.169 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 15:04:39.170 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 15:04:39.171 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 15:04:39.172 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 15:04:39.173 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 15:04:39.173 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=255
2022-06-02 15:04:39.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 15:04:39.175 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=255
2022-06-02 15:04:39.176 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to OPEN [OpenClosedType]
2022-06-02 15:04:39.177 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 15:04:39.178 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1956688.
2022-06-02 15:04:39.180 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:39.180 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:39.181 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 15:04:39.182 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 15:04:55.638 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 00 C6
2022-06-02 15:04:55.641 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 15:04:55.643 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 15:04:55.644 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 15:04:55.645 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 15:04:55.646 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 15:04:55.647 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 15:04:55.648 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 15:04:55.649 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 15:04:55.650 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=0
2022-06-02 15:04:55.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 15:04:55.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=0
2022-06-02 15:04:55.652 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to CLOSED [OpenClosedType]
2022-06-02 15:04:55.654 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 15:04:55.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1bf71d9.
2022-06-02 15:04:55.657 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:55.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:55.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 15:04:55.662 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Great !

  1. Should cut myself off from responding late at night. Anyway “Delete thing” is correct to pick up the new XML. “remove device from controller” will never really work for a battery device.
  1. For the sake of science I would be interested in the Debug log from that test for comparison. I’m puzzled by why ECO would have a that parameter. I still have a remote hope it will send a notification instead and a test would put that to rest.

Anyway you have a working zwave binding that can be used until we get the DB figured out.

Bob

@apella12 I updated oarameter 2 to 255

openhabian@openhabian:/var/log/openhab $ grep "Configuration update set config_2_1" zwave.log
2022-06-02 16:44:49.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set config_2_1 to 255 (BigDecimal)

Here is the log from a door open/close. I am not sure what I am looking for, but it looks the same as the Parameter 2=0 log.

2022-06-02 16:52:02.849 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 FF 39
2022-06-02 16:52:02.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 16:52:02.856 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 16:52:02.857 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 16:52:02.858 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 16:52:02.858 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 16:52:02.859 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:52:02.860 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:52:02.861 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 16:52:02.862 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=255
2022-06-02 16:52:02.864 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 16:52:02.865 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=255
2022-06-02 16:52:02.866 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to OPEN [OpenClosedType]
2022-06-02 16:52:02.867 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 16:52:02.868 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1f26622.
2022-06-02 16:52:02.869 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:02.870 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:02.871 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 16:52:02.872 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:52:24.480 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 00 C6
2022-06-02 16:52:24.483 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 16:52:24.486 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 16:52:24.487 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 16:52:24.488 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 16:52:24.489 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 16:52:24.490 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:52:24.491 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:52:24.492 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 16:52:24.493 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=0
2022-06-02 16:52:24.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 16:52:24.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=0
2022-06-02 16:52:24.495 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to CLOSED [OpenClosedType]
2022-06-02 16:52:24.497 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 16:52:24.498 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@b26f5e.
2022-06-02 16:52:24.498 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:24.499 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:24.501 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 16:52:24.502 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:55:04.783 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling...
2022-06-02 16:55:04.785 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:sensor_door
2022-06-02 16:55:04.787 [DEBUG] [converter.ZWaveBinarySensorConverter] - NODE 4: Generating poll message for COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:55:04.788 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Creating new message for application command SENSOR_BINARY_GET
2022-06-02 16:55:04.789 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:55:04.790 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Command Class COMMAND_CLASS_SENSOR_BINARY is NOT required to be secured
2022-06-02 16:55:04.791 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:alarm_tamper
2022-06-02 16:55:04.792 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 4: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm null, event null
2022-06-02 16:55:04.793 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 4: Node doesn't support get requests
2022-06-02 16:55:04.794 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:battery-level
2022-06-02 16:55:04.795 [DEBUG] [rnal.converter.ZWaveBatteryConverter] - NODE 4: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
2022-06-02 16:55:04.796 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:55:04.797 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
2022-06-02 16:55:04.797 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Bump transaction 43 priority from Get to Immediate
2022-06-02 16:55:04.798 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-06-02 16:55:04.799 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 43 to queue - size 6
2022-06-02 16:55:04.799 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:55:04.800 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Bump transaction 44 priority from Get to Immediate
2022-06-02 16:55:04.801 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-06-02 16:55:04.801 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Transaction already in queue - removed original
2022-06-02 16:55:04.802 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 44 to queue - size 6
2022-06-02 16:55:04.802 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

That it does. Thanks for that. It is an odd parameter since it appears to have no effect with either the current binding XML (that does not work either way) or the one I modified to use the Sensor binary (that works either way)

Thanks again for humoring me.
Bob

@chris I finally got through to someone at Ecolink. The tiltzwave2 is based on the 300-series Z-Wave chip, while the tiltzwave25 uses the 500-series chip. I was told this explains the differences in the command classes.

My Ecolink contact could not find a tiltzwave2 manual that listed the command classes and configuration parameters described in the tiltzwave25 manual but was able to provide the attached summary. I hope this helps clarify the tiltzwave2 sensor operation. Please let me know if you need additional information.
Garage Door Tilt Sensor Zwave 300 series.pdf (415.2 KB)

Not really. You talk about hardware versions here.

In any case, we need to know how to tell the devices apart - normally the device will report different application versions if the software is different - in fact this is a requirement for them to do this. This is what we need to know - so that we can create two different database entries for the two different firmware versions.

@chris OpenHAB reports that the tiltzwave2 sensor as manufacturerId=014A and manufacturerRef=0001:0003, which is already described at https://www.opensmarthouse.org/zwavedatabase/139. My contact at Ecolink did not say that there were two versions of this device. The change to using the ALARM class for the door state was introduced with 2.5 version of the sensor described at https://www.opensmarthouse.org/zwavedatabase/581.

@mhilbush thought database update 1373 from 2020/08/09 introduced changes to the tiltzwave2 database definition that prevented OpenHAB from properly reporting the data sensor state.

Strange - but you said earlier -:

So do I understand then that there are actually two different devices?

If so it seems we already have two versions in the database? But this thread (if I understand correctly) is about two different tilt-zwave2 responses. If there is only 1 version, then why are there two different responses?

Or is it that the database incorrectly identifies the 2 and 2.5 versions? I think a clear understanding of the different versions is still needed.

Last March (15 months ago) I posted in this thread:

  • The database is wrong. It references (and seems to rely on) the “Updated Manual” Tilt-ZWave-Plus-Manual-R1-04-021816kgs.pdf which is not for this device. The manual is for product type 4 (see bottom page 4). This discussion is about is product type 1, not product type 4.
  • I speculate that at some point TILTZWAVE2 (product type 1) was erroneously updated to reflect the characteristics from the manual for TILT-ZWAVE2.5-ECO (product type 4).

I posted this again 10 days ago in this thread. If this is not the answer to the question that keeps getting asked over and over again, sorry about that, but don’t worry; this will be my last post here. Just trying to help.

Sorry if I missed your posts - I don’t read everything here.

Please feel free to provide an update to the database if you have the solution to this issue - clearly that is the best way forward!

@chris, You replied directly to my previous posts, so I’m not sure that’s the problem. This really is my last post here because as I described above I have switched to Home Assistant. I was just trying to help out here, but I want to be clear that you should not be waiting for me to update the database, just like I explained over a year ago. Thanks for all the fish.

Without going back and re-reading everything I can’t really say why you didn’t just update the database then, or what else was outstanding. Sorry for any confusion.

[edit] looking above, you didn’t reply to my message (you wrote a new message in the thread without replying to me) so I didn’t get notified. As this was 1 week before I moved from the UK to New Zealand I was quite busy at the time :wink: - again, apologies for missing this response.

Ok, but someone needs to update the database if it’s wrong. There are 1300 or more entries and I personally can’t maintain them all - I just don’t have the bandwidth - again - sorry but this is a community and it does rely on others helping out and not just expecting me (or “someone else”) to do everything.

I don’t have this device, or the bandwidth to try and work out what versions exist, so it’s really appreciated when others can chip in :slight_smile: