Thanks for the informative reply. I have configured the callback, and also added a things file. The smartlock and bridge both show up as āUNINITIALIZEDā Restarting the bundle puts this in the log
2017-04-03 09:37:24.627 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update 'ON' for item 'TestLock' to handler for channel 'nuki:smartLock:NukiBridge1:TestLock:smartLockOpenClose', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.
What am I missing? Do I need a service file? If I do what do I put in it?
Did you configure .things and .items file like documented it in the README.md?
I got this error when I edited these files on my windows pc over a share running openHAB on a RaspberryPi3. Connecting over SSH and editing the files via nano or vim works for me. Also, if I use PaperUI I never got this error message.
If the error still shows up, please restart openHAB via SSH: systemctl stop openhab2.service systemctl start openhab2.service
2017-04-03 10:30:05.248 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate command 'ON' for item 'Testdoor' to handler for channel 'nuki:smartLock:NukiBridge1:TestDoorLock:smartLockOpenClose', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.
2017-04-03 10:30:05.253 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update 'ON' for item 'Testdoor' to handler for channel 'nuki:smartLock:NukiBridge1:TestDoorLock:smartLockOpenClose', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.
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
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
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 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
The Nuki Bridge is not posting its Lock State change to openHAB2.
Did the Smart Lock unlock / lock when you toggled the Switch Item in the Sitemap?
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.
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