But won’t sensor_door, only be opened or closed (0 and everything else will result in closed) ?
return ((Integer) event.getValue() & 0x01) == 0x00 ? OpenClosedType.OPEN : OpenClosedType.CLOSED;
Regards, S
No - 1 and 3, and 0 and 2 will provide close/open respectively.
How do I distinguish door opened / closed from locked and unlocked then? (If we talk about door condition: 0, 1, 2, 3) ?
As I said earlier -:
I’m clearly not following 
So door_lock (the existing channel), will get its status from door condition?
No.
From the DOOR_LOCK_REPORT, DOOR_CONDITION processes the sensor_door and DOOR_LOCK_STATE processes the lock_door.
You can see this in the logs that you referenced earlier - both events are logged here -:
03-Sep-2019 19:36:48.274 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 23: Incoming command class COMMAND_CLASS_DOOR_LOCK, endpoint 0
03-Sep-2019 19:36:48.274 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 23: Received COMMAND_CLASS_DOOR_LOCK V1 DOOR_LOCK_REPORT
03-Sep-2019 19:36:48.274 [DEBUG] [al.protocol.commandclass.ZWaveDoorLockCommandClass] - NODE 23: Door-Lock state report - lockState=Unsecured, handlesMode=0, doorCondition=2, timeoutMinutes=254, timeoutSeconds=254
03-Sep-2019 19:36:48.275 [DEBUG] [ng.zwave.internal.converter.ZWaveDoorLockConverter] - NODE 23: Handle door lock event DOOR_LOCK_STATE
03-Sep-2019 19:36:48.275 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:1:node23:lock_door to OFF [OnOffType]
03-Sep-2019 19:36:48.278 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
03-Sep-2019 19:36:48.278 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_DOOR_LOCK, value=2
03-Sep-2019 19:36:48.278 [DEBUG] [ng.zwave.internal.converter.ZWaveDoorLockConverter] - NODE 23: Handle door lock event DOOR_CONDITION
Or am I missing something? We are talking about the DOOR_LOCK_REPORT aren’t we? (sorry if we are talking about different things?)
I’m probably missing something. What I meant was that for IDLock 150, DOOR_CONDITION
will not only tell you if the door is OPEN/Closed but also if the door is locked / unlocked.
If you limit yourself to only look at existing door_lock channel to determine if the door is locked / unlocked, you will at some point miss if the door is locked / unlocked (the “missing notifications”).
I noticed that door_condition together with entry_notification gave me the full truth as to whether the door is locked / unlocked.
Yes, so there are two ways to tell if it’s locked/unlocked - the binding is using the mode, and as you say this information is also available in the condition. Are you saying that the mode and the condition don’t align? One says it’s locked, and the other says it’s unlocked? If they are the same, then it doesnt matter which one we use does it - there are still two bits of information - locked/unlocked, and open/closed.
The binding looks at mode and condition. Mode is defined as follows -:
This can be interpreted as FF = locked, and anything else other than FE is unlocked. Agreed?
It also has condition which is defined as follows -:
This is linked to the sensor_door. I agree that there is also a locked/unlocked state here which we don’t use, but as above, there is another interpretation of locked/unlocked and I hope that it results in the same answer? If there are different interpretations here then that’s something we need to look at.
1 Like
From what I could tell with the new firmware mode and door condition are not aligned, or rather mode is not always updated, or notification is not sent to controller, so yes it might be that we have to look at door_condition in those cases for idlock.
This definition is the same - assuming that SECURED = LOCKED and UNSECURED = UNLOCKED. Otherwise what you have pasted from the device manual is basically the same as I pasted from the protocol spec (the protocol spec defines more stuff).
So I don’t see the difference. Above, I said mode FF=locked and anything else is unlocked, which is what you paste here, and for condition we just look at the open/closed.
I think the only question is if secured and locked mean the same thing. To me, they are the same thing, but maybe that’s not the case.
I would assume they are the same.
From above, I confirmed with my lock and hacked version it translates to
Door condition 0: Door is Locked and Door is opened
Door condition 1: Door is Locked and Door is closed
Door condition 2: Door is unlocked and Door is opened
Door condition 3: Door is unlocked and Door is closed
i.e when I unlock the door it get status 3, and when I open the door it gets status 2.
Ok, so then (I think 
) we are in agreement, and then the only thing to do is to add the sensor_door channel to the DOOR_LOCK command class on these devices. There shouldn’t be any code change needed and once the database is updated it will hopefully do what you want (I hope ).
Are you able to update the database? If not I will do this.
1 Like
Sounds good. I can test this manually, but might not be able to test it out until tomorrow.
I’ve updated the database to add this channel to both these devices.
to get this change working on an already added device, do I delete the xml and delete/add the device in habmin? 
Yes, once the binding is updated, you will need to delete the thing and re-add so that it picks up the updated thing definition. You don’t need to exclude/re-include though.
2 Likes
This works now, great!
The notification is not updated when locking/unlocking via ZWave as discussed earlier in this thread, the lock it self doesn’t send it so nothin to be done in the binding. For me I get all changes on the lock_door channel and the new sensor_door channel. So this is good and I do not need the raw 0 - 3 condition when it is already decoded by the binding.
To understand why 1 and 3 gives closed and 0 and 2 gives open you need to know bit-masking I guess (I just realized my self 
). 0 = 00bin, 1 = 01bin, 2 = 10bin and 3 = 11bin, so masking the last bit is what the code does and checks if it is 0 or 1, smart.
What is left: Add the rest of the alarm channels to the database entry for FW 1.6 so that database entries for FW up to 1.5 and FW 1.6 and up is equal for the alarm channels.
This is duscussed by Chris and me earlier in this thread and it is not the binding that misses any events nor an error in the database, the IDlock it self doesn’t send the event when the command is coming from the ZWave controller. That being said, some one needs to add the missing alarm channels for the FW 1.6 database entry to get the events accessible. I will do that when I have more than a small screen in front of me tomorrow if no one is getting it done before.
Just be aware there is currently a freeze on database reviews until Chris finishes some database maintenance.
Just to clarify, the events that misses for me is not commands coming from ZWave, it is regular unlocks from the outside from users with codes and the channel that does not update correct is Alarm (Raw), that is my issue.
Please can you provide a debug log file - it’s really hard to know what this is without actually seeing the data that is received by the binding. If it’s above somewhere, then please reference it, otherwise please provide this information.