I’m trying to figure out why controlling the Nuki lock through the bridge from Node Red does not work reliably. I’m using the current version of the node-red-contrib-nuki module, which is using the current version of nuki-bridge-api NPM.
Lock and bridge firmware are up to date (I believe), Lock is at 2.10.8, Bridge is at 2.9.3. The bridge is not too far from the lock, but also not right next to it, when I go into the Bridge admin UI it says Bluetooth signal is very good though.
Problem: In about 10-20% of tests, requesting lock status from the bridge does not return a result. The response to a request “GET /lockState?nukiId=…” is an HTTP code 200 with data: {“success”: false}
That breaks the nuki api module handling of the request because it doesn’t know how to handle that.
Looking at the log of the bridge and comparing one request that worked and one that didn’t I see some differences: (Reverse chronological order, lines with a “*” only show up in failed requests.)
BLE-Disconnected
BLE-Disconnect
BLE-ConnectionTimeout
*HTTP-Post
BLE-ReadStates
*BLE-Retry
*BLE-TurnOnNotific
*BLE-Connected
*BLE-Connect
*BLE-Connect
*BLE-EarlyDisconnect
BLE-TurnOnNotific
BLE-Connected
BLE-Connect
BLE-Connect
HTTP-LockState
This looks to me like something about the BLE connection between bridge and lock went wrong at first and the bridge retried it. But instead of reporting the result of the retry to the client, it just reported failure to the client and instead did an HTTP-POST - but where to? I ran a tcpdump on my node red machine and did not see any incoming HTTP connections from the bridge after it closed the original connection when it reported the success:false data.
Is this a bug in the bridge, or do clients need to apply some extra steps to retry in this case?
Thanks,
Karsten