toes-matter/README.md
2026-05-17 22:01:34 -07:00

58 lines
1.8 KiB
Markdown

# toes-matter
Tiny facade around `rs-matter` for the Toes RGB light flow:
```rust
#![recursion_limit = "256"]
fn main() -> toes_matter::Result<()> {
env_logger::init_from_env(
env_logger::Env::default().filter_or(env_logger::DEFAULT_FILTER_ENV, "info"),
);
futures_lite::future::block_on(async {
toes_matter::generate_credentials("./creds").await?;
toes_matter::provision().await?;
toes_matter::listen().await
})
}
```
## Runtime assumptions
- Linux + BlueZ on system D-Bus
- `wpa_supplicant` controlling the Wi-Fi interface
- `wpa_cli`, `ip`, and a DHCP client available
- `rgbled` in `$PATH`
- Avahi/zeroconf for mDNS
## Environment
- `TOES_MATTER_CREDS_DIR` / `MATTER_CREDS_DIR` default: `./creds`
- `TOES_MATTER_STATE_DIR` / `MATTER_KV_DIR` default: `<creds>/state`
- `TOES_MATTER_WIFI_IFACE` / `MATTER_WIFI_IFACE` default: `wlan0`
- `RGBLED_ORDER` default: `grb`
## Development credentials
`generate_credentials()` writes rs-matter's built-in development/test DAC/PAI/CD plus setup QR/manual-code metadata. It creates a random setup passcode/discriminator the first time and reuses an existing `setup.txt` on later runs. These credentials are for local development, not production.
## Post-flash headless provisioning
After flashing a Linux device reachable over SSH:
```bash
toes-matter/scripts/provision-device.sh user@device-host device-001
```
The script generates `manufacturing/device-001/creds`, prints the manual code / QR payload, renders a terminal QR if `qrencode` is installed, copies the creds to `/var/lib/toes-matter/creds`, and restarts `toes-matter.service` if present.
Set these if your service uses different paths:
```bash
REMOTE_CREDS_DIR=/var/lib/my-app/creds \
REMOTE_STATE_DIR=/var/lib/my-app/state \
SERVICE=my-app.service \
toes-matter/scripts/provision-device.sh user@device-host device-001
```