Don’t forget the door condition channel.
That requires changes to the code in the binding which I’m not able to do until the long standing issues with the development environment get resolved.
That development environment is real blocker :s I’ll continue to use my skunk version.
Sorry - I can only apologise, but I’ve spent most of my time over the past few weekends, and a lot more over the past couple of months that this has been ongoing, trying to get this working. It’s a bit of a mess at the moment 
.
1 Like
Thanks for great information.
Regarding changes in the code for the door condition: I don’t think this will brake other devices using the same code. My rationale for saying this is that this should (from my point of view) reflect the command class content. I found a document describing the command classes and the COMMAND_CLASS_DOOR_LOCK_V2 is described there as in the idLock manual. So the correction of the code will most likely enable better functionality for everyone using this command class.
Mentioned document (chapter 4.35 and table 46 in chapter 4.37.5: https://www.silabs.com/documents/login/miscellaneous/SDS13781-Z-Wave-Application-Command-Class-Specification.pdf
No - this is not the point. I’m fully aware of the ZWave docs, and you are right that the command classes will allow the resolution of the different features on the ZWAVE side of the interface, but not on the OPENHAB side. We need to expose the same channel types to openhab users. The binding can work this all out as you say from the command class data, but the converter needs to provide different data to openHAB users - this is where the code changes are needed, and this is where we need to be careful not to change things that will break other users systems.
1 Like
The main question still exists, how should we solve the issue that the binding misses unlock events.
You know better than the developer?? The binding does not miss them but cannot translate them for OpenHAB core.
Right now, the binding development is on hold until there is a working development environment for the binding.
If the controller doesn’t receive them, then the binding can’t do anything about them. If the binding receives them, it will process them - it won’t “miss” them.
1 Like
I’m running a.modified version, for me it’s now stable, I have not missed any events so far. Will continue to test it out.
Chris can we create a new converter for the new firmware version? so depending on firmware version different converter, thus not breaking any functionality for people on the old firmware.
Please provide information on how you have fixed missing events since I’d be extremely surprised if the binding missed events once they have been received from the controller. It should either process them, or not. If you have fixed such a bug, then it would be appreciated if you can publish this.
No - this is not possible.
As I’ve said - this is about channel types. We MUST (absolutely MUST) keep the same data type for a specified channel type otherwise it will break backward compatibility.
This is not related to this device - if we change this channel type, we will break all users of this channel across all devices - ie all ZWave locks, other than your system, will not work - this might be good for you, but not so good for others 
We can have however many converters we want - this is not really the point. What users see is channel types.
As I’ve already stated above (somewhere), we need to define a new channel type that provides this information. I think I suggested the json string as we are using elsewhere for these types of issues.
1 Like
That sounds great, could you provide a simple guide with the things you changed?
Then I also could test this, I miss multiple unlocks every day. Iam using latest firmware from IDlock
If I know better than the developer?
I don’t think so, but what I know is that I have this lock installed at my home and OH misses multiple unlocks. If it is the binding that misses them or if the binding have issues translate them, I don’t know. But the result is the same for me, it’s broken.
To be clear. I have posted all changes I have made in this thread, both rules, items and changes in java code. What I believe is making a difference, is that the current converter class for idlock, which is only handling door condition 0 and 1, but door condition can be 0, 1, 2, 3.
I’m also considering both door condition and entry notification. When unlocking using openhab, door condition is not updated, but entry notification is.
So what I believe is that in order to not miss events:
- You need to handle all door condition values (0, 1, 2, 3) current zwave converter is not.
- You need to write a rule which consider both door condition and entry notification
So far I have not seen a miss, but I have not yet tested it that extensively, so yes there could be cases when the controller is not getting notified, but so far that’s not the case.
All my changes are in this thread. Feel free to modify the binding and test it out. You will have to compile the binding yourself.
Regards, S
Ok, so the binding isn’t “missing events” then - there are just some types of events that it doesn’t process. That’s quite a different issue.
Can you please provide a short log showing all these received frames. I appreciate that you might have posted one somewhere above, but it would be good if you can summarise this.
Or better still please raise an issue and post the log there.
1 Like
Yes this is at least what I think the problem is.
I believe @vegarroe posted the logs for this.
https://community.openhab.org/uploads/short-url/2hcN04UgG4xK4kth475Z4PUcEC7.log
I’m not at my home today and tomorrow, so don’t have access to create logs for this atm. Will
do it later if the above log is not enough.
Regards S
1 Like
Thanks - I’ll take a look at this.
1 Like
I’ve had a look at the binding code, and don’t see anything wrong. The binding seems to correctly process both the condition and the mode. However the database doesn’t have both channels defined for this device - it only has the lock mode (secured and unsecured).
I think all that is required here is to add the second channel sensor_door to the database and it should provide you the state information that is defined above.
The would give you two channels - door_lock which is ON / OFF for unlocked / locked, and sensor_door which is OPEN / CLOSED.
Does that make sense, and does that give you what you required? This is the way it is defined for other locks.
1 Like
Yes, that’s what I did in my hacked version added a new channel as a sensor_general, and changed the converter so I got the values 0 - 3.
I then used rules for two new items so I dived locked / unlocked and door opened / closed. See above
Yes makes sense, as long as door condition is used for telling if the door is both locked / unlocked as well as opened / closed. To rephrase door_condition is needed for telling you if the door is locked/ unlocked not only to tell whether the door is opened / closed. We can’t only relay only on door_lock channel for determining if the door is locked/ unlocked, otherwise you will “miss” some locks / unlocks.
This is how the current door condition is handled:
private State handleEventCondition(ZWaveThingChannel channel, ZWaveCommandClassValueEvent event) {
if (!channel.getUID().getId().equals("sensor_door")) {
return null;
}
switch (channel.getDataType()) {
case OpenClosedType:
return ((Integer) event.getValue() & 0x01) == 0x00 ? OpenClosedType.OPEN : OpenClosedType.CLOSED;
default:
logger.warn("No conversion in {} to {}", this.getClass().getSimpleName(), channel.getDataType());
break;
}
return null;
}
The return ((Integer) event.getValue() & 0x01) == 0x00 ? OpenClosedType.OPEN : OpenClosedType.CLOSED;
Should handle 0, 1, 2, 3.
Regards, S
Ok, that’s not what I’m suggesting. As far as I can see, the binding requires no modification at all.
Yes, it does that now - there are no changes required. You just need to add the sensor_door channel to the database and it should work fine.