Design and implement Arduino integration with Azure IoT Hub and IoT Edge, including secure provisioning, MQTT telemetry, gateway topologies, offline buffering, command handling, OTA configuration, and production guardrails. Use when connecting Arduino sensors or actuators to Azure IoT or edge gateways.
Connects Arduino-class devices to Azure IoT Hub or an IoT Edge gateway with secure identity, resilient telemetry, command authorization, local buffering, and a practical firmware, gateway, and cloud backlog.
When to invoke
"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."
"Design Arduino telemetry with offline buffering and local actuation."
Prerequisites and context
Before recommending IoT Edge topology or runtime behavior, review:
If documentation cannot be consulted, proceed with explicit assumptions and highlight them in the output.
Connectivity patterns
Pattern
Use when
Design notes
Arduino direct to IoT Hub
Connectivity is stable and cloud latency is acceptable.
Use MQTT over TLS, per-device SAS or X.509 credentials, and compact JSON with timestamp, device ID, metrics, and optional quality flags.
Arduino to local gateway, then IoT Edge
Links are constrained, local control is required, batching improves reliability or cost, or offline behavior matters.
Arduino communicates with a local gateway through serial, BLE, local MQTT, RS-485, or Modbus bridge; the gateway publishes through IoT Edge routes.
Design flow
Define the device contract: sensor catalog, units, sampling frequency, expected throughput, message schema versioning, desired properties, and reported properties.
Establish the security baseline: unique identity per device, no hardcoded secrets, credential rotation, signed firmware, and controlled update process where possible.
Plan reliability and offline behavior: backoff with jitter, bounded local queue, duplicate suppression, idempotent downstream processing, and fallback to last-known-good configuration.
Define cloud and edge routes: raw telemetry to cold storage, curated telemetry to hot analytics, alerts to operations channels, and commands/configuration back to edge or device.
Specify observability: heartbeat, firmware version, connectivity state transitions, message send success/error counters, gateway module health, and restart reasons.
Message and command contract
Field
Rule
deviceId
Stable per-device identity; do not share across devices.
timestamp
Use device time only when synchronized; otherwise include gateway receipt time.
schemaVersion
Increment on incompatible payload changes.
metrics
Include units, quality flags, and sampling frequency assumptions.
Commands
Authorize, audit, validate parameters, and define safe fallback for actuator scenarios.
OTA configuration
Use desired/reported properties for configuration state; do not use ad hoc unaudited command payloads.
Gotchas
Do not use shared credentials across devices: shared SAS keys break revocation, auditing, and production operations.
Do not assume always-on connectivity: field deployments need buffering, retries, dedupe, and last-known-good config.
Do not omit command authorization: actuator scenarios require audit trails and safe failure behavior.
Do not choose direct-to-cloud by default: use a gateway when local control, constrained links, or batching are load-bearing.
Progressive disclosure and bundled resources
references/arduino-official-best-practices.md: official Arduino quality baseline for firmware and hardware recommendations.
references/arduino-iot-checklist.md: architecture and implementation checklist before finalizing guidance.
Related primitives
Name
Type
Use it when
azure-smart-city-iot-solution-builder
skill
The request is city-wide architecture and phased rollout.
azure-resource-visualizer
skill
The request needs relationship diagrams.
appinsights-instrumentation
skill
The request focuses on telemetry instrumentation patterns.
Arduino edge vocabulary
This skill covers edge-heavy, end-to-end designs with store-and-forward, queue/buffer, Desired/reported twin properties, identity/credentials/updates., cost/reliability., and edge/device. routing decisions.
Output template
### Arduino Azure IoT integration result
**Status:** architecture ready | implementation backlog | blocked
**Scenario and assumptions:** <connectivity, board class, gateway, docs assumptions>
## 1. Recommended architecture
**Pattern:** Arduino direct to IoT Hub | Arduino to local gateway, then IoT Edge
**Rationale:** <why this pattern fits>
## 2. Device and gateway contract
**Telemetry payload:**
```json
{
"deviceId": "<device-id>",
"timestamp": "<ISO-8601>",
"schemaVersion": "1.0",
"metrics": { "<name>": { "value": 0, "unit": "<unit>", "quality": "good" } }
}
```
**Commands/configuration:** <desired/reported properties and authorization>
## 3. Security and reliability controls
- Identity and credentials: <plan>
- Retry, buffering, dedupe: <plan>
- Firmware/update controls: <plan>
## 4. Deployment plan and validation tests
| Backlog item | Owner area | Validation |
| --- | --- | --- |
| <firmware/gateway/cloud item> | <area> | <test> |
Quality gate
Azure IoT Edge and official Arduino documentation were reviewed or assumptions were stated.
Connectivity pattern and rationale are explicit.
Message contract includes fields, units, schema version, and sample payload.
Security checklist covers identity, credentials, command authorization, auditing, and updates.
Reliability plan covers retry, buffering, dedupe, and last-known-good config.
Implementation backlog covers firmware, gateway, and cloud work.
1---2name: arduino-azure-iot-edge-integration3description: Design and implement Arduino integration with Azure IoT Hub and IoT Edge, including secure provisioning, MQTT telemetry, gateway topologies, offline buffering, command handling, OTA configuration, and production guardrails. Use when connecting Arduino sensors or actuators to Azure IoT or edge gateways.4---56<!-- Generated from harness/github-copilot/skills/arduino-azure-iot-edge-integration/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->78# Arduino Azure IoT Edge integration910Connects Arduino-class devices to Azure IoT Hub or an IoT Edge gateway with secure identity, resilient telemetry, command authorization, local buffering, and a practical firmware, gateway, and cloud backlog.1112## When to invoke1314- "I want to connect Arduino sensors to Azure."15- "How do I send MQTT telemetry to IoT Hub?"16- "I need an edge gateway for field devices."17- "I want cloud-to-device commands and OTA configuration updates."18- "Design Arduino telemetry with offline buffering and local actuation."1920## Prerequisites and context2122Before recommending IoT Edge topology or runtime behavior, review:2324- https://learn.microsoft.com/azure/iot-edge/2526Before proposing firmware, wiring, or communication implementation details, consult official Arduino sources first:2728- https://docs.arduino.cc/learn/starting-guide/getting-started-arduino/29- https://docs.arduino.cc/30- https://docs.arduino.cc/language-reference/31- `references/arduino-official-best-practices.md`3233If documentation cannot be consulted, proceed with explicit assumptions and highlight them in the output.3435## Connectivity patterns3637| Pattern | Use when | Design notes |38| --- | --- | --- |39| Arduino direct to IoT Hub | Connectivity is stable and cloud latency is acceptable. | Use MQTT over TLS, per-device SAS or X.509 credentials, and compact JSON with timestamp, device ID, metrics, and optional quality flags. |40| Arduino to local gateway, then IoT Edge | Links are constrained, local control is required, batching improves reliability or cost, or offline behavior matters. | Arduino communicates with a local gateway through serial, BLE, local MQTT, RS-485, or Modbus bridge; the gateway publishes through IoT Edge routes. |4142## Design flow43441. Define the device contract: sensor catalog, units, sampling frequency, expected throughput, message schema versioning, desired properties, and reported properties.452. Establish the security baseline: unique identity per device, no hardcoded secrets, credential rotation, signed firmware, and controlled update process where possible.463. Plan reliability and offline behavior: backoff with jitter, bounded local queue, duplicate suppression, idempotent downstream processing, and fallback to last-known-good configuration.474. Define cloud and edge routes: raw telemetry to cold storage, curated telemetry to hot analytics, alerts to operations channels, and commands/configuration back to edge or device.485. Specify observability: heartbeat, firmware version, connectivity state transitions, message send success/error counters, gateway module health, and restart reasons.4950## Message and command contract5152| Field | Rule |53| --- | --- |54| `deviceId` | Stable per-device identity; do not share across devices. |55| `timestamp` | Use device time only when synchronized; otherwise include gateway receipt time. |56| `schemaVersion` | Increment on incompatible payload changes. |57| `metrics` | Include units, quality flags, and sampling frequency assumptions. |58| Commands | Authorize, audit, validate parameters, and define safe fallback for actuator scenarios. |59| OTA configuration | Use desired/reported properties for configuration state; do not use ad hoc unaudited command payloads. |6061## Gotchas6263- **Do not use shared credentials across devices**: shared SAS keys break revocation, auditing, and production operations.64- **Do not assume always-on connectivity**: field deployments need buffering, retries, dedupe, and last-known-good config.65- **Do not omit command authorization**: actuator scenarios require audit trails and safe failure behavior.66- **Do not choose direct-to-cloud by default**: use a gateway when local control, constrained links, or batching are load-bearing.6768## Progressive disclosure and bundled resources6970- `references/arduino-official-best-practices.md`: official Arduino quality baseline for firmware and hardware recommendations.71- `references/arduino-iot-checklist.md`: architecture and implementation checklist before finalizing guidance.7273## Related primitives7475| Name | Type | Use it when |76| --- | --- | --- |77| `azure-smart-city-iot-solution-builder` | skill | The request is city-wide architecture and phased rollout. |78| `azure-resource-visualizer` | skill | The request needs relationship diagrams. |79| `appinsights-instrumentation` | skill | The request focuses on telemetry instrumentation patterns. |8081## Arduino edge vocabulary8283This skill covers `edge-heavy`, `end-to-end` designs with `store-and-forward`, `queue/buffer`, `Desired/reported` twin properties, `identity/credentials/updates.`, `cost/reliability.`, and `edge/device.` routing decisions.8485## Output template8687````markdown88### Arduino Azure IoT integration result8990**Status:** architecture ready | implementation backlog | blocked91**Scenario and assumptions:** <connectivity, board class, gateway, docs assumptions>9293## 1. Recommended architecture94**Pattern:** Arduino direct to IoT Hub | Arduino to local gateway, then IoT Edge95**Rationale:** <why this pattern fits>9697## 2. Device and gateway contract98**Telemetry payload:**99```json100{101 "deviceId": "<device-id>",102 "timestamp": "<ISO-8601>",103 "schemaVersion": "1.0",104 "metrics": { "<name>": { "value": 0, "unit": "<unit>", "quality": "good" } }105}106```107**Commands/configuration:** <desired/reported properties and authorization>108109## 3. Security and reliability controls110- Identity and credentials: <plan>111- Retry, buffering, dedupe: <plan>112- Firmware/update controls: <plan>113114## 4. Deployment plan and validation tests115| Backlog item | Owner area | Validation |116| --- | --- | --- |117| <firmware/gateway/cloud item> | <area> | <test> |118````119120## Quality gate121122- [ ] Azure IoT Edge and official Arduino documentation were reviewed or assumptions were stated.123- [ ] Connectivity pattern and rationale are explicit.124- [ ] Message contract includes fields, units, schema version, and sample payload.125- [ ] Security checklist covers identity, credentials, command authorization, auditing, and updates.126- [ ] Reliability plan covers retry, buffering, dedupe, and last-known-good config.127- [ ] Implementation backlog covers firmware, gateway, and cloud work.128129## References130131- [Azure IoT Edge](https://learn.microsoft.com/azure/iot-edge/)132- [Arduino getting started](https://docs.arduino.cc/learn/starting-guide/getting-started-arduino/)133- [Arduino documentation](https://docs.arduino.cc/)134- [Arduino language reference](https://docs.arduino.cc/language-reference/)
Run npx skillmds@latest add paulasilvatech/arduino-azure-iot-edge-integration in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Design and implement Arduino integration with Azure IoT Hub and IoT Edge, including secure provisioning, MQTT telemetry, gateway topologies, offline buffering, command handling, OTA configuration, and production guardrails. Use when connecting Arduino sensors or actuators to Azure IoT or edge gateways. It is listed under DevOps & Infra on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
paulasilvatech (@paulasilvatech) published this skill. Their other Agent Skills are listed on their SkillMD profile.