New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lock'n'go not recognized when initial state is 'closed' #35
Comments
I tested it, it worked so far. It changed from unlocked to unlockedLnga to locked. How did you trigger the lock'n'go? |
Double click on the button. Note: The door was locked initially. |
I've done some additional tests. The results a reproducible for me:
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. |
ok I'll check it when I have time |
This morning, the state change was recorded even starting from |
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. |
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.) |
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. |
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. |
I'll ask in the NUKI developer forum. |
Did you get around to this? |
Workaround in #365. |
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 notnuki/lock/binaryState
for HA).The text was updated successfully, but these errors were encountered: