after restarting everything, the state is:
paper ui: NaN%
habpanel (knob number widget): 0
in openhab.log and events.log there is nothing to see. at least in the night it should be easy to find something in log file… but nothing 
did anyone recognized that sometimes the danalock doesnt react on zwave commands like ON or OFF? I have a zwave keyfob to open the door. the zwave controller becomes the signal for sure because I also have a rule that I get a telegram message
rule "FB1"
when
Item FB1 received update
then
if (FB1.state == 1.0) {
Tuer.sendCommand("OFF")
}
if (FB1.state == 2.0) {
Tuer.sendCommand("ON")
}
end
rule "Telegram Tuer"
when
Item Tuer received command
then
if(receivedCommand == ON) {
sendTelegram("bot1", "Tür: abgeschlossen")
}
else {
sendTelegram("bot1", "Tür: geöffnet")
}
end
Item Tuer is my danalock. So when I get a telegram message, the controller sends the open/close command to danalock. but sometimes danalock only react on second or third press of my keyfob.
any idea?
Yes, I’m finding the zwave control very unreliable. The Bluetooth control, on the other hand, is perfect. So I am just finishing a script for a raspberry pi to control an old android phone running the official Danalock app. A very haiku and indirect way of getting openHAB to control the danalock, but hopefully more reliable.
I’ll post the script when it’s finished.
1 Like
Please provide a debug log showing the issue. I think this is reasonably unlikely to be a problem with the binding though unless this device is doing something non-standard.
A reason could be (but not sure), that the app ia reading the battery voltage/state while close/open the door (motor under load). In zwave I think its just to configured polling time
1 Like
I’ve found the same thing - I’ve resorted to querying the status using an android phone attached to a raspberry pi: Controlling danalock via openhab using old android phone
It’s a terrible, stupid, awful approach - but I fear the bug is in the danalock and not the zwave binding… so I’m not holding my breath for a fix…
If you think that this issue is a bug in the ZWave binding, then please grab a debug logfile so we can investigate…
thanks for the credit - but i only can guess. This is very depending on how the guys from danalock designed the whole RF stuff. While it could be a good idea to send a zwave signal at the end of a transaction - i don’t know if they are sending it at all. because - while the bluetooth signal is attached - you don’t know if you can interrupt it with a sending zwave signal. (which may also cause an energy issue). But - everything blindfolded guessing from my side.
This is a question for the danalock-support - i guess. And also something they could easily fix with an firmware update. It would be very nice if someone of their hardware-developers would give us a hint/support.
This version does not include security - you should use the snapshot build.
It is included in the snapshot build now, but it can’t be retrospectively added to versions that were created in the past.
See here for the merging notification -:
It’s hard to say - I’d need to see the debug logs. If it’s not showing up at all, then there is something fundamentally wrong with the inclusion (not even secure inclusion) as a device should pretty much always include if the device and controller are working.
It’s unlikely but possible that the reset did not clear it’s zwave info, so try doing an exclusion of the lock.
Just a little hint, are you on the latest firmware of the Danalock? If not, it would be a good idea to update it.
No - the message says the manufacturer data is now known, so probably the device discovery has not happened. It’s worth looking at DEBUG logs to see what is happening.
I’m not really sure what’s happening. The log unfortunately isn’t so helpful, but the status in PaperUI is that the device is not communicating, and this is also about all I can conclude from the log.
The best thing from here would be to reset the device and re-include it, and provide me the full log of that first inclusion. The device will only securely include the first time it’s included after a reset - this secure key exchange must occur within 15 seconds of the inclusion, and if it doesn’t work, then you must reset and start again from the beginning as the device will then never allow secure communications.
There have been very few changes, so my guess is that it should still work.
I would need to see a debug logfile to see what is happening - there must be information logged showing the issue, just maybe not where you are looking. Maybe the issue is during initialisation - maybe the secure inclusion didn’t work? This would still have the device online, but it would not be able to do much as most CCs are hidden.
It would be great if you could add this into the database so it ends up in the documentation. There is a box called something like “Usage Information” where this sort of information could be added - or even in the overview information.