
Domain Iot
Map IoT realities— flaky networks, batteries, tamper risk, and OTA—into Rust-friendly design choices before you wire MQTT, sensors, or edge gateways.
Overview
domain-iot is an agent skill most often used in Build (also Operate, Ship) that encodes IoT domain constraints—offline-first buffering, power efficiency, encrypted comms, and safe OTA—for Rust sensor, MQTT, and edge desi
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-iotWhat is this skill?
- Six-row domain rule table tying network, power, footprint, security, reliability, and OTA to concrete Rust implications
- Critical constraints for offline-first queuing, power-aware sleep and minimal allocation, and mandatory TLS plus signed
- Trace-down links from constraints to lifecycle persistence, domain errors with backoff, no_std embedded patterns, and pe
- Explicit RULE/WHY/RUST blocks for network unreliability, power management, and device security
- Layer 3 domain framing meant to sit above shared Rust skill modules in the same rust-skills stack
- Six domain rules mapped in the constraints-to-Rust-implications table
- Three critical constraint sections: network unreliability, power management, and device security
Adoption & trust: 535 installs on skills.sh; 1.2k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are modeling MQTT, sensors, or edge devices in Rust but default web patterns ignore dropped links, battery limits, and on-device security exposure.
Who is it for?
Indie builders or small teams writing Rust for IoT backends, gateways, or firmware-adjacent services where connectivity and power are unreliable.
Skip if: Pure cloud-only CRUD with no devices, or stacks where Rust and edge constraints are out of scope and another language owns the device layer.
When should I use this skill?
Building IoT apps with keywords such as IoT, sensor, MQTT, device, edge computing, telemetry, actuator, smart home, or gateway.
What do I get? / Deliverables
You get explicit RULE/WHY/RUST guidance and trace-down targets so firmware, gateways, and telemetry code favor local queues, backoff, TLS, signed updates, and recovery instead of naive always-online assumptions.
- Constraint-aligned architecture notes for offline-first, power, security, and OTA
- Explicit retry, buffering, and crypto requirements for device communication
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
IoT product work lands in Build when you shape firmware, gateways, and telemetry services; this skill is the domain constraint layer for those Rust designs. Backend is the canonical shelf because constraints drive service buffers, retry logic, crypto on the wire, and device lifecycle hooks—not just a one-off script.
Where it fits
Before implementing an MQTT ingestion service, you lock in local queue persistence and exponential backoff instead of assuming always-on Wi-Fi.
While preparing release checks, you require TLS on all device traffic and signed firmware artifacts with rollback paths.
When incidents spike from flaky field networks, you align watchdog, retry, and telemetry buffering behavior with the documented domain rules.
How it compares
Use as a domain constraint checklist layered on generic Rust architecture skills, not as a drop-in MQTT client library or hosted IoT platform.
Common Questions / FAQ
Who is domain-iot for?
Solo and indie developers using agent-assisted Rust work when the product touches sensors, MQTT, gateways, telemetry, or edge compute—not generic SaaS-only APIs.
When should I use domain-iot?
During Build when scoping backend or integration designs for devices; during Ship when hardening reliability and crypto for deployment; during Operate when reasoning about watchdogs, retries, and safe OTA rollbacks in production-like conditions.
Is domain-iot safe to install?
Treat it as procedural documentation in your skills bundle; review the Security Audits panel on this Prism page and your org policy before trusting any third-party skill content in production device codepaths.
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