New openHAB2 Binding for Nuki Smart Locks

openhab2
binding
Tags: #<Tag:0x00007fe0581ee5c0> #<Tag:0x00007fe0581ee390>

(Markus) #61

@The-Elk Yes, the callback from the bridge seems to be OK. I will look into this on the weekend and keep you updated!


(Stefan) #62

Thank you and hope you can find it quickly, so that you have a nice weekend :wink:


(Stefan) #63

@mkatter did you find something?


(Thomas Binder) #64

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:

  1. 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
  2. bundle:start <ID> (210 in my case)
  3. 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…?)


(Markus) #65

@all, sorry for my … not replying :slight_smile:
Correct, I was really busy tha last months because of the IFA @Berlin. After this I totally deserved 2 weeks of vacation! :smiley:

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!


(Rudolf Kuehn) #66

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.


(Markus) #67

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


(Stefan) #68

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.


(kevin) #69

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


(fridomac) #70

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.


(Patrick Boch) #71

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


(Stefan) #72

Any new about that? Is it possible to control nuki from openHab with this binding now?
@mkatter Do you work on a solution?


(kevin) #73

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

(kevin) #74

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.


(Stefan) #75

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)


(Alexander) #76

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.


(Stefan) #77

@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


(Alexander) #78

@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

(Stefan) #79

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

?


(Alexander) #80

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!