[SOLVED] Danalock V3 - Z-Wave

thanks - will report back

Dan

hey,

I just did all steps again with new jar. The device got recognized now and I can manage it via openHab / zwave.

thx!

edit: one thing: does the battery level work? it shows me 0%

Yes - it should be fine.

To confirm, with the previous version, you were unable to include the Danalock, and now it’s ok?

@chris yes, but I dont want to put my hands into fire that I didnt have done any mistake with the previous jar. But with the new jar I just uninstalled the zwave binding v2.2, stopped openhab, placed jar into addons, started openhab and just searched for new devices without rebind my old devices again. they still worked and I found the danalock directly.

regarding battery level… hmmm, paperui control shows me 0%, the same in habpanel. perhaps any error in my item declaration?

Number TuerBatterie "Tuer Batterie" <Door> (Door) ["Number"] {channel="zwave:device:0a8ccf87:node9:battery-level"}

Ok, thanks - a positive sign at least, and I’ve also have someone else provide similar feedback.

This looks ok. I would check the log to make sure the device response looks ok, but I would be reasonably sure it’s correct.

Hi chris,

found nothing in log file. Meanwhile I’m searching a habpanel widget. a simple switch does work, but I want it a bit more visualize like in danalock app with red/green bgcolor of current state etc. and especially sometimes I want to just open the door. this is not possible with a simple switch. is there anything available or does I have to create an own one?

The battery state should be updated every hour - it’s polled. I guess it should be in the log somewhere or the log every hour or so or the UI would not show a value if it’s never been updated.

I would probably ask that in another place rather than here as different people will probably answer - certainly I can’t comment on HABpanel configuration (sorry)…

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 :confused:

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 -: