Skip to content
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

Closed
edelmaca opened this issue Nov 23, 2021 · 26 comments
Closed

Nuki Smart Lock 3.0 Pro not Added #44

edelmaca opened this issue Nov 23, 2021 · 26 comments
Labels
enhancement New feature or request

Comments

@edelmaca
Copy link

edelmaca commented Nov 23, 2021

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.

@edelmaca edelmaca changed the title Lock 3.0 Pro not Added Nuki Smart Lock 3.0 Pro not Added Nov 23, 2021
@ebaauw
Copy link
Owner

ebaauw commented Nov 23, 2021

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.

@ebaauw ebaauw added the enhancement New feature or request label Nov 23, 2021
@luissimoes
Copy link

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
Copy link
Owner

ebaauw commented Nov 23, 2021

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
Copy link
Author

edelmaca commented Nov 23, 2021

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
Copy link
Owner

ebaauw commented Nov 23, 2021

"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 added a commit that referenced this issue Nov 23, 2021
@ebaauw
Copy link
Owner

ebaauw commented Nov 23, 2021

Could you try beta v1.2.0-0?

@edelmaca
Copy link
Author

edelmaca commented Nov 23, 2021

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
Copy link
Author

edelmaca commented Nov 23, 2021

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
Copy link
Owner

ebaauw commented Nov 23, 2021

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
Copy link
Author

edelmaca commented Nov 24, 2021

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
Copy link
Owner

ebaauw commented Nov 24, 2021

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 added a commit that referenced this issue Nov 24, 2021
Cater for different `deviceType` values for same service, in support of Smart Lock 3.0 Pro, see #44.
ebaauw added a commit that referenced this issue Nov 24, 2021
- 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.
@ebaauw
Copy link
Owner

ebaauw commented Nov 24, 2021

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
Copy link
Author

edelmaca commented Nov 24, 2021

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
Copy link
Owner

ebaauw commented Nov 24, 2021

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...

@edelmaca
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

ebaauw commented Nov 25, 2021

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

@edelmaca
Copy link
Author

edelmaca commented Nov 25, 2021

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

@ebaauw
Copy link
Owner

ebaauw commented Nov 25, 2021

Released v1.2.0.

@ebaauw ebaauw closed this as completed Nov 25, 2021
@edelmaca
Copy link
Author

edelmaca commented Nov 25, 2021

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
Copy link
Owner

ebaauw commented Nov 25, 2021

[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
Copy link
Author

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
Copy link
Owner

ebaauw commented Nov 26, 2021

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
Copy link
Author

Will do. thank you for this tip.

@ebaauw
Copy link
Owner

ebaauw commented Nov 26, 2021

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
Copy link

pespinel commented May 9, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants