aioble on PICO_W: getting notified of pairing failures. #14064
Replies: 1 comment 2 replies
-
@jimmo I am trying to get the status of a pairing attempt. I can get the status in the
I add the extra parameter at the end of the call. The method then looks as follows (also in
Note that I changed the size of args to be 6 instead of 5.
I don't think I need to do anything else in the C code. However I am not sure how to handle the python code in
Of course I tried just adding the status field but I get an error that it is undefined. If I do nothing I get an error that it is expecting 5 fields but it is getting more. Well that is a start. I am not sure why it is expecting 5 fields when I changed the underlying event to deliver 6. What steps am I missing? Cant get any logging either in spite of setting log level = 2 Thanks |
Beta Was this translation helpful? Give feedback.
-
Note: the PICO-W micropython uses the btstack.
I don't know what I am doing wrong, but when I invoke the pair method on the DeviceConnection object in aioble, the await returns successfully when the pairing succeeds, but if it fails, it does not return and I get no indication of the failure. I am not sure what I need to do to catch the error. Looking at the code I do not see any note about exceptions raised or a way to get a status field. It might be there, but I don't know how to access it.
The aioble code that invokes the pairing is
My application code simply does
The event being handled is the Encryption changed event. How do I trap the error? I do not catch it in the exception but here is the log from the btstack and support code:
This situation comes from a pulse oximeter that is paired with another client and the device sends a 'pairing not supported' message (misleading error message but that's what the spec says) and it clears its LTKs and it is then ready to connect again and repair. The problem is my client does not know the error occurs and the patient doesnt either and the device remains connected until it is detached from the patient. I need to trap that error and disconnect. This will cause the pulse oximeter to re-advertise and my client can reconnect, repair and do so successfully. The patient would have no idea that happened.
Outside of my particular use case, it is generally important for a client to know when a (bt) transaction fails.
Beta Was this translation helpful? Give feedback.
All reactions