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!?
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.
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?
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 :
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).
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.
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…
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).
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]
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.
That’s weird, are you using the switch channel (lock) or the number channel (lockState)? Try setting log level for org.openhab.binding.nuki.internal to DEBUG, try again and post log here.