-
Notifications
You must be signed in to change notification settings - Fork 37
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. |
@iranl does this work for you even when double pressing the button (LockNGo via button)? |
@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. |
I am reopening since this is the original issue. |
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. @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. |
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. |
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. |
This issue was automatically closed because of being stale. Feel free to reopen if you still experience this problem. |
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: