Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
zhanghandong avatar

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-iot

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs581
repo stars1.3k
Security audit2 / 3 scanners passed
Last updatedMay 24, 2026
Repositoryzhanghandong/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

SKILL.mdMarkdownGitHub ↗

IoT Domain

Layer 3: Domain Constraints

Domain Constraints → Design Implications

Domain RuleDesign ConstraintRust Implication
Unreliable networkOffline-firstLocal buffering
Power constraintsEfficient codeSleep modes, minimal alloc
Resource limitsSmall footprintno_std where needed
SecurityEncrypted commsTLS, signed firmware
ReliabilitySelf-recoveryWatchdog, error handling
OTA updatesSafe upgradesRollback 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

EnvironmentStackCrates
Linux gatewaytokio + stdrumqttc, reqwest
MCU deviceembassy + no_stdembedded-hal
HybridSplit workloadsBoth

Key Crates

PurposeCrate
MQTT (std)rumqttc, paho-mqtt
Embeddedembedded-hal, embassy
Async (std)tokio
Async (no_std)embassy
Logging (no_std)defmt
Logging (std)tracing

Design Patterns

PatternPurposeImplementation
Pub/SubDevice commsMQTT topics
Edge computeLocal processingFilter before upload
OTA updatesFirmware upgradeSigned + rollback
Power mgmtBattery lifeSleep + wake events
Store & forwardNetwork reliabilityLocal 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

MistakeDomain ViolationFix
No retry logicLost dataExponential backoff
Always-on radioBattery drainSleep between sends
Unencrypted MQTTSecurity riskTLS
No local bufferNetwork outage = data lossPersist locally

---

Trace to Layer 1

ConstraintLayer 2 PatternLayer 1 Implementation
Offline-firstStore & forwardLocal queue + flush
Power efficiencySleep patternsTimer-based wake
Network reliabilityRetrytokio-retry, backoff
SecurityTLSrustls, native-tls

---

Related Skills

WhenSee
Embedded patternsdomain-embedded
Async patternsm07-concurrency
Error recoverym13-domain-error
Performancem10-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.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.