But like I said before: if I need python because of limitations, then it’s better to develop a custom-component.
Alessandro, do I have to understand @hillbicks comments about https calls breaking the firmware install in the bridge as we will never get a new firmware while Nuki card is doing http request basically ever 2 minutes and a firmware install takes longer and will intentionally be broken by the request? If so, how about stretching the intervalls between calls to 5 or 10 minutes?
Nuki Card is not doing calls basically every 2 minutes. If a user follows to the letter the instructions of the first post, there’s no issue whatsoever. What he wrote in the post is his personal opinion of how things went, not necessarily reality. Please let’s not panic on opinions, they’re not facts.
Also, ask yourself a question: why did he have an old version of the firmware, before configuring Nuki Card, if the updates are automatic? 
John,
the bridge accepts one call at a time, even with newer versions of the firmware, please don’t make wrong statements and assumptions like these in order to find an explanation to why you weren’t able to configure the integration properly. Many users configured it correctly by paying attention to everything I wrote in the first post. Nobody went into an “endless loop”, not even you. 
Nuki Card v8.7 released: localization support by @spokin (just use input_select.nuki_language to configure it). Removed the duplicated door/lock polling sensors. Relaxed the REST sensors polling periods even further. Lot of optimizations to the code. Please re-edit the lovelace card, as sensor names have changed.
For old-time users: there’s a new file to install (read the instructions of first post) and the code for the lovelace card has changed a bit, make sure to read the instructions and apply them.
1 Like
Great work guys, thanks.
Just updated and it’s looking good. Repeated warning in the log, everything appears to be working though:
2021-07-29 18:22:16 INFO (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Choose at step 1: choice 1: Running automation actions
2021-07-29 18:22:16 INFO (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Choose at step 1: choice 1: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.automation.nuki_card_callback] Nuki Card Callback: Choose at step 1: choice 1: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Running script sequence
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Choose at step 1: choice 1: Running script sequence
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Choose at step 1: choice 1: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Choose at step 1: choice 1: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 INFO (MainThread) [homeassistant.components.script.nuki_set_language] nuki_set_language: Executing step call service
2021-07-29 18:22:17 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'nuki_bridge_callback_id_list_states' when rendering '{{ nuki_languages[states('input_select.nuki_language')]['nuki_bridge_callback_id_list_states'] }}'
Do you have debug enabled maybe? I don’t have that stuff in the logs, @spokin did you see it in the logs? Strange…
@alexdelprete: I think this is a misunderstanding, so let me try again to get my point across. First of all, I’m not blaming the integration and not looking for excuses. I already stated that my scenario could’ve been avoided if I had read more carefully what you wrote in the notes and updated the bridge BEFORE adding the integration. That was my mistake.
After I added the integration, while still being on firmware 2.3 (which was the firmware installed on the bridge when it was delivered to me) I noticed my mistake and then tried to upgrade the firmware. But since I had already enabled the integration, I couldn’t update the firmware. To quote from the nuki developer forum in the stickied troubleshooting post:
Troubleshooting
It may happen, that your Nuki Bridge is not updating properly due to several reasons:
- A smart home integration might cause too much traffic on the Nuki Bridge, which suppresses the automatic update flow described above
- The Nuki Bridge is not having a steady internet connection, which prohibits the proper download
For being able to still get the latest Nuki Bridge update, you can apply one of the following steps:
- Manually trigger the update by calling the /fwupdate command of the Bridge HTTP API
- Disable all your running smart home integrations and wait for 24 hours
- Disable the HTTP API of your Bridge and wait for 24 hours
That is all I wanted to state here for other users who might run into the same scenario. The bridge might not update to a newer firmware if regular calls to the bridge API are made. Which is the scenario I experienced. I started the firmware update process, the integration made a call to the bridge, the firmware update could not complete. That is the endless loop I was talking about. Start the update, HA makes a call, update gets interrupted.
And that is all I wanted to mention, that it might be worth to mention in the notes that a firmware update might/will fail if a call is made to the bridge during the update process.
So I agree with @jezinke: From what I’ve quoted before, it seems that the callback might hinder automatic firmware updates of the bridge, which is poor design on the bridge part, not the mistake of this integration.
Hope that clarifies it…
1 Like
Everything clear now. Sorry, I misinterpreted your words.
It’s not the callback (the bridge that calls HA), but the REST sensors of the integration, that poll periodically the bridge. I’ve relaxed the polling frequency to 4-5 minutes.
In any case, 4-5 minutes are more than enough to send the fwupdate command. In case of problems, you can disable/uninstall the integration, update, then restart it.
Thanks a lot for clearing this out John.
2 Likes
No worries, glad we cleared that up. And I agree 4-5 minutes should be plenty of time to update the firmware.
And thanks for the latest update! Have a nice evening.
Yes, I’ve enabled debugging, whilst this is under active development.
I’ll disable it and see if the warning still appears.
Ok, that’s why. It’s true we’re in active dev. mode, but I advise to enable debugging only in case of severe problems.
Hi Alessandro,
There is one problem with version 8.7, in my logs I see:
The problem is at line 428 you refer to:
{{ nuki_languages[states('input_select.nuki_language')]['nuki_bridge_callback_id_list_states'] }}
However “nuki_bridge_callback_id_list_states” is not available in the json file, so the code should be changed to:
{{ nuki_languages[states('input_select.nuki_language')]['bridge_callback_id_list_states'] }}
or change all “bridge_callback_id_list_states” tags to “nuki_bridge_callback_id_list_states”
Hi Alessandro,
more work to come, the lock entity will also have the state “jammed” as of the August release of HA. See the beta release notes.
Nuki Card v8.8 released: typo in json file corrected, reference to an old binary_sensor corrected in the code.
Please update both files, the .json and the .yaml. Sorry for that.
1 Like
Yes, I spotted that too. And I also found an old reference to the old binary door sensor, corrected that one too. v8.8 just released. Thank you Jeroen.
it also has support for locking/unlocking states. but the problem is that the bridge doesn’t send callback for those states. I don’t know about jammed though, I guess that would be 254.
Anyway, we just need to map 2, 3, 254. But we’ll never receive those, I guess. Locking/Unlocking are not sent, I already tested. Don’t know how to test Jammed. 
"lock_sensor_states": {
"0": "uncalibrated",
"1": "locked",
"2": "unlocking",
"3": "unlocked",
"4": "locking",
"5": "unlatched",
"6": "unlocked (lock ‘n’ go)",
"7": "unlatching",
"254": "motor blocked",
"255": "undefined"
},
Hi @alexdelprete
Thanks again for your effort!
Small question:
Until 8.4 (at least for what I upgraded) I had the door sensor icon yellow when open.
And now it stays gray.
Is it something in the new configuration?
Yes, we had duplicate door sensors, one was binary (the callback one) and the other was a normal sensor. I decided to delete the binary one. Unfortunately, I only remembered afterwards that the colored state is active only with binary_sensor since device_class is configurable only on those kind of sensors.
Actually, your apparently simple question also led me to a conclusion: we didn’t need the translation system if we only used binary_sensor type for door/lock and all binary state nuki information.
@spokin: if we use only binary_sensors with the appropriate device_classes, HA automatically uses the user profile language for the status strings. Right now the lock is a binary sensor, and I will revert the door to a binary sensor. The lock_bt can be converted to a binary_sensor with device_class:connectivity. So basically we have all the main sensors automatically covered by HA for the translation. Let me know your thoughts…but I think almost all this can be managed by HA and its localization support if we use the appropriate binary_sensor with device_class.
"English (default)": {
"lock_bt_states": {
"1": "connected",
"2": "disconnected",
"255": "unknown"
},
"door_sensor_states": {
"1": "deactivated",
"2": "closed",
"3": "open",
"4": "unknown",
"5": "calibrating"
},
"lock_sensor_states": {
"0": "uncalibrated",
"1": "locked",
"2": "unlocking",
"3": "unlocked",
"4": "locking",
"5": "unlatched",
"6": "unlocked (lock ‘n’ go)",
"7": "unlatching",
"254": "motor blocked",
"255": "undefined"
},
"keypad_battery_critical_states": "not installed",
"nuki_bridge_callback_id_list_states": "not configured"
},
I’m glad I was able to turn some wheels:)
My understanding is much modest then yours but it sounds like your idea is going to simplify the code.
So based on my latest success 
here’s another simple question:
Is there a way to send “lock&go” command through the lock entity in your code?
I’m actually using it a lot (leaving home with hands full)
Thanks!