IdLock 150 FW 1.6

I have just started cleaning up my setup (lots of crap from OH1) and started off with a clean install. I have a IdLock 150 FW 1.6 and i get unknown device when adding it as a Thing.

I see in the database (OpenSmartHouse Z-Wave Device Database) that only FW < 1.5 is mentioned there.

Also in Github it seams to be missing, 1.6 is deleted in Database update #1495 Database update by cdjackson · Pull Request #1495 · openhab/org.openhab.binding.zwave · GitHub

@chris Can you clarify?

1 Like

I’m not sure why it was removed - the entry in the database is incomplete so that’s why it’s not in the binding, but I don’t know now why it’s this way as this was about a year ago.

What needs to be done to make this work? Would it be enough to set maximum firmware version to 255-255? I guess both @vegarroe and I have this lock, so please let us know if we can help in any way.

I really don’t know. Are the devices the same, or are there differences? Is the configuration the same between all versions? If everything is the same, then yes, changing the version is fine, but if there are differences, this will cause problems and you really need to create a new entry.

The physical device is the same, only the firmware has been updated.
Considering the guide says:
*By default, a device should be configured with the maximum version to detect all new versions (ie set to 255.255). This means that new devices will work, even if new features are not supported without a database update. *
and “nobody” knows the reason for setting it to 1.5, I would assume (although, assumption is the mother of all f**k ups) setting it to 255.255 wouldn’t make it worse, since 1.6 doesn’t work at all as of now - or at least, there is no reference to it so it can not be installed.

Sure - but the question remains. The binding doesn’t care about the physical device - it cares about the definition of functionality - channels, configuration parameters etc.

Please check that the two versions don’t have different configuration definitions - if they are the same, then probably it is ok to remove the limit, but if they are different, then as I said above it will require a new entry.

According to there is a significant difference between version <= 1.5 and >= 1.6.

Thanks. Yes, there are a couple more parameters in the newer version, so @gauteg I guess this wasn’t just a “f*ckup” and it does require a new entry.

And that why I love forums :slight_smile: There’s always someone who knows.

Who can add this to the database? I can do it but have to wait for editor rights so if someone else can do this faster it would be appreciated.

@gauteg I made the 1.5 version work on my lock with a workaround editing the XML (changed version to 1.5). It works for status closed/open and locking/unlocking but lacks of course the additional stuff for W 1.6.

1 Like

@chris For the record - it was my assumption that could be a f*ckup - not anything that was done by others.

I guess I’ll have to try that xml-trick myself when I get home. Thanks, @vegarroe

For info, I have started adding an entry in the database or FW > 1.6

Entry in database is now sent for review.

For info: I have added Channels for some of the config parameters. As I understand this will enable manipulating config from rules and show current status in UI/Items.

Examples of use:
Volume to be able to turn it down during late hours
Service pin to be able to enable and disable without having to change in config view and also to automate it e.g. timer or only during daytime for one week etc.

1 Like

Good job! After a quick glance of the new version - Did you implement all parameters available, or just a sub set/the most important ones? I’m not sure if I can see all modifications to the new device version you made, but it appears that it is possible to get a lot more info from the device - or maybe I am wrong again…

All configuration parameters are included. The cutout attached is the ones I additionally added as Channels so it is possible to modify through rules/Items.

Did you look into the database or only my cutout above? Database entry here: OpenSmartHouse Z-Wave Device Database

@vegarroe I looked in the Database, but couldn’t quite understand where all the User PIN codes and RFID’s could go. I would have guessed they would be in the COMMAND_CLASS_USER_CODE_V1, but only see the Service PIN there. Maybe they are not available to Z-Wave.

@gauteg I’m not sure how this works. I have seen all the user codes under parameters in an earlier version of the binding. Looking into the xml-files in the binding I don’t see such configuration org.openhab.binding.zwave/src/main/resources/OH-INF/thing/idlock at 671a0691acb1b26955150c7c24c4e398768420f2 · openhab/org.openhab.binding.zwave · GitHub.

My guess is that some COMMAND_CLASSes are handled automatically by the binding showing available information, while other have to be added manually in the database with parameters and channels. I added a channel for the service code for possibility to use it in the UI, adding all is a crazy task. @chris can you clarify how this work for the different COMMAND_CLASSes? Is there any good documentation for this or is looking into the code the only way. Code below mentions the COMMAND_CLASS_USER_CODE, understanding the total picture for the binding is way over my head.

You don’t need to add all the user code options - there isn’t anywhere to add them in the database editor anyway. You only need to add the association groups and config parameters into the database.

1 Like

I have done some testing with this new database entry for IDLock 150 FW 1.6 (added by me). It works (not all parts tested) but I had a hard time to come to that point.

I use openHABian and started off just changing to snapshot to get the new device in. From that point it seamed ok first but I was not able to change and save parameters and an error in the openhab.log came when saving: Unexpected exception occurred while processing REST request.
java.lang.NumberFormatException: null

My final solution was to take a step back and recover a snapshot in my virtual environment (ESXi, always good to have that possibility). This got me to the point where I had manually edited the xml-file to trick the binding to think that I had a FW v1.5 lock.

My solution, hopefully it will stay stable:

  • unlink items and delete thing
  • stop openHAB
  • delete the userdata/zwave/network_xxxxxxxx__node_yy.xml
  • clean cache (sudo openhab-cli clean-cache)
  • update to openhab snapshot
  • start openhab
  • discover and add thing

Then it seams to work and I see correct status of the door, I can lock and unlock. Those are my basic needs.

For the config part only parameters 1 and 2 seem to work. Parameters 3, 4, 5, 6, 8 and 9 stays as pending after change. Parameter 7 is read only and supposed to give the value 150 (96 hex) but shows 0.

I added channels for some of the parameters, these are not yet tested.

Attached one log file where IDLock is removed at 14:19:34 and discovered and added as thing at 14:26:18, completed at 14:26:27. Config changes done one by one starting from 14:26:57.

@chris I had appreciated if You could look at this and guided further steps for diagnostic/tests. I can supply more logfiles if needed and any other steps needed.

openhab reduced.log (970.0 KB)