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