[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FS7ZMNRT3QDYQSNBJW35P":3,"skill-same:01M70FS7ZMNRT3QDYQSNBJW35P":94},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M70FS7ZMNRT3QDYQSNBJW35P","iot-system-architect",null,"Expert IoT system architecture covering distributed systems, event-driven design, edge computing, and microservices patterns. Use when designing multi-device systems, planning communication architecture, implementing event-driven patterns, or scaling IoT deployments. Specializes in MQTT-based architectures, state synchronization, and real-time constraints.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"architect","system","iot","System Architect","iot system architect","event","real-time","planning","architectures","mqtt","patterns","communication","architecture","synchronization","when","design","implementing","time","expert","scaling","2026-11-10 10:12:30",false,"---\nname: iot-system-architect\ndescription: Expert IoT system architecture covering distributed systems, event-driven design, edge computing, and microservices patterns. Use when designing multi-device systems, planning communication architecture, implementing event-driven patterns, or scaling IoT deployments. Specializes in MQTT-based architectures, state synchronization, and real-time constraints.\n---\n\n# IoT System Architect\n\n## Overview\n\nThis skill provides expert guidance for architecting distributed IoT systems with multiple devices, edge computing, and cloud integration. It covers event-driven design patterns, microservices architecture, state management across distributed devices, and scalability considerations for production deployments.\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- Designing multi-device IoT systems with distributed coordination\n- Planning communication architecture and message broker topology\n- Implementing event-driven patterns with MQTT or similar protocols\n- Making edge computing vs cloud processing decisions\n- Scaling IoT deployments beyond proof-of-concept\n- Establishing state synchronization across devices\n- Designing for offline-first or eventually consistent systems\n- Creating architecture decision records for IoT projects\n- Evaluating trade-offs between performance, reliability, and complexity\n\n## Core Capabilities\n\n### 1. Distributed Systems Design\n\nApply distributed systems principles to IoT architectures:\n\n**Event-Driven Architecture:**\n- Design pub\u002Fsub patterns with MQTT as the primary message broker\n- Establish topic hierarchies that scale with device count\n- Implement event sourcing for device state history\n- Create idempotent message handlers to handle duplicate delivery\n- Design for eventual consistency across device fleet\n\n**CAP Theorem Trade-offs:**\n- Prioritize Availability and Partition tolerance for IoT (AP systems)\n- Accept eventual consistency for device states\n- Implement conflict resolution strategies (last-write-wins, vector clocks, CRDTs)\n- Design compensating transactions for failed operations\n\n**Offline-First Design:**\n- Enable devices to operate independently during network outages\n- Queue messages locally when broker connection is lost\n- Implement state reconciliation upon reconnection\n- Design graceful degradation of functionality\n\n**Data Consistency Patterns:**\n- Use optimistic replication for device state\n- Implement causal consistency where order matters\n- Apply strong consistency only for critical operations (e.g., safety shutoffs)\n- Design idempotent operations to handle message replay\n\n### 2. Communication Architecture\n\nDesign robust communication patterns for device coordination:\n\n**Topology Patterns:**\n\n*Hub-and-Spoke (Argus Pattern):*\n- Central hub (e.g., Jetson Nano with MQTT broker) coordinates all devices\n- Devices communicate through the hub, not directly\n- Simplifies message routing and state management\n- Single point of failure mitigated with local device autonomy\n\n*Mesh Networking:*\n- Direct device-to-device communication when needed\n- Higher complexity but better fault tolerance\n- Consider for offline operation or peer coordination\n\n**MQTT Broker Design:**\n- Configure Mosquitto with appropriate QoS levels per message type\n- Implement retained messages for device state\n- Use persistent sessions for reliable delivery\n- Set up authentication and ACLs for security\n\n**Topic Naming Conventions:**\n```\n\u003Cdomain>\u002F\u003Cdevice_id>\u002F\u003Ccomponent>\u002F\u003Caction>\nExamples:\n- argus\u002Fpresto\u002Ftimer\u002Fstate\n- argus\u002Ftembed\u002Fdisplay\u002Fcommand\n- argus\u002Fphone\u002Fnotification\u002Fevent\n```\n\n**Quality of Service Strategy:**\n- QoS 0: Fire-and-forget for high-frequency sensor data\n- QoS 1: At-least-once for commands and state updates\n- QoS 2: Exactly-once for critical operations (use sparingly due to overhead)\n\n**Message Payload Optimization:**\n- Use compact JSON or binary formats (Protocol Buffers, MessagePack)\n- Minimize payload size for bandwidth-constrained devices\n- Batch non-urgent messages to reduce overhead\n- Implement compression for larger payloads\n\n### 3. Microservices for IoT\n\nDecompose monolithic systems into maintainable services:\n\n**Service Boundaries:**\n- One service per device type or functional domain\n- Services own their data and expose APIs\n- Bounded contexts prevent tight coupling\n- Each service can be developed, deployed, and scaled independently\n\n**API Design:**\n- RESTful APIs for synchronous operations (device configuration)\n- Event-driven messaging for asynchronous coordination (state changes)\n- WebSocket connections for real-time bidirectional communication\n- GraphQL for flexible data queries from dashboards\n\n**Service Discovery:**\n- Use mDNS\u002FBonjour for local network discovery\n- Implement service registry for dynamic environments\n- Hard-code endpoints for static deployments to reduce complexity\n\n**Inter-Service Communication:**\n- MQTT for event broadcasts and state synchronization\n- HTTP\u002FREST for request-response operations\n- gRPC for high-performance service-to-service calls\n- Message queues (Redis Streams) for work distribution\n\n**Failure Isolation:**\n- Circuit breakers to prevent cascade failures\n- Timeouts on all network operations\n- Bulkhead pattern to isolate resources\n- Health checks and automatic restart policies\n\n**Container Orchestration:**\n- Docker for backend service deployment\n- Docker Compose for local development and small deployments\n- Consider Kubernetes for large-scale production (>50 devices)\n- Maintain device firmware separate from backend containers\n\n### 4. Edge Computing Patterns\n\nOptimize processing placement between edge and cloud:\n\n**Processing Decision Framework:**\n\n*Process at Edge When:*\n- Real-time response required (\u003C100ms latency)\n- Bandwidth is limited or expensive\n- Privacy\u002Fsecurity requires local processing\n- Operation doesn't require cloud data\n- Example: Timer state transitions, button press handling\n\n*Process at Cloud When:*\n- Heavy computation required (ML inference on large models)\n- Data aggregation across multiple devices needed\n- Long-term storage and analytics required\n- Integration with external services needed\n- Example: Notification routing, usage analytics, backup\n\n**Data Aggregation at Edge:**\n- Pre-filter sensor data before sending to cloud\n- Compute running averages and statistics locally\n- Send only deltas or significant changes\n- Batch non-urgent updates\n\n**Real-Time Decision Making:**\n- Implement state machines on devices for autonomous operation\n- Use edge AI for local inference (TensorFlow Lite, ONNX Runtime)\n- Maintain decision logic at the edge to survive network outages\n- Update logic remotely via MQTT or OTA updates\n\n**Bandwidth Optimization:**\n- Compress data before transmission\n- Use delta encoding for state updates\n- Implement adaptive sampling rates based on network conditions\n- Cache frequently accessed cloud data at edge\n\n**Edge AI\u002FML Deployment:**\n- Run inference on Jetson Nano for vision tasks\n- Use TensorFlow Lite on ESP32\u002FRP2350 for simple models\n- Implement model quantization to reduce size\n- Update models remotely without reflashing firmware\n\n### 5. State Management\n\nSynchronize state across distributed devices reliably:\n\n**Device State Synchronization:**\n- Publish state changes to MQTT with retained messages\n- Subscribe to relevant device states for coordination\n- Handle out-of-order message delivery gracefully\n- Implement state versioning with timestamps or vector clocks\n\n**State Machine Design:**\n```\nStates: IDLE → RUNNING → PAUSED → COMPLETED\nEvents: start, pause, resume, reset, complete\nTransitions: validated to prevent invalid state changes\n```\n\n- Define clear states and valid transitions\n- Implement guards to prevent invalid transitions\n- Publish state change events for observability\n- Persist state to survive reboots\n\n**Conflict-Free Replicated Data Types (CRDTs):**\n- Use for state that multiple devices can modify\n- G-Counter for increment-only values (usage statistics)\n- LWW-Register for last-write-wins semantics\n- OR-Set for collaborative collections\n\n**Event Sourcing:**\n- Store all state changes as immutable events\n- Rebuild current state by replaying events\n- Enable time-travel debugging and audit trails\n- Simplify state synchronization across devices\n\n**State Recovery:**\n- Devices request current state upon reconnection\n- Use MQTT retained messages for latest state\n- Implement state snapshots to avoid replaying entire history\n- Handle partial state during recovery gracefully\n\n**Idempotent Operations:**\n- Design operations to have the same effect if repeated\n- Use unique message IDs to detect duplicates\n- Implement deduplication windows for recently processed messages\n- Critical for at-least-once delivery semantics\n\n### 6. Scalability Considerations\n\nDesign systems that scale from prototype to production:\n\n**Horizontal vs Vertical Scaling:**\n- Scale MQTT broker vertically for small deployments (\u003C100 devices)\n- Scale horizontally with broker clustering for large fleets\n- Use load balancers for HTTP\u002FREST APIs\n- Shard device connections across multiple broker instances\n\n**Load Balancing Strategies:**\n- Round-robin for stateless services\n- Consistent hashing for affinity-based routing\n- Geo-based routing for distributed deployments\n- Health-aware routing to avoid overloaded instances\n\n**Database Sharding:**\n- Partition device data by device ID or device type\n- Time-series databases (InfluxDB, TimescaleDB) for sensor data\n- Document stores (MongoDB) for device configurations\n- Use read replicas for analytics queries\n\n**Caching Strategies:**\n- Redis for session state and frequently accessed data\n- Cache device states at edge to reduce broker queries\n- Implement TTL-based expiration for stale data\n- Use cache-aside pattern for device configurations\n\n**Message Queue Sizing:**\n- Configure broker memory limits based on device count\n- Implement message TTL to prevent queue buildup\n- Monitor queue depth and set up alerts\n- Use dead-letter queues for failed message handling\n\n**Connection Pooling:**\n- Reuse MQTT connections across message publishes\n- Pool database connections in backend services\n- Implement connection retry with exponential backoff\n- Set appropriate keepalive intervals\n\n### 7. Architecture Decision Records (ADRs)\n\nDocument key architectural decisions with rationale:\n\n**When to Create an ADR:**\n- Choosing between MQTT, CoAP, or HTTP for device communication\n- Selecting edge vs cloud processing for specific workloads\n- Deciding on state synchronization strategy\n- Evaluating database technology for device data\n- Adopting new design patterns or frameworks\n\n**ADR Template:**\n\nUse the provided `assets\u002Fadr_template.md` to document decisions:\n\n```markdown\n# ADR-NNN: [Decision Title]\n\nDate: YYYY-MM-DD\nStatus: [Proposed | Accepted | Deprecated | Superseded]\n\n## Context\n[Describe the architectural challenge and constraints]\n\n## Decision\n[State the decision clearly]\n\n## Rationale\n[Explain why this decision was made]\n\n## Consequences\n[Document trade-offs, benefits, and drawbacks]\n\n## Alternatives Considered\n[List other options and why they were rejected]\n```\n\n**Best Practices:**\n- Number ADRs sequentially (ADR-001, ADR-002...)\n- Keep ADRs concise (1-2 pages maximum)\n- Update status as decisions evolve\n- Link related ADRs\n- Include performance metrics when relevant\n\n## Architecture Principles\n\nFollow these principles when designing IoT systems:\n\n1. **Loose Coupling**: Devices operate independently; failure of one device doesn't cascade\n2. **High Cohesion**: Group related functionality within service\u002Fdevice boundaries\n3. **Fail-Safe**: Design for graceful degradation when network or services fail\n4. **Observability**: Instrument with logging, metrics, and distributed tracing\n5. **Maintainability**: Clear module boundaries, documentation, and testability\n6. **Performance**: Meet real-time constraints through edge processing and optimization\n7. **Security**: Defense in depth with encryption, authentication, and authorization\n\n## Argus Reference Architecture\n\nThe Argus system provides a concrete example of these principles in practice:\n\n**System Overview:**\n```\n┌─────────────────────────────────────────────┐\n│         Android Device (Pixel Pro)          │\n│     [Notification Bridge & Control]         │\n└────────────┬──────────────┬─────────────────┘\n             │ BLE          │\n             ▼              ▼\n    ┌──────────────┐  ┌──────────────┐\n    │   Presto     │  │   T-Embed    │\n    │  (Central)   │◄─┤   (Desk)     │\n    │ RP2350+4\"    │  │ ESP32-S3     │\n    └──────┬───────┘  └──────┬───────┘\n           │ MQTT            │ MQTT\n           └────────┬────────┘\n                    ▼\n         ┌─────────────────────┐\n         │   Jetson Nano       │\n         │ [MQTT Broker+AI]    │\n         └─────────┬───────────┘\n                   │ WebSocket\n                   ▼\n         ┌─────────────────────┐\n         │   Stream Deck Neo   │\n         │  [Macro Control]    │\n         └─────────────────────┘\n```\n\n**Key Architectural Patterns Applied:**\n\n- **Observer Pattern**: All devices subscribe to timer state changes via MQTT\n- **State Pattern**: Timer implements multiple operating modes (work, break, long break)\n- **Strategy Pattern**: Different timing strategies (Pomodoro, custom intervals)\n- **Publish-Subscribe**: Core communication model enables loose coupling\n- **Singleton**: MQTT broker connection shared across device handlers\n\n**Multi-Device State Synchronization:**\n1. Presto publishes timer state to `argus\u002Fpresto\u002Ftimer\u002Fstate`\n2. T-Embed subscribes and updates display accordingly\n3. Phone receives notifications via BLE bridge\n4. Stream Deck reflects current state via WebSocket connection\n\n**Fallback Behavior During Outages:**\n- Presto operates autonomously if MQTT broker is down\n- T-Embed shows \"disconnected\" status but retains last known state\n- Phone queues notifications until BLE connection restored\n- System auto-recovers when connectivity returns\n\n**Scalable MQTT Topic Structure:**\n```\nargus\u002F\n├── presto\u002F\n│   ├── timer\u002Fstate          (retained, QoS 1)\n│   ├── timer\u002Fcommand        (QoS 1)\n│   └── button\u002Fevent         (QoS 0)\n├── tembed\u002F\n│   ├── display\u002Fstate        (retained, QoS 1)\n│   └── display\u002Fcommand      (QoS 1)\n├── phone\u002F\n│   ├── notification\u002Fevent   (QoS 1)\n│   └── notification\u002Fack     (QoS 1)\n└── system\u002F\n    ├── health               (QoS 0, periodic)\n    └── logs                 (QoS 0)\n```\n\nFor detailed design patterns and examples, see `references\u002Fdesign_patterns.md` and `references\u002Fargus_architecture.md`.\n\n## Diagramming and Modeling\n\nUse these techniques to communicate architecture effectively:\n\n**System Context Diagram (C4 Level 1):**\n- Show the system and its users\u002Fexternal systems\n- Identify system boundary and key interactions\n\n**Container Diagram (C4 Level 2):**\n- Show major containers (devices, services, databases)\n- Illustrate communication protocols and dependencies\n\n**Sequence Diagrams:**\n- Document multi-device interaction flows\n- Show message ordering and timing constraints\n- Highlight error and retry scenarios\n\n**State Diagrams:**\n- Model device state machines\n- Document valid transitions and guards\n- Clarify complex stateful behavior\n\n**Data Flow Diagrams:**\n- Trace data through the system\n- Identify transformation points\n- Highlight aggregation and filtering\n\n**Deployment Diagrams:**\n- Show physical device placement\n- Document network topology\n- Illustrate container orchestration\n\n## Resources\n\nThis skill includes bundled resources for reference and templates:\n\n### references\u002F\n\n- **`design_patterns.md`**: Comprehensive catalog of design patterns for IoT systems with examples and anti-patterns\n- **`argus_architecture.md`**: Detailed Argus system architecture including component specifications and implementation details\n\nLoad these references when working on complex architectural decisions or needing detailed pattern examples.\n\n### assets\u002F\n\n- **`adr_template.md`**: Architecture Decision Record template for documenting key design decisions\n\nCopy this template when creating new ADRs for IoT projects.\n","# IoT System Architect\n\n## Overview\n\nThis skill provides expert guidance for architecting distributed IoT systems with multiple devices, edge computing, and cloud integration. It covers event-driven design patterns, microservices architecture, state management across distributed devices, and scalability considerations for production deployments.\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- Designing multi-device IoT systems with distributed coordination\n- Planning communication architecture and message broker topology\n- Implementing event-driven patterns with MQTT or similar protocols\n- Making edge computing vs cloud processing decisions\n- Scaling IoT deployments beyond proof-of-concept\n- Establishing state synchronization across devices\n- Designing for offline-first or eventually consistent systems\n- Creating architecture decision records for IoT projects\n- Evaluating trade-offs between performance, reliability, and complexity\n\n## Core Capabilities\n\n### 1. Distributed Systems Design\n\nApply distributed systems principles to IoT architectures:\n\n**Event-Driven Architecture:**\n- Design pub\u002Fsub patterns with MQTT as the primary message broker\n- Establish topic hierarchies that scale with device count\n- Implement event sourcing for device state history\n- Create idempotent message handlers to handle duplicate delivery\n- Design for eventual consistency across device fleet\n\n**CAP Theorem Trade-offs:**\n- Prioritize Availability and Partition tolerance for IoT (AP systems)\n- Accept eventual consistency for device states\n- Implement conflict resolution strategies (last-write-wins, vector clocks, CRDTs)\n- Design compensating transactions for failed operations\n\n**Offline-First Design:**\n- Enable devices to operate independently during network outages\n- Queue messages locally when broker connection is lost\n- Implement state reconciliation upon reconnection\n- Design graceful degradation of functionality\n\n**Data Consistency Patterns:**\n- Use optimistic replication for device state\n- Implement causal consistency where order matters\n- Apply strong consistency only for critical operations (e.g., safety shutoffs)\n- Design idempotent operations to handle message replay\n\n### 2. Communication Architecture\n\nDesign robust communication patterns for device coordination:\n\n**Topology Patterns:**\n\n*Hub-and-Spoke (Argus Pattern):*\n- Central hub (e.g., Jetson Nano with MQTT broker) coordinates all devices\n- Devices communicate through the hub, not directly\n- Simplifies message routing and state management\n- Single point of failure mitigated with local device autonomy\n\n*Mesh Networking:*\n- Direct device-to-device communication when needed\n- Higher complexity but better fault tolerance\n- Consider for offline operation or peer coordination\n\n**MQTT Broker Design:**\n- Configure Mosquitto with appropriate QoS levels per message type\n- Implement retained messages for device state\n- Use persistent sessions for reliable delivery\n- Set up authentication and ACLs for security\n\n**Topic Naming Conventions:**\n```\n\u003Cdomain>\u002F\u003Cdevice_id>\u002F\u003Ccomponent>\u002F\u003Caction>\nExamples:\n- argus\u002Fpresto\u002Ftimer\u002Fstate\n- argus\u002Ftembed\u002Fdisplay\u002Fcommand\n- argus\u002Fphone\u002Fnotification\u002Fevent\n```\n\n**Quality of Service Strategy:**\n- QoS 0: Fire-and-forget for high-frequency sensor data\n- QoS 1: At-least-once for commands and state updates\n- QoS 2: Exactly-once for critical operations (use sparingly due to overhead)\n\n**Message Payload Optimization:**\n- Use compact JSON or binary formats (Protocol Buffers, MessagePack)\n- Minimize payload size for bandwidth-constrained devices\n- Batch non-urgent messages to reduce overhead\n- Implement compression for larger payloads\n\n### 3. Microservices for IoT\n\nDecompose monolithic systems into maintainable services:\n\n**Service Boundaries:**\n- One service per device type or functional domain\n- Services own their data and expose APIs\n- Bounded contexts prevent tight coupling\n- Each service can be developed, deployed, and scaled independently\n\n**API Design:**\n- RESTful APIs for synchronous operations (device configuration)\n- Event-driven messaging for asynchronous coordination (state changes)\n- WebSocket connections for real-time bidirectional communication\n- GraphQL for flexible data queries from dashboards\n\n**Service Discovery:**\n- Use mDNS\u002FBonjour for local network discovery\n- Implement service registry for dynamic environments\n- Hard-code endpoints for static deployments to reduce complexity\n\n**Inter-Service Communication:**\n- MQTT for event broadcasts and state synchronization\n- HTTP\u002FREST for request-response operations\n- gRPC for high-performance service-to-service calls\n- Message queues (Redis Streams) for work distribution\n\n**Failure Isolation:**\n- Circuit breakers to prevent cascade failures\n- Timeouts on all network operations\n- Bulkhead pattern to isolate resources\n- Health checks and automatic restart policies\n\n**Container Orchestration:**\n- Docker for backend service deployment\n- Docker Compose for local development and small deployments\n- Consider Kubernetes for large-scale production (>50 devices)\n- Maintain device firmware separate from backend containers\n\n### 4. Edge Computing Patterns\n\nOptimize processing placement between edge and cloud:\n\n**Processing Decision Framework:**\n\n*Process at Edge When:*\n- Real-time response required (\u003C100ms latency)\n- Bandwidth is limited or expensive\n- Privacy\u002Fsecurity requires local processing\n- Operation doesn't require cloud data\n- Example: Timer state transitions, button press handling\n\n*Process at Cloud When:*\n- Heavy computation required (ML inference on large models)\n- Data aggregation across multiple devices needed\n- Long-term storage and analytics required\n- Integration with external services needed\n- Example: Notification routing, usage analytics, backup\n\n**Data Aggregation at Edge:**\n- Pre-filter sensor data before sending to cloud\n- Compute running averages and statistics locally\n- Send only deltas or significant changes\n- Batch non-urgent updates\n\n**Real-Time Decision Making:**\n- Implement state machines on devices for autonomous operation\n- Use edge AI for local inference (TensorFlow Lite, ONNX Runtime)\n- Maintain decision logic at the edge to survive network outages\n- Update logic remotely via MQTT or OTA updates\n\n**Bandwidth Optimization:**\n- Compress data before transmission\n- Use delta encoding for state updates\n- Implement adaptive sampling rates based on network conditions\n- Cache frequently accessed cloud data at edge\n\n**Edge AI\u002FML Deployment:**\n- Run inference on Jetson Nano for vision tasks\n- Use TensorFlow Lite on ESP32\u002FRP2350 for simple models\n- Implement model quantization to reduce size\n- Update models remotely without reflashing firmware\n\n### 5. State Management\n\nSynchronize state across distributed devices reliably:\n\n**Device State Synchronization:**\n- Publish state changes to MQTT with retained messages\n- Subscribe to relevant device states for coordination\n- Handle out-of-order message delivery gracefully\n- Implement state versioning with timestamps or vector clocks\n\n**State Machine Design:**\n```\nStates: IDLE → RUNNING → PAUSED → COMPLETED\nEvents: start, pause, resume, reset, complete\nTransitions: validated to prevent invalid state changes\n```\n\n- Define clear states and valid transitions\n- Implement guards to prevent invalid transitions\n- Publish state change events for observability\n- Persist state to survive reboots\n\n**Conflict-Free Replicated Data Types (CRDTs):**\n- Use for state that multiple devices can modify\n- G-Counter for increment-only values (usage statistics)\n- LWW-Register for last-write-wins semantics\n- OR-Set for collaborative collections\n\n**Event Sourcing:**\n- Store all state changes as immutable events\n- Rebuild current state by replaying events\n- Enable time-travel debugging and audit trails\n- Simplify state synchronization across devices\n\n**State Recovery:**\n- Devices request current state upon reconnection\n- Use MQTT retained messages for latest state\n- Implement state snapshots to avoid replaying entire history\n- Handle partial state during recovery gracefully\n\n**Idempotent Operations:**\n- Design operations to have the same effect if repeated\n- Use unique message IDs to detect duplicates\n- Implement deduplication windows for recently processed messages\n- Critical for at-least-once delivery semantics\n\n### 6. Scalability Considerations\n\nDesign systems that scale from prototype to production:\n\n**Horizontal vs Vertical Scaling:**\n- Scale MQTT broker vertically for small deployments (\u003C100 devices)\n- Scale horizontally with broker clustering for large fleets\n- Use load balancers for HTTP\u002FREST APIs\n- Shard device connections across multiple broker instances\n\n**Load Balancing Strategies:**\n- Round-robin for stateless services\n- Consistent hashing for affinity-based routing\n- Geo-based routing for distributed deployments\n- Health-aware routing to avoid overloaded instances\n\n**Database Sharding:**\n- Partition device data by device ID or device type\n- Time-series databases (InfluxDB, TimescaleDB) for sensor data\n- Document stores (MongoDB) for device configurations\n- Use read replicas for analytics queries\n\n**Caching Strategies:**\n- Redis for session state and frequently accessed data\n- Cache device states at edge to reduce broker queries\n- Implement TTL-based expiration for stale data\n- Use cache-aside pattern for device configurations\n\n**Message Queue Sizing:**\n- Configure broker memory limits based on device count\n- Implement message TTL to prevent queue buildup\n- Monitor queue depth and set up alerts\n- Use dead-letter queues for failed message handling\n\n**Connection Pooling:**\n- Reuse MQTT connections across message publishes\n- Pool database connections in backend services\n- Implement connection retry with exponential backoff\n- Set appropriate keepalive intervals\n\n### 7. Architecture Decision Records (ADRs)\n\nDocument key architectural decisions with rationale:\n\n**When to Create an ADR:**\n- Choosing between MQTT, CoAP, or HTTP for device communication\n- Selecting edge vs cloud processing for specific workloads\n- Deciding on state synchronization strategy\n- Evaluating database technology for device data\n- Adopting new design patterns or frameworks\n\n**ADR Template:**\n\nUse the provided `assets\u002Fadr_template.md` to document decisions:\n\n```markdown\n# ADR-NNN: [Decision Title]\n\nDate: YYYY-MM-DD\nStatus: [Proposed | Accepted | Deprecated | Superseded]\n\n## Context\n[Describe the architectural challenge and constraints]\n\n## Decision\n[State the decision clearly]\n\n## Rationale\n[Explain why this decision was made]\n\n## Consequences\n[Document trade-offs, benefits, and drawbacks]\n\n## Alternatives Considered\n[List other options and why they were rejected]\n```\n\n**Best Practices:**\n- Number ADRs sequentially (ADR-001, ADR-002...)\n- Keep ADRs concise (1-2 pages maximum)\n- Update status as decisions evolve\n- Link related ADRs\n- Include performance metrics when relevant\n\n## Architecture Principles\n\nFollow these principles when designing IoT systems:\n\n1. **Loose Coupling**: Devices operate independently; failure of one device doesn't cascade\n2. **High Cohesion**: Group related functionality within service\u002Fdevice boundaries\n3. **Fail-Safe**: Design for graceful degradation when network or services fail\n4. **Observability**: Instrument with logging, metrics, and distributed tracing\n5. **Maintainability**: Clear module boundaries, documentation, and testability\n6. **Performance**: Meet real-time constraints through edge processing and optimization\n7. **Security**: Defense in depth with encryption, authentication, and authorization\n\n## Argus Reference Architecture\n\nThe Argus system provides a concrete example of these principles in practice:\n\n**System Overview:**\n```\n┌─────────────────────────────────────────────┐\n│         Android Device (Pixel Pro)          │\n│     [Notification Bridge & Control]         │\n└────────────┬──────────────┬─────────────────┘\n             │ BLE          │\n             ▼              ▼\n    ┌──────────────┐  ┌──────────────┐\n    │   Presto     │  │   T-Embed    │\n    │  (Central)   │◄─┤   (Desk)     │\n    │ RP2350+4\"    │  │ ESP32-S3     │\n    └──────┬───────┘  └──────┬───────┘\n           │ MQTT            │ MQTT\n           └────────┬────────┘\n                    ▼\n         ┌─────────────────────┐\n         │   Jetson Nano       │\n         │ [MQTT Broker+AI]    │\n         └─────────┬───────────┘\n                   │ WebSocket\n                   ▼\n         ┌─────────────────────┐\n         │   Stream Deck Neo   │\n         │  [Macro Control]    │\n         └─────────────────────┘\n```\n\n**Key Architectural Patterns Applied:**\n\n- **Observer Pattern**: All devices subscribe to timer state changes via MQTT\n- **State Pattern**: Timer implements multiple operating modes (work, break, long break)\n- **Strategy Pattern**: Different timing strategies (Pomodoro, custom intervals)\n- **Publish-Subscribe**: Core communication model enables loose coupling\n- **Singleton**: MQTT broker connection shared across device handlers\n\n**Multi-Device State Synchronization:**\n1. Presto publishes timer state to `argus\u002Fpresto\u002Ftimer\u002Fstate`\n2. T-Embed subscribes and updates display accordingly\n3. Phone receives notifications via BLE bridge\n4. Stream Deck reflects current state via WebSocket connection\n\n**Fallback Behavior During Outages:**\n- Presto operates autonomously if MQTT broker is down\n- T-Embed shows \"disconnected\" status but retains last known state\n- Phone queues notifications until BLE connection restored\n- System auto-recovers when connectivity returns\n\n**Scalable MQTT Topic Structure:**\n```\nargus\u002F\n├── presto\u002F\n│   ├── timer\u002Fstate          (retained, QoS 1)\n│   ├── timer\u002Fcommand        (QoS 1)\n│   └── button\u002Fevent         (QoS 0)\n├── tembed\u002F\n│   ├── display\u002Fstate        (retained, QoS 1)\n│   └── display\u002Fcommand      (QoS 1)\n├── phone\u002F\n│   ├── notification\u002Fevent   (QoS 1)\n│   └── notification\u002Fack     (QoS 1)\n└── system\u002F\n    ├── health               (QoS 0, periodic)\n    └── logs                 (QoS 0)\n```\n\nFor detailed design patterns and examples, see `references\u002Fdesign_patterns.md` and `references\u002Fargus_architecture.md`.\n\n## Diagramming and Modeling\n\nUse these techniques to communicate architecture effectively:\n\n**System Context Diagram (C4 Level 1):**\n- Show the system and its users\u002Fexternal systems\n- Identify system boundary and key interactions\n\n**Container Diagram (C4 Level 2):**\n- Show major containers (devices, services, databases)\n- Illustrate communication protocols and dependencies\n\n**Sequence Diagrams:**\n- Document multi-device interaction flows\n- Show message ordering and timing constraints\n- Highlight error and retry scenarios\n\n**State Diagrams:**\n- Model device state machines\n- Document valid transitions and guards\n- Clarify complex stateful behavior\n\n**Data Flow Diagrams:**\n- Trace data through the system\n- Identify transformation points\n- Highlight aggregation and filtering\n\n**Deployment Diagrams:**\n- Show physical device placement\n- Document network topology\n- Illustrate container orchestration\n\n## Resources\n\nThis skill includes bundled resources for reference and templates:\n\n### references\u002F\n\n- **`design_patterns.md`**: Comprehensive catalog of design patterns for IoT systems with examples and anti-patterns\n- **`argus_architecture.md`**: Detailed Argus system architecture including component specifications and implementation details\n\nLoad these references when working on complex architectural decisions or needing detailed pattern examples.\n\n### assets\u002F\n\n- **`adr_template.md`**: Architecture Decision Record template for documenting key design decisions\n\nCopy this template when creating new ADRs for IoT projects.\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect",{"tool":70,"command":71},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect",{"tool":73,"command":74},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002FSKILL.md",true,[78,84,90],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Fadr_template.md","ASSET","资产文件",6950,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fassets\u002Fadr_template.md",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fargus_architecture.md","REFERENCE","参考文档",13366,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Freferences\u002Fargus_architecture.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fdesign_patterns.md",16732,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Freferences\u002Fdesign_patterns.md",[95,112,143,169,191,211],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"publishedAt":49},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[105,106,107,108,109,110,111],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":124,"publishedAt":49},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":122,"categoryName":123,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[114,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,41,140,141,142],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","code","unknown","generated",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":153,"publishedAt":49},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[149,150],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":151,"categoryName":152,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[145,154,155,156,157,158,159,160,133,161,162,163,43,164,165,166,167,168],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","use","auto","types","Video","创作",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":49},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[175],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},[177,178,145,179,180,167,181,182,183,184,185,186,187,188,131,189,43,164,125,190],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":201,"publishedAt":49},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[197,198,199,200],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":151,"categoryName":152,"taxonomyType":26,"taxonomyTypeDesc":27},[202,110,203,204,205,206,140,43,164,207,208,209,210],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":219,"publishedAt":49},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[217,218],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":151,"categoryName":152,"taxonomyType":26,"taxonomyTypeDesc":27},[220,110,221,129,222,208,43,203,206,164,209],"Rules","writing rules","project rules"]