[SOLVED] Adding new zwave device to database, command class channel types? lock_door deprecated

I just added a new lock to the zwave database


I saw it was compiled into the binding on Sunday (thanks!) and I installed the latest snapshot on Monday. I can now operate the lock and it reports its battery level (awesome!). But the lock doesn’t update its status (locked vs unlocked) and the alarms aren’t working.

Why does it say the channel Door Lock (lock_door) is deprecated? I added it to the DOOR_LOCK command class. I added it because I was copying another lock (one I own already in the database) and it isn’t marked deprecated there. What should I be doing instead? One change I just made a few minutes ago was to tick the BASIC box for the DOOR_LOCK command class. I think this might allow the lock to report its status. Should I then remove the lock_door channel and just have no channel there? I didn’t have to add a channel to the BATTERY command class yet it works with no issues, so maybe I should handle DOOR_LOCK the same?

I am also pretty sure I did the alarms wrong. In the XML file I saw 3 alarm types under COMMAND_CLASS_ALARM:

So I added 3 channels named alarm_power, alarm_access, and alarm_burglar to the ALARM command class (again copying another lock in the database). But I am thinking I should delete these three and just add the alarm_raw channel instead. I use alarm_raw with my existing lock (same brand: Kwikset / Weiser / Black&Decker) and it works well for me. This lock (the old one) doesn’t update its locked/unlocked status for about 30 minutes after you operate it, but the alarm updates instantly, so I use that. For the new lock, I do see a bunch of activity in the zwave debug log when I manually turn the knob. I won’t include it all (there is a lot. Plus it looks like it might have my security key in some of the lines?) but it does seem to want to report an alarm, which is what I want

10-Dec-2019 21:52:26.149 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 21: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
10-Dec-2019 21:52:26.149 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 21: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
10-Dec-2019 21:52:26.149 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 21: NOTIFICATION report - 22 = 1, event=2, status=255, plen=0
10-Dec-2019 21:52:26.149 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 21: Alarm Type = ACCESS_CONTROL (22)
10-Dec-2019 21:52:26.149 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 21: Got an event from Z-Wave network: ZWaveAlarmValueEvent
10-Dec-2019 21:52:26.149 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 21: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter processing NOTIFICATION
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter NOTIFICATION event is 2, type OnOffType
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter processing NOTIFICATION
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter NOTIFICATION event is 2, type OnOffType
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter NOTIFICATION event is 2, channel alarm_access is not implemented.
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter processing NOTIFICATION
10-Dec-2019 21:52:26.149 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 21: Alarm converter NOTIFICATION event is 2, type OnOffType
10-Dec-2019 21:52:26.149 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 21: Commands processed 1.
10-Dec-2019 21:52:26.149 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 21: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3c039996.

In summary I am wondering

  1. Was linking DOOR_LOCK to BASIC the right thing to do?
  2. Should I remove lock_door from DOOR_LOCK?
  3. Should I delete the 3 alarm channels I made and replace them with alarm_raw?


This is a bug in Firefox (I guess you did use FF to add the device to the database). The “deprecated” tick box is checked by default. This does not happen in Chrome.

In general it is not needed to edit the command classes at all. Those are read from the xml you are uploading.
Locks are a special case, unfortunately I don’t have any and can’t comment on that.

that seems to be the case (and solution) for many, it not all locks.
There are several threads from Chris about the alarm_raw channel, please read them and edit the database accordingly.

1 Like

Thanks for the quick reply

I did use Firefox to add the device. But when I’m editing or adding channels I don’t see a “deprecated” tick box anywhere. I tried re-adding the channel using Chromium 78.0.3904.108 and the new one says deprecated as well. Maybe it copied it from the existing channel. I’ll submit a ticket on the database to have this fixed (I need to to delete the duplicated channel I just made anyway)

edit: after having no better luck in Chromium I switched back to Firefox. I found that when you create a new channel it adds [deprecated], but if you go back in and edit the channel label, it removes it. So that could be a workaround for users facing this issue, create your new channel with a label that’s slightly wrong, then go back in and edit it to what you actually want, and it won’t say [deprecated] any more.

Yeah, unfortunately when I first included the device in my controller, it wasn’t included securely. The XML file I got when I first un-securely included it was very different from the one I got with secure inclusion. Or maybe this wasn’t because of security but just an error with the first inclusion. I uploaded the first XML file, and then when I updated it with the new one, it didn’t edit any of the command classes. I guess that’s normal - uploading an XML file later is only intended to add device IDs, when you have a device that’s the same as an existing one in the database. You wouldn’t want that later upload to mess with people’s existing devices.

I did find a bunch of threads about alarm_raw on the community here in the past week. I’m glad I did - I’m using this channel with my old lock and it works very well! I was just wondering if it was the right thing to use on this new lock. I guess the only way to know would be to ask the manufacturer (they have been extremely unhelpful), so I will just give it a try and see what happens.

Thanks for your help

I am not sure this is a database issue as it is working fine with Chrome.

Don’t worry too much, during approval we will set the correct checkmarks (usually).

Correct. If command classes are already available newly uploaded xml files are ignored to not mess up the database.

No, this won’t work either :smiley:

If you now have a correct xml I suggest the following: I will delete the device and you start from scratch.

1 Like

Oh, sorry, I just meant fix my channel with the deprecated tab, if the database works fine for you then I agree it must be something on my end

I appreciate the offer but I would rather not. I already added all the stuff that has to be done manually, like explanation for the configuration parameters, association groups, etc. and I would rather not do it over. I double checked the new XML file vs. what I put in the database and I think everything is okay.

My lock is already reporting battery level and I can operate the lock, I only need alarms now, and putting the alarm_raw channel in the ALARM command class should fix it I think. The lock not updating thing seems to be pretty common among locks and most users use the alarm_raw channel for updates.

I see someone deleted the extra channels in the database for me so I submitted it for review/approval. Then, when the binding is next compiled, I’ll update my snapshot and see what happens. Thanks for your help.

Unless it is already approved you can easily copy all that from the old device through the menu with “Copy configuration”.