[Feature] BLE Serial Communication

[jpcraft-jp]

Is your feature request related to a problem? Please describe.
Yes. Currently, Pybricks lacks native support for BLE Serial communication or a similarly flexible interface to communicate with external microcontrollers (e.g., ESP32) for more complex, multi-device setups like autonomous LEGO train systems. This limits the ability to integrate LEGO hubs into larger IoT or automation ecosystems efficiently. I often get frustrated because I have to build unreliable or complex workarounds to coordinate multiple hubs and peripherals.

Describe the solution you'd like
I want Pybricks firmware to support a standardized BLE Serial interface (or similar protocol) that exposes communication channels to send and receive commands/data in real-time. This would allow ESP32 or other microcontrollers to control motors, lights, and sensors on LEGO hubs via BLE, enabling advanced use cases like autonomous train control, remote monitoring, and integration into home automation platforms (e.g., Home Assistant). The solution should be robust, easy to use, and documented to facilitate both simple and complex projects.

Describe alternatives you've considered

Using IR communication with LEGO remotes, which is limited in bandwidth and functionality.

Using UART wired connections with custom hardware, but this is cumbersome and lacks official support.

Hacking or modifying firmware locally, which is possible but risky and not scalable.

Using BLE from scratch on ESP32, but no straightforward bridge exists with Pybricks hubs.

Additional context

I'm working on autonomous train setups requiring coordination of multiple hubs and sensors.

My goal is to build a system where hubs communicate seamlessly with ESP32 controllers over BLE.

Pybricks is great for basic control but falls short on networked multi-device communication.

A BLE Serial feature would massively improve Pybricks usability in DIY, robotics, and IoT contexts.

[dlech]

We used to use the Nordic UART Service (NUS) before we made a custom protocol for Pybricks. So technically, that is still there, IIRC, just not usable from MicroPython. We could take the stream classes I made in pybricks/pybricks-micropython#332 to make a wrapper around that to expose it in MicroPython. But we have found stream type connections aren't always the easiest to write robust programs for. On the other hand, NUS is very common and would be compatible with many devices without requiring custom programming on the other device.

As an alternative to the stream-type communication channel, we also have an undocumented AppData class in pybricks.tools that can be used to send state over BLE similar to how the broadcast/observe works but uses an actual BLE connection instead of advertising data.

[antonvh]

@jpcraft-jp I'd love to see this feature too, and I could maybe do a PR, but I would like to be on the same page with @laurensvalk and @dlech before starting the work. Here are my thoughts:

• Stream is indeed difficult. However, the nature of NUS is more like two registers, an RX and TX register, of fixed (MTU) size. This is considerably easier to handle than streams because it solves delimitation issues.
• The current broadcast protocol is problematic for desktops and smartphones to join, since they cannot pose as peripherals easily and manipulate advertising payload. I.e. they can only observe, not broadcast.
• I propose a fixed size RX and TX characteristic, say 32 bytes, and the hub advertising with it's hub name. Barebones and simple.
• TX characteristic has notify, so the central (phone/pc) knows there is data available can do a read.
• RX characteristic is read-once-full-buffer. So you get the content once and then zeroes until it is written again by the central.
• On the hub side I'm imagining something like this:

hub = PrimeHub()
my_bytes = hub.ble.nus.read() # 32-length bytes object like b"Hi there"+b"\x00"*25
if any(my_bytes):
     my_obj = eval(mybytes)
my_answer = b"Thanks!"
hub.ble.nus.write(my_answer) # pads or crops to 32 bytes and notifies central