Hm is this 3.3.0-SNAPSHOT compatible with OH 3.1 latest? I’ve put the jar into the addons folder and adapted permissions. Also restarted the openhabian pi again. But the addon seems not to be picked up. The old version I deinstalled before. If I try to manually add the binding via UI (+), it shows only 3.1 as offer.
Yes, I’ve tried it with 3.1 and 3.1.1 and it works just fine. Try looking into openhab logs if there’s any error.
Ah, my bad - works for me as well. It was auto-enabled. I was confused because it didn’t appear under installed bindings :).
Hey again. Meanwhile I bought the real bridge - the android software bridge was not so reliable. I have now a combination of the new SmartLock 3.0 (non pro) and the hardware bridge. Unlocking and locking including callbacks seem to work. Thanks for that!
The only issue I have is, although I’ve enabled “Unlatch” in the OH SmartLock thing settings, If I open the door via OH, it only unlocks - but does no unlatch. I called the /unlock API on the bridge manually providing the token and the nukiId, there it unlatches properly. Any idea what might be wrong? I’ve installed the SNAPSHOT version that was mentioned earlier. Also in the app the door is configured with a knob. Also there it unlatches properly.
Yeah, you’re right. There’s a bug and the configuration for smartlock handler is only loaded when the handler is created - which only happens on OH startup, I’ll fix that.
As a workaround for now, every time you change unlatch property you have to either restart openHAB or uninstall and install the binding again (if you have the snapshot jar in addons folder, just move it somewhere else, wait till it’s uninstalled and put it back again).
But to be honest I’m not sure I’d trust openHAB enough to let it open my front door, especially using some rule I’ve written. I use it mainly to lock doors when I leave or at night and unlock it in the morning. For opening (unlatching) I use Nuki app only.
Ah, ic. Thanks!
Yeah I fully agree @ not opening the door automatically :)!
For me it’s a sidedoor from the garage to the house. Since I don’t want to rely on the Nuki app and all boilerplate which comes with it (finding the phone, unlock, start the app, auth, selecting the lock, finally unlatch), I want do go a more pratical way here using a keypad. But since the Nuki keypad is only limited to Nuki itself and not general purpose, it makes it hard/impossible e.g. to disarm an alarm before actually opening the door. Also you can’t trigger any other actions based on different codes since Nuki APIs don’t provide that currently.
So my idea is now to buy one of the Linkind keypads that seem to be able to connect using a zigbee usb stick and zigbee2mqtt. The protocol seems pretty straightforward to be handled by a OH rule. As it seems you can then also provide feedback to the user whether something went wrong etc. And you can trigger whatever you want using keycodes. A zigbee stick plus the keypad in sum is still cheaper than the Nuki keypad and is way more open.
So pressing 6 buttons (or whatever count suits you) is hopefully more quickly than doing the Nuki app thing. Also you can’t forget your keypad :). I know that something like auto-unlock exists if you’re nearby the lock - but I can imagine certain situations, where I maybe want to park in the garage and NOT open the sidedoor door but use the frontdoor. In that case it would most likely open the sidedoor once I’m leaving the car :/.
Long (and hopyfully interesting?) story short: I need a way to unlatch the door using openhab item. Yesterday evening I also found the option to write to the lockState channel right? Maybe that’s a better way to go for me then. WDYT?
You can put shortcut on home screen that will launch Nuki app and show menu for opening specific lock, but you still have to get your phone so I agree that keypad is more convenient. You can also get Nuki fob which is just one button, but it’s quite pricy and pretty limited in function (it only toggles lock/unlatch so if doors are just closed, it will lock first).
Yes, sending one of supported commands to lockState channel is the way to do it, that lock switch channel is there only for convenience when creating sitemap, internally it sends unlatch/unlock command based on lock configuration (all use the /lockAction endpoint on bridge API).
Pefect then, thanks for the pointers!
Hi,
I have a problem with this binding.
The states of all the channels of my Opener and my Smart Lock are not refreshing.
I assume this has something to do with the callbacks not working.
I setup the binding in OH3.3.0-shapshot by discovering all devices (bridge, opener, smart lock). They appear online, and they get their initial states but then thats it.
I’ve read somewhere, that theres a problem with the decimal to hex conversion, but even if I put in the NukiID in hex, the channels do not update.
What am I missing?
//Edit:
Just solved myself.
I am running openhab in a docker with two networks and the wrong Ip adress was published to the bridge as callback url.
So I changed the primary interface in openhab settings to the correct one and reinitialized the binding. Now it works as expected…
1 Like
Hello… ee thank you for your time… I tried your addons, but I have the problem that in openhab 3 I do not see the objects OPEN and CLOSE… what do you recommend?
That’s just the bridge, it does not have any channels on its own. Now run discovery again and it should find smartlock (or opener, if you have it).
I have the same issue, I am able to auto discover my bridge (Nuki Bridge, not SmartLock 3.0) but if I scan again there, no other devices appear. (Smartlock 2.0)
Did you add the discovered bridge as a new thing before running discovery again? Is it online?
You mean I have to delete the thing and than add it again with the known data?
The bridge is shown as online since yesterday yes.
And this call looks also fine:
{"bridges":[{"bridgeId":XXX,"ip":"192.168.155.10","port":8080,"dateUpdated":"2022-05-23T07:42:16Z"}],"errorCode":0}
If you have bridge added as a Thing and it’s online, then it should work. Run discovery again and check logs for any errors, maybe try raising log level of org.openhab.binding.nuki to debug.
Just to be sure we are talking about the same thing, “Run discovery” means, Things → + → Select Nuki Binding → click Scan in the top?
I will check the logs
Best
Tim
Okay thats interesting, looks like the device is there, but not shown in the UI.
openhab> log:tail org.openhab.binding.nuki
12:40:23.425 [DEBUG] [.internal.dataexchange.NukiHttpClient] - getList() in thread 71077
12:40:23.432 [DEBUG] [.internal.dataexchange.NukiHttpClient] - executeRequest(http://192.168.155.10:8080/list?ts=2022-05-24T10%3A40%3A23Z&rnr=3338&hash=XXX)
12:40:23.606 [DEBUG] [.internal.dataexchange.NukiHttpClient] - contentResponseAsString[[{"deviceType": 4, "nukiId": XXX, "name": "Seitentür", "firmwareVersion": "3.2.8", "lastKnownState": {"mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 90, "keypadBatteryCritical": false, "doorsensorState": 2, "doorsensorStateName": "door closed", "timestamp": "2022-05-24T10:24:26+00:00"}}]]
12:40:23.624 [DEBUG] [.internal.dataexchange.NukiHttpClient] - getList status[200] response[[{"deviceType": 4, "nukiId": XXX, "name": "Seitentür", "firmwareVersion": "3.2.8", "lastKnownState": {"mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 90, "keypadBatteryCritical": false, "doorsensorState": 2, "doorsensorStateName": "door closed", "timestamp": "2022-05-24T10:24:26+00:00"}}]]
12:40:23.641 [DEBUG] [.internal.dataexchange.NukiHttpClient] - getList OK
12:40:23.660 [DEBUG] [.discovery.NukiBridgeDiscoveryService] - Discovery finished, found WebApiBridgeDiscoveryDto{bridges=[WebApiBridgeDto{bridgeId='XXX', ip='192.168.155.10', port=8080, dateUpdated='2022-05-23T07:42:16Z'}], errorCode=0} bridges
12:40:23.672 [DEBUG] [.discovery.NukiBridgeDiscoveryService] - Bridge nuki:bridge:XXX already exists, skipping discovery
Are you sure you have Smartlock 2.0? The bridge reports deviceType 4, which is Smart Lock 3.0. You’d need latest snapshot/milestone version of binding, Smart Lock 3.0 is not supported in stable version.
Oh men, you are totally right, I bought 3.0, I will try it out with the latest snapshot.
Thank you very much.
