Open kedars opened 1 year ago
An update here since it was discussed recently, a rough overview of my current strategy and timeline:
ble-peripheral
, a trait only crate that defines a complete set of GATT server APIs and the BLE peripheral definitions to support it. This should be sufficient for all BLE embedded use cases I'm aware of, for Matter or otherwise. Status: Working locally, RFC by Oct 9.bluer-ble-peripheral
, an impl crate combining the BlueZ Rust API (BlueR) with ble-peripheral
and a set of examples showing it in action. Status: Working locally, RFC by Oct 9.esp-idf-ble-peripheral
, an impl crate combining the current esp-idf-svc
BLE support with ble-peripheral
. Status: Early research, RFC by Oct 16.esp-idf-svc
support to include all necessary use cases to support ble-peripheral
. Apply fixes as necessary. Status: Early research, no code written, RFC by Oct 16.ble-peripheral
for rs-matter
. This will be a lot of work for sure but from the spec nothing seems too scary or hairy. The biggest issue will be if I have to do heavy refactoring of Matter to decouple transports; we'll see. Status: Reviewed Matter spec only, RFC by Oct 20.Obviously these dates are just wild guesses but so far the work is pretty straight forward and I'm quite familiar with BLE transport work. If someone wants to re-order and speed up (5) I'm supportive of that, I can just merge in my work after the fact to make the support generalized.
An alternative I considered as well was to just develop the traits within rs-matter
and have them only as fleshed out as Matter's BTP needs. I decided against this approach as it's still a huge amount of work given the scope of BTP and ends up with wayyyyyy less community value for embedded Rust.
Oh yeah, and it looks like someone is also squatting the ble-peripheral
crate name, sigh: https://crates.io/crates/ble-peripheral. I'll reach out to the author soon.
Actually, I've decided to swap the order of (3) & (4) with (5). I also have (1) and (2) ready for preview, so I'm moving on to implementing BTP directly in Matter now.
I'm making good progress on generic support for BTP, there's really not that much sophistication there other than some simple windowing implementation you need to do. There are, however, a few issues that need to be resolved before I can get a PR up:
ExchangeCtx
and use an Option<ReliableMessage>
based on the exchange flags?Matter.run
hardcodes the raw UDP transport backend (but it seems only this function, so bravo!). This means we'll need a breaking API change to provide some configuration of different transports. As I see it we have a couple of different options here: (a) keep the Matter.run
API more or less the same and expand NetworkStack to support plugging in abstract backend transports (UDP, BTP, etc) or (b) go the mdns route and require that the caller fire up separate runners for each transport, with the current Matter.run
really being run_udp
. I'm of the opinion that we should actually lean more into (a) than we do today and merge the mdns runner into a pure UDP transport backend and make it so Matter.run
is a declarative API where you set up everything you want to happen and just hit run and off you go. As it is now, simply forgetting to poll the mdns future means that you won't get mdns support. That said, I'm not married to any particular solution and definitely looking for feedback on the preferred approach.I don't think I'm quite ready to need answers to all of these questions, but just wanted to jot down my notes so as not to surprise anyone when PRs start coming in :)
I'm interested in trying to add this, but I'm thinking about starting from the beginning and introducing an
embedded-svc
-style set of traits for BLE first. I'd really rather avoid going the monolith strategy of a complete BT implementation that supports every platform directly (i.e. not like https://crates.io/crates/btleplug or https://crates.io/crates/rumble) as I don't think that will scale well for the diverse set of customers that rs-matter could one day have. I also have a non-goal of implementing BLE or choosing a specific strategy for its implementation. The caller should just be able to inject whichever library meets our contract (e.g. nimble for esp-idf or bluez for Linux, whatever).Thoughts?
EDIT: See https://github.com/rust-embedded/not-yet-awesome-embedded-rust/issues/29 for a potential discussion with the broader Rust embedded community