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)
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)
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.
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 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.
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.
@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:
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.
@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.
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.
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.
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)
@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.
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.
@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 - 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
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. 
