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.

[mundschenk-at]

I'll ask in the NUKI developer forum.

Did you get around to this?

[technyon]

https://developer.nuki.io/t/signaling-of-lock-state-change-from-closed-to-lockngo/23838

[iranl]

Workaround in #365. This will report lockngo_state in lock/json. This will be a value > 0 in seconds while Lock N Go is active.

[zanna-37]

Workaround in #365. This will report lockngo_state in lock/json. This will be a value > 0 in seconds while Lock N Go is active.

@iranl does this work for you even when double pressing the button (LockNGo via button)? Because in my tests this only works when sending the LockNGo action via software. When using the button, the lock only sends an update after it is locked again, thus not showing the state change.

[iranl]

@zanna-37: Have not tested it that way. But if it is not picked up in lock/json you should be able to detect it using the auth log.

[mundschenk-at]

I am reopening since this is the original issue.

[iranl]

It is unfortunate that this still does not work as hoped/wanted, but I don't think there is anything more we can do about it.

Nuki Hub can only react on information the Nuki lock sends. If the lock does not signal a signal change until after the action is completed, Nuki Hub can't know about it and can only publish it to log afterwards.

@technyon has tried to get a reaction from Nuki about this, but I don't expect them to come up with a response after 6 months of silence.

Every part of the keyturner state and auth log from the API is now implemented (some still open in #389). LockNGo does seem to be signaled better in the official MQTT implemantion so the new Hybrid mode (in #389) might help for users with a 3.0 Pro or 4.0 (Pro), but thats about all I can think of at this time.

We can label this as "unfixable", but I don't see much reason for keeping this issue open.

[zanna-37]

I see, and I agree with you. Sorry if I bothered you. I thought I might have done something wrong in my setup, but that's not the case. The issue can't be fixed on our end and can only be mitigated by reading the log. Thanks anyway.

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any activity in the last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.