I am using the BLE API to directly connect an ESP32 to a Nuki lock.
When I execute multiple commands after each other and one of them fails I get an error report with an unknown error (00 12 00 ff 10 00).
I am not looking for the reason why the error occurred but I want to know why the next command is not picked up anymore and how to handle this.
After getting an error report I send a new command and I see the command being sent but I do not get any more messages back (also no error).
(And eventually I get a ble disconnected notification but I do not know when the disconnect actually happened or if it was due to the error or due to inactivity).
Does the lock close the connection on error? Is this standard behavior after every error?
So After an error I should always reconnect BLE or is there a better/different way to handle this?
Hi! This error looks like a MAC address, and Bluetooth and WLAN are using often a slightly other mac address, like the same it is with devices what have a LAN Port and WLAN antenna, then the LAN Port has a slightly other mac then the WLAN chip. Try to read out and use this address.
The error msg is correct, 00 12 means “error report” , 00 FF is “Unknown error”, 10 00 is the command (Openings Closings Summary) that was send which caused the error.
The Smart Lock is not closing the connection after sending an error report.
So you should be able to continue with the next command.
If you receive an error report make sure to also acknowledge the indication containing it.
In your case it seems your using a Smart Lock 2.0 or later but the command you’re executing (“Openings/Closings summary”) is only available on Smart Lock 1.0.
oke, I think acknowledging the indication is at BLE " transport" level, this is handled by the core software, I will try to find out but I think this is done.
I am implementing all the commands that are in the API 2.1 documentation, this does not list for which version lock a command is implemented.
Do you have an overview of which commands are not supported by the smartlock 2.0?
(maybe a good idea to add this to the api documentation…?)