If you read the post above yours, you’ll see that I already created something, I’ll publish it as soon as I solved a small isue about the availability of the sensor. 
A little bit of patience…
1 Like
What we’re doing is switching from polling the Bridge to using the Bridge callback, at least for the door and lock sensor. For the rest of the info we have to poll, but with long polling times, so it’s not an issue. One can also decide to not implement the polling to get the rest of the info and only implement the lock sensor and the door sensor.
BTW: there’s a PR in which they are discussing exactly that, so the integration should leverage callbacks instead of polling, and it can also automagically create the webhook and add it to the bridge without user intervention. We’ve done it like they’re discussing, but it requires manual user configuration.
It would be nice !
However it should be an option of the Nuki integration to stick with a polling method since callback method implies to set a proxy-reverse to provide both http and https access.
I thought about it, but it’s less flexible than the switch, there’s no icon_template support. The only added feature is the optimistic mode functionality, but I don’t like it. I’ll stay on the switch, but thanks for the suggestion.
Yes there is a discussion on al these things in the PR here: https://github.com/home-assistant/core/pull/44310
The new version of the integration will have both polling and callbacks, without requiring any user configuration. 
1 Like
Yes, I just saw that reading the PR. Thanks.
Nuki Card v3.0 completed.
Let me know if it works for you.
May be I made something wrong but I get it on the UI:
(I lock/unlock the door after to re-start HA as requested)
That is the binary_sensor in templates.yaml. Same as v2.0, if that worked before, it should work now, nothing changed on that one.
Double-check secrets.yaml, make sure there’s the webhook. And check templates.yaml.
Also check HA logs for errors…
Well, I double-checked with a diff tool and I found nothing “wrong”.
But if I try to evaluate value_template and availability_template of nuki_lock switch in Developer Tool
"{{ is_state_attr('binary_sensor.nuki_door_status', 'lock_state', 'locked') }}"
"{{ state_attr('binary_sensor.nuki_door_status', 'lock_state') != None }}"
I get false for both, whatever the value of lock_state. I have to use sensor instead of binary_sensor to get the right value.
It seems indeed that the nuki_door_status is defined as a sensor in your templates.yaml, not as a binary_sensor:
- trigger: - platform: webhook webhook_id: !secret nuki_bridge_webhook sensor: - name: "Nuki Door Status" [...]
It was also a sensor in templates.yaml v2.
I’m sorry, when I cut&pasted in the post, something happened, and I made a mistake for templates.yaml.
Recheck the post, I updated the templates.yaml section. The door sensor should be a binary_sensor.
You are right, I made a mistake when I edited the post. Now it should be fixed.
Yes, the problem was that I had an intermediate version between v2 and v3, so in my mind nothing had changed in templates.yaml.
I’m sorry.
No problem ! I am grateful for the work you are doing.
Anyway, replacing binary_sensor by sensor runs ok (except a bad cosmetic behavior I describe below).
In the meantime, I tried with a lock instead of a switch (without optimistic mode). I found that the behavior is better this way because when you set the switch - let say off to on - it goes to on representation and back to off until door_status is updated by the callback to locked. But may be it is because I replaced binary_sensor by sensor ? With a lock, the representation stays off until door_status is updated by the callback to locked.
By the way, what is the difference in this case between using sensor or binary_sensor ? In others words, why you changed it between v2 and v3 ?
I already received that suggestion by @Friedrieck and I answered but I found it less flexible in terms of customization. But if you say it works better I can test it again. I’ll let you know.
It’s a matter of taste but I prefer a big button to lock/unlock because I find it easier to use with a smartphone. So, to not be able to customize it is not a problem for me in this case.
Because I couldn’t set device_class: door otherwise.