mirror of
https://github.com/github/awesome-copilot.git
synced 2026-05-04 14:15:55 +00:00
feat(skills): add IoT edge skills and align agent/instruction docs (#1431)
* feat(skills): add IoT edge skills and align agent/instruction docs * fix(ci): handle fork permission errors in plugin structure check * fix(ci): allow intentional Spanish vocabulary in codespell * docs(skills): translate IoT edge skill content to English * fix(ci): pass codespell and README validation * chore: regenerate skills index after merge
This commit is contained in:
Sertxito
GitHub
141
skills/arduino-azure-iot-edge-integration/SKILL.md
Normal file
141
skills/arduino-azure-iot-edge-integration/SKILL.md
Normal file
@@ -0,0 +1,141 @@
|
||||
---
|
||||
name: arduino-azure-iot-edge-integration
|
||||
description: 'Design and implement Arduino integration with Azure IoT Hub and IoT Edge, including secure provisioning, resilient telemetry, command handling, and production guardrails.'
|
||||
---
|
||||
|
||||
# Arduino Azure IoT Edge Integration
|
||||
|
||||
Use this skill when the user needs to connect Arduino-class devices to Azure IoT, especially in edge-heavy scenarios (gateways, intermittent networks, offline buffering, and local actuation).
|
||||
|
||||
## When to use it
|
||||
|
||||
Use this skill for requests such as:
|
||||
|
||||
- "I want to connect Arduino sensors to Azure"
|
||||
- "How do I send MQTT telemetry to IoT Hub?"
|
||||
- "I need an edge gateway for field devices"
|
||||
- "I want cloud-to-device commands and OTA configuration updates"
|
||||
|
||||
## Mandatory documentation review
|
||||
|
||||
Before recommending an IoT Edge topology or runtime behavior, review:
|
||||
|
||||
- https://learn.microsoft.com/azure/iot-edge/
|
||||
|
||||
If documentation cannot be consulted, proceed with explicit assumptions and highlight them in a dedicated section.
|
||||
|
||||
## Official Arduino references and best practices (required)
|
||||
|
||||
Before proposing firmware, wiring, or communication implementation details, consult official Arduino sources first:
|
||||
|
||||
- https://www.arduino.cc/en/Guide
|
||||
- https://docs.arduino.cc/
|
||||
- https://docs.arduino.cc/language-reference/
|
||||
- references/arduino-official-best-practices.md
|
||||
|
||||
When choosing between implementation alternatives, prioritize official Arduino guidance over community snippets unless there is a clear technical reason to deviate.
|
||||
|
||||
## Objectives
|
||||
|
||||
- Produce a secure end-to-end reference path from the Arduino device to cloud insights.
|
||||
- Handle unstable links (store-and-forward, retries, idempotency).
|
||||
- Define an actionable device and cloud backlog.
|
||||
|
||||
## Integration patterns
|
||||
|
||||
### Pattern A: Arduino direct to IoT Hub
|
||||
|
||||
Use when connectivity is stable and cloud latency is acceptable.
|
||||
|
||||
- Protocol: MQTT over TLS.
|
||||
- Identity: per-device credentials (SAS or X.509).
|
||||
- Telemetry payload: compact JSON with timestamp, device ID, metrics, and optional quality flags.
|
||||
|
||||
### Pattern B: Arduino to local gateway, then IoT Edge
|
||||
|
||||
Use when links are constrained, local control is required, or batching improves cost/reliability.
|
||||
|
||||
- Arduino communicates with a local gateway (serial, BLE, local MQTT, RS-485, Modbus bridge).
|
||||
- The gateway publishes upstream through the IoT Edge runtime and routes data to IoT Hub.
|
||||
- Local modules can filter, aggregate, and trigger actions even during cloud outages.
|
||||
|
||||
## Design flow
|
||||
|
||||
### 1) Device contract
|
||||
|
||||
Define:
|
||||
|
||||
- Sensor catalog and units.
|
||||
- Sampling frequency and expected throughput.
|
||||
- Message schema versioning strategy.
|
||||
- Desired/reported device twin properties to control runtime behavior.
|
||||
|
||||
### 2) Security baseline
|
||||
|
||||
Require:
|
||||
|
||||
- Unique identity per device.
|
||||
- No hardcoded secrets in source code or firmware artifacts.
|
||||
- Credential rotation strategy.
|
||||
- Signed firmware and a controlled update process when possible.
|
||||
|
||||
### 3) Reliability and offline behavior
|
||||
|
||||
Plan and document:
|
||||
|
||||
- Backoff with jitter.
|
||||
- Local queue/buffer strategy with bounded size.
|
||||
- Duplicate suppression or downstream idempotent processing.
|
||||
- Fallback to last-known-good configuration.
|
||||
|
||||
### 4) Cloud and edge routing
|
||||
|
||||
Define routes for:
|
||||
|
||||
- Raw telemetry to cold storage.
|
||||
- Curated telemetry to hot analytics.
|
||||
- Alerts to operations channels.
|
||||
- Commands and configuration back to edge/device.
|
||||
|
||||
### 5) Observability
|
||||
|
||||
Specify minimum operations telemetry:
|
||||
|
||||
- Device heartbeat and firmware version.
|
||||
- Connectivity state transitions.
|
||||
- Message send success/error counters.
|
||||
- Gateway module health and restart reasons.
|
||||
|
||||
## Reuse other skills
|
||||
|
||||
When relevant, combine with:
|
||||
|
||||
- `azure-smart-city-iot-solution-builder` for city-wide architecture and phased rollout.
|
||||
- `azure-resource-visualizer` for relationship diagrams.
|
||||
- `appinsights-instrumentation` for app and service telemetry patterns.
|
||||
|
||||
Also use `references/arduino-official-best-practices.md` as a quality baseline for firmware and hardware recommendations.
|
||||
|
||||
## Required output
|
||||
|
||||
Always provide:
|
||||
|
||||
1. Chosen connectivity pattern and rationale.
|
||||
2. Message contract (fields, units, sample payload).
|
||||
3. Security checklist for identity/credentials/updates.
|
||||
4. Reliability plan (retry, buffering, dedupe).
|
||||
5. Implementation backlog (firmware, gateway, cloud).
|
||||
|
||||
## Output template
|
||||
|
||||
1. Scenario and assumptions
|
||||
2. Recommended architecture
|
||||
3. Device and gateway contract
|
||||
4. Security and reliability controls
|
||||
5. Deployment plan and validation tests
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Do not propose production deployments with shared credentials across devices.
|
||||
- Do not assume always-on connectivity in field deployments.
|
||||
- Do not omit command authorization and auditing in actuator scenarios.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Arduino Azure IoT Checklist
|
||||
|
||||
Use this checklist before finalizing architecture or implementation guidance.
|
||||
|
||||
## 0) Official Arduino Baseline
|
||||
|
||||
- Official references reviewed from <https://www.arduino.cc/en/Guide> and <https://docs.arduino.cc/>.
|
||||
- Language/API calls validated against <https://docs.arduino.cc/language-reference/>.
|
||||
- Best practices reviewed from `references/arduino-official-best-practices.md`.
|
||||
|
||||
## 1) Device Profile
|
||||
|
||||
- MCU model and memory constraints documented.
|
||||
- Sensor list and sampling strategy defined.
|
||||
- Power model documented (mains, battery, sleep cycles).
|
||||
|
||||
## 2) Connectivity
|
||||
|
||||
- Selected transport documented (MQTT over TLS preferred).
|
||||
- Network failure behavior defined.
|
||||
- Local timestamp strategy defined if device lacks RTC sync.
|
||||
|
||||
## 3) Security
|
||||
|
||||
- Unique identity per device.
|
||||
- No secrets in source control.
|
||||
- Credential rotation plan documented.
|
||||
- Firmware update and rollback plan documented.
|
||||
|
||||
## 4) Edge and Cloud Flow
|
||||
|
||||
- Routing from edge to IoT Hub documented.
|
||||
- Offline buffering limits defined.
|
||||
- Duplicate handling strategy documented.
|
||||
- Alerting thresholds and destinations defined.
|
||||
|
||||
## 5) Validation
|
||||
|
||||
- Connectivity soak test scenario.
|
||||
- Packet loss and reconnection test.
|
||||
- Command authorization test.
|
||||
- Firmware version and health reporting verification.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Arduino Official References and Best Practices
|
||||
|
||||
Use these official Arduino resources before finalizing firmware or hardware guidance.
|
||||
|
||||
## Official References
|
||||
|
||||
- Arduino main guide: <https://www.arduino.cc/en/Guide>
|
||||
- Arduino docs home: <https://docs.arduino.cc/>
|
||||
- Getting started path: <https://docs.arduino.cc/learn/starting-guide/getting-started-arduino/>
|
||||
- Arduino IDE usage: <https://docs.arduino.cc/learn/starting-guide/the-arduino-software-ide/>
|
||||
- Arduino language reference: <https://docs.arduino.cc/language-reference/>
|
||||
- Arduino programming reference overview: <https://docs.arduino.cc/learn/programming/reference/>
|
||||
- Arduino memory guide: <https://docs.arduino.cc/learn/programming/memory-guide/>
|
||||
- Arduino debugging fundamentals: <https://docs.arduino.cc/learn/microcontrollers/debugging/>
|
||||
- Arduino low-power design guide: <https://docs.arduino.cc/learn/electronics/low-power/>
|
||||
- Arduino communication protocols index: <https://docs.arduino.cc/learn/communication/>
|
||||
- Arduino style guide for libraries: <https://docs.arduino.cc/learn/contributions/arduino-library-style-guide/>
|
||||
|
||||
## Firmware Best Practices
|
||||
|
||||
- Keep the `loop()` non-blocking; avoid long `delay()` usage in production logic.
|
||||
- Use `millis()`-based scheduling for periodic tasks.
|
||||
- Budget SRAM explicitly and avoid dynamic allocation in hot paths.
|
||||
- Validate sensor ranges and provide safe defaults for invalid readings.
|
||||
- Add startup self-checks and periodic health heartbeat messages.
|
||||
- Version the payload schema and firmware version in every telemetry stream.
|
||||
- Implement retry with exponential backoff and jitter for network operations.
|
||||
- Store credentials outside source code and rotate them according to policy.
|
||||
|
||||
## Hardware and Power Best Practices
|
||||
|
||||
- Document voltage levels, pin mapping, and current limits per peripheral.
|
||||
- Design for brownout and power fluctuation scenarios.
|
||||
- Use watchdog and safe recovery behavior where available.
|
||||
- Plan low-power modes for battery deployments and validate wake cycles.
|
||||
|
||||
## Integration Best Practices for Azure IoT
|
||||
|
||||
- Prefer secure transports (MQTT over TLS) and per-device identity.
|
||||
- Define idempotent upstream processing for duplicate message scenarios.
|
||||
- Include device health metrics (uptime, reset reason, RSSI where applicable).
|
||||
- Validate offline buffering bounds to avoid uncontrolled memory growth.
|
||||
Reference in New Issue
Block a user