@The-Elk Yes, the callback from the bridge seems to be OK. I will look into this on the weekend and keep you updated!
Thank you and hope you can find it quickly, so that you have a nice weekend
Any progress on this binding? I donāt understand everything in the PR (https://github.com/openhab/openhab2-addons/pull/2019), ā¦
@mkatter seems to be busy right now? Anybody got this binding running?
I did the following to get it running:
-
bundle:install https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.nuki/2.1.0-SNAPSHOT/org.openhab.binding.nuki-2.1.0-SNAPSHOT.jar
in the OH2-Console - bundle:start
<ID>
(210 in my case) - configured via text-files like stated here: https://github.com/mkatter/openhab2-addons/tree/nuki/addons/binding/org.openhab.binding.nuki
So everything works as expected - except the calllback doesnāt seem to update the states? If I change the SmartLock via the App or the button, the states stay - no updates.
Callback is active:
http://192.168.xxx.xxx:8080/callback/list?token=123456 results in:
{"callbacks": [{"id": 1, "url": "http://192.168.xxx.xxx:8080/nuki/bcb"}]}
Is there something to be done on top of that? Opening the callback in the browser results in a 404 (as this is a POST and not a GET, perhaps itās running neverthelessā¦?)
@all, sorry for my ā¦ not replying
Correct, I was really busy tha last months because of the IFA @Berlin. After this I totally deserved 2 weeks of vacation!
After (auto) updating eclipse my development environment is not longer working - so I need to look first into this.
Hopefully on this weekend (not promising) I will post an update!
Hi Markus. Are you planning to further develop the NUKI binding ? It would really be great, as (not only I) want to use it for the integration of Nuki.
Hi,
yes absolutely! Iāll find time to (hopefully) finish this binding during the Christmas holidays.
FYI - Iām using the current state of the pull request at home and it works for me just perfect! Nevertheless, Iāll definitely finish this binding so it can be officially added to be OH Add-Ons library.
CU Markus
nice to hear that.
Under which Openhab version do you use this binding?
For me, the binding worked too, but the CallBack (you remember?) did not worked.
I use it on openhabian with one of the latest 2.2 snapshots.
Iāve been using the binding happily but have noticed a delay has crept in between issuing an unlock command and the door unlocking so Iāve reverted to using a curl command for that functionality and I use the binding for status updates. Updating from the early snapshot to the latest version of the binding doesnāt seem to have helped.
Iām always happy to help with testing, and Iāve now updated my system from OH V2.1 to V2.2 Snapshot, although I havenāt tested the latency with this version to see if its improved
Since the update to OH 2.2 i keep getting the Status āHTTP 503 unavailableā from the Nuki Lock thingā¦
Has anybody seen this, too?
bye, Frido.
Hi
ever since I upgraded to OH2.2, the binding stopped working for me as well - or rather, it showed some unexpected behavior.
Firstly, I can reproduce the error by @fridomac and might even be able to detail it: When I start OH2, it will show both Nuki bridge and lock online. I can also control it and e.g. lock it. However, after that first control the smart lock changes to state HTTP 503 as well.
Furthermore, when I leave it online, and control it via the official nuk app, there is no update of the status in OH2 (hence: no callback).
Anyway, I am hoping that development of this binding continues, i actually moved to 2.3 snapshots but still get the same errors.
If it is of any help, I also get the following errors in the log when OH2 is started up:
2018-01-20 19:57:23.606 [ERROR] [org.openhab.binding.nuki ] - [binding.nuki.bcb(3)] unbind method [unsetThingRegistry] not found; Component will fail
2018-01-20 19:57:23.616 [ERROR] [org.openhab.binding.nuki ] - [binding.nuki.bcb(3)] unbind method [unsetThingRegistry] not found
2018-01-20 19:57:23.656 [ERROR] [org.openhab.binding.nuki ] - [binding.nuki.bcb(3)] unbind method [unsetHttpService] not found; Component will fail
2018-01-20 19:57:23.668 [ERROR] [org.openhab.binding.nuki ] - [binding.nuki.bcb(3)] unbind method [unsetHttpService] not found
Any help is greatly appreciated
Thx
Patrick
Any new about that? Is it possible to control nuki from openHab with this binding now?
@mkatter Do you work on a solution?
Iām currently plagued by this happening when I try to lock the door from OH - Iām on OH2.3 Snapshot Build 1203, and I had similar problems with OH2.2. The problem seems to happen whenever the lock command was sent before the binding had finished sending the unlock, and usually happened when I unlocked with the button on the lock, and locked via OH. I used the āNuki Smart Lock Lock Actionsā Channel previously and Iāve just changed to using the āNuki Smart Lock Unlock / Lockā Channel.
Iāve rewritten my rules to insert a 2 second delay after every state change before another command is sent to see if this works better. It will likely be after the weekend before I will have any results, and Iāll update this post then
If anyone else wants to test, the rule Iāve used is below which should work if you operate the lock from a rule. The autoupdate=āfalseā should ensure that the UI is only updated once the lock has changed which hopefully will ensure that it canāt be operated too quickly from the UI
Items file:
Switch NukiLockState {autoupdate="false"}
Rules file:
var boolean LockBusy = false
rule "Nuki Available"
when Item NukiLockState changed then {
LockBusy = true
Thread::sleep(2000)
LockBusy = false
} end
rule "lock Nuki"
when <whatever you use to work the lock> changed then {
createTimer(now.plusSeconds(5))[|
logInfo("Nuki", "lock Nuki rule ran")
if (!LockBusy && NukiLockState.state == OFF) {
NukiLockState.sendCommand(ON)
logInfo("Nuki", "Nuki Locked on first attempt") } else {
createTimer(now.plusSeconds(10))[|
if (!LockBusy && NukiLockState.state == OFF) {
NukiLockState.sendCommand(ON)
logInfo("Nuki", "Nuki Locked on second attempt") } else {
createTimer(now.plusSeconds(10))[|
if (!LockBusy && NukiLockState.state == OFF) {
NukiLockState.sendCommand(ON)
logInfo("Nuki", "Nuki Locked on third attempt") } else {
logInfo("Nuki", "Nuki couldn't be locked")
}
]
}
]
}
]
}
end
UPDATE:
Iāve been running the above rule for 4 days now and havenāt had a single lock failure. Most of the time it locks on the first attempt unless the close signal comes very soon after the open signal and then its the second attempt.
Any news about the binding?
Is it possible to control nuki from openHab with this binding now?
Does the callback work with snapshot 2.3 now?
(my installation runs on Raspi with openhabian)
@mkatter Do you work on the binding for a final Release?
At the moment, I use a rule that queries the bridge every 30 seconds and evaluates the strings with JsonPath.
That works well, but however, it drains my batteries on Smartlock very quickly. (within 2 month)
Yes, it works like a charm, with callbacks.
Binding: org.openhab.binding.nuki-2.1.0-SNAPSHOT
openHAB2: 2.3.0-snapshot Build#1281, running in Docker
No issue at all so far, I keep āunlatch=falseā because Iām paranoid but itās great to get the Telegram messages when lock states change.
@gittyhub2 could you show us your configuration, like callback, items and so on ā¦ā¦
That would be great, because with my configuaration the callback does not work on the raspi with openhabian 2.3.0 #1279
@The-Elk Here you go. Hope it helps.
You need to fix the following āfakeā things with your installationās values for the openHAB setup (.things file):
- apiToken=ā123456ā
- nukiId=ā123456789ā
- ip=ā192.168.123.123ā
nuki.things:
// DNS Nuki_Bridge_12345678
Bridge nuki:bridge:NB "Nuki Bridge" [ ip="192.168.123.123", port=8080, apiToken="123456" ] {
Thing smartlock SL "Nuki Smartlock" [ nukiId="123456789", unlatch=false ]
}
nuki.items
//
// Nuki Smart Lock
//
// channel unlock
// Use this channel with a Switch Item to unlock and lock the door.
// Configure "Unlatch" to true if your Nuki Smart Lock is mounted on a door lock with a knob on the outside.
//
Switch nuki_lock "TĆ¼r (auf/zu)" {
channel="nuki:smartlock:NB:SL:unlock"
}
// channel lockAction
// Use this channel if you want to execute other supported lock actions or to display the current lock state.
// Supported Lock Actions are: 2 (Unlock), 4 (Lock), 7 (Unlatch), 1002 (Lock 'n' Go), 1007 (Lock 'n' Go with Unlatch).
// Supported Lock States are : 1 (Locked), 2 (Unlocking), 3 (Unlocked), 4 (Locking), 7 (Unlatching), 1002 (Unlocking initiated through Lock 'n' Go) and 1007 (Unlatching initiated through Lock 'n' Go with Unlatch).
// Unfortunately the Nuki Bridge is not reporting any transition states (e.g. for Lock 'n' Go).
//
Number nuki_state "TĆ¼r (Zustand)" {
channel="nuki:smartlock:NB:SL:lockAction"
}
// channel lowBattery
// will indicate a low battery
//
Switch nuki_lowbat "TĆ¼r Nuki Low Battery" {
channel="nuki:smartlock:NB:SL:lowBattery"
}
nuki.rules:
rule "Tuer Nuki"
when
Item nuki_state changed
then
var String msg = "TĆ¼r wurde gerade " + transform("MAP","nukilockstates.map",nuki_unten_state.state.toString)
sendTelegram("bot", msg)
logInfo("Nuki", msg)
end
// Nuki Schloss, Batteriewarnung
rule "Nuki Batterie leer"
when
Item nuki_lowbat changed from OFF to ON
then
sendTelegram("bot", "Nuki 1.OG - Batterie bald leer")
end
nukilockstates.map:
1=abgeschlossen
2=schlieĆt auf
3=aufgeschlossen
4=schlieĆt ab
7=ƶffnet TĆ¼r
1002=schlieĆt auf (Lock 'n' Go)
1007=ƶffnet TĆ¼r (Lock 'n' Go)
-=undefiniert
Now the fun part: establishing the callbacks
You need to fix the following āfakeā things with your installationās values in HTTP-callback URLs:
- token=123456 with your API token
- openhabhost.my.domain with your own openHAB service / or IP address if not in DNS
Read existing callbacks on lock
http://192.168.123.123:8080/callback/list?token=123456
Delete existing callbacks on lock
Killing spree ā¦ remove all three
http://192.168.123.123:8080/callback/remove?token=123456&id=0
http://192.168.123.123:8080/callback/remove?token=123456&id=1
http://192.168.123.123:8080/callback/remove?token=123456&id=2
Set the callback
http://192.168.123.123:8080/callback/add?url=http%3A%2F%2Fopenhabhost.my.domain%3A8080%2Fnuki%2Fbcb&token=123456
I have set
http://192.168.123.123:8080/callback/add?url=http%3A%2F%2Fopenhabhost.my.domain%3A8080%2Fnuki%2Fbcb&token=123456
especially %3A%2F%2F and not :// and so on and not:
http://192.168.123.123:8080/callback/add?http://openhabhost.my.domain:8080/nuki/bcb&token=123456
?
yes. thatās the catch.
and make sure to remove all existing callbacks. What does the ālistā command say from your lock?
If the lock does not return
{"callbacks": [{"id": 0, "url": "http://openhabhost.my.domain:8080/nuki/bcb"}]}
the binding wonāt work.
Other potential caveat: powercycle the bridge! (pull out of socket, put back in)
The bridge seems to go in some kind of power save mode on the WiFi side. If you canāt ping them, you wonāt be able to read/delete/set the callbacks.
Good luck!