Danalock not reporting status

By the way:
I recognized that the channel “alarm_entry” reports more reliably it’s state than the “lock_door” channel.

I would assume they are providing different information, but the “reliability” of the reporting should be the same.

Both channels seem to be triggered simultaneously (see here):

But the Lock is sometimes not received by OH

My point is that if commands aren’t received, and there’s a general reliability issue, then it should not be worse on one channel than the other. The binding should be 100% reliable - if it receives the data, then it will process it - if the data is corrupted over the air, then it will not differentiate between different packet types.

1 Like

Alright - thank you, Chris.

I hope that you @cinadr don’t mind, that I use your original thread, because I still have the issue, that the danalock (node 16) does not report back it’s state.
(OH 2.5.8 with zwave 2.5.8 on openhabian)

The lock is online according to Habmin / Paper UI:

Node 14 is not operational (wall plugg currently not used).

After switching to TRACE for the zwave binding I see entries for Node 16 while locking the door with the danalock app:
See log here:
openhab_Node16.log (192.8 KB)

According to your zwave log viewer @chris 29% of the Node 16 messages are lost:

I also see NONCE ID invalid:

Does this red circled NO ACK mean that Node 16 did not get anm ACKNOWLEDGE from the controller?

No - it means that the controller didn’t get an ack from the lock.

1 Like

Thanks Chris,

So, Could this be the reason, why OH does not get an update from the lock?
How to solve the missing ACK?

Could this be a problem (these are the default values - I did not change these)

Possibly - it means that communications links are probably poor. It looks like maybe this is causing things to get out of sync - the secure protocol uses multiple commands to transfer a single report and if they are out of sync, as they are in this log, it won’t work (that’s security for you :wink: ).

How far away from the controller, or another mains device is the lock?

No - it’s not a problem.

So, that might be the problem…
The closest mains powered device is a fibaro FGS222 Double Switch (Node 4 in the Habmin screenshot above) and about 3 m away.
The second one with a direct connection (Node 9 in the Habmin screenshot above) is an FGWP102 Wall Plug and about 8 m away.
My Controller is approximately 5-6m away with a Brick wall in between.

I have moved the Node 12 Wall Plug close to the lock (1 m below).
The zwave network looks the same though.
Even after restart I don’t see a connection between the two.
Shouldn’t the devices hook up with each other?

After a complete restart there is still no co0nnection between Node 12 and Node 16.
However, closing the lock looks kind of better:

(except the No valid NONCE! null

As mentioned in my earlier post 40 the ALARM_REPORT is received, the LOCK_DOOR is not received.

This morning I just recognized that the lock now has a direct connection to the plug beneath it. So I hope that improves the communication.
We’ll see…

With the new zwave hub (Wall plug close to the Lock) it seems to be ok.
At least the mast few times, the lock reported both alarm_entry and lock_door properly.

Thanks a lot for your patience and support!
I hope this case is closed now :wink:

1 Like

Glad it’s working.

I would have generally expected that your original configuration with a powered device 3m away should have been ok, but there’s a lot of variables that can influence this…

Too early happy.

Trying it again (Locking) after a while brings the following log:
openhab_Node16_3.log (152.5 KB)

That’s really strange, because zwave based devices used to be the most stable ones in my setup.
The only issue I had was with Sensative strips with an older FW years ago.

Do you have any more suggestions how to troubleshoot improve things?

By the way, my controller (if that matters)
Bus 001 Device 007: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

Showing almost all devices as neigbors - not the Lock though (Node 16)
(and the Sensative Strip Node 8 - about 10m away from the Controller)

After changing the position of my openhab Raspi with the zwave controller it seems to be ok.
But time will tell…

I think the various comments here seem to indicate that the issue is a comms issue. As I mentioned earlier, I would really have expected this to be ok if it was only a few meters away, but there are so many factors that can influence this that you can’t be sure.

Hopefully it stays working now though :slight_smile:

Thank you, @chris
I hope so, too.
Trust me, if not I will report back :wink:

Do you think that using security makes a difference?

It won’t directly make a difference to the quality of the communications, but it will highlight any issues since the secure protocol broadly doubles the number of packets that need to be sent. This means that if there are any comms issues, you’re now approximately twice as likely to see lost data.



I can confirm that repositioning really improves the overall communication. What I assumed is that my 868 MHz devices (Bisecur Hoermann Garage Door opener) was interfering with the communication. I relocated the gateway and now I have a really solid Danalock operation. I also updated its firmware through the Android App and my AEOTEC USb Stick Gen 5 firmware as well. I have a rule that monitors the thing status of the lock and I have an AEOTEC Recessed Door Sensor that keeps up a logic (If the lock is ON and the Door is opened the Danalock status needs to be updated, etc). In this setup the operation is really smooth.

var Timer timer = null
val logName = "AutoLock"
var Danalock = true

rule "Monitor DanaLock_DoorLock Disconnected"
    Thing "zwave:device:controller:node2" changed from ONLINE
    logInfo(logName,"Danalock is not online.")
    Danalock = false
    //try to bring back online
    if (Danalock_DoorLock.state == ON) {
    } else {

rule "Monitor DanaLock_DoorLock Connected"
    Thing "zwave:device:controller:node2" changed to ONLINE
    logInfo(logName,"Danalock is online.")
    //sync states
    if (Danalock_DoorLock.state == ON) {
    } else {
    Danalock = true

rule "React on DoorSensor_SensorDoor OPEN"
    Item DoorSensor_SensorDoor changed to OPEN
    createTimer(now.plusSeconds(5), [ |
        if (Danalock_DoorLock.state == ON) {
            logInfo(logName,"Danalock status is updated (Door opened <--> Lock is locked.")

Got it.
That totally makes sense.
Thanks, @chris Chris.

Thanks for sharing, @cinadr
The thing is, that my lock was always online - even if the „lock“ message did not come through.
I will check for SW updates for the usb stick, though.

for those of you with a danabridge, there should now be a much more reliable way to control your danalocks - see this post