
Domain Iot
- 581 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
domain-iot is a Rust domain-constraint skill that guides power-efficient, reliable Rust code for IoT sensors, MQTT gateways, and edge devices when developers face unreliable networks and resource limits.
About
domain-iot is a Layer 3 Domain Constraints skill from zhanghandong/rust-skills for building IoT applications in Rust. It maps domain rules—unreliable networks, power limits, small footprints, encrypted comms, and self-healing reliability—to concrete Rust design choices such as offline-first local buffering, sleep modes with minimal allocation, no_std where needed, TLS and signed firmware, and watchdog recovery. Keywords span MQTT, telemetry, actuators, smart home, gateways, and edge computing in English and Chinese. Developers invoke domain-iot when writing firmware or edge services where every allocation and wake cycle matters on constrained connected hardware.
- Translates 6 core IoT domain rules into concrete Rust design constraints
- Maps unreliable networks to local buffering and retry-with-backoff patterns
- Enforces power and resource limits via no_std, sleep modes and minimal allocation
- Requires encrypted communication and self-recovery mechanisms in every implementation
- Provides traceable links from constraints to reusable Rust modules and patterns
Domain Iot by the numbers
- 581 all-time installs (skills.sh)
- +5 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #659 of 4,386 Backend & APIs skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-iotAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 581 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 2 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
How do you write power-efficient Rust for IoT devices?
Apply domain-specific constraints when creating reliable, power-efficient Rust code for connected devices and edge systems.
Who is it for?
Rust developers building MQTT-connected sensors, actuators, or edge gateways on power- and memory-constrained hardware.
Skip if: Cloud-only Rust microservices on always-on servers where standard async Tokio patterns suffice without no_std or sleep-mode constraints.
When should I use this skill?
The user mentions IoT, MQTT, sensors, edge computing, telemetry, actuators, smart home gateways, or 物联网 in a Rust project context.
What you get
Rust modules with offline buffers, sleep-mode-friendly allocation, TLS-secured MQTT, and no_std-ready structure for edge targets.
- Domain-constrained Rust module structure
- offline buffer and TLS patterns
Files
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 backoffPower Management
RULE: Minimize power consumption
WHY: Battery life, energy costs
RUST: Sleep modes, efficient algorithmsDevice 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
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 + flush |
| Power efficiency | Sleep patterns | Timer-based wake |
| Network reliability | Retry | tokio-retry, backoff |
| Security | TLS | rustls, native-tls |
---
Related Skills
| When | See |
|---|---|
| Embedded patterns | domain-embedded |
| Async patterns | m07-concurrency |
| Error recovery | m13-domain-error |
| Performance | m10-performance |
Related skills
How it compares
Pick domain-iot over generic Rust backend skills when firmware constraints, MQTT on unreliable links, or no_std footprint limits dominate the design.
FAQ
What IoT constraints does domain-iot cover?
domain-iot maps five domain rules to Rust: unreliable networks require offline buffering, power limits need sleep modes and minimal allocation, resource limits favor no_std, security demands TLS and signed firmware, and reliability needs watchdog self-healing.
When should domain-iot be invoked in rust-skills?
domain-iot is user-invocable false and auto-applies when building IoT apps with keywords like MQTT, sensor, telemetry, actuator, edge computing, gateway, smart home, or 物联网 in a Rust codebase.
Is Domain Iot safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.