
Domain Iot
- 1.2k installs
- 1.3k repo stars
- Updated May 24, 2026
- actionbook/rust-skills
domain-iot is an actionbook Rust domain skill that enforces IoT and edge constraints—MQTT, offline buffering, no_std, and TLS—for developers writing power-efficient reliable Rust device and gateway code.
About
domain-iot is an actionbook rust-skills Layer 3 domain module for Internet of Things, edge, sensor, and smart-home Rust development. It maps domain rules to design constraints: unreliable networks require offline-first local buffering, power limits demand sleep modes and minimal allocation, resource caps push no_std where feasible, and security mandates TLS plus signed firmware. The skill surfaces keywords including MQTT, telemetry, actuators, gateways, and edge computing so agents apply the right Rust patterns during implementation. Developers reach for domain-iot when writing device firmware services, telemetry collectors, or gateway backends where embedded constraints beat generic web-service defaults. It complements general Rust skills by anchoring architectural decisions to IoT realities instead of datacenter assumptions.
- Translates 6 core IoT domain rules into concrete Rust design constraints
- Provides ready-to-use patterns for offline-first buffering, no_std, TLS, watchdog timers and OTA rollback
- Maps every constraint directly to m12-lifecycle, m13-domain-error and domain-embedded modules
- Includes bilingual keyword triggers for IoT, MQTT, telemetry, actuator, edge computing and 物联网
- Hard-gated Layer 3 checklist that must be reviewed before committing embedded or connected-device code
Domain Iot by the numbers
- 1,166 all-time installs (skills.sh)
- +48 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #358 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/actionbook/rust-skills --skill domain-iotAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.2k |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 2 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | actionbook/rust-skills ↗ |
How do you design Rust backends for IoT devices?
Apply domain-specific constraints when creating reliable, power-efficient Rust code for IoT, edge, and sensor-based applications.
Who is it for?
Rust developers building MQTT telemetry, edge gateways, sensor services, or smart-home backends with unreliable networks and tight resources.
Skip if: Standard cloud-only Rust web APIs without device connectivity, power, or embedded footprint requirements.
When should I use this skill?
A developer mentions IoT, MQTT, sensors, edge computing, telemetry, actuators, smart home, or no_std Rust device code.
What you get
IoT-constrained Rust architecture with offline buffering, efficient allocation, encrypted comms, and protocol-aware backend code.
- IoT-constrained Rust design guidance
- Protocol-aware backend 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
Use domain-iot for connected device and edge Rust; use a general Rust API skill when services run only in reliable cloud environments.
FAQ
What IoT constraints does domain-iot enforce in Rust?
domain-iot enforces offline-first buffering for unreliable networks, minimal allocation and sleep modes for power limits, no_std options for small footprints, and TLS plus signed firmware for device security.
When should domain-iot activate during Rust development?
domain-iot activates for IoT, sensor, MQTT, telemetry, actuator, gateway, edge computing, or smart-home Rust work where embedded constraints should override generic backend defaults.
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.