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

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.
[/quote]
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"
when
    Item FrontDoor_Alarm_Raw received update
then
    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" : {
                    LockStatus.postUpdate("Locked")
                    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("martin.koskela@gmail.com", "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)
        }
    }
end

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:

3 Likes

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.

I’ve heard that a lot of people have had problems with their batteries. I changed batteries in the end of August and still running the same, but as I’ve written before, it’s not possible to get the battery level reported so it’s hard to say how fast they are draining. I don’t know if this is relevant, below you can see my polling settings (I think those are the default ones).

Regarding the error, I have the same and also for the alarm_access channel. I’m only using alarm_raw and don’t actually know what the two other alarm channels are used for. So maybe they could be removed, but I’m not sure.

Ok, good to know! I’ve got the same settings so they shouldn’t be the problem.
Yeah nobody seems to get the battery level (heard on other forums aswell on different systems, homeseer etc.), the manufacturer is supposedly working on it…it will be interesting to see how we’re suppose to fix it (firmware update).

This channel is not in the database.

My guess is it was changed some time ago and you’re probably using an old version of the binding.

Can you provide a debug log showing the polling? In theory, every time the device is polled (1500 seconds in your case, but by default, it is a little longer I think) it should request the battery state.

Could be, I’m using:
2.4.0-SNAPSHOT
Build #1363
Z-wave binding: 2.4.0.201809142025

This binding should have the latest definition, but unless you delete and re-add the thing, it won’t change to use the updated definition from the database, so I’d suggest to do this.

Hmm - what device do you have? 101, or 150? I looked at the 101, but the 150 does still have this channel so what I said above is only relevant for the 101.

Ah this is the 150 version

Ok, let me think about this for a day or two. I could just remove the channel, but it might make sense to try and see what it does, and make it work properly :wink:

1 Like

For information, the emergency channel is a fire alarm (detecting heat on the inside of the door) -:

1 Like

Everytime I lock or unlock via Z-Wave command the item state changes twice:

Lock command sent (ON):
2018-10-16 13:54:12.465 [ome.event.ItemCommandEvent] - Item 'MyLockSwitch ' received command ON
2018-10-16 13:54:12.469 [nt.ItemStatePredictedEvent] - MyLockSwitch predicted to become ON
2018-10-16 13:54:12.476 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
2018-10-16 13:54:14.140 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
2018-10-16 13:54:15.763 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON

Unlock command sent (OFF):
2018-10-16 13:54:24.241 [ome.event.ItemCommandEvent] - Item 'MyLockSwitch ' received command OFF
2018-10-16 13:54:24.246 [nt.ItemStatePredictedEvent] - MyLockSwitch predicted to become OFF
2018-10-16 13:54:24.250 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
2018-10-16 13:54:25.917 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
2018-10-16 13:54:26.481 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF


Manual lock (inside):
2018-10-16 13:55:53.986 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON

Manual unlock (inside):
2018-10-16 13:56:11.513 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF

Anyone else noticed this? @kosken?

Here’s a debug of a lock command sent (node92).

https://pastebin.com/nrMvHNFT

@chris can you make any sense of this?

Hate to bug you about this, but could you please have a look at the debug log to see if anything is wrong @chris ? When you have the time… :innocent: