search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[nuki] Error with nukiId Dec/Hex convert #13088

Closed momo584 closed 2 years ago

momo584 commented 2 years ago

Current Behavior

The Nuki-ID of my Smartlock is nukiId: "88710849" The binding tries to convert it because it has 8 digits only, but it isn nessecary. If It try to add a "0" at the beginning it is also failling.

Your Environment

janvyb commented 2 years ago

Does that mean the binding does not work with smartlock with id this low?

Ger-sh-win commented 2 years ago

Does that mean the binding does not work with smartlock with id this low? Yes! The binding ist not working with smartlocks that have an ID with only 8 digits.

janvyb commented 2 years ago

Ok, sorry for late reply, I had no idea this issue existed. The reason the conversion is there is for compatibility with old binding version since it required nukiId to be in hexadecimal format but the new one requires it to be in decimal format (same as the API uses). Does that mean that your hexadecimal nukiId starts with zero, or is just 7 digits long? I assumed all nukiIds are 8 hexadecimal digits long, now I'm wondering how to fix that since there's now way to tell if "88710849" should be interpreted as hexadecimal or decimal.

momo584 commented 2 years ago

Yes my hexadecimal nukiId is just 7 digits long. In the nuki API it does not show a "zero" at the beginning. Just the 7 digits.

In the meantime I replaced my old nuki with a new one, but maybe for other the same can appear. (and also for me if i would decide to use the old nuki for another door ;))

janvyb commented 2 years ago

Right, I think the easiest solution would be to say nukiId is in hexadecimal format if it contains at least one a-f letter. It's still possible to have nukiId in hexadecimal format with only numeric digits, but that can be fixed by manually converting it to decimal (and it should only be problem for people who upgrade from old version of binding).

momo584 commented 2 years ago

Isn't it the best solution to use the id as it is, without converting ?!

janvyb commented 2 years ago

The problem is that all Nuki APIs accept both formats but only return id in decimal. So when bridge sends callback that some device was updated the binding searches for the changed thing using nukiId. Using both id formats in binding would be messy since you would not be able to tell what format the nukiId is in and whether you can compare them or not.