Ok, I’ll tell users that I can’t do much in the code to improve that delay, and they’ll have to live with that. They’re used to fast response times for the door-sensor and lock too.
An OT question: I have a user which has an old hw v1 bridge, and he had problems with the integration, after debugging the issue, I discovered that the /info endpoint didn’t contain the expected data, the scanResults element is empty. Is that an issue of v1 bridge? Is there a way from the bridge API to know if a bridge is v1 or v2?
No, not a known issue. But the hardware of the v1 bridge is not capable of several concurrent BLE connections. Overstressing the BLE part or even the bridge itself (e.g. by polling the API every second) might lead to such symptoms.
Thanks Juergen, I’ll suggest the user to get a v2 bridge.
Regarding the opener, I read in the Bridge API docs this, regarding ringactionState:
When someone rings, the ringactionState turns on and a callback is sent. After 30s, it resets, but is a callback triggered or not? Because it seems it doesn’t, so my integration is not aligned with the opener internal state.
Keeping the state for 30s is intended for integrations that use polling in order to allow them to detect a ring. If you work with callbacks you can just use the callback as „ring“ and ignore the state change altogether.
I use callbacks to trigger the polling, since the callbacks don’t contain all the relevant info on the Nuki state. So everytime I receive a callback I update all sensors of all Nuki devices via /list and /info. I have a Feature Request open to have the callbacks send all needed info, so polling via /list and /info would not be needed.
Regarding ringactionState, the users are telling me that after it turns on, it never turns off, because no other callback is received for ringactionState=off event. I wanted to know if this is by design, or I actually should receive a callback when ringactionState goes off after 30 secs.
Is there a way for me (I have an opener not connected, only for developement) to simulate the ringaction so I can do tests? Pressing the button on the opener only locks/unlocks.
Hi @Juergen, I’d like to release the official version of my integration with Opener support, but I have this last problem to solve, can I have your feedback please? Thank you very much.
I was thinking to force the ringactionState to false after 30s it has been turned on, but it’s not really elegant…
By design. As i told you above you can reset the Ring state back to 0 immediately after you received the call back. You can also reset it after 30s though. Whatever fits best to your integration.
a user of my integration reported that when Suppress Ring is enabled, and someone rings, the bridge doesn’t send any callback. If he disables Suppress Ring, callbacks for ring are received correctly.
So if wired correctly, suppression works as it should, if not, the fact that callbacks weren’t been received was because the opener didn’t even detect the ring, right?
