-
-
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
Nuki Smart Lock 3.0 Pro not Added #44
Comments
I don’t know, to be honest, technical info on the 3.0 Pro is scarce. Does the bridge expose it over its HTTP API? Or does the lock provide over WiFi the same HTTP API as the bridge? Could you please run I understand the door sensor only connects (over BLE) to the lock (similar to keypads), so it can only be exposed through the lock.
No. Do you know if the native HomeKit function now uses WiFi as well, or is that still using BLE? Do you see a Bonjour announcement for the lock? Could you please check using the Discovery app, or the
That sounds promising, although it seems like a waste to disable WiFi on the Pro. I would hope the bridge might connect to it over WiFi, or the lock provides a (similar) HTTP API over WiFi. |
I would also be interested in this enhancement (also have now a 3.0 Pro) |
Cool. To help, please provide the info I requested above.
Definitely for the Opener (since that doesn’t do WiFi). As I said above: I don’t know for the 3.0 Pro. I double-checked the Nuki developer forum, but no mention of a local HTTP API by it. It’s mentioned on the web API (which I suspect the Nuki app will be using), but that’s violating my “no clouds in my sky” principle. I’m half considering creating (another) Homebridge plugin that would communicate with the Opener and Smart Lock over BLE, ditching the Nuki bridge altogether. I’m still very new to Bluetooth, and my first experience for controlling my blind motors isn’t all positive (see Homebridge SOMA). I want to work that out, before embarking on a new project.
The 2.0 has a native HomeKit feature as well, over BLE. I already expose the integrated door sensor of that device, so that shouldn’t be an issue, if it’s available over the HTTP API. |
Hey, thank you for looking into this.
I checked nb list and got this output for the Lock: { So your tool is recognizing it but can't hand it over to HomeKit?!
I added the Nuki Lock again through the native HomeKit function, that worked fine. But i couldn't find a new Nuki device with the Discovery App so far. Just the Nuki Bridge with Homebridge flags. But i think the lock should, at some point, use WiFi. Nuki is advertising with Native HomeKit for this Lock. This should also be possible without an HomePod/AppleTV. So it has to use WiFi instead of BLE to connect to your Network?!
That sounds really cool. Looking forward to this.
I needed the Bridge for the Opener. Since i do have the Bridge i did turn off WiFi for the better batterie life. |
As I suspected:
I will need to whitelist this device type. Otherwise, the output looks suspiciously familiar (including the door sensor), except for:
Do you have a keypad, or could this be the battery state of the door sensor? Out of interest: what is the firmware version of your Opener? And of your bridge? Could you check with |
Could you try beta v1.2.0-0? |
no, i don't have a Keypad and never had one. So maybe it's the Door Sensors tinker switch.
{
i will give it a try right now. |
It is working. Everything is working as it should so far. Edit: That's not True, Sorry I will test some more scenarios tomorrow. Thanks for your fast response with the beta. Will get back soon with more testing if needed. |
Oh, that's interesting: the bridge returns
Could you please double-check that you can control the lock, including an identify to force-refresh the device state (should update
Similar for the Smart Lock 2.0 with integrated sensor. Worse, sometimes it doesn't even report if I open and close the door too "quickly". Indeed, my Xiaomi Aqara door sensor with Homebridge Hue is a keeper. |
Nevermind. I only checked the Door sensor yesterday night. I dont wanted to crank up the Lock motors because my Family was sleeping. If I'm doing a Unlatch:
If I'm trying to Lock it:
If i want to identify the Lock in Eve App with the ID Button in the Top right:
|
And if you try Note to self: looks like there’s also an unhandled promise rejection… |
Cater for different `deviceType` values for same service, in support of Smart Lock 3.0 Pro, see #44.
- Use `firmware` and `deviceType` to detail _Model_ for Smart Lock. - Cater for different `deviceType` values for same service, in support of Smart Lock 3.0 Pro, see #44. - Bug fix: Unhandled promise rejection on _Identify_ in case of API error.
Beta v1.2.0-1 should handle |
This looks very promising.
That was the only instance it printed an error. I tried any possible mix of locking, unlocking, latching, unlatching. It seems very stable for now. I couldn't get it to output any error except this one at the start. I love that it is possible to reduce the logging. Unlike with homebridge-hue, which all the time spams the nuki logs. It is giving me a hard time to find all the NB outputs. 😄 |
HTTP status 503 means the bridge is busy and won't currently accept the command. Typically happens when two clients interact with it at the same time, or when it receives too many commands in too quick succession. It's not very powerful. The dynamic logging feature is provided by homebridge-lib. Homebridge Hue still isn't based on homebridge-lib, see ebaauw/homebridge-hue#4. No dynamic logging, until I'll get to that. So much to do, so little time... |
To much "traffic" could be possible. I accidentally switched the latching switch a few times because nothing happened at the first activation and opened the door manually. |
Is there anything I can do to help you with. Right now it looks like you did it. The lock is functioning exactly as it should and i couldn't find any further errors in the logs so far. |
Cool. Just wondering what the non-Pro Smart Lock 3.0 looks like, in particular what |
sadly i can't help you with that. Lets hope someone can jump in and get you the missing value. |
Released v1.2.0. |
one last thing.
|
It looks like the bridge sent an incomplete response to the
This would suggest the bridge rebooted just before Homebridge NB sent the
And again a minute later? |
That's strange. I did not reboot the bridge. No |
I think it might be prudent to power cycle the bridge and monitor if you see more of these odd messages. As I said above, the bridge is not very powerful and it occasionally (every couple of months?) locks up. Also better power cycle it, after firmware updating the connected devices. |
Will do. thank you for this tip. |
Got a reply from Nuki developer support. The bridge doesn't distinguish between the Smart Lock 3.0 and the Smart Lock 3.0 Pro. They documented the new |
Hi! Any update on this? I have the 3.0 Pro smartlock and I am wishing to be able to unlock my door instead of just opening it 😄 |
I added my new bought setup (Bridge, Opener, Smart Lock 3.0 Pro with Door Sensor) to HomeKit with this plugin and only the Bridge and Opener get exposed. Can't find a way to get the Lock and Sensor to get exposed. Deleted, deactivated und reinstalled the plugin several times. Deleted the cached devices generated by this Plugin. Every time my devices get added, excluding the Lock with the Door Sensor.
Is the 3.0 Pro supported by this Plugin?
Is it possible that the lock can't get recognized because I had it added through the native HomeKit function before?
I removed it shortly after, deactivated it in the Nuki App and found your Plugin.
I checked that the Lock is connected with Bluetooth to the Bridge. The bridge is telling me it is connected to it correctly via the App and the dedicated WiFi module installed within the Pro is deactivated.
The text was updated successfully, but these errors were encountered: