New openHAB2 Binding for Nuki Smart Locks

What version (date?) of the Nuki Binding have you installed?

Please see README.md (https://github.com/mkatter/openhab2-addons/tree/nuki/addons/binding/org.openhab.binding.nuki#troubleshooting-debugging-and-tracing)
and send me a full openHAB / Nuki Binding startup log.

01/04/2017 12:19, on my filesystem, its the one showing as 30th March @12:00 on your server
Those logs ARE from a reboot with the settings at trace

openhab> log:get org.openhab.binding.nuki
Logger                   | Level
--------------------------------
org.openhab.binding.nuki | TRACE

I have been waiting for this and love to see it! (Even tried to develop it myself.) I will test it and report back how it works.

Thanks a lot for the effort! :blush:

Edit: The review might take some time, I think it would be a good idea to distribute the Binding
in the marketplace(Distributing bindings through the IoT Marketplace) in the meantime.

1 Like

Correct, I was allready thinking about providing the Nuki Binding via the IoT Marketplace untill it is incorporated into the openHAB2 distro… but you can actually download the current development state (of the pull request). See first post!

Please note: At the moment the Jenkins build fails for any reason (still waiting on clarification). So the current .jar for download is not the current development state as it is in my repo! I will keep you updated once the Jenkins build succeeds and the download .jar is up-to-date.

Yes, but still, I would need the full log not just some snippets.

Your problem could also be related to the fact that your .jar is an “old” version but you are using the config for the current version (see New openHAB2 Binding for Nuki Smart Locks).
Try to use upper case letters for all configuration parameters like:

Bridge nuki:bridge:NukiBridge1 [ IP="192.168.xx.xx", PORT="8080", APITOKEN="ABCDEFGH", CALLBACK_PORT="8081" ] { 
    Thing smartLock TestDoorLock [ NUKIID="12345678" ]
}

Once the Jenkins build succeeds again, please use the README.md as configuration reference again!

1 Like

Hey there!

I am pretty sure you might not be the only one with build problems, see: Jenkins build problems

All parameters changed to upper case, but still no go, I’ve sent you a PM with a link to the full log after a reboot, and my nuki things file

You have to be careful about the type of the config parameters. I overlooked it too!! :slight_smile:
Try this:

Bridge nuki:bridge:NukiBridge1 [ IP="192.168.x.x", PORT=8080, APITOKEN="xxxxxx", CALLBACK_PORT=8081 ] { 
  Thing smartLock FrontDoorLock [ NUKIID="123456789" ]
}
1 Like

Yes, you are right! Thanks for sharing this thread

@all I provided an alternative download URL - please see https://community.openhab.org/t/new-openhab2-binding-for-nuki-smart-locks/25940?u=mkatter

Progress! I can now lock and unlock via the Openhab Switch item, BUT a manual unlock or lock doesn’t update the item. As you are changing the way callback works is it better to wait for a later version and test some more?
This isn’t on a door yet so waiting isn’t a problem

Neither the Smart Lock nor the Binding will work correctly, if the Smart Lock is not mounted on a door!

I definitely recommend to mount and set up the Smart Lock and the the Nuki Bridge first. Then, if everything is working as expected, you should start with the next challenge: testing the Nuki Binding :slight_smile:

The binding .jar which I uploaded to Google Drive (link is in the first post) is the current development state and it works fine for me.

It was mounted on the door, so as far as Nuki is concerned all is normal :wink: It seems to store the lock and unlock position somewhere, so with care to not pull out the batteries it still thinks its on a door. I guess they didn’t want to stall the motor after every lock and unlock as it would kill the batteries.
I’ve got it working with the Google Drive version, but I think the callback server terminates once it has had a reply from the lock after a lock / unlock operation. This means it doesn’t catch an operation from the button. See the last but one line in the log I PM’d you. Is this the way it should work?

Correct, once the Smart Lock is calibrated you can “use” it also unmounted :slight_smile:

The Nuki Bridge is not posting its Lock State change to openHAB2.

  1. Did the Smart Lock unlock / lock when you toggled the Switch Item in the Sitemap?
  2. Did you also change the callback URI on the Nuki Bridge (to http://openHAB2ServerIP:8080/nuki/bcb)? It’s documented in the README.md in the shared Google Drive folder.

It turns out that the bridge hadn’t retained the callback, I have entered it again and it works.
I’ll keep an eye out for any updates and test again if it helps, otherwise I’ll wait for the released version. :joy:

OK, thanks for helping and the feedback!

Have fun with the Smart Lock, the Binding and openHAB2 :slight_smile:

1 Like

Great work - works perfectly for me as well. This was the right .things configuration-format for me:

Bridge nuki:bridge:NukiBridge1 [ IP="192.168.x.x", PORT=8080, APITOKEN="xxxxxx", CALLBACK_PORT=8081 ] { 
  Thing smartLock FrontDoorLock [ NUKIID="123456789" ]
}

Now here is my wishlist (it’s Easter period soon :slight_smile:):

  • Could you add support for pulling the latch?
  • Could you add a string item that reflects all states?
  • Could you add the “critical battery” information?

Thanks for your great work and keep it up! :slight_smile:

3 Likes

I’ve noticed that when I use the binding I get an error in the log, there is a slight delay between operating the test item and the lock operating, this doesn’t really upset the functionality. I only usually get the “takes more than 5000ms” errors around 4 times on booting from the RFXCOM binding

2017-04-06 08:44:18.388 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:44:18.393 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event
2017-04-06 08:45:04.661 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:45:04.667 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event
1 Like

@kevin @mkatter forgot to mention this. I see this errors as well.

@kevin @philKrylc
Thanks for the feedback. This issue is already written down on my internal issue tracker :slight_smile:

@philKrylc
Please use the latest Nuki Binding .jar (see first post). As I can see from the config you posted you are still using the outdated configuration!

Use the channel “smartLockUnlatchClose” to pull the latch.

I’ll think about this as the Nuki Bridge does not really send all of the available states.

I added this to my internal Feature Request list

Thx

1 Like