Request to add device to the Z-wave DB - New version of ID Lock

Ok thanks! Can’t wait :hugs:

Hey again,

I don’t know what I’m doing wrong, but I can see that there was a new build of the binding on GIT hub. I couldn’t find a new version of the JAR file though. I’ve tried all night to create a working JAR file from the GIT repository without getting it to work. I googled these steps so I don’t even know if it’s possible to do it like this. Could someone guide a noob in how to get this new build in? I was running the build from the 3rd of August until now when started to mess things up :slight_smile:

No - there hasn’t been an update yet. I’ve made some changes this morning, and I have updated my code here, but what you see on GH is the master binding - not the development binding.

I will likely do this tomorrow now.

Hi Chris, yesterday I downloaded and installed the new build and I got all the parameters to work which is awesome :slight_smile:

However, I was not able to get any of the Channels to work. Nothing happens when I click the “Door Lock” and I don’t get any battery indication. The alarms I don’t understand how to I should use. I don’t know if I’m doing anything wrong (or not doing it at all). I enabled the logs already during the weekend and forgot to disable them again, so the logs are both with the previous build and the new one. I think installed the build at 9:15 and you can find those logs here. When I got home I started to play with the new configuration and that was around 19:21, or at least the logs show Param activity at that time. You can find those logs here

I imported both of them to the log viewer tool on, but I couldn’t draw any conclusions based on them. I just saw that there was a lot of activity and something happened almost every minute.

I can see all four channels in Habmin and Paper UI

Can someone make anything out of this?

The log looks like the lock is responding to commands…

But there are some USER_CODE_GETs, so it looks like the lock is not done initializing. Secure devices will take a while, especially locks that have a lot of user code slots. Until it is done initializing, there won’t be a handler assigned to the channels. Try giving it some more time to complete. I’m 90% sure I have this right… Chris will know best!

Ok thanks. I think there are 109 code slots so it can indeed take some time. I will give it til Sunday and let you know if there is any change

Nice! Will also test this.lock out as I hands on one.just recently. Will be interesting to see if it is somewhat battery friendly.

An hour would have been a long time! If it isn’t working by now, there’s a problem.

Ok, I tried after 24h and the Channels were still not working. But as you can see from the logs I was able to update the parameters. So there’s something wrong with the Endpoint or Command classes.

I compared with the DB entry for ID Lock 101 and noticed that the guy who added it created a new endpoint, but left the other one empty and with the same endpoint number (0).

I’m home tomorrow so I can try including and excluding it from the controller, but it feels like it’s initiated correctly since the parameters are working.

Have you seen this type of error before and/or do you know what could be the reason?

Also, according to the manual you should be able to get information about alarms (unlock by code and which code etc.), but the “Alarm access” is a Switch which I guess just indicates if an alarm is sent. So should I add a Alarm_raw command class in the DB or what should I do to get that information?

Eureka! I noticed that there were several XML files on both the “lock node” and the “controller node”. I did a factory reset of both devices, removed the XML-files and initialized the lock again. After that the battery and lock channels started to work.

I still have some problems with the notifications, but I need to run some more tests to understand the problem. So far I’ve noticed one thing in the logs that I reacted on and that is “channel alarms_access is not implemented”. Any idea what that might mean? See full message below

[DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, channel alarm_access is not implemented.

I haven’t tested my lock yet. Rebuilding the exterior of the house and going to switch front door. Can hopefully test the zwave a week or two.

At one point you had an item linked to this channel. Make sure that you still have one after resetting the lock.

An alarm_raw channel will report a json string message with all of the details about an alarm event. You’ll then need a rule to parse and respond to it. There are examples on the forum. You can add this to the lock in the device db. The other alarm channels are switches that respond to specific alarms from the lock. These are easier to use than alarm_raw, but they do not contain all of the information. For example, I use alarm_raw to know which code was used to open my locks, and use this info as an input to presence detection.

By item, do you mean an item in the item config file? Since the channels have not worked earlier I have not bothered to create items. But I will do that and see what happens.

This is exactly what I want to do. I want to keep a log over codes used and when in my influxdb. I’ll add it to the db and search the forum for some examples.

Yes. Based on the image, you had one linked to the channel in this post.

quote=“kosken, post:33, topic:48824”]
I’ll add it to the db and search the forum for some examples.
Here is what I use for a Schlage BE469 (it may not be up-to-date though). My lock does not report the lock state, so I have to use alarm_raw to update an item so that I know if it’s locked or not. But there is a section where I am also picking out the code used to unlock it.

Check this out too…

@kosken, did you get everything to work?
How do you experience battery life? I’ve read there are users having problems with the z-wave module draining battery.
If you have the time , please write down how you parsed the _RAW json string to get the info you wanted :slight_smile:Thanks!

I’ve haven’t had time to even add the _raw class to the db so no progress there unfortunately. Last improvement I made was to classify the lock as a swith and got it working with the new Google assistant integration. Even though “switch of front door” isn’t the most obvious thing to say to unlock the door, it’s working :smile:

Regarding the battery life I initially thought I didn’t have a problem because I didn’t get any warnings after the first 3 weeks. But then last week I had to change them. I’ve tried to extend the polling, but it’s hard to know if it’s had any impact yet since the battery status class doesn’t work either (also a common problem with this module). So yes, I have a problem with battery life, but it I don’t know how extensive it is :slight_smile:

1 Like

Hey! I’ve made a lot of progress, but I haven’t posted any updates here so now it’s time. I’ve added the alarm_raw channel and I get the json string from that channel as anticipated. I simplified the code you wrote @5iver since I only have one lock (I assume your code included a solution for three locks). It is most probably not the most beautiful piece of code or most efficient, but it works and now it looks like this:

//Rule for updating the lock status based on alarm_raw channel
rule "Lock: Update lock states after alarm_raw event"
    Item FrontDoor_Alarm_Raw received update
    logDebug("lock", "Lock: Alarm events: {}=[{}]",FrontDoor_Alarm_Raw,triggeringItem.state.toString)
    switch (transform("JSONPATH","$.type",triggeringItem.state.toString)) {
        case "ACCESS_CONTROL" : {
            switch (transform("JSONPATH","$.event", triggeringItem.state.toString)) {
                case "1" : {
                    logDebug("lock", "Lock: Alarm events: {}",LockStatus)
                case "2" : {
                    LockStatus.postUpdate("Unlocked from the inside")
                    logDebug("lock", "Lock: Alarm events: {}",LockStatus)
                case "4" : {
                    LockStatus.postUpdate("Unlocked with RFID key tag #" + (transform("JSONPATH", "$.code", triggeringItem.state.toString))) 
                    logDebug("lock", "Lock: Alarm events: {}",LockStatus)
                case "6" : {
                    switch (transform("JSONPATH", "$.code", triggeringItem.state.toString)) {
                        case "0" : {
                            LockStatus.postUpdate("Unlocked by zwave")
                        case "1" : {
                            LockStatus.postUpdate("Unlocked by master pin")
                        case "60" : {
                            LockStatus.postUpdate("Ulocked by family")
                        case "61" : {
                            LockStatus.postUpdate("Unlocked by cleaner")
                            sendNotification("", "The lock was unlocked by the cleaner code")
                        default : {
                            LockStatus.postUpdate("Unknown door lock Event")
                            logDebug("lock", "Lock: Alarm events: {}",LockStatus)
                logDebug("lock", "Lock: Alarm events: {}",LockStatus)
        case "BURGLAR" : {
                DoorStatus.postUpdate("The Burglar alarm is active")
                logDebug("lock", "Lock: Alarm events: {}",DoorStatus)
        default : {
            DoorStatus.postUpdate("Unknown Type in alarmRawParser")
            logDebug("lock", "Lock: Alarm events: {}",DoorStatus)

and the items I use look like this:

String      FrontDoor_Alarm_Raw         "Alarm Raw [%s]"                          <shield>                                       { channel="zwave:device:XXXXX:node2:alarm_raw"}
String      LockStatus                  "Test state [%s]"                         <shield>

So what I’m after is to store the values in my influxDB and therefore I created a virtual item which I populate with the status. I have not added that to the persistence file yet so that’s the next step. I don’t know if it’s even possible to store strings and display them in a nice way in HabPanel.

Anyway, the rule works great and I get the status on the virtual item :slight_smile:

I’m eternally greatful to you @chris and @5iver for all the help. Please let me know if I can help you in anyway; testing, sanity check something or perhaps a kidney :smiley:


Do you have an issue with battery drain?
Id lock recommend polling to be off completely but seemslike people still have problems with short battery life.

I have not included my module yet. Rebuilding my house exterior so can’t have a non working lock until the carpenters are done.

It’s a bit hard to tell since the battery report is not working. I installed the lock in May and the z-wave module in the beginning of August. In the end of August I needed to change the batteries. I’m still running on those batteries and no “twinkle twinkle little star” (it’s the melody it plays when battery level is low) yet.

So, I think I have a problem with the batteries, but not as big as some people have. I’ll let you know when they run out.

1 Like

I’ve used the id lock 150 for a month now, had to change batteries twice :frowning: Still don’t get what’s wrong with it, I just changed the batteries and did a re-inclusion, hopefully it performs better or I’ll have to contact the manufacturer.

Oh and I did notice something when I added it:

2018-10-10 20:28:42.248 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'alarm_emergency' for thing type 'zwave:device:zController:node92', because channel type 'zwave:alarm_emergency' could not be found.