Hello.
I am using version the snapshot version of org.openhab.binding.zwave 2.5 and i have noticed that openHAB miss several unlocks with code on my ID Lock 150.
Anyone else here using this lock? and maybe same issue?
Same here, did you figure anything out?
Nope, I still have the same issue.
I am using the latest firmware for the lock but the problem is still there.
Yeah I’ve tried resetting, reincluding, updated firmware etc… haven’t solved anything, think I’ll have to do some debugging. Reading on different forums other people on other systems don’t have the same issue, so it could be something OH/z-wave binding specific…
Yeah, I think you are right.
Last time I enabled debug mode for the z-wave binding then it did not miss any unlocks, maybe I have to run some more tests, it would be nice to solve this issue.
I have the IDLock 150 with Zwave module FW 1.6 and also looses some events. For now it seams that the info is read by the binding but not always forwarded to things/items.
I will compile comparable log entries from my event-log and zwave-log to morrow. Are you able to share your config for things and items @lfs_alp5 and @kristofferis ?
Tried to debug a couple of times but of course everything works just fine then. Don’t like debug’ing the zwave binding too much because of excessive writes on a SD image. But I’ll keep trying…
Items:
Switch DL_Fe_Yttergang_Ytterdoer "Ytterdør lås" <lock> (gPersistMysqlChange,zDevices,Fe_Yttergang) { channel="zwave:device:zController:node97:lock_door" }
Switch AlarmAccess_Fe_Yttergang_Ytterdoer (zDevices,Fe_Yttergang) { channel="zwave:device:zController:node97:alarm_access" }
Switch AlarmBurglar_Fe_Yttergang_Ytterdoer (zDevices,Fe_Yttergang) { channel="zwave:device:zController:node97:alarm_burglar" }
String AlarmRaw_Fe_Yttergang_Ytterdoer (zDevices,Fe_Yttergang) { channel="zwave:device:zController:node97:alarm_raw" }
Number BNM_Fe_Yttergang_Ytterdoer "Ytterdør Batterinivå [%d %%]" <battery> (gPersistMysqlTimed,batteryDevPercent) { channel="zwave:device:zController:node97:battery-level" }
I have done som further debugging.
Locked/unlocked state works.
It seams that the alarm_raw-channel (json-string) doesn’t receive data from the lock when a command is sent from a zwave controller.
The alarm_entry-channel is from what I can see a on/off read only switch. I’m bot sure what is the origin for it but reading the manual from idLock I would assume it shows if the door is open or closed. Maybe @chris could tell how this channel is updated.
The manual has this information for the COMMAND_CLASS_DOOR_LOCK_V2 so it should be possible to show unlocked/locked and open/closed and from my logs I can se the COMMAND_CLASS_DOOR_LOCK_V2 (index 62) is uppdated correctly:
Attached also a zwave-log, my lock has node id 23 that shows some COMMAND_CLASS_DOOR_LOCK_V2 (index 62) entries.
ZWave_log.log (111.4 KB)
I Installed this lock today, and I took a look at the code. From what I can see the COMMAND_CLASS_DOOR_LOCK handles door condition correctly.
@ZWaveResponseHandler(id = DOOR_LOCK_REPORT, name = "DOOR_LOCK_REPORT")
public void handleDoorLockReport(ZWaveCommandClassPayload payload, int endpoint) {
dynamicDone = true;
int lockMode = payload.getPayloadByte(2);
int handlesMode = payload.getPayloadByte(3);
int doorCondition = payload.getPayloadByte(4);
int statusTimeoutMinutes = payload.getPayloadByte(5);
int statusTimeoutSeconds = payload.getPayloadByte(6);
DoorLockStateType doorLockState = DoorLockStateType.getDoorLockStateType(lockMode);
logger.debug(
"NODE {}: Door-Lock state report - lockState={}, handlesMode={}, doorCondition={}, timeoutMinutes={}, timeoutSeconds={}",
getNode().getNodeId(), doorLockState.label, handlesMode, doorCondition, statusTimeoutMinutes,
statusTimeoutSeconds);
ZWaveCommandClassValueEvent zEvent = new ZWaveCommandClassValueEvent(getNode().getNodeId(), endpoint,
CommandClass.COMMAND_CLASS_DOOR_LOCK, lockMode, Type.DOOR_LOCK_STATE);
getController().notifyEventListeners(zEvent);
zEvent = new ZWaveCommandClassValueEvent(getNode().getNodeId(), endpoint, CommandClass.COMMAND_CLASS_DOOR_LOCK,
doorCondition, Type.DOOR_CONDITION);
getController().notifyEventListeners(zEvent);
}
Where doorCondition is our value. ( int doorCondition = payload.getPayloadByte(4); )
However in the zwave db the value is assigned to an OnOffType, I think we should change that to a StringType and then map the values in the table id lock is providing. I can probably test this in a day or two. I don’t think there is need to implement a v2, as v1 per above is already defined as 0x62 and seem to handle the doorcondition just fine.
Regards, S
Agree, for me an integer value works great.
I don’t know if this is anything to consider but there’s some changes in the latest versions:
I’ve not followed this, but thought I’d make a few comments…
We can’t change this channel as it will break all existing devices. We could add a new channel if needed - probably this would be best provided as a json string as we’ve done for alarms so that multiple bits of information can be provided.
Sounds good with a new channel for the door lock condition.
Looked in the code, and it looks like the current ZWaveDoorLockConverter is assuming OnOff type and only 0 or 1 (for obvious reasons 
)
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;
}
So I guess this would be have to changed to handle 0, 1, 2, 3 .
Haven’t been able to dig deeper than that today.
I actually managed to read the door lock condition successfully, but I hacked somewhat in the code and changed the channel to an sensor_general to read it out as an int.
@chris the firmware release notes they posted should probably need a new entry due to configuration parameter changes anyway. Changing channels would break existing customers then too.
This is what I changed to make it work, don’t know if it helps you @chris .
ZwaveDoorLockConverter.java
private State handleEventCondition(ZWaveThingChannel channel, ZWaveCommandClassValueEvent event) {
return new DecimalType((Integer) event.getValue());
}
idl150_0_0.xml Added a new channel of type sensor_general.
<channel id="sensor_general" typeId="sensor_general">
<label>Door Condition</label>
<properties>
<property name="binding:*:DecimalType">COMMAND_CLASS_DOOR_LOCK;type=DOOR_CONDITION</property>
</properties>
</channel>
Zwave items:
/////////////////
Group ZwaveIdLock "ID Lock" (Zwave)
Number ZwaveIdLockBattery "ID Lock [%d %%]" <battery> (ZwaveIdLock,Battery,gRestore) { channel="zwave:device:xxxxxx:node49:battery-level" }
String ZwaveIdLockAlarmRaw "ID Lock Alarm Raw [%s]" <alarm> (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:alarm_raw" }
Switch ZwaveIdLockAlarmBurglar "ID Lock Alarm Burglar [%s]" <alarm> (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:alarm_burglar" }
Switch ZwaveIdLockAlarmEmergency "ID Lock Alarm Emergency [%s]" <fire> (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:alarm_emergency" }
Switch ZwaveIdLockEntryNotification "ID Lock Entry Notification [%s]" <switch> (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:alarm_entry" }
Switch ZwaveIdLockDoorLock "ID Lock Door Lock [%s]" (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:lock_door" }
Number ZwaveIdLockDoorCondition "ID Lock Door Condition [%d]" (ZwaveIdLock,gRestore) { channel="zwave:device:xxxxxx:node49:sensor_general" }
In that case we would need a new version to add the new parameters. However we still cannot change the channel definition as it will break the system for other users.
So, just add the new definitions and not change the old. We are in agreement.
If there are new parameters in a new version of the firmware, then we should create a new database entry, copy over the old parameters from the original entry, and add the new parameters to the new entry… Is that what you mean?
1 Like
Yes.
1 Like