I am using the textual thing & bridge configuration from the docs.
During every start I get the following message:
[WARN ] [nternal.handler.NukiSmartLockHandler] - SmartLock 'nuki:smartlock:nb1:front_door' was created by old version of binding. It is recommended to delete it and discover again
I’ve removed the things file and added it again but the warning keeps reappearing in the log.
Is there anything I can do?
It’s not really an issue. The old version of binding expected the nukiId property to be in hexadecimal format (since thats how it’s displayed in UI), the new version uses automatic discovery and expects the nukiId to be in decimal format (that’s how it’s returned from API).
If the binding detects nukiId in hexadecimal format, it will log this message, convert it automatically to decimal format and save it. I guess since you use textual config it’s not persisted and the same thing happens every time the thing is activated.
To fix it you can just take your nukiId and convert it from hexadecimal to decimal (you can use some online converter or even calculator in windows). Guess I shoud update the docs, I didn’t really pay much attention to the manual config example since not a lot of people use it.
Debatable 
.
Is there a way that it’s still possible to enter the hex id since that’s the value that is shown in the App?
Since it’s only a string maybe prefix it with “0x”
E.g.:
0x22AA22 → No warning
22AA22 → Warning
I’ve created a PR that adds the parameter to the docs since it has been missing, too.
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).
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.
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.
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",
That’s not really useful since the addon is not using rest api internally, I was hoping there’s something on openHABs Thing API.
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 …
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.
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!
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.
Ah, thanks. I used the wrong kind of item first. It needs a number item to work.
I guess it is not possible to pair multiple Door Sensors with one Nuki Smart Lock, correct?
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.
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?
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.
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.
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.
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.