Opener "Ring Action" is not reliably transmitted

[TheCyberfreak]

My goal is to receive a notification via HomeAssistant when the doorbell rings, which I can then use to open the front door. This has always worked smoothly for quite a while. For some time now, this no longer works reliably but only sporadically.

My HomeAssistant is up to date, as is the nuki_ng extension. In the web log I also see that the opener registers the ringing, but not in HomeAssistant. I also noticed that often the entity "ring action" is not available. However, usually only for a few seconds to a few minutes.

I don't know what other information would be useful for further analysis, but if needed I can provide everything.

[kvj]

what's your setup? do you have/use bridge? is web hook set correctly?

[TheCyberfreak]

I have a bridge and use the WebAPI, all other functions do not cause any problems either. I can operate the lock and the opener. I notice at least that in any case the status of ringing is not transmitted reliably.

[kvj]

Web API won't help you here, as it's a polling.

If you expect (near) real-time status updates, that should go through the bridge. If you have configured everything correctly, that should reliably work.

You can enable debug logs for the custom_components.nuki_ng logger as described here: https://www.home-assistant.io/integrations/logger/

and then look for lines containing: _hook_handler: to check how reliably bridge emits status updates via web hooks

[TheCyberfreak]

So, I've been experimenting a bit the past few days. My assumption was that the bridge pushes the ring status to HA. This does not seem to be the case. I reconfigured everything and set the interval of the status request to 10s. Since then the ringing works reliably again. It's just a pity that it can take up to 10 seconds that I notice that someone has rung.

[kvj]

Do you receive anything via the web hook? Does the web hook work for you?

[TheCyberfreak]

I looked at the logs as described above _hook_handler: was nowhere to be seen there. Only the callbaks, as configured every 10s. Where do I have to look for the correct configuration?

[kvj]

Do you see other debug messages from nuki_ng?

Regarding the web hook setup, start by checking the following entity as on screenshot. it should be ON, and the URL in the attributes section should look correct

[TheCyberfreak]

Yes, for me the callback link is correct and everything looks like yours.

The log says the same thing every 10 seconds:

2022-08-29 11:21:23.071 DEBUG (MainThread) [custom_components.nuki_ng.nuki] bridge_check_callback: {'callbacks': [{'id': 0, 'url': 'http://10.1.5.3:8123/api/webhook/nuki_ng_bridge_hook_fe08ccc1e06075bb29011619b2d312b3'}]}, http://10.1.5.3:8123/api/webhook/nuki_ng_bridge_hook_fe08ccc1e06075bb29011619b2d312b3
2022-08-29 11:21:23.071 DEBUG (MainThread) [custom_components.nuki_ng.nuki] Callback is set
2022-08-29 11:21:24.493 DEBUG (MainThread) [custom_components.nuki_ng.nuki] _update: ......
2022-08-29 11:21:24.493 DEBUG (MainThread) [custom_components.nuki_ng.nuki] Finished fetching nuki_ng data in 1.493 seconds (success: True)

I do not see any other entries in the log.

[kvj]

@alexdelprete Hey, I know you own an opener, does the web hook work for you? Do you receive any update from opener via the hook?

[kvj]

@TheCyberfreak just to test that URL is accessible, you can call smth. like the following from the command line:

curl -X POST -d '{"test": "json"}' "<your callback URL>" and then you your log you should see smth. like:

2022-08-29 11:48:34.068 DEBUG (MainThread) [custom_components.nuki_ng.nuki] _hook_handler: {'test': 'json'}

[TheCyberfreak]

The test was successful in the log! 2022-08-29 11:58:07.733 DEBUG (MainThread) [custom_components.nuki_ng.nuki] _hook_handler: {'test': 'json'}

[TheCyberfreak]

I have now observed the whole issue even further. The ringing is not passed on as a push, with the detour to query the status every 10 seconds it works to some extent, but leads to the fact that you realize the ringing sometimes only after 10 seconds.

[kvj]

anyway we need a confirmation from some other Opener owners that "ring action" triggers the webhook. if yes - than it's configuration/integration bug, if not - bridge limitation