Some of the boards do support BLE in UIflow, specifically Core2, Fire, and Tough show Blynk BLE and Nordic BLE UART services under the Advanced menu.

There doesn't appear to be general support for custom BLE services and characteristics in UIflow itself at the moment, but the micropython modules may still be present in firmware, I haven't looked yet. If so, you could potentially run them from an Execute block, or someone could make a custom block for common BLE services.

Whether it's intentional or a coincidence, the boards that show BLE support in UIflow all happen to have psram, so it's possible they did that to avoid crashes that would be hard for inexperienced users to diagnose.

On the other hand, UIflow doesn't show any BLE services for Atom psram and M5Stack paper, even though they both have psram, but that could be an oversight.

While not quite the same, on the Core 2, Tough and Fire boards you can use Advanced > BLE UART in UIFlow (or the equivalent Micropython/ Arduino/ESP-IDF/Zephyr code) to wirelessly send logs to any Nordic BLE UART terminal, including web NUS consoles like https://wiki.makerdiary.com/web-device-cli/

Just visit that page on a BLE enabled desktop using Chrome or Firefox and pair your device once it has BLE UART running. Even works to send commands back to the M5stack if you set up receiving in your esp32 app.

This happens sometimes when I have a UIFlow tab open already for lets say an M5StickC Plus, then open another UIFlow browser tab for a 2nd device like the Core 2.

Because I selected Core 2 in the new browser tab, somehow the device selected in the other browser tab changes to Core 2 as well, and it shows that error the first time I run the program on the M5StickC until I update the device type again in that first tab.

I have no idea why the UIFlow tabs aren't fully isolated.

@hwtaro9 I've never seen bala 2 work with the UIFlow blocks they provide (are those even for the Bala2 or just Bala?).

When I had a UIFlow program on mine I had to set the i2c registers in python code (in an execute block), which works but implementing a PID loop in there wasn't something I wanted to do.

It would be great to have official UIFlow blocks for that robot though, it's really nice hardware.

While not quite the same, on the Core 2, Tough and Fire boards you can use Advanced > BLE UART in UIFlow (or the equivalent Micropython/ Arduino/ESP-IDF/Zephyr code) to wirelessly send logs to any Nordic BLE UART terminal, including web NUS consoles like https://wiki.makerdiary.com/web-device-cli/

Just visit that page on a BLE enabled desktop using Chrome or Firefox and pair your device once it has BLE UART running. Even works to send commands back to the M5stack if you set up receiving in your esp32 app.

Some of the boards do support BLE in UIflow, specifically Core2, Fire, and Tough show Blynk BLE and Nordic BLE UART services under the Advanced menu.

There doesn't appear to be general support for custom BLE services and characteristics in UIflow itself at the moment, but the micropython modules may still be present in firmware, I haven't looked yet. If so, you could potentially run them from an Execute block, or someone could make a custom block for common BLE services.

Whether it's intentional or a coincidence, the boards that show BLE support in UIflow all happen to have psram, so it's possible they did that to avoid crashes that would be hard for inexperienced users to diagnose.

On the other hand, UIflow doesn't show any BLE services for Atom psram and M5Stack paper, even though they both have psram, but that could be an oversight.

@siva Old thread but yes, however I had to send commands to the bala2 manually as there is no module for it at the moment.

However I am seeing some odd problems with power, everything is fine when USB is connected but without it, eventually the combined grey+bala2 (or core2+bala2) gets in to a state where the power button cannot turn it on anymore until the controller is briefly removed and stacked on again. Once that is done it immediately can be turned on again. This doesn't seem to be a UIFlow issue though as ESP-IDF and Arduino sketches do the same thing.