Nuki Smart Lock 3.0 Pro not Added

[edelmaca]

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.

[ebaauw]

Is the 3.0 Pro supported by this Plugin?

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 nb discover to check whether the lock advertises itself as a bridge? And could you run nb list to check whether the bridge exposes the lock over the HTTP API? It might use a new deviceType that Homebridge NB doesn’t yet know how to handle.

I understand the door sensor only connects (over BLE) to the lock (similar to keypads), so it can only be exposed through the lock.

Is it possible that the lock can't get recognized because I had it added through the native HomeKit function before?

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 hap utility bundled with homebridge-lib?

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

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.

[luissimoes]

I would also be interested in this enhancement (also have now a 3.0 Pro) One comment / question thought: why do you need the Bridge? the Pro has builtin WiFi so no bridge needed.... Or ist because of the Opener? Also: Since Nuki exposes directly to Homekit, a really needed feature is the exposure if the new "Door Sensor"... since Nuki still didnt expose this to Homekit

[ebaauw]

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.

why do you need the Bridge? the Pro has builtin WiFi so no bridge needed.... Or ist because of the Opener?

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.

Since Nuki exposes directly to Homekit, a really needed feature is the exposure if the new "Door Sensor"

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.

[edelmaca]

Hey, thank you for looking into this.

Does the bridge expose it over its HTTP API?

I checked nb list and got this output for the Lock:

{ "deviceType": 4, "firmwareVersion": "3.0.40", "lastKnownState": { "batteryChargeState": 96, "batteryCharging": false, "batteryCritical": false, "doorsensorState": 2, "doorsensorStateName": "door closed", "keypadBatteryCritical": false, "mode": 2, "state": 3, "stateName": "unlocked", "timestamp": "2021-11-23T20:32:33+00:00" }, "name": "Wohnungstüre", "nukiId": xxxxxxxxx }

So your tool is recognizing it but can't hand it over to HomeKit?!

Do you know if the native HomeKit function now uses WiFi as well

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?!

I’m half considering creating (another) Homebridge plugin....ditching the Nuki bridge altogether.

That sounds really cool. Looking forward to this.

...although it seems like a waste to disable WiFi on the Pro.

I needed the Bridge for the Opener. Since i do have the Bridge i did turn off WiFi for the better batterie life. I really liked the Brushed Stainless steal Look of the Pro and wanted the most future proof Nuki to date. So yeah, turning off WiFi on the Pro is kind of a waste, but since the Bridge is doing its thing here anyway, why wasting energy. 😜 I do not have any advantage of using Wifi instead of BLE with my Setup, right? But I'm getting off topic.

[ebaauw]

"deviceType": 4,

As I suspected:

It might use a new deviceType that Homebridge NB doesn’t yet know how to handle.

I will need to whitelist this device type. Otherwise, the output looks suspiciously familiar (including the door sensor), except for:

"keypadBatteryCritical": false,

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 nb info, in particular the bridgeType and versions values.

[ebaauw]

Could you try beta v1.2.0-0?

[edelmaca]

Do you have a keypad

no, i don't have a Keypad and never had one. So maybe it's the Door Sensors tinker switch.

Could you check with nb info

{ "bridgeType": 1, "currentTime": "2021-11-23T22:19:01+00:00", "ids": { "hardwareId": xxxxxxxxx "serverId": xxxxxxxxx }, "scanResults": [ { "deviceType": 0, "name": "Nuki_2C23XXXX", "nukiId": xxxxxxxxx, "paired": false, "rssi": -51 }, { "deviceType": 2, "name": "Nuki_Opener_2A5DXXXX", "nukiId": xxxxxxxxx, "paired": true, "rssi": -45 } ], "serverConnected": true, "uptime": 2491, "versions": { "firmwareVersion": "2.10.4", "wifiFirmwareVersion": "2.2.0" }, "wlanConnected": true }

Could you try beta v1.2.0-0?

i will give it a try right now.

[edelmaca]

It is working. Now the lock gets exposed to HomeKit as well. Even the door sensor is detected and doing its thing. But the sensor do need around 30sec. to report the state of the door. Not an instant report like with Homebridge-hue sensors. 😟 I hoped i could replace the door sensor I already put on the door a long time ago and use it elsewhere. But the delay is too significant. Zigbee is more superior in this regard.

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.

[ebaauw]

Oh, that's interesting: the bridge returns deviceType 0 in the scanResults of info, but 4 in the list.

Will get back soon with more testing if needed.

Could you please double-check that you can control the lock, including an identify to force-refresh the device state (should update timestamp)? The API also takes deviceType as an argument to most calls, but I'm sending 0 for the smart lock. Alternatively, check the nb commands that take deviceType as parameter (see nb -h): lock, unlock, lockAction and lockState.

But the sensor do need around 30sec. to report the state of the door. Not an instant report like with Homebridge-hue sensors.

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.

[edelmaca]

Nevermind. I only checked the Door sensor yesterday night. I dont wanted to crank up the Lock motors because my Family was sleeping. The lock is visible through HomeKit, but i can't control it. As you probably suspected.

If I'm doing a Unlatch:

[24/11/2021, 11:59:22] [Nuki] Nuki_Bridge_59E0XXX: request 2047: GET /lockAction?nukiId=2C23XXX&deviceType=0&action=3
[24/11/2021, 11:59:22] [Nuki] Nuki_Bridge_59E0XXX: warning: request 2047: error: http status 404 Not Found
[24/11/2021, 11:59:25] [Nuki] Wohnungstüre Latch: set Lock Current State from 1 to 0

If I'm trying to Lock it:

[24/11/2021, 12:00:33] [Nuki] Wohnungstüre Lock: Lock Target State changed from 0 to 1
[24/11/2021, 12:00:34] [Nuki] Nuki_Bridge_59E0XXX: request 2051: GET /lockAction?nukiId=2C23EXXX&deviceType=0&action=2
[24/11/2021, 12:00:34] [Nuki] Nuki_Bridge_59E0XXX: warning: request 2051: error: http status 404 Not Found

If i want to identify the Lock in Eve App with the ID Button in the Top right:

[24/11/2021, 12:04:25] [Nuki] Nuki_Bridge_59E0XXX: request 8: GET /lockState?nukiId=2C23EXXX&deviceType=0
[24/11/2021, 12:04:25] [Nuki] Nuki_Bridge_59E0XXX: warning: request 8: error: http status 404 Not Found

/usr/local/lib/node_modules/homebridge-nb/node_modules/homebridge-lib/lib/HttpClient.js:415
                  new HttpError(
                  ^
Error: http status 404 Not Found
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/homebridge-nb/node_modules/homebridge-lib/lib/HttpClient.js:415:19)
    at IncomingMessage.emit (node:events:402:35)
    at endReadableNT (node:internal/streams/readable:1343:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
[24/11/2021, 12:04:25] [Nuki] goodbye
[24/11/2021, 12:04:25] [Nuki] Child bridge process ended
[24/11/2021, 12:04:25] [Nuki] Process Ended. Code: 1, Signal: null
[24/11/2021, 12:04:32] [Nuki] Restarting Process...
[24/11/2021, 12:04:33] [Nuki] Launched child bridge with PID 15841
[24/11/2021, 12:04:33] Registering platform 'homebridge-nb.Lib'
[24/11/2021, 12:04:33] Registering platform 'homebridge-nb.NB'
[24/11/2021, 12:04:33] [Nuki] Loaded homebridge-nb v1.2.0-0 child bridge successfully
[24/11/2021, 12:04:33] Loaded 4 cached accessories from cachedAccessories.0E40C212XXX.
[24/11/2021, 12:04:33] [Nuki] homebridge-nb v1.2.0-0, node v16.13.0, homebridge v1.3.8, homebridge-lib v5.1.17
[24/11/2021, 12:04:33] [Nuki] warning: recommended version: homebridge v1.3.6
[24/11/2021, 12:04:33] [Nuki] Nuki_Bridge_59E0XXX: Nuki Bridge v2.10.4 59E0XXX at 192.168.1.7:8080
[24/11/2021, 12:04:33] [Nuki] Haustür: Nuki Opener v1.6.4 2A5DXXX
[24/11/2021, 12:04:33] [Nuki] Wohnungstüre: Nuki Smart Lock v3.0.40 2C23EXXX
[24/11/2021, 12:04:33] [Nuki] Wohnungstüre Sensor: Nuki Door Sensor v3.0.40 2C23EXXX-S
[24/11/2021, 12:04:34] [Nuki] restored 4 accessories from cache
[24/11/2021, 12:04:34] Homebridge v1.3.8 (HAP v0.9.7) (Nuki) is running on port 33148.
[24/11/2021, 12:04:35] [Nuki] Nuki_Bridge_59E0XXX: warning: unclean shutdown - checking for stale subscriptions
[24/11/2021, 12:04:35] [Nuki] Nuki_Bridge_59E0XXX: remove stale subscription
[24/11/2021, 12:04:35] [Nuki] warning: latest version: homebridge-nb v1.1.15
[24/11/2021, 12:04:35] [Nuki] listening on http://0.0.0.0:37131/notify
[24/11/2021, 12:04:35] [Nuki] Nuki_Bridge_59E0XXX: subscribe to event notifications

[ebaauw]

And if you try nb lockAction 2C23EXXX 4 3 (specifying deviceType 4)?

Note to self: looks like there’s also an unhandled promise rejection…

[ebaauw]

Beta v1.2.0-1 should handle deviceType. It also fixes the uncaught promise rejection. And it considers firmware and deviceType when setting the Model for Smart Locks. That will only be visible after deleting the Smart Lock from cachedAccessories, as HomeKit doesn't support changing Model of existing accessories..

[edelmaca]

This looks very promising. I did every function at least once. Only once, at the beginning, i had this error.

[24/11/2021, 21:22:52] [Nuki] Wohnungstüre Latch: Lock Target State changed from 1 to 0
[24/11/2021, 21:22:52] [Nuki] Wohnungstüre Lock: set Unlatch from false to true
[24/11/2021, 21:22:53] [Nuki] Nuki_Bridge_59E00XXX: request 26: GET /lockAction?nukiId=2C23EXXX&deviceType=4&action=3
[24/11/2021, 21:22:53] [Nuki] Nuki_Bridge_59E00XXX: warning: request 26: error: http status 503 Service Unavailable
[24/11/2021, 21:22:55] [Nuki] Wohnungstüre Lock: set Unlatch from true to false
[24/11/2021, 21:22:55] [Nuki] Wohnungstüre Latch: set Lock Target State from 0 to 1
[24/11/2021, 21:22:55] [Nuki] Wohnungstüre Lock: set Unlatch from false to true
[24/11/2021, 21:22:55] [Nuki] Wohnungstüre Latch: set Lock Current State from 1 to 0
[24/11/2021, 21:22:55] [Nuki] Wohnungstüre Latch: set Lock Target State from 1 to 0
[24/11/2021, 21:23:05] [Nuki] Wohnungstüre Lock: Lock Target State changed from 0 to 1

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. 😄 Is it possible to get rid of the last updated timestamp logging every minute and just see the actions it is executing?

[ebaauw]

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 https://github.com/ebaauw/homebridge-hue/issues/4. No dynamic logging, until I'll get to that. So much to do, so little time...

[edelmaca]

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.

[edelmaca]

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.

[ebaauw]

Cool. Just wondering what the non-Pro Smart Lock 3.0 looks like, in particular what deviceType it uses.

[edelmaca]

sadly i can't help you with that. Lets hope someone can jump in and get you the missing value.

[ebaauw]

Released v1.2.0.

[edelmaca]

one last thing. after updating to the non Beta Version i got this message.

[25/11/2021, 22:36:22] [Homebridge UI] Running Command: sudo -E -n npm install -g homebridge-nb@latest [25/11/2021, 22:37:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Updated from "Thu Nov 25 2021 22:36:01" to "Thu Nov 25 2021 22:36:51" [25/11/2021, 22:37:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Boot from "Thu Nov 25 2021 20:37:57" to "Thu Nov 25 2021 22:36:41" [25/11/2021, 22:37:15] [Nuki] Nuki_Bridge_59E00XXX: set Status Fault from 0 to 1 [25/11/2021, 22:37:15] [Nuki] Haustür: set Firmware Revision from "1.6.4" to undefined [25/11/2021, 22:37:15] [homebridge-nb] This plugin generated a warning from the characteristic 'Firmware Revision': characteristic value expected string and received undefined. See https://git.io/JtMGR for more info. [25/11/2021, 22:37:15] [Nuki] Nuki_Bridge_59E00XXX: warning: heartbeat error: TypeError: Cannot read properties of undefined (reading 'ringactionTimestamp') at DoorBell.update (/usr/local/lib/node_modules/homebridge-nb/lib/NbService.js:362:15) at Opener.update (/usr/local/lib/node_modules/homebridge-nb/lib/NbAccessory.js:370:26) at Bridge.heartbeat (/usr/local/lib/node_modules/homebridge-nb/lib/NbAccessory.js:272:32) at runMicrotasks () at processTicksAndRejections (node:internal/process/task_queues:96:5) [25/11/2021, 22:38:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Updated from "Thu Nov 25 2021 22:36:51" to "Thu Nov 25 2021 22:38:13" [25/11/2021, 22:38:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Boot from "Thu Nov 25 2021 22:36:41" to "Thu Nov 25 2021 22:37:03" [25/11/2021, 22:38:14] [Nuki] Nuki_Bridge_59E00XXX: set Status Fault from 1 to 0 [25/11/2021, 22:38:15] [Nuki] Haustür: set Firmware Revision to "1.6.4"

[ebaauw]

[25/11/2021, 22:37:15] [Nuki] Haustür: set Firmware Revision from "1.6.4" to undefined [25/11/2021, 22:37:15] [Nuki] Nuki_Bridge_59E00XXX: warning: heartbeat error: TypeError: Cannot read properties of undefined (reading 'ringactionTimestamp')

It looks like the bridge sent an incomplete response to the /list request, with firmwareVersion and lastKnownState missing. I've never seen that before (and this shouldn't happen, according to the bridge HTTP API documentation).

[25/11/2021, 22:37:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Boot from "Thu Nov 25 2021 20:37:57" to "Thu Nov 25 2021 22:36:41" [25/11/2021, 22:37:15] [Nuki] Nuki_Bridge_59E00XXX: set Status Fault from 0 to 1

This would suggest the bridge rebooted just before Homebridge NB sent the /list. Did you reboot (or power cycle) it?

[25/11/2021, 22:38:14] [Nuki] Nuki_Bridge_59E00XXX: set Last Boot from "Thu Nov 25 2021 22:36:41" to "Thu Nov 25 2021 22:37:03" [25/11/2021, 22:38:14] [Nuki] Nuki_Bridge_59E00XXX: set Status Fault from 1 to 0

And again a minute later?

[edelmaca]

That's strange. I did not reboot the bridge. No I just updated to the new Version and did nothing else with Homebridge or the Nuki Devices. I just saw these logs a few minutes later.

[ebaauw]

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.

[edelmaca]

Will do. thank you for this tip.

[ebaauw]

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 deviceType value (which is 4 for both) as well as that for the Smart Door. Made the corresponding adjustments in v1.2.1 and unpublished v1.2.0

[pespinel]

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 😄 If I can help with any test let me now it.