NEW BINDING creation support Request - NUKI SMART LOCK

Yes, when I can avoid being connected to the cloud, I always prefer to avoid it :wink:

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 :smile:

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! :wink:
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). :wink:

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!

1 Like

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)]"}
1 Like

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)
 	}
end

Hi,

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 Lock widget

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 )
end
1 Like

Hello,

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 :slight_smile:

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 :frowning:

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 :slight_smile:

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.

1 Like