Yes, when I can avoid being connected to the cloud, I always prefer to avoid it 
Thanks a lot! This looks nice indeed. It would not be a perfect solution for OH as it requires bluez so it would not be truly OS independent but for people using linux (as I am) that’s a nice solution.
So with that I really need to get Nuki now… and to try it 
I completely agree - I would much prefer to have a cloud-less solution but I have already bought the bridge and it works quite nicely. I am hopeful if I keep pestering them they will eventually make it work cloud-free.
It really doesn’t need a connection, it talks to the lock via BT and OH can talk to it directly via HTTP. It only needs Nuki server access if you want to control the lock using the Nuki app on your phone.
It is a great little lock though - I think you will like it!
I also have the Nuki Smartlock including the Nuki Bridge and I do see the points for an integration via a Nuki-Binding. Would be making life more easy for all Nuki-Users!
But until then, I am having some understanding problems on how to integrate the Nuki like you guys did already.
So I activated the “http”-binding and tried to use the above codes, but I already got this one after pasting the simple Switch-Item in my .items:
// hint: see next post: POST won't work with Nuki Bridge and Nuki Smartlock - use GET instead
Switch EGFrontdoorLock "Haustüre [%s]" <lock> (EG_Windfang) { http=">[ON:POST:http://192.168.xx.xx:8080/lockaction?token=xxxxx&nukiid=xxxxxxx&action=2] >[OFF:POST:http://192.168.xx.xx:8080/lockaction?token=xxxxx&nukiid=xxxxxxx&action=1]" }
which results in
// events.log
2016-11-20 09:26:32.013 [ItemCommandEvent ] - Item 'EGFrontdoorLock' received command ON
2016-11-20 09:26:32.036 [ItemStateChangedEvent ] - EGFrontdoorLock changed from NULL to ON
// openhab.log
2016-11-20 09:26:32.135 [WARN ] [org.openhab.io.net.http.HttpUtil ] - Method failed: HTTP/1.1 400 Bad Request
Using the above URLs in .items result in opening/closing the door as expected. Do I miss something here?
Thanks for your help,
Thomas.
Oh! My bad! After posting this and seeing the CODE in colour, I just replaced POST with GET and everything worked fine:
so, with this .items I get the Nuki to open and close as intended:
Switch EGFrontdoorLock "Haustüre [%s]" <lock> (EG_Windfang) { http=">[ON:GET:http://192.168.xx.xx:8080/lockaction?token=xxxxx&nukiid=xxxxxxx&action=2] >[OFF:GET:http://192.168.xx.xx:8080/lockaction?token=xxxxx&nukiid=xxxxxxx&action=1]" }
I’d like to add my support for a “real” binding, as with Version 1.3 of the Nuki Bridge API there’s also the above callback present. This feature of the Nuki Bridge triggers in every event of the Nuki Smartlock. With this there’s also a update on the respective openHAB items, if the Smartlock changes the state manually or via a smartphone App. Of Course you could fire regularly with the API to see, if there are some changes, but this drains the battery pretty fast.
See https://nuki.io/wp-content/uploads/2016/04/Bridge-API-v1.3.pdf for Details. /callback is the action, where you could add up to three endpoints which will be notified (via JSON) with updates.
@ben_jones12 did a workaround via a python/bottle described here: Receiving `Content-Type=application/json` payload on REST API but I’m afraid, I’m not so deep into WSGI, that I’d like to open that bottle (HARHAR).
From my side a simple +1 for an OH2 binding, would be great!
Maybe a dumb question, but how to get
token=xxxxx&nukiid=xxxxxxx
thanks chris
I am also supporting a binding and the idea of a cloud free Nuki installation.
Would be great if Nuki Dev Team would provide their Nuki Web as on premise installable solution.
Nuki Web with IFTTT integration is a no-go for at least the typical front-door use case in a Smart Home (you would hand over a virtual key to your front-door to the Nuki Cloud Server and indirectly the ability to unlock the door to IFTTT.
Also there is a security process issue (from my perspective) with their password reset implementation - so once you have access to email account or unencrypted email network traffic you can take over the door.
So proper integration with openHAB is the preferable solution.
There was a question regarding Token and NukiID:
Token from App when setting the bridge to developer mode (=API activation). Nuki ID can easily be requested then via Browser and command sent to the Bridge using the Token.
Maybe there is another way to retrieve ID via App, this is how I did it.
BR
and a happy new year
Uwe
Hi Thomas!
After reading the API I thought that it might be a better idea to get the lock’s state using http://192.168.xx.xx:8080/list?token=xxxxxx
This reads the last known state of the lock from the bridge and not from the lock directly. So it does not drain the battery on the lock. On the web browser this works like a charm. But the item is not updated at all. I wonder why.
String WohnungsTuerStatus "Wohnungstür [%s]" {http="<[http://192.168.xx.xx:8080/list?token=xxxx:30000:JSONPATH($.lastKnownState.stateName)]"}
Can you see what I am doing wrong?
Thank you!
Never mind! I found the error. It’s an array, so it works like this:
String WohnungsTuerStatus "Wohnungstür [%s]" {http="<[http://192.168.xx.xx:8080/list?token=xxxx:30000:JSONPATH($[0].lastKnownState.stateName)]"}
Thanks for the info! That’s good! Getting all Nuki-information is on my ToDo list. I’ll like to get e.g. the battery Status.
This is my final configuration:
Items:
Number WohnungsTuerStatus {http="<[http://192.168.xx.xx:8080/list?token=xxx:30000:JSONPATH($[0].lastKnownState.state)]"}
Switch WohnungsTuerSchloss <lock> {http=">[ON:GET:http://192.168.xx.xx:8080/lockaction?token=xxx&nukiid=xxx&action=2] >[OFF:GET:http://192.168.xx.xx:8080/lockaction?token=xxx&nukiid=xxx&action=1]"}
Rules:
rule "Nuki Haustuer"
when
Item WohnungsTuerStatus received update
then
if (WohnungsTuerStatus.state == 1) {
WohnungsTuerSchloss.postUpdate(ON)
} else {
WohnungsTuerSchloss.postUpdate(OFF)
}
endHi,
Here are my final items and rules - Meanwhile (API version 1.5) it is possible to retrieve the RSSI signal strengths of the locks. As it is easier to use with icons and such I decided to create a rule to translate “BatteryCritical” into Battery levels of either 20% or 80% and also to translate RSSI into signal level between 0 and 5 - This fits nicely with the Nuki Lock widget I posted here:
Nuki.items (replace xxx with your token and yyy with your lock ID, in case of multiple locks you also need to change the [0] below):
Number EGFrontdoorLockStatus { http="<[http://EGTec1NukiBridge:8080/list?token=xxx:30000:JSONPATH($[0].lastKnownState.state)]"}
Switch EGFrontdoorLock <lock> { http=">[ON:GET:http://EGTec1NukiBridge:8080/lockaction?token=xxx&nukiid=yyy&action=2] >[OFF:GET:http://EGTec1NukiBridge:8080/lockaction?token=xxx&nukiid=yyy&action=1]"}
String EGFrontdoorLockBatteryCritical { http="<[http://EGTec1NukiBridge:8080/list?token=xxx:30000:JSONPATH($[0].lastKnownState.batteryCritical)]"}
Number EGFrontdoorLockBattery <battery>
Number EGFrontdoorLockRSSI { http="<[http://EGTec1NukiBridge:8080/info?token=xxx:30000:JSONPATH($.scanResults.[0].rssi)]"}
Number EGFrontdoorLockSignal <signal>
Nuki.rules:
rule "Nuki EGFrontdoorLock"
when
Item EGFrontdoorLockStatus received update
then
if (EGFrontdoorLockStatus.state == 1) {
EGFrontdoorLock.postUpdate(ON)
} else {
EGFrontdoorLock.postUpdate(OFF)
}
end
rule "Nuki EGFrontdoorLockBattery"
when
Item EGFrontdoorLockBatteryCritical received update
then
if( EGFrontdoorLockBatteryCritical.state == 'true' ){
EGFrontdoorLockBattery.postUpdate(10)
} else {
EGFrontdoorLockBattery.postUpdate(80)
}
end
rule "Nuki EGFrontdoorLockSignal"
when
Item EGFrontdoorLockRSSI received update
then
var Number RSSI = EGFrontdoorLockRSSI.state
var Number Signal = RSSI / 20 + 5
EGFrontdoorLockSignal.postUpdate( Signal )
endHello,
i try your Code for my Nuki but it doesn´t work. On the Browser i get this:
item file:
//Nuki
String nuki_status "Wohnungstür [%s]" {http="<[http://IP:8080/list?token=token:30000:JSONPATH($[0].lastKnownState.stateName)]"}
and sitemap:
Text item=nuki_status
IP and token are correct. But i don´t get the Status displayed in the Sitemap. What could be the problem ?
Kay
I got it 
I define a rule with a cron timer which checks every minute the Last State of the Nuki:
rule "Nuki abholen"
when
Time cron "0 0/1 * * * ?" // every minute
then
var String var1= sendHttpGetRequest("http://xxx:8080/list?token=yyy")
var String value = transform("JSONPATH", "$[0].lastKnownState.stateName", var1)
postUpdate(nuki_status, value)
end
your item looks good to me, i think it should work. I had sometimes weird behaviour when having german umlauts in the items file, but this was like ages ago. http binding is installed i guess ?
Shame on me 
I think it should be, but it wasn´t. Now it works great. Thanks Max.
In which interval is your method asked for the bridge? With the Rule Method there is a interval from 1 Minute.
Kay
i update every 30 seconds, however think of changing that to a longer period and also use the webhooks which are described somewhere - that way the lock sends any changes in status directly to openhab, and for battery/RFFI status as well as “doublecheck” 5 min should be ok. reason is I’m pushing tons of updates to openhab using http for other stuff, i guess someday my network will be congested or openhab cant cope with it anymore
How do you set the 30 seconds interval with the item ?
And the Nuki Webhook aka Callback doesn´t work at the moment because the type of json and not plain text. I read this in another thread.
Yes - but if you use my nuki-proxy python script (linked here) you can use the callback URLs with openHAB. I have been using this for a few months and now that the bridge firmware has had a few bugs ironed out, it is working very very well.