Description
Last year I had developed some custom features for sending and receiving text data via ble using the Golioth_Basics template and the ble.c/ble.h files in the common folder of the examples. Although Golioth_basics was depreciated in newer versions I was still able to get the code working by copying everything over to the newer SDK. Now I whenever I upload new firmware the ble characteristics have mismatched/random UUIDs
Expected Behavior
UUIDs and read/write properties match the values set in the ble.c file
Actual Behavior
UUIDs are random and not updating when new firmware is uploaded. Read/Write properties of the characteristics do not update either.
Impact
Cannot update firmware of devices without breaking necessary ble features.
Environment
golioth-firmware-sdk v0.18.1
ESP-IDF v5.16 (cannot upgrade further due to unrelated library incompatibilities)
esp32-WROOM-32E Hardware
Logs and Console Output
characteristic that is set to have UUID: 7b145a1c-47b8-11ee-be56-0242ac120002 instead has 00303030-3a31-3a54-4553-3a30303030 (which is 0000:1:TEST:0000 in plaintext but I could not find that string anywhere in the SDK)
Attempts to Resolve
Searched through ble.c and ble.h files for possible causes. Tried to revert to older versions of firmware but issues persist on device after new firmware is uploaded to device even if old firmware is reuploaded.
Some screenshots for reference:
The code for setting UUIDs:
The actual characteristics on the device (as seen using nrfconnect):
@npschwab thanks for reaching out! I don’t suspect this behavior has anything to do with changes in the Golioth Firmware SDK, but I have seen this behavior occur when services are cached on the mobile device and not refreshed. Have you tried turning off Bluetooth on your mobile device, then turning it back on, then attempting to your BLE device again? If you still see stale data after doing so then I’d be happy to assist in investigating further.
Also, we had a timely announcement for Bluetooth support on Golioth this week. While it appears that you are mostly using this example for provisioning purposes, it may be worth exploring if our Bluetooth capabilities could simplify some of what you’re trying to accomplish.
So I am using these BLE characteristics for provisioning I am also using them for device control and monitoring while not connected to wifi, I may take a look at the new bluetooth support soon but right now I want to get this set of features working.
The caching refresh you mentioned did set me on the right path so I was able to solve the issue. Turning off bluetooth and even restarting the phone were not sufficient though. I would need to manually unpair the device in question in the bluetooth menu and then restart the phone in order to clear the cache and see the correct characteristic values.
Thanks.
1 Like
