Nope, that is the behaviour if you use the initial configuration option, that you wisely chose not to use. 
Instead, you rightly opted to configure it with 1 option (and without the initial config), but even if you configured it with the whole json file, if it’s the first time, the default value is the 1st value of the list.
So, the preserved entity is not needed, and probably you can !include the json file when you initialize the sensor, but I didn’t try…
Let me know if you agree…
Read the thread. 
Serious answer: try it and let us know. 
Hint: it’s WAY faster than the official integration. It’s the bridge that takes literally 8-10 secs to execute the callback, many people are complaining on Nuki’s forums for this. The bridge firmware is not very efficient, or maybe it’s the hardware, who knows.
At first I didn’t have it and then every time I did a restart of HA, the language was English. So I deduced that it had somehow to do with the missing options in the input select_entity. To my opninion this is what happens:
I hope you know understand why I needed that input_select.
You can also test it by yourself:
Just got my nuki smartlock, bridge and keypad yesterday. I got this integration installed and working as well, so thank you very much for the work!
That being said, I only got it working after some troubleshooting, which is why I would suggest adding a couple of things to the NOTES section of the initial post. There are a couple of posts in this thread reminding people to update the firmware, but I think it deserves a bit more explanation.
My bridge was still on firmware 2.3 when I got it and I had a hard time getting it to upgrade. I had to sift through the nuki dev forum, where I found the information that a call to the bridge interrupts the firmware update process. So you have to upgrade the firmware before adding this integration, otherwise the fwupdate process get’s interrupted and never finishes. Even after disabling the integration, doing a factory reset on the bridge and using http://nuki_bridge.lan:8080/fwupdate?token=XXXXX, the bridge stayed on 2.3. So I did another factory reset, left the http api disabled and went shopping, hoping that the automatic firmware update process would work (which only runs every 24 hours). And that really did work. When I came back, firmware was on 2.9.3. Then I could reactivate this integration and everything was working.
One other question that I have and couldn’t find in this thread:
Does the API hold information about how the door was locked/unlocked?It would be a nice to know when the door was unlocked/locked via the keypad, or if a wrong code was entered. We could use that for additional automations, i.e: door was locked via keypad: Check all windows are closed and send notification if not.
Again, thanks for the integration, a great addition to my “smart home” and home assistant.
EDIT: After looking through the API documentation and finding no information about the keypad, I searched the developer nuki forum. Here is one post from a developer for the nuki loxone integration asking for exactly this. So it seems there is no way currently to get this information. Maybe I’ll put in my two cents over there as well.
John, thanks for your post.
In the instructions, at the very beginning, I put this note:
Obviously I can expand it if you feel it’s not enough, but I think it’s pretty clear I’m saying that this integration requires at least fw v2.5.3 to work correctly.
No, unfortunately the Bridge API v1.12 doesn’t provide that info.
Thanks,
Alessandro
Jeroen,
you’re right, the input_select allows to extend the options via a service call, but when you restart HA, it gets reconfigured by the definition you have in the yaml, so you lose the additional options added at runtime.
I see only one workaround: add the already available languages in the json to the definition of the sensor. The downside is that if a user adds his language, he has to add it also to the code. Unless we add ALL most used languages both in the definition and in the json, leaving the strings in english in the file, and ask users to translate them. 
I also know there’s a select entity, added in 2021.7 release, but I found no usable documentation about it.
Alessandro,
The way I programmed it, it will restore the chosen language on a (re)start of HA. The only thing a user has to do if a language is added to the nuki_languages.json file is restart HA and choose the newly added language. From then on HA will remember the chosen language.
BTW, I might have found a solution for serializing the REST commands making use of the possibility to execute shell commands. I found a way to execute a curl command and pipe the output to a curl command that does a post to a HA sensor. This way it should be possible to create an automation that triggers every x minutes and fires the needed REST commands one after one, waiting for the one before to have ended.
Yes, that’s why I left the input_text that saves the preference. Anyway, input_select is not well designed.
I would be happy if REST sensors and command would return an HTTP status code for now. Did you find that? I didn’t. Error management for these sensors is ridiculously impossible, unless I’m missing some important information on how to capture the status code.
Not necessarily that it requires at least 2.5.3 (although I did miss initially I have to say), but a clearer statement that one should upgrade the bridge, if needed, to fw > 2.5.3 BEFORE adding this integration. Like I said, if you add this integration with the correct token and URL before doing the upgrade, the fwupdate process will fail, since it can only handle one request at a time. And additional request to the bridge while the update process runs, will result in the process being stopped. Which puts you in an endless loop.
That’s what I think should be added, first make sure the bridge is up to date, only then add the integration to HA.
Again, thanks for you work!
John,
if at the beginning of the instructions I put a clear note in which I say the integration requires at least fw 2.5.3, so it’s a mandatory prerequirement, what does that imply? That you need to be sure you have at least v2.5.3 on the bridge before trying to configure it.
You missed that note, otherwise you would have verified it before. I can stress out that point even more, but I cannot oblige people to be careful when they read instructions.
Thanks for your comments and glad the integration has worked for you. A new version is being released today or tomorrow. Keep an eye on this thread.
Ciao,
Alessandro
Sorry no, not yet, but what I found for a shell command:
List:
curl -s -X GET 'http://<nuki ip>:8080/list?&token=<nuki token>' | sed 's/\[//g' | sed 's/\]//g' | echo {\"state\": \"OK\", \"attributes\": $(</dev/stdin)} | \
curl -X POST \
-H "Authorization: Bearer <HA access token>" \
-H "Content-Type: application/json" \
--data-binary @- http://<HA ip>:8123/api/states/sensor.nuki_test_1
will create the sensor “nuki_test_1” and place the json values as attributes
Info:
curl -s -X GET 'http://<nuki ip>:8080/info?&token=<nuki token>' | echo {\"state\": \"OK\", \"attributes\": $(</dev/stdin)} | \
curl -X POST \
-H "Authorization: Bearer <HA access token>" \
-H "Content-Type: application/json" \
--data-binary @- http://<HA ip>:8123/api/states/sensor.nuki_test_2
will create the sensor “nuki_test_2” and place the json values as attributes.
The difference between the 2, is that for REST list call, the “[” and “]” characters are deleted in the json result, otherwise you’ll get an internal server error from the side of HA.
I don’t want this integration/automation to become a whole bunch of workarounds to REST sensors and Nuki Bridge limitations. I prefer to ask devs to add status codes to those, and wait. We can live with some errors in the logs.
I agree and from what I’ve seen from the nuki logs, is that the bridge will restart when 2 api calls arrive at the same moment.
Another improvement would be if there was a possibility for the REST sensors to stop them from firing every x seconds and that you could control it via an automation.
I also found out that there is a possibility to call python scripts, see:
Maybe this way somethings can partly be moved to python, without having the knowledge to completely write a whole integration. Downside is that you can’t put everything in a package or in the same directory…
Remember when I noticed reboots in the logs? It was because of the 2 REST calls. But now I put different timings on the sensors, relaxed them, so it should not happen very often.
The bridge also reboots if it doesn’t communicate with the lock (BT) and other cases. I really don’t like how it is designed, quite frankly.
There’s also a custom component, pyscript, that allows you to use python as a scripting language.
But it doesn’t make sense, IMHO, at that point we can start developing a custom component.
You don’t need that custom component for executing simple python scripts. For simple scripts you only need to add something to your configuaration.yaml and put the script in a certain directory. Then you can call that script from within an automation or HA script and it is even possible to update entities in HA and receive parameters from the calling service.
pyscript is a different beast, it’s a script engine for HA: Pyscript: Python Scripting for Home Assistant — hacs-pyscript 1.3.2 documentation
