I updated my openhab to version 2.3.
Currently I’m using version ‘2.4.0-SNAPSHOT’ of the z-wave binding (downloaded today).
The latest version of the development binding dated 8th Sep 2018 is
Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…
Now I encounter the problem, that my Danalock (v3) doesn’t report back the door lock status if manually triggered.
If I click in the UI (e.g. Habmin) on close or open, the lock closes or opens as expected.
If I use the lock manually, the new state (let’s say ‘open’) is not reported to openhab.
What did I try:
deleted all things and added them newly after the update (everything else works fine)
checked lifeline association (was empty in Habmin and PaperUI, set Controller as lifeline and saved, but didn’t help).
new inclusion of Danalock v3
new firmware for Danalock and reinitialization of the lock itself
healed the Danalock (in Habmin)
restarted openhab a few times
I also set the level of the binding to debug and created a few
Danalock is node 74
Does anyone have an idea what the problem could be?
It seems, as if the Danalock always looses (or never accepts?) the lifeline setting. Because after a while and a reload of habmin (or paper ui), the lifeline is empty again.
Since this is a lock it probably is using the Security command class which is not yet (hopefully really soon) supported by the 2.4 SNAPSHOT. You have to use the development branch version of the Zwave binding and include the device using the instructions at the following thread.
The latest version of the development binding dated 17th July 2018 is
Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which…
Yep, that’s actually what I’m using
I’ve found the danalock highly unreliable on zwave, so ended up using an old android phone to pull updates off bluetooth:
Controlling danalock via openhab using old android phone
Hm, well till the update (to openhab 2.3 and newest dev z-wave binding) I didn’t have any problems with the Danalock. It always reported back the door lock.
Now it doesn’t and I feel a bit uncomfortable to create a workaround just because the z-wave binding (?) or openhab doesn’t play along with Danalock.
There have been some changes in the latest dev binding to try and fix some issues with associations. I would suggest to try reinitialising the device (there’s an option in HABmin menu to do this) and if that doesn’t work, please grab the debug log from the initialisation so I can see how the associations have been set.
As this is a security device, please provide the logs via a ticket on my website.
Thank you. I created a ticket (ZFyhRpDM8TX) and added the logs.
I don’t really see anything immediately wrong. The associations are being set correctly -:
This shows the lifeline group (group 1) being set to node 1 (the controller), and the report confirms that it is set correctly.
Is there anything received when you open the lock manually?
As you see, I provided 2 logs, the second one has openclose in it’s name and was taken a few minutes after I opend and closed the lock manually.
So, I think nothing is there …
But this log is 10MB and has hundreds of entries for node 74. I don’t know when you opened/closed the lock so I can’t tell if there was nothing there at the exact time you opened the door…
Can you tell me the exact time you manually opened the door?
I will create a clean log (in a few minutes)
Reinit will be the first thing to see
Then a log where I try to open close
and the timestamps when what happend
I added two new logs with a comment in the given ticket.
Thanks, so it seems there’s nothing in the logs. I’m not sure what else I can add really - the association seems to be set fine, so if the door is not sending reports, I’m not sure what else can be done to change this. There doesn’t appear to be any configuration that can be changed either.
Since the device doesn’t support the MC association command class, there is really only 1 way that the associations can be set (unlike more complex devices with multiple endpoints where the multi channel association class is often used these days) so I don’t see any possibility for this to be wrong.
I will try another hard reset of the Danalock and see if something changes.
The hard reset did the thing. Now it works, funny thing is, that it reports:
open -> switch: On
closed -> switch: Off
It also behaves the same way, if triggered by the ui.
Switch: On -> opens the door
Switch: Off -> closes the door
Except of that, everything works fine now
Have you tried recalibration it?
Yep, but it does what it should, the controls are just inverted. But on the other hand, that may be related to the newest firmware of the Danalock.
My assignment of the controller to the lifeline setting gets lost after each restart so that I have to assign it manually. Is there a trick to automise it?
Please ensure you are using the latest binding, and if it is really getting lost, then please provide a log showing what is happening. It could just be a display error with the UI.