ShellyShelly设备控制

Setup

On first use, read setup.md and align activation boundaries, local network scope, and write-safety defaults before sending Shelly commands.

When to Use

Use this skill when the user needs practical Shelly execution: local RPC control, status and telemetry reads, cloud-assisted operations, device grouping, or staged automations.
Use this instead of generic IoT advice when outcomes depend on Shelly-specific RPC behavior, transport channel choice, and safe multi-device rollouts.

Architecture

Memory lives in ~/shelly/. See memory-template.md for structure and status values.

CODEBLOCK0

Quick Reference

Use the smallest file needed for the current task.

Requirements

• - Shelly devices reachable in the target local network, or cloud account access for cloud mode
• For cloud operations: SHELLY_CLOUD_TOKEN set in environment
• For reliable automation: stable device ids, component ids, and execution boundaries

Never ask users to paste production secrets in chat logs. Prefer local environment variables and redacted examples.

Data Storage

Keep local operational notes in ~/shelly/:

• - network and endpoint decisions
• device component maps and verified RPC methods
• automation policies, sequencing, and rollback constraints
• incident signatures and mitigations

Core Rules

1. Select the Correct Control Plane Before Acting

• - Decide local-only, cloud-assisted, or mixed mode before issuing commands.
• Block execution when control plane is ambiguous because status and command outcomes become inconsistent.

2. Resolve Transport Channel by Task and Scale

• - Use local HTTP RPC for direct control and deterministic reads.
• Use WebSocket notifications for near real-time state updates and MQTT for event pipelines where broker integration is required.

3. Discover Components and Capabilities Before Writes

• - Read device status and component layout before command generation.
• Generate writes only for existing component ids and supported method parameters.

4. Use Read-Before-Write and Read-After-Write Loops

• - Capture baseline state before every write.
• Verify resulting state after execution and stop rollout on mismatch.

5. Enforce Explicit Safety Gates for High-Impact Actions

• - Start in read-only inspection and dry-run planning mode.
• Require explicit confirmation before relay power toggles, heating control, locks, alarms, or bulk updates.

6. Keep Local and Cloud Views Consistent

• - Reconcile device identity and state if local RPC and cloud responses diverge.
• Prefer local device truth for immediate state decisions when reachable.

7. Design Automations as Idempotent and Observable

• - Use deterministic run ids, bounded retries, and hard stop conditions.
• Log each execution step with expected state checks to avoid duplicate or partial transitions.

8. Preserve Security and Privacy Boundaries

• - Use least-privilege credentials and only declared endpoints.
• Read cloud token from environment variables and never write raw secrets to local notes.

Common Traps

• - Mixing local and cloud control without precedence rules -> conflicting state and duplicate writes.
• Sending RPC methods without validating component ids -> rejected calls or wrong target behavior.
• Treating transport choice as interchangeable -> latency and reliability mismatches under load.
• Bulk execution without canary checks -> large blast radius when one method is misconfigured.
• Assuming notification streams imply successful writes -> command accepted but desired final state not reached.
• Storing cloud tokens in plaintext notes -> unnecessary credential exposure.

External Endpoints