Nuki 3.0 Pro without bridge

so you replaced “smartlockid” with your smartlock id, right?
Where did you get it from? I got it from a GET to /smartlock (for getting list of all smartlocks) using postman.

That’s right. I found the smart ID in both the app and the web interface. Can you confirm that you see there the same ID as you get with your GET-Command?

No the “smartlockId” from GET https://api.nuki.io/smartlock is a 11 digit numeric value.
In Nuki Web I see a different ID which I cannot find in the response of the REST call.
So try to read the “smartlockId” via REST.

The hint to get the right id via postman was the right one. Thanks a lot. Now it works.
Id isn’t the same as id.

2 Likes

I’ve created feature request in github [nuki] Support for Web API · Issue #13457 · openhab/openhab-addons · GitHub to discuss this topic. I also did some work implementing it, it’s still work in progress but if anyone is brave enough you can try it here - https://github.com/janvyb/files/raw/main/org.openhab.binding.nuki-3.4.0-SNAPSHOT.jar.

You’ll need to:

  • Add your devices to Nuki Web
  • Generate API token with “View devices” and “Operate devices” permission
  • In openHAB, create new “Nuki Web Account” thing, add your token there
  • Run discovery, your registered devices should show up in inbox
1 Like

I tried to connect my nuki 3.0 Pro with openhab, unfortunately this doesn’t work.
Here are my openhab settings:

Nuki.things

Thing http:url:nuki "nuki" [ 
	baseURL="https://api.nuki.io/",
	authMode="BASIC",
	stateMethod="GET",
	commandMethod="POST",
	contentType="application/json",
	headers="Authorization=Bearer <api token>", "key2=value2", 
	refresh=60] {
		Channels:
			Type string : state "Status" [stateExtension="smartlock/<XX0403921XX>", stateTransformation="JSONPATH:$.state.state" ]
			Type switch : action "Aktion" [mode="WRITEONLY", stateExtension="smartlock/<XX0403921XX>/action", onValue="{\"action\": 2}", offValue="{\"action\": 1}"]
}

XX0403921XX - Smartlock ID

Nuki.itmes

String  Nuki_Status     "Nuki Status [MAP(Nuki.map):%s]"    {channel="http:url:nuki:state"}
Switch  Nuki_Action     "Nuki Aktion"                       {channel="http:url:nuki:action"}

Nuki.rules

rule "nuki-test" 
when
  Item Anwesendheit received update
then
   Nuki_Action.sendCommand(ON)
end

tail -f /var/log/openhab/openhab.log /var/log/openhab/events.log

2022-11-21 20:40:37.786 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Nuki_Action’ received command ON

but my nuki device does not work …

Does anyone have an idea where my mistake is

Thanks Christoph

I would also like support for the Pro version. I own 2 locks and full integration with Openhab would be awesome!

I’m going to try the HTTP sollution for now.

Call me paranoid but I would really recommend to use the suggested ESP32 firmware as it won’t require you to store credentials in the Nuki cloud and on your OH server. It works perfectly, it’s cheap and easy to setup :blush: Theoretically it should also allow you to disable wifi on your lock completely, which would even save you some energy.

You can try the snapshot binding I posted which already supports web api. I’m not sure what features would be useful so I’m waiting for feedback before putting more work into it.

Btw seems like beta firmware for Nuki 3.0 has added support for MQTT (see Smart Lock Firmware 3.5.x Beta - Nuki Smart Lock Beta - Nuki Developers), wouldn’t that work for you better?

1 Like

I still did not buy the lock because of the missing binding in openHAB :slight_smile:
So yes, please, don’t stop working on the binding :heart_eyes:

I noticed your snapshot after my reply. I wanted to try it this weekend, but i will also look into the MQTT support, that’s sounds really nice!

As I think about it, a beta on my lock doesn’t feel good. So i’m using the binding now. I can see a lot of values from both my lock, so that’s great! I’m able to send commands to the [lockState] channel and the lock reacts but i’m not sure how i’m suppose to interpret the values.

I’m reading a bit on the github page from Nuki and it looks like the lockState is just for checking the state of the lock (but it does react when sending a value there, but not sure what numbers to send). To change to state of the lock, I think we have to use _ACTION and send a state to that channel I guess.

But i’m not sure about this. Do you know how to send commands to the door locks, m0rgoth?

I guess this has not changed:

I ordered a lock now finally, testing should begin next week :grinning:

Should be the same as described in docs for smartlock connected using bridge - Nuki - Bindings | openHAB

feeling a bit dumb, i though this binding was completely different from the normal one… i should have looked there first! Thnx for help!

My nuki smart locks are draining fast. They are empty after a couple of days with the power pack… Not sure what the reason is. I tried everything I could find but nothing works. So I thought maybe it’s the binding who is draining the locks.

In the configuration of the locks, i see two values: Poll interval / Refresh delay. I changed the poll interval from 60 to 900 (I guess seconds?). Looks like the state values are updates a bit less frequent, fine with me :). But what does Refresh delay do? I changed it from 5 to 60 (seconds?) but the locks react as fast as before on lock commands. Could the 5 second poll delay have to do something with draining more battery from the locks?

This is the main problem with web api - there are no callbacks when property on the lock changes so the binding has no other option than to poll it periodically. I would expect that not every call to web api will wake up the smart lock (same as the bridge caches lock status and doesn’t wake lock up with every call), but maybe I’m wrong. You can try contacting nuki support or developer forums, maybe they’ll know whats going on with your lock specifically.
Refresh delay indicates how long to wait with updating lock status after command was sent. For example - if you have it set to 5s and send Unlock command, the binding will call nuki web api to unlock the door, wait 5s and then query the api for current lock status. If it’s too short, then the lock might not finish performing action and the binding will report old value (e.g. still locked, and if you have some rules which trigger on unlock, they might not work).

Thanks for the clear explanation. That makes sense. Still not sure what the reason of the drain is, but one lock doesn’t drain anymore for some reason. I already had contact with nuki support for the drain problems. They couldn’t imagine a smarthome platform could drain the batteries this fast. Maybe it’s just battery calibration.

I now know how and why to set the values Delay and refresh, that helpes me a lot.

Hi,

you’re using a transformation map, could you post your map as well?