[Feature] Reintroduce pybricks.messaging module

[laurensvalk]

We are starting to have various i/o methods now. This is very exciting, but they are a bit all over the place at the moment. In Pybricks 2.0, we used to have the pybricks.messaging module, so I've been wondering if it makes sense to collect messaging related classes or streams here.

These are the ones I could think of so far:

pybricks.messaging

• BluetoothMailboxServer() (exists since 2.0, needs reimplementation on EV3)
• BluetoothMailboxClient() (exists since 2.0, needs reimplementation on EV3)
• Radio(): (exists since 3.X, currently pre-instantiated at hub.ble)
• AppData(): exists since 3.X, currently in pybricks.tools
• bleio: maybe, see USB stdio pybricks-micropython#332
• usbio: maybe, see USB stdio pybricks-micropython#332

I've not really been a fan of having the instance of the broadcasting class at hub.ble. But as it was the only messaging tool we had, it was reasonable at the time to avoid adding another module. But as we are adding more, we can re-evaluate it. By having it separate, we don't have to have all its init arguments copied on all hubs. Since it can also run on and work with non-Pybricks boards, a consistent class would be nice too.

[dlech]

I would just stick with AppData() and see how far we get. Also, not a fan of more modules, we already have way too many (kind of necessary for organization though).

[laurensvalk]

This is an existing module, so we'll have to have it in our documentation, api, etc. So we might as well use it to collect all communication-related classes instead of having them in three places.

If we're going to re-structure things (while preserving backwards compatibility), the 4.0 release is probably a good time to do it.

See https://pybricks.com/ev3-micropython/messaging.html

[laurensvalk]

This has come up in pybricks/pybricks-micropython#405, concerning serial Bluetooth classic connections. Fully-fledged async streams may be more trouble than it is worth, but I think we can come a long way by letting connections return objects with the same interface as a UARTDevice to keep things consistent and async compatible.

We could do something like this:

from pybricks.messaging import rfcomm_listen

# Wait for incoming connection
dev = rfcomm_listen(optional_name_or_address)

data = dev.read(10)

dev.write(b"abc")

and on the other hub:

from pybricks.messaging import rfcomm_connect

# Initiate connection
dev = rfcomm_connect(optional_name_or_address)

data = dev.read(10)

dev.write(b"abc")

We can also have a rfcomm_scan for users that want to discover devices dynamically. All methods here would also support async.

If we need to do any initialization or just want to keep it organized, we could group the methods as a RFCOMM or BluetoothSerial class. Then bluetooth = BluetoothSerial() and dev = bluetooth.listen() but still work the same as above.

---

This could work on EV3 as well as SPIKE. On NXT, we would just raise if the user attempts too many listen or tries to both listen and connect since it can't do that.

---

We can use the very same pattern to enable Nordic UART service on BLE hubs which is requested in #2281. So dev = ble_serial_connect(...) or if we pick the class variant above: nus = BLESerial() and dev = nus.connect(...).

---

What I like about this approach is that we wouldn't enforce users to choose being a client or server, or set up multiple, but treat it as an implementation detail. Since communications are bidirectional, this was always very confusing to me as a newcomer many years ago. And then it got even more confusing if you throw in central and peripheral terminology.

With the approach above, the user instead thinks in terms of initiating or accepting connections, which works for both classic and ble.