ZWave Door Lock - OH2 - Help

Thanks.

As my milage with OH2 is just 10 days, please remember to explain in your tomorrow update how to handle jar in relation to kar (which is a new concept for me as I am rookie with Karaf), should it be pasted into addons along with kar?

Thanks Chris! I’m excited to test this out, even though I haven’t even gotten past including all my devices, and getting Alexa to control them. It’s been too long since I set my original OH 1.x setup. Now I have to re-learn all I did before, and the new adaptations. So it’s taking some time to say the least. But I look forward to the endeavor of testing out the lock integration.

@chris I’m sure you’re a busy man, but just wanted to check on the test version of the secure lock inclusion function? You’ve seen my chaos lately with having to swap out some switches (thanks for the help btw!) - so I figure for now I can focus on the lock functionality.

See here -:

I would like to confirm that the new binding mentioned above works with Danalock/Gerdalock.

@JjS I would suggest posting in the referenced post from Chris. This thread seems to be the place that this information should be noted/confirmed.

I’ll be looking to test this out as well and post my results there. To help reduce confusion and continued add-on to this thread, I’m going to repeat the link Chris supplied here:

And will mark this thread as “resolved” so folks can direct to the correct thread. Thanks again @chris for pointing us in the right direction here and all your hard work on the ZWave support.

I posted in both threads, so either way one can find the confirmation.

Another question about the lock, about feeding back lock status to OH2.
In previous version of the binding there was a lock status channel. It was quite useful, as if someone turns the lock by hand/key, it does not change the state of the zwave:device:controller:nodexx:lock_door now. It seems that the switch works like toggle switch, everytime I change it in OH, the lock starts to move (locking if it was unlocked or unlocking if it wasn’t), but with no correlation between lock status and the switch state.

My lock is BTZW125 Danalock v2 circle.

If there was a lock_status channel in the past, I don’t know what it is as it doesn’t exist (and I think has never existed) in the code :confused:.

My Yale lock doesn’t send an update to the lock status when the door changes state which I agree is really anoying. It sends an alarm message which can be used to provide a status somewhere, but it probably can’t easily be linked to the door_lock channel.

If your device is sending a status update, then please let me know what it is and I’ll take a look.

Sorry - I don’t have this device to test against.

I meant OH 1.9, there was an item linked to the status:
Contact Door_Status “Lock status [MAP(pl-lock.map):%s]” {zwave=“56:command=door_lock,refresh_interval=120”}

How can I pull the status in OH 2.X?

I guess you can do the same thing in OH2 - this is the same channel that you should have now (ie door_lock). It should be the same - if the device provides the information through an association etc, then it will update - if not, you need to use polling - same as OH1.

Frankly, I don’t know how to setup polling in OH2.

My OH 1.9 definitions that worked were:

Switch Door_Lock "Lock" <doorlock>  {zwave="88:command=door_lock"}
Contact Door_Status "Lock status [MAP(pl-zamek.map):%s]" <doorlock>  {zwave="88:command=door_lock,refresh_interval=120"}
Number Door_Corridor_Battery "Lock battery [%d %%]" { zwave="88:command=battery,refresh_interval=43200" }

Currently I have

Switch Door_Lock "Lock" <doorlock>  {channel="zwave:device:controller:node88:lock_door"}
Contact Door_Status "Lock status [MAP(pl-zamek.map):%s]" <doorlock>  {channel="zwave:device:controller:node88:lock_door"}
Number Door_Corridor_Battery "Lock battery [%d %%]" { channel="zwave:device:controller:node88:battery-level" }

But the status of the lock is not fed back to OH. I can read the battery status only.

We discussed it over in the other thread -:

If it’s no working, then let’s get a debug log so we can see what is happening.

What log will be the most useful? Should I collect it from the OH start or after some time? Should I wait for the newer version of binding?

Always the openhab log file with debug enabled.

Well we need to capture the polling of this device. This will happen during initialisation, or you could increase the polling and just grab another time which is likely to be easier (eg set the polling the 20 seconds, and then grab a minute from the log and it should be there).

No - nothing has changed.

Howdy all.

I’m hoping someone can provide a summary of the latest status on Z-wave locks. It seems like most of the info is in this thread, the “Z-wave (Schlage) Lock Support”, and the “Z-Wave refactoring and testing… and SECURITY” one, but that’s literally 700+ posts to read through.

Can anyone provide a step-by-step guide to getting a Z-wave lock included and working (mine is a Schlage BE469), including:

  • can z-wave locks be used with OH 2.0 out of the box, without the security bindings
  • is habmin needed to do the install, which version, and how to use it
  • is the new 2.1.0 z-wave binding needed, and is it reliable
  • how to install that binding
  • what uninstalling/reinstalling of Things, bindings, etc. is needed
  • what functionality will be there / missing

Or, just a pointer to a single post or shorter thread with a summary on it?

I want to shoot myself in the head after trying to plow through the posts on this for the last couple of nights!

Thanks in advance from a noob.

@iiigoiii - welcome! I would suggest that if you advertise as being a ‘noob’, you should definitely take the time to start from the top and scroll through the other topic. You will learn A LOT by reading through those comments. Even when it doesn’t make sense at first, when you get into the weeds of testing and using a newer and unsupported binding, you can navigate safely through and at least recall some things you read through. So my advice, definitely click on and read from the top on the referenced thread. At a minimum, you will need to find where the link is for the new binding.

No, currently the ZWave binding included with the currently released versions of OH, DO NOT include support of the Security class for ZWave.

I don’t know that HABmin is required, but in my opinion, it’s the better tool to use with this setup. I don’t believe there is a “version” of HABmin that is required. You should be able to just enable the binding and then the UI will appear on the drop page with the UI choices.

Yes, it is required, and it is not “supported” in OpenHAB yet. Currently the thread you mentioned is the “support” for it and managed by a very generous contributor here @chris. He spends a lot of time and puts a lot of work into this for the good of the community. Please do your due diligence in reading and researching how to use the binding, locks, devices, etc, before trying to bombard him on that thread. Many things have already been handled and answered, and that thread is for folks testing this new binding and finding the bugs/issues with it. That said, don’t be scared to report something that doesn’t seem to be working as expected, and be prepared (aka learn how to) enable DEBUG logging and pull these logs.

Instructions for installation are outlined many time throughout the thread referenced. I’ll give you the short snippet version, but if something doesn’t make sense, please read through the thread. The search option is your friend to use keywords necessary to jump to what you need.

  1. Uninstall the current ZWave binding if already installed
  2. Verify the Serial binding IS installed (ZWave binding may remove it or if not installed it may be missing)
  3. Remove existing ZWave Things (you can leave items and remap afterward)
  4. Stop currently running OpenHAB instance
  5. Download the latest test binding
  6. Copy it into the /openhab/addons folder in your installation
  7. Start OpenHAB
  8. Verify ZWave binding is installed/available

See above

I don’t believe this is any missing functionality, there is only new more advanced functionality to support the Security Class for ZWave devices.

1 Like

Thanks @shawnmix for the info, really appreciate it.

(Believe me - I did plow my way through the evolving info in those threads, and read everything I could find on the bindings & devices…hours & hours worth! There’s huge value in someone putting the pieces together in one place - I’ll do the same when I find out what works for me.)

My first question was not if the released zwave binding would work for security, but rather if locks could be used without the security bindings in the first place. Guessing not since I was able to associate the lock with OH as released, but it didn’t function.

I’m making slow progress anyway with the new binding, now have a secure association but the device is unknown, even though the device was known and correct under the 2.0.0 zwave binding. Will post about that in the other threads.

@iiigoiii - got ya. Well as you found yes the answer is that it will NOT work with the regular binding at all. It shows up and may identify the device, but since it isn’t SECURE included, it won’t communicate properly for the Security Classes you need. Essentially making it useless.

If you are noticing that the device is shown as unknown, I often find this happening as well. Delete the ZWave Thing and then run the re-scan of ZWave devices. It won’t delete from the controller, but for some reason the second scan works on identifying the details of the item. You also need to be sure that it did in fact securely include (aka see the green bar message in HABmin when including). If not, it’s very likely it did fail. I had this problem the first few times with my Schlage BE469.

1 Like

Well, it finally worked…I think it was your hint to rescan without excluding that might have done the trick.

I reset everything and scanned for devices with a secure inclusion, and the lock showed up again as an unknown device. I then deleted the lock thing without excluding it or removing it from the controller stick, and then re-scanned. The second scan showed the device as known with the correct manufacturer and device params.

Or who knows, maybe it was just luck on the 11th try.

Thanks again for the help!