Sometimes I get an unsuccessful lockAction response (success = false)…
…directly after sending the lockAction request (with nowait=0)
…without Error
…even if the lockAction was executed successfuly!
I am also getting the callback fired trough this"unsuccessful" request.
Can anybody help me?
Sounds like you are sending requests twice. Make sure that you do not use a browser to issue the request but a command line tool like curl.
Thank you.
I am already using curl.
The request ist sent only once (I have implemented logging in the background)
In this case the next step is to have a look at the /log output of the bridge, which contains detailed information on whats going on.
Here is a log-extract of such operation…
{“timestamp”: “2022-07-05T22:32:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Retry”, “pairIndex”: 0, “count”: 1},
{“timestamp”: “2022-07-05T22:32:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-05T22:32:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “type”: “BLE-EarlyDisconnect”, “nukiId”: “2E01FB6C”},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-05T22:32:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “HTTP-LockActionStart”, “action”: “lock”},
This sample does not seem long enough to cover the full lock action.
Requests done:
|11.07.2022 14:14:39|exec.php|Requesting|http://172.24.0.17:8080/lock?token=xxx&nukiId=771881836&deviceType=4|
|11.07.2022 14:14:39|exec.php|lockaction|— no success!!! —|
|11.07.2022 14:14:39|exec.php|Requesting|http://172.24.0.17:8080/list?token=xxx|
|11.07.2022 14:14:40|exec.php|Requesting|http://172.24.0.17:8080/callback/list?token=xxx|
|11.07.2022 14:14:52|oncallback.php|Callback|locked|
log-extract regarding those requests…
{“timestamp”: “2022-07-11T12:15:12+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Disconnected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:12+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Disconnect”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:12+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-ConnectionTimeout”},
{“timestamp”: “2022-07-11T12:15:07+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:07+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 205},
{“timestamp”: “2022-07-11T12:15:07+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 273},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 96},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 245},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 56},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 237},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 56},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “type”: “SSE-KeyturnerEventResp”},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “type”: “HTTP-Post”, “nukiId”: “2E01FB6C”},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “SSE-KeyturnerEventReq”},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-ReadStates”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Retry”, “pairIndex”: 0, “count”: 2},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:06+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “type”: “BLE-EarlyDisconnect”, “nukiId”: “2E01FB6C”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Retry”, “pairIndex”: 0, “count”: 1},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “type”: “BLE-EarlyDisconnect”, “nukiId”: “2E01FB6C”},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:05+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-StateChanged”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Disconnected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Disconnect”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:15:04+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-ConnectionTimeout”},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-SendLockAction”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-GetChallenge”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “type”: “HTTP-List”},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Retry”, “pairIndex”: 0, “count”: 1},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:54+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “type”: “BLE-EarlyDisconnect”, “nukiId”: “2E01FB6C”},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D27201FB6C”},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2022-07-11T12:14:53+00:00”, “nukiId”: “2E01FB6C”, “type”: “HTTP-SimpleLockStart”},
The log shows that the Smart Lock does not send the complete state of the lock command and therefore the BLE connection is dropped after 10s. You also have BLE disconnects and retries in your log. Maybe the bridge is positioned too far away from the Smart Lock.
You do also send requests in parallel. There is a /list sent while the lock action is still in progress. This might also be the reason for problems. As i told you in another thread, you should serialize requests to the bridge and do not send parallel or duplicated requests.
I am sending all requests serialized.
After the lock-command the api directly returns with an empty “success” response.
In the meanwhile, the lockaction ist performed successfully by the smartlock.
(BTW: Thats exactly the content of this thread)
Directly after receiving this reply, /list is sent.
(this is just a workaournd in the moment to get the state!)
Main Question still remains: Why do I get a negative reply (directly after sending the command), even lockAction was performed successfully?
This behaviour is independent of the positioning of the bridge (1m - 5m)
Ok, we found out that the problem is the BLE retry that happens before the lock command is sent to the Smart Lock. This leads to a (too early generated) “false” response on the HTTP-API while the bridge still retries and executes the command.
We have recorded it as a bug and will try to fix it in one of the upcoming releases.
Placing the bridge closer to the Smart Lock should reduce the frequency of this case to happen.
Could this be related as I do a retry in my plugin on a false or error response?
And details are here from another user:
Yes. Please let your users check if they are included on this list:
Smart Locks that are affected by the service program have a much worse BLE reach which makes retries and connection problems much more likelier than usual.
I am using Nuki 2. Can this still be the same issue with the success: false?
In theory yes, if you have BLE retries in /log