Implement new device types (available since 2 weeks)

[thomascandrian]

Nuki Bridge HTTP API V1.13.1 introduced 2 new device types, which the actual version does not support. As I found out, the implementation of Nuki integration in Home Assistant relies on your work, so probably update this library will fix the issues in HA ... thank you!

https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4/

Nuki device type
0 => smartlock (Nuki Smart Lock 1.0/2.0)
2 => opener (Nuki Opener)
3 => smartdoor (Nuki Smart Door)
4 => smartlock 3 (Nuki Smart Lock 3.0 (Pro))

My Python skills are not good enough to supply a complete fix, but this could be a simple option. A better option would be to add an array that contains all supported device types, but that's probably more complicated...

pynuki/constants.py
After line 22, add:
DEVICE_TYPE_SMARTDOOR = 3
DEVICE_TYPE_NEWLOCK = 4

pynuki/bridge.py
After Line 218, add
elif dev_type == const.DEVICE_TYPE_NEWLOCK:
//modify data that device_data.get("deviceType") gives back 2 instead of 3 ... no idea how that is done in Phyton :-(
dev = NukiLock(self, data)
elif dev_type == const.DEVICE_TYPE_NEWLOCK:
//modify data that device_data.get("deviceType") gives back 2 instead of 4 ...no idea how that is done in Phyton :-(
dev = NukiLock(self, data)

[chheiss]

This would be very much appreciated!

[pree]

Do the two new types handle any different than a standard lock on the API ? Do you maybe even have a door or the new SmartLock to test this?

[chheiss]

No, they behave exactly the same as the standard ones. Just the types have to be set, all else is identical.
I do have a v3 lock, if needed.

[pree]

Yes, please test it. It's already merged into this branch. Just pull pynuki=1.5.0.

$ python
>>> import pynuki
>>> bridge = pynuki.NukiBridge('id', 'token')
>>> bridge.info()
>>> bridge.locks

The Lock should be listed there.

[chheiss]

Can I install it as a repository via HACS?

[pree]

you would need to update the dependency manually if you want to test it inside HomeAssistant (or just wait for the update to get merged)

[chheiss]

Then I will have to wait, as I am not set up for that.

[pree]

The new HomeAssistant release is out, which contains this change. Could you test it?

[chheiss]

Works fine now! Thanks for that!

[FabianKielkopf]

It didn't work for me... it tries to send to deviceType = 0 but I have a devicType 4 (3.0 Lock) running HomeAssistant core-2022.3.4 and tried 3.5

I think the problem is in the request url while locking
http://ip:8080/lockAction?ts=2022-03-17T18:44:09Z&rnr=48763&hash=....&nukiId=123456789&deviceType=0&action=2&noWait=1

[FabianKielkopf]

Hey, I created a Pull Request with a working version for my locks.

[SmilyHM]

Hi, I'm waiting for the upgrade-program to switch from v2.0+bridge to v3.0pro. Now I just saw the Q&A on nuki.io:

Is the built-in WiFi module compatible with all integrations?
Yes. Now the built-in WiFi module does not support Bridge API. If the Bridge API is required, you have to connect the Smart Lock 3.0 Pro to a Nuki Bridge.

Ist das integrierte WiFi-Modul mit allen Integrationen kompatibel?
Ja. Jedoch unterstützt das integrierte WiFi-Modul nicht die Bridge API. Wenn die Bridge API erforderlich ist, musst du das Smart Lock 3.0 Pro mit einer Nuki Bridge verbinden.

Could this be an issue?

Best regards
Sascha

[pree]

Yes, even if you have the 3.0 Pro Lock you still would need the bridge to be able to use the local API.

[jmpavlec]

Just returned my 3.0 Pro lock in favor of the regular 3.0 + bridge because the pro doesn't have local API. Simpler to go that route than to wait and see if they add the local API for the pro version.