This should solve it: State Trigger
Working on it…
How is it possible to have that:
(the icon is the opposite of the text)
The dynamic icon code was missing. Happened when I transitioned all state sensors to the new format.
- name: "Nuki Lock Sensor State"
icon: >
{% set lock_icon = state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['state'] %}
{% if lock_icon == 1 %}
mdi:lock-outline
{% elif lock_icon == 3 %}
mdi:lock-open-outline
{% endif %}
Same for the door, right above…I already fixed these, but I’m concentrated on the sensor issues now…
Released v4.5 (only templates.yaml changed). You’ll find the icons ok for the polled sensor, now they’re dynamic, they were static before. Fixed the icon of the device name as you asked. 
Please retest the triggered sensor, restarting and reloading templates and tell me if you still find weird behaviour. Thank you for the help.
@Friedrieck @mahikeulbody I think I’ve finally solved the HA restart problem. I introduced the State trigger, so now as soon as the polling updates the door sensor (at startup, and periodically after obviously), it refreshes the triggered Door sensor. If a callback arrives it gets processed as it was before, idem for the template reload.
- trigger:
- platform: webhook
webhook_id: !secret nuki_bridge_webhook
- platform: event
event_type: event_template_reloaded
- platform: homeassistant
event: start
- platform: state
entity_id: sensor.nuki_door_sensor_state
to:
- "open"
- "closed"
This is the state after an HA restart:
Notice the trigger platform value. Probably, the homeassistant start could be removed from the triggers, I have to test later.
Yes, that is what I proposed in illo tempore (Nuki Smart Lock 2.0 - support all available API actions (i.e. add lock/unlock) - #283 by alexdelprete)
At that time (48h ago) I didn’t even know what you were talking about…
If I don’t experiment and study it myself, I’m never confident of anything.
So now we have a sensor that is updated both by callback AND by polling. That was the goal.
I have small warnings in the log at HA startup on some sensors, because I think the rest calls are not completed yet…but I don’t know if I can do something about it…
Are you sure to have posted the right version ? Because I have still the icon of device name ‘numeric’ and also sensor lock state not updated:
Yes, the code is there:
- name: "Nuki Lock Sensor State"
icon: >
{% set lock_icon = state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['state'] %}
{% if lock_icon == 1 %}
mdi:lock-outline
{% elif lock_icon == 3 %}
mdi:lock-open-outline
{% endif %}
- name: "Nuki Friendly Name"
icon: mdi:numeric
state: "{{ state_attr('sensor.nuki_endpoint_list','name') }}"
- name: "Nuki Device Name"
state: "{{ state_attr('sensor.nuki_endpoint_info','scanResults')[0]['name'] }}"
icon: mdi:numeric
Refresh the browser and check the code in the release post. Then copy it and make sure you paste it.
1 Like
Sorry but I refreshed the browser and I copy again template (and I make sure it is pasted). I restarted and I get everything ok at first but then I locked the Nuki and I get lock sensor state not updated
Fixed the icon of the device name as you asked.
It is anecdotic but what I had suggested is icon: mdi:alpha instead of icon: mdi:numeric for both nuki friendly name nuki device name (btw, it was a case for device name in a previous version).
Since it was not the case, I hoped you had not posted the right version since lock sensor state is not ok (at least for me).
If I may, I would opt for mdi:alphabetical
One lesson learned for me, is that the event homeassistant_start is triggered even before all sensors are ready, which is not optimal, in my humble opinion.
Good to know.
Or actually, this is not how it is stated for the moment. I wonder if there would be a difference between what you have now:
- platform: homeassistant
event: start
And what could possibly work as well (not tested, of course):
- platform: event
event_type: homeassistant_start
If you already miss these endless edit/save/reload sessions, you could add the second to your triggers and see what happens (likely to be the same thing, but you never know).
Well, it toke me 1h (!!!) to understand that sensors are only updated by endpoint_list so by polling. I though they were also updated by the webhook (since these infos are also in the json). It is a little bit destabilizing to show them in the card only through polling and not also on webhook but one can remove them from the card if wished.
Sorry for the false “alert” 
I can confirm that here:
Nuki Lock Action is updated “in real time” (so webhook is operational).
Nuki Lock Sensor State is updated at restart and after only each 5’ whatever lock/unlock action is made in between (so, by polling, no by webhook).
Last minute: it is also immediately updated if I open/close the door.
the two sensors with State at the end of thr name (3rd and 4th in that list) are the polling sensors. the first two are with callback AND polling. I left them to notice the difference while developing, but they can also be removed when we’re sure everything works ok.
So it looks like it’s working for you, or not? I’m out for dinner, no computer here.
I agree. Will modify it.
you wrote mdi:numeric in the request. probably i didn’t understand the request, sorry.
i don’t understand what doesn’t work for you, try to tell me exactly what you see, but concentrate on first and second sensor, not the polling sensors.
i think i will remove that event, because in the end, i need the callback sensor to be linked to the polling sensor, also at startup. also event_reload, i think that the state trigger supersedes both of them.
it was useful during development to understand what was going on under the hood.
remove them.