toes-matter

Tiny facade around rs-matter for the Toes RGB light flow:

#![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, run the host-side credentials command from Linux or macOS:

cargo run --no-default-features --manifest-path ~/apps/toes-matter/Cargo.toml --bin toes-matter-credentials -- \
  user@device-host device-001

It 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, creates /var/lib/toes-matter/state, and restarts toes-matter.service if present.

The older script is now just a wrapper around that command:

~/apps/toes-matter/scripts/provision-device.sh user@device-host device-001

Set these if your service uses different paths:

cargo run --no-default-features --manifest-path ~/apps/toes-matter/Cargo.toml --bin toes-matter-credentials -- \
  --remote-creds-dir /var/lib/my-app \
  --remote-state-dir /var/lib/my-app/state \
  --service my-app.service \
  user@device-host device-001

Serial instead of network/SSH:

cargo run --no-default-features --manifest-path ~/apps/toes-matter/Cargo.toml --bin toes-matter-credentials -- \
  --serial /dev/cu.usbserial-0001 \
  --device-id device-001

If the serial console is already at a shell prompt, omit login flags. If it is at login:, provide credentials:

cargo run --no-default-features --manifest-path ~/apps/toes-matter/Cargo.toml --bin toes-matter-credentials -- \
  --serial /dev/cu.usbserial-0001 \
  --login root \
  --password 'your-password' \
  --device-id device-001

For passwordless root/login, use --login root and omit --password. The tool waits for login:, optional Password:, then a shell prompt marker (# or $ by default) before sending the install script. If your prompt is unusual, add --prompt 'my-prompt>'.

The wrapper script supports serial via environment too:

SERIAL_PORT=/dev/cu.usbserial-0001 \
SERIAL_LOGIN=root \
SERIAL_PASSWORD='your-password' \
~/apps/toes-matter/scripts/provision-device.sh device-001

On macOS, /dev/cu.* is usually better for outbound serial than /dev/tty.*, though either can appear depending on the adapter.

Useful macOS extras:

brew install qrencode