You would still need a bridge of sorts - in your case a BT bridge.
The latest version of the Nuki Bridge firmware supports callback URLs so I have mine configured to callback to openHAB whenever the lock state changes, and openHAB can send lock/unlock commands via the REST API.
All working very nicely now. The bridge doesnât need to connect to the Nuki servers other than to get the time during startup. Without this connection it does tend to behave a bit funny which is a shame. I requested they enhance the bridge so it could work in offline mode but they are too busy to worry about this edge case (their words) right now.
I tried it with no internet and once it was up and running I could send commands and receive updates. But as soon as the bridge restarts it canât load the time and things go awry.
OK. Were you able to figure out how the bridge is getting the time ? is that via a standard protocol like NTP ?
What I do not like so much about the bridge is that itâs another piece of hardware needed to control the lock (of course using REST is an advantageâŚ)âŚ
If it works directly using the android app (without bridge) a standard Bluetooth card in a pc, should be enough to control it via OH, or am I missing something ?
I have been looking at Nuki since the beginning but was too late to get one on Kickstarter and then I decided to wait a bit before buying it (as it has been delayed and its price doubled ) so I do not have it yetâŚ
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?
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.
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.
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.
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
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 )
end
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 ?