IdLock 150 FW 1.6

gauteg · December 18, 2021, 9:38pm

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.

chris · December 18, 2021, 10:50pm

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.

anon71759204 · December 18, 2021, 10:55pm

According to https://devices.zwave-js.io/ there is a significant difference between version <= 1.5 and >= 1.6.

chris · December 18, 2021, 11:03pm

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.

gauteg · December 18, 2021, 11:20pm

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

vegarroe · December 19, 2021, 1:12pm

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.

gauteg · December 19, 2021, 4:02pm

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

gauteg · December 19, 2021, 4:05pm

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

vegarroe · December 19, 2021, 9:13pm

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

vegarroe · December 19, 2021, 11:34pm

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.

gauteg · December 20, 2021, 7:28am

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…

vegarroe · December 20, 2021, 7:55am

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: https://opensmarthouse.org/zwavedatabase/1449

gauteg · December 20, 2021, 2:28pm

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

vegarroe · December 20, 2021, 4:03pm

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

github.com

openhab/org.openhab.binding.zwave/blob/671a0691acb1b26955150c7c24c4e398768420f2/src/main/java/org/openhab/binding/zwave/internal/protocol/commandclass/ZWaveUserCodeCommandClass.java

/**
 * Copyright (c) 2010-2021 Contributors to the openHAB project
 *
 * See the NOTICE file(s) distributed with this work for additional
 * information.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0
 *
 * SPDX-License-Identifier: EPL-2.0
 */
package org.openhab.binding.zwave.internal.protocol.commandclass;

import java.io.UnsupportedEncodingException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

This file has been truncated. show original

chris · December 20, 2021, 6:59pm

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.

vegarroe · December 28, 2021, 7:55pm

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)

sintei · December 31, 2021, 2:03pm

I just did the exact same thing, cleaning up and migrating to OH3.
So I actually did a hard reset of my zwave stick to start over.
Included some wall plugs, all ok.

But my ID lock 150 will not include or be seen at all in openhab.
After seeing your post I did an upgrade to openhab snapshot.
But no dice…
How do you include it?
I go to settings → Things → “+” sign → Z-wave binding → Scan

On my id lock 150 (fw 1.6) I press the keylock button for 3 seconds so the sound is heard.
Then I input my masterpassword followed by *
press number 2 followed by *
and then press 5.
The sound blinks blue briefly and the OK sound is heard.

I have tried this several times, pressing SCAN in openhab simultaneously with the 5 on my lock.
Nothing is seen in openhab.
I’ve also tried resetting the z-wave using “0” instead of “5”.

EDIT: well when posting on community the idlock got scared and suddenly was included… however… not secure. Happy new year , I’ll take a break and try to solve it tomorrow.

gauteg · December 31, 2021, 2:22pm

After an apparently successful inclusion, according to the OK sound - if you go to the z-wave controller in Things and choose the View Network Map - is it there? Find the highest node number and remember it/write it down.
If you still don’t get any new things in the inbox - try to choose Exclude devices and go for the master-25 again. That should exclude the lock from the z-wave network. Do the master-20 reset after that.
Check your View Network Map - is your highest number the same? Try to include it again. I use my phone to perform the scan, because I then can be sure to press master-2’5 om the lock within 15 seconds after the scan starts - as far as I’ve read it’s a requirement to have it included in secure mode.

vegarroe · December 31, 2021, 3:22pm

@sintei what is the distance from your controller to the lock?

Check the settings of your controller thing:

Inclusion Mode: Network Wide Inclusion
Secure inclusion: Entry Control Devices
Network Security Key: a 16 byte hex number is needed

This is also how I did it.

Happy new year!

sintei · January 1, 2022, 2:16pm

New year, new z-wave

@gauteg , I did a reset of the lock (for the gazillionth time). And persistence paid off.
The lock was now added with secure:true.
I could open/close the lock from openhab. But no states were reported back (except battery!) to openhab if I actually did it on the lock.

I then did (again) as @vegarroe detailed in his previous post to clear cache, delete .xml etc.
And this time it actually worked!
My ID lock is now functioning again with openhab.

Now on to migrate everything else.