New openHAB2 Binding for Nuki Smart Locks

Add-ons Bindings
,
206

I mean you can just use it as it is if you don’t mind the warning which doesn’t really do anything.

That’s one way to do it, I’m not sure I like it since that 0x adds a bit of visual clutter to config. I was also thinking about adding new property, like nukiIdHex, which would do that conversion and only be used for text config. Or maybe there’s a way to detect if thing was created from text config?

It’s missing since user cannot edit it in UI but yeah, if you want to use text config it should be there (probably with some note that it’s only relevant to text config). We should also fix the text config examples - it’s missing example for opener also some new parameters (like Secure Token on bridge).

207

The “0x” will only be in the things-file and is used to not display the warning. It’s just for parsing the value.
In the gui the NukiID is shown as a number - as it is now with the hex values.

Imho two parameters which do the same thing is not nice and leads to more confusion.

Yes - there is a readOnly or some other thing property which indicates that the thing can be edited through the GUI. Things from textual config have it set to false.

208

Is there? I can’t find anything. That would be my preferred solution - only show it for things created from UI. The warning is there for people who used UI with old version of addon to create the thing, since new version has improved id generation. If you use text config then this does not really apply.

209

If you request the thing through the RestAPI you can see that editable is set to false for my textual:config.

  "statusInfo": {
    "status": "ONLINE",
    "statusDetail": "NONE"
  },
  "editable": false,
  "label": "Nuki Smart Lock",
  "bridgeUID": "nuki:bridge:nb1",
210

That’s not really useful since the addon is not using rest api internally, I was hoping there’s something on openHABs Thing API.

211

I’m aware.
But the RestAPI accesses the internal thing api so the property has to be there.
I thought maybe you can find it by going backwards from the RestAPI to the thing api.
If you can’t find it you can always ask a maintainer for help …

212

Found it, I’ve made new PR which should fix this - [nuki] Disabled warning for things created from textual config by janvyb · Pull Request #13331 · openhab/openhab-addons · GitHub, you can close the one you’ve created since I’ve also updated documentation with missing parameters.

1 Like
213

Hello,
I just installed a Nuki 3.0 Lock and the Bridge and added both to my OpenHAB 3 system. Nuki also offers a separate door sensor (not the one integrated in an older version of the lock) in a small and simple design with apparently long battery life. Is it possible to include this in the binding so I can add this thing to OpenHAB? Thanks!

214

There’s doorSensorState channel which should return door state if you have door sensor connected to smartlock. It does not show as a new thing.

215

Ah, thanks. I used the wrong kind of item first. It needs a number item to work.

216

I guess it is not possible to pair multiple Door Sensors with one Nuki Smart Lock, correct?

217

I doubt that this is possible. The door sensor is always directly tied to a lock and it does not make a lot of sense to detect the state of a different door for the lock.

218

What is the functional requirement to this? You only have one door for one Smart Lock? you don’t have a door, that opens both sides, do you? :wink:

219

I like the Nuki Door Sensor because it is small and apparently has long battery life. I would like to use it for another door without a Smart Lock.

220

There’s no way to use multiple sensors since the API only reports status of one. Why not use zigbee door sensors? You can get bunch of them with zigbee dongle cheaper than one nuki sensor. I’m using aquara door sensors and they last couple years on single CR1632 battery.

221

Doesn’t work that way. The Nuki SmartLock is designed to have only one door sensor - the one directly netx to the SmartLock. It makes really no sense to use it any other way. The door sensor has to have the SmartLock next to it to work - without it the sensor is useless.

=> so you either need another SmartLock for the other door or you have to use another completely from Nuki independent hardware.

222

Ok, thanks.
Is there a way to get a readout for the battery level of the Door Sensor? I don‘t see such a channel.

223

Not in the bridge API the binding uses right now. There’s doorsensorBatteryCritical in the web API but that only tells you when battery is critical, not the actual battery level.

224

The Bridge-API does offer a batteryChargeState → you could file an feature request on github - or the binding-author reads this and updates the binding. but AFAIR the binding is orphaned and not updated for quite a while?

225

Posting also into this thread - I’m working on support for Web API, you can try latest verson here: