Danalock not reporting status

NCO · August 26, 2020, 8:47am

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

chris · August 26, 2020, 10:22am

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

NCO · August 26, 2020, 10:48am

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

But the Lock is sometimes not received by OH

chris · August 26, 2020, 10:50am

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.

NCO · August 26, 2020, 11:25am

Alright - thank you, Chris.

NCO · August 28, 2020, 12:53pm

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?

chris · August 28, 2020, 1:19pm

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

NCO · August 28, 2020, 3:13pm

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)

chris · August 28, 2020, 3:35pm

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 ).

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

No - it’s not a problem.

NCO · August 28, 2020, 4:01pm

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.

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

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

NCO · August 29, 2020, 6:31am

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.

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

chris · August 29, 2020, 8:24am

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…

NCO · August 29, 2020, 9:02am

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.

@chris
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)

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

chris · August 30, 2020, 8:12am

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

NCO · August 30, 2020, 8:21am

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

Do you think that using security makes a difference?

chris · August 30, 2020, 8:31am

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.

cinadr · August 30, 2020, 9:17am

Hi!

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"
when
    Thing "zwave:device:controller:node2" changed from ONLINE
then
    logInfo(logName,"Danalock is not online.")
    Danalock = false
    //try to bring back online
    if (Danalock_DoorLock.state == ON) {
        Danalock_DoorLock.sendCommand(ON) 
    } else {
        Danalock_DoorLock.sendCommand(OFF) 
    }
end

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

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

NCO · August 30, 2020, 1:04pm

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

NCO · August 30, 2020, 1:10pm

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.

dan12345 · November 19, 2021, 8:49pm

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