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

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

Add your badge

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

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

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

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.

Backend & APIsbackendintegrations

This week in AI coding

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

unsubscribe anytime.