I could release it now, but I’m too tired (didn’t sleep tonight) to rewrite the instructions and could make mistakes. 
I was also thinking to start a new thread, this one is getting a little bit confusing, what do you think? Shall we continue here or start a new thread?
Let’s vote 
Than better get some rest. HA and the locks will still be the there later 
I don’t use it to retrieve the status, only to start the action (lock/unlock). The status of the door and the lock comes through the callback right after the action.
I sent my post and immediately after I understood that you don’t change the way to retrieve status. So I deleted my post: (post withdrawn by author, will be automatically deleted in 24 hours unless flagged) but you can read it.
Why did you delete it? It’s ok. Even from that post, and the relevant answer, something can be learned…
You may all consider voting for my feature request: Add 'initial' and 'restore' variables to (event) trigger-based template sensors
*L’espoir fait vivre… *
I am more and more convinced that the “door sensor jammed” problem come from the interval between two requests to get this value. Nuki app has a 20" refresh period for that but it refreshes immediately lock status. So, whatever the solution, I think we have to understand which scenario drives the Nuki bridge to send two requests to the smart lock in less than 20". I am pretty sure that the bridge does a request to the smart lock to elaborate the callback (it could get cached value). So, if you lock/unlock just after a 20" refresh of the Nuki app, it will be two consecutive requests sent to the smart lock.
I have to test after to stop (or uninstall) the Nuki app (which work in the backgroud). Have you this app running ? If not, that could explain why you have not the problem.
A great idea Friedrieck. But I don’t think devs will listen…
So we have to find a workaround…an elegant one…I started thinking about it tonight: right now the lock and the door sensors are initialized and get values only through the callback, but when you restart HA, all the other sensors are initialized through the poll. So when you restart you have all the polled sensors immediately available but the callback sensors are unavailable/not initialized.
I was thinking of a way to initialize the callback sensors both from the callback and the polling, either permanently or only after a restart. This would solve the restart issue, while still having the advantage of the callback system.
Let me know your thoughts…I was too tired to try something…will do after I get some rest.
To explore indeed. I think you can’t have e.g. two templates triggered by a same webhook, but you can have several triggers in a single template. It will complexify the templates values (starting with a ‘if’ or ‘choose’ depending on the triggers platform), but it seems doable…
I’ll show you what I’d like to do to solve the problem:
- trigger:
- platform: webhook
webhook_id: !secret nuki_bridge_webhook
binary_sensor:
- name: "Nuki Door State"
unique_id: nuki_door_state
device_class: door
state: >
{{ trigger.json.doorsensorState == 3 }}
Should become something like this:
- trigger:
- platform: webhook
webhook_id: !secret nuki_bridge_webhook
binary_sensor:
- name: "Nuki Door State"
unique_id: nuki_door_state
device_class: door
state: >
{% if (trigger.json.doorsensorState == None) %}
states('sensor.nuki_door_state') # the sensor of the polling (initialized after restart)
{% else %}
trigger.json.doorsensorState == 3
{% endif %}
The problem is that I don’t know if the condition == None is true when it’s not initialized. There should be a way to determine if the trigger data is empty/null.
You mean the App or the integration?
Native Nuki app (android or iOS).
Yes sure. (ok, in order to answer I have to write 10 characters)
I think the “door sensor jammed” problem could come from concurrency between Nuki app and HA “callback solution” (see my post above). If @alexdelprete does not use it that may explain why he does not have the problem. Moreover, a concurrency problem (related to the Nuki app 20" period to refresh door sensor) could explain the difficulty to find a reproducible sequence driving to the problem.
The problem is the trigger. Your templates won’t be evaluated until there is a trigger. In what your propose, you still have only the callback event, so the values will still only be calculated only when a callback arrives.
You could try the solution proposed here: Enhance Trigger-based Template Sensors
Or add a state trigger based on your sensor.nuki_door_state entity (if this is the correct entity). This latter solution will also make this trigger template updates every time your polled sensor updates
Then for your ifs, you should test on the trigger.platform / event_type, I think.
I use it all the time. The bridge should serialize the calls and queue them, I don’t think that is the problem. If they’ve done a good job on the firmware, the bridge should also have a cache for very near requests. It’s strange that I don’t see any sensor warning in my app.
What fw are you on? Bridge and Lock firmware…here are my versions:
Yes. I use it for notifications, etc.
So I can have more trigger types for the same sensor? that’s interesting, because if I can filter the trigger I can then use a value in case of the callback and another in case of the polling…
From the docs I didn’t notice you could have more triggers…I’ll have to read it again.
Thanks for the suggestions…if I can’t solve the puzzle I’ll write you, if you don’t mind…I’m still a beginner with HA stuff.
No problem (I’m not an expert either!)