BLE GATT read failing until I edit the flow but change nothing

16 views
Skip to first unread message

Marnick “Marnes” L'Eau

unread,
Oct 21, 2025, 4:43:34 PMOct 21
to Automate for Android
Hi, I've been meaning to post an apparent bug I've reproduced over and over. It has to do with GATT read, I know it's experimental on android, but the read actually works eventually.

Attached is a screen recording. I have an esp32 constantly emitting a value, its service and characteristic uuid are hardcoded, the value itself is updated every second, there's no other signal consumer hogging the connection.

Every time I take a reading, the shortcut to the flow instantly fails (NO from the GATT block). Starting the flow from inside the gui has the same result.

If I then just go into the flow, edit the GATT block, select the device with the same 2 uuids again (i.e. changing nothing), and save the flow, then suddenly it works... until next month when I have to do the same thing again, changing nothing but just saving the flow again.

I'm kinda puzzled tbh, it's like an initialization issue. Does the GATT read block not init the bluetooth stack while the device picker does, or something like that?
Screen_Recording_20251021_221816_Automate.mp4

norman bond

unread,
Oct 21, 2025, 4:50:36 PMOct 21
to Automate for Android
Probably not related, but i have a similar problem with Termux plugin, I have to resave the block every month.

Henrik "The Developer" Lindqvist

unread,
Oct 22, 2025, 9:47:38 AMOct 22
to Automate for Android
The BT stack on Android is a broken mess.
The problem you describe is likely due to some internal Android caching issue, caching of BT devices and/or their advertised services, that an "discovery" clears/reset, i.e. what the picker does.
You might try doing an Bluetooth device scan when your flow can't find the device as it expects.
Also ensure the the devices are paired, otherwise Android will randomize the MAC addresses causing an device to not be found.
To avoid missing value changes the Bluetooth GATT read block will not "unregister" if the fiber returns to such a block within one second, otherwise it will "unregister" from the Android API then "register/initialize" again whenever the fiber executes such a block again.

Marnick “Marnes” L'Eau

unread,
Oct 22, 2025, 3:05:58 PMOct 22
to Automate for Android
Well the mac hasn't changed once either. I'll try adding a scan to the process. Thanks for the insights and advice 💪
Reply all
Reply to author
Forward
0 new messages