Lock'n'go not recognized when initial state is 'closed'

[mundschenk-at]

After some further testing it looks like the lock'n'go state change is not recognized anymore, at least not reliably. I monitored the MQTT messages and it appears that lock'n'go did not update nuki/lock/state (and consequently also not nuki/lock/binaryState for HA).

[technyon]

I tested it, it worked so far. It changed from unlocked to unlockedLnga to locked. How did you trigger the lock'n'go?

[mundschenk-at]

Double click on the button. Note: The door was locked initially.

[mundschenk-at]

I've done some additional tests. The results a reproducible for me:

Initial state	State change recorded
open	yes
closed	no

So the issue might be that the initial opening is not recognized and then of course for the closing, there is no state change when lock was closed before initiating lock'n'go.

[technyon]

ok I'll check it when I have time

[mundschenk-at]

This morning, the state change was recorded even starting from locked (real-world usage). A few test runs now show the same result as yesterday. It looks like there might be some sort of race condition regarding the initial state change of the unlock/lock sequence triggered by lock'n'go.

[technyon]

Can you try setting the energy-saving mode to fast?

Explanation: To notify a state change, the lock sends iBeacons. When setting it to fast, beacons are sent in shorter intervals, so detecting a state change is faster (and also more likely in case a beacon is missed). This of course drains the battery faster, which is the reason why it's listed as energy-saving mode.

[mundschenk-at]

The setting didn't make any difference. (It was set to "auto", I changed it to the fastest available, but the results didn't change.)

[technyon]

I could reproduce the behavior. It's strange though it seems the lock signals the state change after it returns to the locked position, not for the execution of lock'n'go. It's odd because states like unlatching and unlatched are signalled although they are quite short. I'm not sure if this is intentional or a firmware bug.

[mundschenk-at]

Any way to create a workaround for this? I'd write a support ticket with Nuki, but I couldn't document the BLE API details for them.

[technyon]

I'll ask in the NUKI developer forum.