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:
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
It was mounted on the door, so as far as Nuki is concerned all is normal 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?
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.
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