Are you referring to the top row?
That sensor is created by the Nuki integration, I left it in the card to have the possibility of pressing the action button and lock/unlock Nuki. Is it slower than our callback sensor? Cool! 
If I find a way to let the status of the callback sensor an actionable link to lock/unlock we can get rid of the default Nuki sensor. Iām still at the beginning with HA, donāt know how to do it, but if I find some examples etc. I could work on it.
Yes.
Hoping you could find a way !
Iām sure itās doable, but I donāt have the knowledge yet. Canāt promise anything. Iāll try to search for something and readapt it. But no time commitments. 
hi, i deleted a call
I only left the one with the token in sight
but it still gives me the same problem (Iām sure Iām clumsy)
but in the part āyour_long-term_webhook_idā I have to put the name of the token created, or the real token?
in the part āyour_long-term_webhook_idā I have to put the name of the token created, or the real token?
The real token.
long-term webhook_id = long-term HA token. From command line, you need to pass to curl the REAL token, because from shell you canāt access the variable you put in secrets.yaml.
show me the list of callbacks on the bridge, so I can see if you set it properly.
{ācallbacksā: [{āidā: 1, āurlā: āhttp://10.10.10.43:8123/api/webhook/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJmYTE4Y2E5MTI4MjM0YTYxYmYyOWM3YTIzMWUwYjAwZSIsImlhdCI6MTYyMTg1Mjc2NywiZXhwIjoxOTM3MjEyNzY3fQ.1CT5pWEpccedcHVIBipUH8cPIL9heHu8NhfEEsmVcmcāā}]}
this is exactly what I get from the ālistā call
itās correct ???
looks ok. did you double-check the token? the IP is HASS server right?
Show me the screenshot of the token in HA profile. To make sure itās exactly like the one you posted.
If you still have āunregistered webhookā errors in the log, it means the token in HA is not the same as the one you added to the bridge callback url.
In your URL on the bridge, at the end, last character, you have an ā before the ending double quote.
{ācallbacksā: [{āidā: 1, āurlā: āhttp://10.10.10.43:8123/api/webhook/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJmYTE4Y2E5MTI4MjM0YTYxYmYyOWM3YTIzMWUwYjAwZSIsImlhdCI6MTYyMTg1Mjc2NywiZXhwIjoxOTM3MjEyNzY3fQ.1CT5pWEpccedcHVIBipUH8cPIL9heHu8NhfEEsmVcmcāā}]}
In the secrets.yaml variable webhook_id you donāt have that, it ends with Vcmc
Thatās why they donāt match.
Now, delete the entry on the bridge, and re-add it with this command, changing only YOUR_BRIDGE_IP and NUKI_TOKEN with your specific data.
curl -X GET -H āContent-Type: application/jsonā āhttp://YOUR_BRIDGE_IP:8080/callback/add?token=NUKI_TOKEN&url=http://10.10.10.43:8123/api/webhook/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJmYTE4Y2E5MTI4MjM0YTYxYmYyOWM3YTIzMWUwYjAwZSIsImlhdCI6MTYyMTg1Mjc2NywiZXhwIjoxOTM3MjEyNzY3fQ.1CT5pWEpccedcHVIBipUH8cPIL9heHu8NhfEEsmVcmcā
In secrets.yaml, donāt use double quotes, just put the token with no extra characters, like this (itās all in one line):
nuki_bridge_webhook: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJmYTE4Y2E5MTI4MjM0YTYxYmYyOWM3YTIzMWUwYjAwZSIsImlhdCI6MTYyMTg1Mjc2NywiZXhwIjoxOTM3MjEyNzY3fQ.1CT5pWEpccedcHVIBipUH8cPIL9heHu8NhfEEsmVcmc
Oh, man, they were so close I didnāt realize Iām trying and let you know
It happens, donāt worry, thatās why I told you to double-check the values.
Hi Friedrieck,
the availability function is not working, the sensor is always available, even when I restart HA and nothing exists, it shows me the door binary sensor as Closed, not grayed out as I expected, and with no attributes, as expected. As soon as I open the door everything initializes properly.
Did you notice the same behaviour? I have a template switch with the availability_template set to the same condition as with the trigger sensor, but it shows disabled, correctly.
I found a way.
The first sensor you see is a template switch, based on the second sensor (triggered template sensor).
So now you have two sensors: lock and door, both based on callback instead of polling, and the lock sensor is actionable, so you can lock/unlock. They react pretty fast.
I have to solve a small issue, then Iāll release the new version of the card: v3.0.
@alexdelprete
I tried to carry out what you said ā¦ and in fact, as I expected, I was the mistake.
your code works a marvel.
thank you !!!
ps: I saw that by the same method you can ācallā opening and closing, they would not be quicker than the current method?
Do you think youāll try and create something?
Indeed. I have tried changing the formula to test the attributes of the sensor instead of the trigger json, but to no avail, same behaviour.
It seems the trigger-based template keeps its status over the reboot and will reassess it only at the next trigger.
But to me, I eventually prefer this to having my door status unavailable until the next trigger (which may take time in some cases).
ps: I saw that by the same method you can ācallā opening and closing, they would not be quicker than the current method?
If I understood right, alexdelpreteās method is about to define a callback into HA that Nuki bridge uses when some event related to the Nuki smartlock raise (so Nuki bridge --callā> HA server). This method cannot be used to ācallā Nuki bridge from HA server to lock/unlock. The way to do that is to use the Nuki bridge API and it is what the Nuki integration is doing already.
PS. I think Nuki integration uses also the Nuki bridge API to check periodically new event. Since it is a periodical check, it is less responsive than the callback method.
Well, may be I am absolutely wrong 
Looks like a bug to me. It should work like per documentation. The problem is that the sensor looks available but its status is wrong until you trigger it the first time. Thatās why I prefer the status unavailable, and I guess thatās why the introduced the availability concept. Thanks for the feedback.
