Reading more data than in the device handler

Reading more data than in the device handler

I have a yale keyfree lock YKFCON. There are transmissions coming back that are not in the handler for this device. I have identified them in the manual and in the logs too.
Manual is here:

See page 4.

These are some examples of messages:

NODE 15: SECURITY_RXD 71 05 16 01
NODE 15: SECURITY_RXD 71 05 1B 01

The 16 01 and 1B 01 indicate the following from the manual:
Manual Unlock 0x16 0x01 By key cylinder or inside thumb turn
Auto Lock Operate Locked 0x1B 0x01 Auto re-lock cycle complete, locked

Here is what happens after the 16 01 RXD:

2019-11-12 20:23:58.492 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 15: SECURITY_RXD 71 05 16 01
2019-11-12 20:23:58.492 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-11-12 20:23:58.492 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Received COMMAND_CLASS_ALARM V1 NOTIFICATION_REPORT
2019-11-12 20:23:58.492 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 15: ALARM report - 22 = 1
2019-11-12 20:23:58.493 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 15: Alarm Type = null (22)
2019-11-12 20:23:58.493 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-11-12 20:23:58.493 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=1
2019-11-12 20:23:58.493 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter processing ALARM
2019-11-12 20:23:58.493 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:71bc65a0:node15:alarm_general to ON [OnOffType]

Is there any way of reading these notifications into a rule?
@chris - Are you able to help since I think you designed these zwave handlers?


The database entry is here. In fact, your manual link comes from our database.

What version of OpenHAB? I would recommend 2.5 M4 to get the latest version of that item from the database. It was updated 3 months ago.

Hi Bruce, Yes thats where I found the documentation whilst looking at the profile for the zwave lock.
I have OH 2.4 installed with a SNAPSHOT of the zwave binding 2.5 installed from August.

So, what we can do is to add the alarm_raw channel. This will provide a JSON string with two components - the type and value. I will actually remove the current alarm_general and replace it with the alarm_raw.

You will be able to use that in the rule to detect these two events. I think there’s more information here -:

1 Like

Thanks Chris, I’ve seen the changes in the XML file in your device database!
So how do I get these changes onto my installation? Do I need to update my zwave binding?
Sorry, rather new to OH. Came from smartthings!

Since you are running 2.4 with a snapshot from August, you can get all but the last few weeks changes by updating the binding to the latest snapshot.
I hope Chris will export this weekend so we can get a more current update.

If these changes are from the past couple of days, then I’ll look to do an update this weekend (probably Sunday) otherwise they should be included in the last update a couple of days ago I assume?

Oops. I must have missed that.
The lasT time I checked must have been before that. I was waiting on the update to verify a new entry for a Zooz customer.

Thank you for your dedication.

I went through and checked the changes from the database in the past few weeks while I was away, so most entries should have been included in the Wednesday update.

Where is the download option for the latest updates? I have seen the jenkins page but cant find an actual download button! :man_facepalming:

If you have the snapshot runtime installed, then simply uninstall the binding using PaperUI and reinstall it again - it will pick up the latest version.

If you have a stable or milestone runtime, then I’d suggest to use the following script -:

1 Like

Unfortunately, this hasn’t worked for quite a while…

I have been experimenting with just using this though. It has worked fine for me and it removes the need to manually resolve the dependencies…


The script will use this one day.


Thanks Scott, that one worked for me!
@chris let me know when you get chance to merge the updated mapping on the lock and I’ll update my binding to test!

I think i’ve updated the database already and I’ll do another binding update tomorrow night so it should be included then.

Yes, sorry I think you did as I saw the changes on your website. Just not in the binding yet.

1 Like

@chris did you manage to get round to a binding update? Ive just updated it from jfrog to todays build but the alarm_general is still a switch.

Yes, I think this was updated last weekend.

Did you delete the thing and add it back? If not, OH will continue to use the original thing definition.

1 Like

Nope! :rofl:
Sorted - thanks a bunch!

1 Like