some days ago (don’t know exactly) my Bridge updated to 2.4.10, and since then, I don’t get any callbacks anymore.
I’ve already rebooted and re-registered the callback (see screenshot), but don’t get any request in.
I tested, and lockActions are still working. Also lockState and all the Bridge API calls are working.
I also tested, that my callback routine is reachable from two clients in my network without authenication.
The Bridge data in the screenshot are directly queried from the Bridge via the server that is also the receiver of the callback.
Possibly, my callback url is not accepted (anymore)?
The query parameter in the URL is a unique identifier from us, so our implementation can query callbacks and identify that it’s own callback.
Currently I don’t know how to investigate further.
Could you give me any hint?
Christian
PS: A privacy/security question for screenshots - what IDs of Nuki and Bridge should I black out? What is safe, and what may be harmful?
It’s now 2.4.12 and it doesn’t show up any http request at all.
As the door was unlocked and locked today via the Bridge API several times, and I just tried it remotely with the Nuki App, something - at least an error - should have arrived at the Apache webserver. But there are no callback.php calls.
In the Bridge Log, I don’t see anything specific to callbacks, and I cannot upload a file here.
I have a
{“timestamp”: “2019-11-25T18:55:08+00:00”, “type”: “HTTP-Post”, “nukiId”: “xxxxxxx”},
I’m also not receiving callbacks anymore. There is a HTTP post in the logs but there are no callbacks logged on my side either. Seems like something is broken indeed.
indeed, in 2.4.13 the callback now is working again. Thanks for the fix.
I discovered another, new behaviour I hadn’t before:
Now, if I send a lockState API call, I directly receive the response with the current state.
It seems that the lockState request now also triggers a callback, that my callback script receives about 250ms after I received the response from the API request.
This seems to be new, and I’m not sure if this is by design now, or an issue, or possibly a new bug in my own implementation.
For a lockState request that queries the current status, a callback wouldn’t be necessary.
)