Comments (5)
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:
- Message Reliability Protocol (MRP) looks a bit too cozy in Exchange and may need to be abstracted. What's unclear to me is whether MRP is actually meant to be a supportable feature for all transports, given that it's explicitly part of the exchange flags. As in, if I wanted to, could I get the MRP protocol support engaged over TCP? If that's the case, the only change we might need is to just modify
ExchangeCtx
and use anOption<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 theMatter.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 currentMatter.run
really beingrun_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 soMatter.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.- Commissioning seems a bit hardcoded to an IP-based transport (e.g. pake.rs talks about mdns directly). We might want to think about this in terms of (2) making for a more robust notion of transport roles not just sending/receiving raw packets. We might also need a global commissioning state machine that has an affinity to a particular transport but is otherwise agnostic. For example, you might want to say that commissioning should only occur at a given time over either BLE or UDP, never both at once. But UDP can be used as a fallback if BLE isn't available.
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 :)
from rs-matter.
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 rust-embedded/not-yet-awesome-embedded-rust#29 for a potential discussion with the broader Rust embedded community
from rs-matter.
An update here since it was discussed recently, a rough overview of my current strategy and timeline:
- Develop
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. - Develop
bluer-ble-peripheral
, an impl crate combining the BlueZ Rust API (BlueR) withble-peripheral
and a set of examples showing it in action. Status: Working locally, RFC by Oct 9. - Develop PoC
esp-idf-ble-peripheral
, an impl crate combining the currentesp-idf-svc
BLE support withble-peripheral
. Status: Early research, RFC by Oct 16. - Extend
esp-idf-svc
support to include all necessary use cases to supportble-peripheral
. Apply fixes as necessary. Status: Early research, no code written, RFC by Oct 16. - Implement BTP protocol using
ble-peripheral
forrs-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.
from rs-matter.
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.
from rs-matter.
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.
from rs-matter.
Related Issues (20)
- IPv6-specific "Host is unreachable" error that exits the matter runtime HOT 10
- How to actually implement an LED light in onff_light example? HOT 2
- Error when trying to add device to Google Home HOT 11
- Logging updates to improve debugging: adding cluster path information
- Error: environment variable not found HOT 14
- Provisioning with Amazon Alexa fails with Invalid Cert error during the Case 3 step HOT 2
- Meeting, 2023-10-06 HOT 2
- Support dimmable and colored lights
- Planned support for zigbee? HOT 4
- ESP-IDF build instructions HOT 2
- Commissioning with Google Home fails at the end with "device not found" HOT 1
- Explain how to install/Link the `chip-tool` in readme
- [BUG] Light On Off Example Crashing [M1][no_std] HOT 2
- Cannot run example onoff_light in the no_std branch HOT 7
- Provide decent error message for wrapped errors HOT 7
- Update README.md with info that Avahi daemon and Chrome on Linux should be stopped HOT 14
- [BUG] Unable to commission with Apple Home HOT 18
- Add `cargo fmt --check` and `cargo clippy` as part of the CI
- Update syn crate version 1 to 2 HOT 1
- Can't establish CASE, rs-matter unable to verify ICAC certificate that's missing subject key ID extension HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rs-matter.