I have a Kwikset SecureCode 888 deadbolt and I have it configured and working on OH2.3 stable, but using the snapshot zwave bindings. I need to use the snapshot bindings because the deadbolt is Gen5 with secured pairing which doesn’t currently work with the 2.3 stable bindings. Because this device was not setup in Device Database, I have submitted the device and I have it currently working, for the most part. The issue I have is that I am not able to get any alarms from the device. I don’t see anything in the logs at all. It does report locked and unlocked statuses, but that’s it. If I put in an invalid code, it doesn’t alarm at all. I also do not get notifications if the door was unlocked or locked with the key or with the internal knob. I only get unlocked/locked notifications if I unlock/lock via OH. I also verified that I have the Lifeline association group assigned to my zwave controller. I had to do some iterations of the database config to get it working correctly since so I had some conversations with @chris about this as well, but he said it would be best to post this on the forum and get some input from others that might have more familiarity with deadbolt configurations. Below is the link to the installation guide for the deadbolt as well as a link to the device configuration in the database. I believe it is close, but that there is probably something I don’t have configured correctly.
Any insight or advice into what could be causing these issues would be appreciated. Let me know if there are any details that are needed to troubleshoot this further.
Do you mean the development binding from the first post in this thread? This is not the snapshot version. If you look at the Thing attributes in Habmin, does Security have a green check mark?
Have you set Association Group 2 to the controller? It’s set in the database to do this by default, but double check. You may want to check the debug log filtered on this node to be extra sure that it it set. Another thought… did you update any of the Alarm channels in the database after the lock was identified by your system? If so, you may need to delete (not exclude) the Thing and start zwave discovery to pull in the updated Thing definition.
I’d focus on the Alarm (Number) channel for now, as that one should provide all of the alarms in a json string. Actually, you may want to change the name of the channel to Alarm(raw) to keep it consistent with other locks in the db.
@5iver, I did have both association groups assigned to the controller. It displays funny in the Habmin UI though. When I add them and click “Save” they show up, but if I refresh the screen they disappear. I have that shown below.
Also, I did have to change the alarm channels, but I have also done the delete and add (not exclude) and it still doesn’t make the alarms show up in the logs at all.
As for the “Alarm(raw)” I am not able to set that because I get a “Depreciated class” warning in the device database when I do it.
Do you have any thoughts on what I could try next?
That is a known UI bug in Habmin. You can view the associations properly in PaperUI if you need to see them. I’m very familiar with the issue.
I don’t know what you mean by this. Where/when do you get the error? Do you have an item linked to the channel? If so, is it receiving updates when using the lock?
Really? I’ll need to double check this, but you should be able to use alarm_raw without error. Looking at the database code, the error should only be on alarm_number which is deprecated, and it should tell you to use alarm_raw.
Sorry about that, I must have had it reversed. I know that it did complain when I had it setup as either alarm_number or alarm_raw because one of them was deprecated.
Also, I did some playing around and deleted the device again and setup all the items again and did a reboot. After that I now notice that I am getting the ‘alarm_raw’ notifications. I am not getting the ‘alarm_access’ notifications though. Does that mean that something still needs to be corrected? I am not sure if this is normal to only get alarm_raw notifications or not.
I’m not sure if you were asking me or Chris, but I only use alarm_raw (with a different lock), and it’s all I need. I parse the json to understand what the lock is saying using this…
Alarm_raw will give you information on all alarms. Alarm_access, or other alarms, will be filtered and will only activate when specified alarm types are received. What do the logs show? What alarms are being received?
