
Domain Iot
Apply IoT domain constraints—MQTT, offline buffers, power, TLS, OTA rollback—to Rust architecture and crate choices.
Overview
domain-iot is an agent skill most often used in Build (also Operate) that encodes IoT domain constraints—network, power, security, and OTA—into Rust design and implementation guidance.
Install
npx skills add https://github.com/actionbook/rust-skills --skill domain-iotWhat is this skill?
- Layer 3 domain constraints mapped to design implications and Rust patterns
- Six critical rules: unreliable network, power, resource limits, security, reliability, OTA updates
- Offline-first with local queue and retry-with-backoff error handling
- Power and footprint guidance including no_std and sleep-oriented efficiency
- Encrypted comms, signed firmware, watchdog and rollback for safe OTA
- 6 domain constraint rows (network, power, resources, security, reliability, OTA)
- 6 critical constraint rule blocks in SKILL.md
Adoption & trust: 675 installs on skills.sh; 1.2k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are modeling an IoT Rust service but your design ignores offline networks, power limits, and device security realities.
Who is it for?
Solo builders architecting Rust telemetry, MQTT gateways, or edge agents before writing protocol and persistence code.
Skip if: Pure cloud-only CRUD APIs with no devices, or teams wanting a turnkey firmware flash tool without Rust design decisions.
When should I use this skill?
Building IoT apps in Rust involving sensors, MQTT, devices, edge computing, telemetry, actuators, or smart-home gateways.
What do I get? / Deliverables
Your architecture explicitly includes buffering, backoff, encryption, watchdog recovery, and safe OTA patterns aligned with domain rules.
- Constraint-aligned architecture decisions
- Traceable links to lifecycle, error, embedded, and performance patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
IoT firmware and gateway logic are implemented in Build; this skill is the domain layer for those Rust designs. Backend covers device protocols, telemetry pipelines, gateways, and edge services rather than mobile UI shells.
Where it fits
Choose local persistence and backoff before wiring MQTT publish loops for field devices.
Require TLS and signed messages when defining actuator command paths.
Align watchdog and OTA rollback policies with fleet observability after first deploy.
How it compares
Domain constraint reference for Rust IoT—not a hardware BOM skill or a managed IoT cloud integration pack.
Common Questions / FAQ
Who is domain-iot for?
Rust-focused solo builders and agents working on sensors, gateways, smart-home, or edge telemetry who need constraint-first design.
When should I use domain-iot?
In Build when shaping MQTT/device architecture and in Operate when reinforcing monitoring, recovery, and OTA safety on deployed fleets.
Is domain-iot safe to install?
Review the Security Audits panel on this Prism page; the skill is documentation-only but your generated code still needs TLS, secrets, and firmware signing review.
SKILL.md
READMESKILL.md - Domain Iot
# IoT Domain > **Layer 3: Domain Constraints** ## Domain Constraints → Design Implications | Domain Rule | Design Constraint | Rust Implication | |-------------|-------------------|------------------| | Unreliable network | Offline-first | Local buffering | | Power constraints | Efficient code | Sleep modes, minimal alloc | | Resource limits | Small footprint | no_std where needed | | Security | Encrypted comms | TLS, signed firmware | | Reliability | Self-recovery | Watchdog, error handling | | OTA updates | Safe upgrades | Rollback capability | --- ## Critical Constraints ### Network Unreliability ``` RULE: Network can fail at any time WHY: Wireless, remote locations RUST: Local queue, retry with backoff ``` ### Power Management ``` RULE: Minimize power consumption WHY: Battery life, energy costs RUST: Sleep modes, efficient algorithms ``` ### Device Security ``` RULE: All communication encrypted WHY: Physical access possible RUST: TLS, signed messages ``` --- ## Trace Down ↓ From constraints to design (Layer 2): ``` "Need offline-first design" ↓ m12-lifecycle: Local buffer with persistence ↓ m13-domain-error: Retry with backoff "Need power efficiency" ↓ domain-embedded: no_std patterns ↓ m10-performance: Minimal allocations "Need reliable messaging" ↓ m07-concurrency: Async with timeout ↓ MQTT: QoS levels ``` --- ## Environment Comparison | Environment | Stack | Crates | |-------------|-------|--------| | Linux gateway | tokio + std | rumqttc, reqwest | | MCU device | embassy + no_std | embedded-hal | | Hybrid | Split workloads | Both | ## Key Crates | Purpose | Crate | |---------|-------| | MQTT (std) | rumqttc, paho-mqtt | | Embedded | embedded-hal, embassy | | Async (std) | tokio | | Async (no_std) | embassy | | Logging (no_std) | defmt | | Logging (std) | tracing | ## Design Patterns | Pattern | Purpose | Implementation | |---------|---------|----------------| | Pub/Sub | Device comms | MQTT topics | | Edge compute | Local processing | Filter before upload | | OTA updates | Firmware upgrade | Signed + rollback | | Power mgmt | Battery life | Sleep + wake events | | Store & forward | Network reliability | Local queue | ## Code Pattern: MQTT Client ```rust use rumqttc::{AsyncClient, MqttOptions, QoS}; async fn run_mqtt() -> anyhow::Result<()> { let mut options = MqttOptions::new("device-1", "broker.example.com", 1883); options.set_keep_alive(Duration::from_secs(30)); let (client, mut eventloop) = AsyncClient::new(options, 10); // Subscribe to commands client.subscribe("devices/device-1/commands", QoS::AtLeastOnce).await?; // Publish telemetry tokio::spawn(async move { loop { let data = read_sensor().await; client.publish("devices/device-1/telemetry", QoS::AtLeastOnce, false, data).await.ok(); tokio::time::sleep(Duration::from_secs(60)).await; } }); // Process events loop { match eventloop.poll().await { Ok(event) => handle_event(event).await, Err(e) => { tracing::error!("MQTT error: {}", e); tokio::time::sleep(Duration::from_secs(5)).await; } } } } ``` --- ## Common Mistakes | Mistake | Domain Violation | Fix | |---------|-----------------|-----| | No retry logic | Lost data | Exponential backoff | | Always-on radio | Battery drain | Sleep between sends | | Unencrypted MQTT | Security risk | TLS | | No local buffer | Network outage = data loss | Persist locally | --- ## Trace to Layer 1 | Constraint | Layer 2 Pattern | Layer 1 Implementation | |------------|-----------------|------------------------| | Offline-first | Store & forward | Local queue + flu