-
-
Notifications
You must be signed in to change notification settings - Fork 3
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 state not updating properly #132
Comments
Does the lock state change in the Nuki app? Does the lock state change after you select Identify on the lock accessory in HomeKit? This causes Homebridge NB to ask the Nuki bridge to contact the smart lock and update its cache of the lock state. Do you see any errors or warnings in the Homebridge log? Please set Log Level on the Nuki bridge accessory to 2, run Homebridge in DEBUG mode, and capture and attach the Homebridge log file, from restarting the child bridge, through unlocking, waiting for the auto-lock and waiting a couple of minutes. |
hi, thank you for a swift reply |
You might need to use Eve or another decent HomeKit app to find Identify; Apple's Home app doesn't support all of HomeKit. Homebridge NB calls the API of the Nuki bridge. My bridge exposes this API on port 8080, which, I think, is the default. Not even sure if that can be changed. It is returned by In addition, Homebridge NB provides a web server for callbacks from the Nuki bridge. By default this uses a random port (>= 1024), but you can change this under the Advanced settings. Homebridge NB issues a log message on startup, which shows the port: "listening on http://0.0.0.0:45969/notify". |
here's and excerpt of homebridge log
|
The Nuki bridge reports it as unlocked (with lock 'n' go enabled):
Note the timestamp of the last known state (by the Nuki bridge): it hasn't updated since 15:08 (UTC). I've never used lock 'n' go myself, but I would expect the lock to report state 1, locked, after it auto locks. If it does, it doesn't seem to inform the Nuki bridge. As I asked before, could you please force the Nuki bridge to update the last known state, by issuing Identify on the HomeKit accessory (as exposed by Homebridge NB), or by issuing |
Just tried myself (on my SmartLock 4): press twice to activate lock 'n' go with the door open. On closing the door (I have a door sensor), the SmartLock locks. The HomeKit accessory, as exposed by the lock itself over Matter, switches state immediately. The Nuki bridge (and, consequently, the accessory as exposed by Homebridge NB) continues to report unlocked. On Identify, the bridge refreshes its cached state and now reports locked, causing Homebridge NB to update the accessory. I would quality this as a Nuki bug, probably in the Nuki smart lock firmware (it should inform the bridge of the new state). |
that's a shame |
Could you try beta v1.4.17-1? This version forces the Nuki bridge to refresh the smart lock's state, when it seems stuck on: unlocked (lock 'n' go), locking, unlocking, or unlatching. I daren't do a regular force-refresh as this would drain the smart lock's battery. |
hi! |
The beta seemed to be running fine in my house; I published v1.4.17. |
Now the lock seems to be stuck on regular unlock |
my setup is Nuki smart lock 4.0, Nuki Bridge and Nuki opener
homekit hub is Apple TV 4K 2nd gen
after unlocking the door lock it remains in "unlocked" state indefinitely even though the lock is auto-locked after a minute
restarting homebridge or just home bridge-nb childbridge sometimes fixes the issue
The text was updated successfully, but these errors were encountered: