The sensor scan interval is used for the polling of non important attributes of the lock : firmware version, last activity, etc… The state of both lock and door is retrieved through callback so it is done immediately or a few seconds after the event. Shortening scan interval is only a workaround which hides the real problem.
I think you have an error with the configuration of the callbacks.
This implementation works like a charm.
I hope the official Nuki integration will implement parts of this logic too in the near future.
OK, I didn’t know that, I thought scan interval was for both sensors (lock and door status).
Any suggestions where to look for errors…
I checked:
There are some steps and requirements others than to copy&paste nuki_card_callback.yaml. You could check them also with the very complete description made by alexdelpetre in the first post of this thread.
I did that too. Curl is working, I get the data from nuki bridge…
Hi Andrej,
You are not getting callback data from the bridge, otherwise you would see immediate status changes. The official integration takes 150 secs, this integration was created exactly to improve the status feedback and to have info of all the system’s sensors available.
From your posts, I can understand you didn’t read the first post, because you asked if you could remove the official integration and if this integration used the cloud.
I’m not even sure you installed it correctly, probably not, that’s why you are not seeing immediate updates (8-10 secs.).
Please read carefully the first post, understand how the integration works, implement it, then give us a feedback about any issues. Many users have installed it and it’s working fine. If it doesn’t work for you it’s something you are doing wrong. This integration works via http, not via bluetooth, so you are not comparing apples with apples.
I suspect you are also confusing the official integration sensor with the sensors created by this integration.
Uninstall everything, official integration too, and just install this, otherwise it will be harder to troubleshoot your issues.
You are receiving POLLING data from the bridge, not the callbacks. This integration, like I have described in first post, which you didn’t bother to read, is based on POLLING sensors for info regarding the system status, and from a triggered sensor based on a callback from the bridge. You didn’t configure the callback correctly, that’s why status changes of door and lock will be updated only by polling (every 150secs), so slowly, like the official integration.
Install and configure the integration correctly, spend 10mins of your time reading the first post.
The timing for every status change is always the same, more or less, 8-10 secs, if configured correcly. It doesn’t matter if the action is lock/unlock.
No, you didn’t figure it out, because you don’t yet understand how it works. The lock/door status is updated via callback by the bridge (triggered mode) AND by the state of the http rest sensors (polling mode). That’s why it’s way faster than the official integration. If it takes more than 10 secs, you are not receiving the callback. Check your logs, and you will see errors regarding a webhook, because you didn’t configure the necessary secrets or the callback on the bridge, like instructed in first post. So either the bridge is calling HA via webhook, but HA is ignoring it, or the bridge is not even configured to callback.
Read the first post carefully.
Thanks @alexdelprete for all your efforts and thank you for all your careful reading of my posts. I hope I didn’t irritate you with my posts, please excuse me if I did.
Actually I did all the readings, your first post cuple of times including post you mentioned to set up webhook. I tried to understand everything but I’m a lawyer not an engineer of any kind, I’m also quite new to HA (since fall last year) so for me was this project very new to me, apart from configs and automations it was my first to to hear about webhook and similar logic. Rome wasn’t build in a day and also I can’t learn everything in few days, that’s why I’m looking in different directions to get information as many as possible can.
Thanks again for your time and help, I’ll get back to you when I manage to “hook” everything up!
Kind regards.
Hello, I’m in the same situation except i’m an hardware electronic engineer and it’s not easy for me too.
If someone can write a tutorial for dummies that would be so perfect ! I will buy him a beer
Reading the posts of people who need help is a matter of respect for me, because I can imagine how hard it can be to make these things work for non tech people. I’m sorry if I sounded rude, it was not my intention, it’s just that I had the feeling you were one of those who didn’t bother to read much and just configured things trying to make it work, then complain about it not working, while the problem is just not devoting enough time to the task and ask for help by providing information (logs, etc.) instead of changing the code (I hope you didn’t think I used 150secs for REST sensors because I’m a masochist 
).
Anyway, I didn’t mean to disrespect you in any way, I just advise anyone to first read the post, and possibly the thread, because many of the questions made by users who had the same issues have already been answered (maybe an FGA is needed?).
In any case, I really appreciate your last post very much, and I’m here to help you in any possible way, even though I think that last version of the integration is easy also for beginners, you just need to pay attention to the installation steps, and not skip any of them.
I hope you manage to make it work, otherwise feel free to write here and I (and other friends here) will do my best to help, but you need to help us help you by making sure you followed the installation steps to the letter, and verify each step before proceeding to the next one. I’m sure you will make it work…
Ciao,
Alessandro
Hi Nathan,
I don’t think I’m able to make the first post easier to follow. Can you be more specific and tell me which step is not clear? I can always improve it with your help, but I need detailed information about what you don’t understand or find difficult to understand.
Sorry to read it’s so difficult, it’s really surprising for me. If this packaged version is difficult, the previous version would be considered a mission to Mars.
I just want to check if the callback is registred correctly and if I put this line in:
➜ /config curl -X GET -H "Content-Type: application/json" 'http://192.168.31.248:8080/callback/list?token=****59eea'
I get response (don’t mind the token - is modified
{"callbacks": [{"id": 0, "url": "http://homeassistant.local:8123/api/webhook/eyJ0eXAi***************JhbGciOiJIUzI1NiJ9.eyJpc3MiOiI5NWY4ODFhOGQxNjc0MTM3YTFjMjI4ZDI2ZWU5OWI2MyIsIml+++++++++++++OTgwOSwiZXhwIjoxOTQxNTU5ODA5fQ.4NZikzRobBziJ************1QmW1xDMAanVxUepJ5Y"}]}#
Is it OK?
Yes, that’s okay.
Yes, make sure that homeassistant.local is resolvable by the bridge. If you are in doubt, use the IP of your HA.
Then check the logs of HA: if the webhook is not correctly defined in HA, you will see error msgs in the log.
Thank you both for feedback. In the mean time I double checked registration and changed address to IP as advised by @alexdelprete. In HA logs didn’t find any entries on webhook, nuki, lock, unlock, endpoint. I found only this:
Logger: homeassistant.components.automation.nuki_card_callback
Source: helpers/script.py:1344
Integration: Avtomatizacija (documentation, issues)
First occurred: 12:54:57 (2 occurrences)
Last logged: 12:57:27
Nuki Card Callback: Already running
The time for lock/unlock state is still 2 mins and some sec. But I noticed the binary sensor for door state binary_sensor.nuki_door_state is very fast 3-8 sec.
Are there any changes to be made in nuki_card_callback.yaml file, f.i. tokens, addresses anything?
The lock state is derived from an attribute of the binary_sensor, so if the binary_sensor is updated very fast like you say, the lock state is updated very fast too.
This is the code of the lock, check how the state is defined:
lock:
- platform: template
name: "Nuki Lock Action"
unique_id: nuki_lock_action
value_template: >
{{ is_state_attr('binary_sensor.nuki_door_state', 'lock_state', 'locked') }}
availability_template: >
{{ is_state_attr('binary_sensor.nuki_door_state', 'lock_state', 'locked') or
is_state_attr('binary_sensor.nuki_door_state', 'lock_state', 'unlocked')}}
lock:
service: rest_command.nuki_lock_action
data:
action: 2
unlock:
service: rest_command.nuki_lock_action
data:
action: 1
I bet you are looking at the official integration lock on the card, not this integration’s lock. Please UNINSTALL the official integration and remove everything regarding it from lovelace cards. Then apply the lovelace code shown in the first post.
OMG 
your were right! Although I uninstalled official integration yesterday I had sensors from it in card. I’m so sorry 
and also grateful to you for your help!
What a mess I made with official sensors…
Thank you!!! 
No problem, I already wrote you yesterday that you made a mess mixing the integrations.
Glad it’s working fine for you now.