New openHAB2 Binding for Nuki Smart Locks

mamoel · January 17, 2019, 6:06pm

Found the solution on my own.
The smartlock id that is shown when calling the API via Browser has to be converted to hexadecimal. Now the callbacks are working as intended.

bruxi · January 24, 2019, 12:29pm

Hi,

I’ve the Nuki working here for nearly 3 years now without any problems. Until now it was integrated into OH2 with a little python script via supervisord.
Now I wanted to change to the Nuku binding. Everything seems to work perfect (lock, unlock, unlatch) but callbacks don’t work here either. Status in the Items via Nuki binding don’t change the status while the “old” items via supervisord still do.

Callback-URL was set up correctly by the binding.

{"callbacks": [{"id": 0, "url": "http://192.168.178.251:8080/nuki/bcb"},{"id": 1, "url": "http://192.168.178.251:9090"}]}

Is there any solution for that available?

Thx

bruxi · January 24, 2019, 3:05pm

Hi,

also resolved the problem on my own.
I had to manually set up the bridge and the Nuki thing in config files because you have to give the Nuki ID in hexadecimal to have the callbacks work properly. However, interestingly the lock and unlock actions work when you configure the lock with decimal ID.

Maybe you should fix this in the code that one can always give the decimal ID!?

mamoel · January 25, 2019, 7:02am

That’s what i wrote one post above yours
Strange that this doesn’t seem to be a more “common” problem…

fridomac · February 12, 2019, 5:35pm

If I get you correctly, I have to convert the NukiID-String that is also shown in the Nuki App to Hex?

Bye, Frido

mamoel · February 12, 2019, 5:59pm

The one you get when you call http://YOURNUKIBRIDGEIP:8080/list?token=YOURTOKEN
I am not sure if it is shown in the app.

UPDATE: the one in the app is already in HEX so it can be used without conversion

DennisVonDerBey · June 20, 2019, 12:01pm

The new bridge beta firmware (only the hardware bridge right now) now supports a hashed time limited API key instead of sending the secret in plain http all the time. Are there already plans to implement it? Sadly I rely on the software bridge and cannot test it.

Announcement: https://developer.nuki.io/t/hashed-token-for-bridge-api/1378

Docs: https://developer.nuki.io/page/nuki-bridge-http-api-190/4/

Scroll down to 3.2.

Should be rather simple to implement. Maybe via autodetection of the firmware version and a manual override in the Thing’s properties?

Falk · July 20, 2019, 12:41pm

Hi there, just want to make you aware of an issue with the Nuki binding:

After some days/weeks of normal operation, the binding seems to end into a blocked thread, impacting operation of other bindings as well.

You can find more details of this problem here: Several items from different bindings stop updating after a while

Falk · August 22, 2019, 9:24pm

Something is going wrong again after about 1 week of normal operation:
Nuki lock does not react. This is OH2.5M1. Threads in OH seem to be blocked:

 threads --monitors --locks | grep org.openhab.binding
    at org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient.executeRequest(NukiHttpClient.java:83)
      - locked org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient@cc66e4
    at org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient.getBridgeInfo(NukiHttpClient.java:118)
      - locked org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient@cc66e4
    at org.openhab.binding.nuki.handler.NukiBridgeHandler.checkBridgeOnline(NukiBridgeHandler.java:119)
    at org.openhab.binding.nuki.handler.NukiBridgeHandler.lambda$1(NukiBridgeHandler.java:84)
    at org.openhab.binding.nuki.handler.NukiBridgeHandler$$Lambda$810/24406338.run(Unknown Source)
      - org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient@cc66e4 locked at
          10 org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient.executeRequest(NukiHttpClient.java:83)
      - org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient@cc66e4 locked at
          11 org.openhab.binding.nuki.internal.dataexchange.NukiHttpClient.getBridgeInfo(NukiHttpClient.java:118)

This does not go away until I restart binding or OH in total.
Any idea of how to fix the problem?

Thanks

apfelflo89 · September 5, 2019, 7:18am

Hi,
there is a problem with using the binding with the new Nuki Opener, to get the lockState of the Opener the api call needs a devicetype parameter within the url like :

http://10.1.1.142:8080/lockState?nukiId=123456&deviceType=2&token=token

The newly introduced deviceType paramater has to also be added for /lockState for an Opener (defaults to 0 for a Smart Lock to be backwards compatible).

Also see:

and the api docs

https://developer.nuki.io/page/nuki-bridge-http-api-190/4/#heading--lockstate

Lolodomo · September 7, 2019, 5:04pm

This will require a change in the binding to support the new Nuki Opener, probably with the introduction of a new thing type. Not a difficult change. I have no Nuki devices, but as I already updated the code today to fix a bug, I could add this new feature if the author of the binding has no time for it.
First I wait for the merge of my fix.

Lolodomo · September 8, 2019, 9:17am

I opened a RFC for the Nuki Opener:

binderth · December 27, 2019, 1:58pm

is the Nuki binding dead? Seems there’s no owner of the binding in github anymore? No response here in the forum also.
Should we skip to calling the API via rules? I can script but can’t develop JAVA…

m0rgoth · May 5, 2021, 9:38pm

So, I recently got Nuki with opener and found out the official Nuki binding has been long since abandoned with no opener support. The binding seemed simple enough so I checked it out and got to work, so far I have:

New Nuki channels:
– battery level
– keypad low battery alarm
– battery charging status
Support for discovery - instad of manually adding nuki, you just hit scan and all devices will appear in inbox
Support for opener with following channels:
– state - displays opener state and allows sending actions
– mode - shows if continuous mode is active
– low battery alarm
– ring action state - shows if someone is ringing doorbell
– ring action timestamp - Timestamp of the last ring-action

Anything else you would like to see? I’ll make PR later when I get around to update all the documentation, but if you’d like to test it I’ve attached built jar (just delete the .txt extension). You need to download snapshot openhab build and drop it into addons folder and it should work (does not work with stable release due to changes in dependencies).

org.openhab.binding.nuki-3.1.0-SNAPSHOT.jar.txt (58.1 KB)

Oggerschummer · May 6, 2021, 9:10am

First of all: Thanks for picking this up, highly appreciated!

Is this compatible with with OH3.0.2 ?
I put the file into the addons-folder, OH tried to load it, but failed:

2021-05-06 11:05:11.153 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.nuki-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.nuki [303]
Unresolved requirement: Import-Package: org.osgi.framework; version=“[1.9.0,2.0.0)”
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

A restart of OH did not solve it.

hmerk · May 6, 2021, 9:12am

No, AFAIK, bindings build under openHAB 3.1 are not compatible to 3.0.x due to a change of the OSGI version.

Oggerschummer · May 6, 2021, 9:31am

One more reason to switch the branch. Thanks!

m0rgoth · May 6, 2021, 10:10am

Yes, you need snapshot version. For testing you can just download snapshot distribution, unzip it, put the jar into addons and run it locally on your pc. But it shouldn’t be too hard to make build that works on current stable version, i’ll look into it.

Oggerschummer · May 6, 2021, 3:49pm

OK, made it.
Created a bridge, afterwards the scan revealed the lock itself. Things are working.
See all the channels, looks perfect.
Thanks again !

Oggerschummer · May 6, 2021, 4:03pm

Locking the door from OH I get an error in the Log:


2021-05-06 17:59:22.710 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_LockState' changed from 3 to 4

2021-05-06 17:59:29.193 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nuki:smartlock:xxxxxxxxxxx:yyyyyyyyyy' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Bad Request

2021-05-06 17:59:29.199 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_Lock' changed from ON to OFF

2021-05-06 17:59:29.202 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_LockState' changed from 4 to 255

2021-05-06 17:59:29.203 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_DoorState' changed from 2 to 4

Somehow the connection seems to break down during the process of locking the door.
Same happens when unlocking the door.
Regards,
Thomas