Python Azure Iot Edge Modules

Build and operate Python Azure IoT Edge modules with reliable messaging, deployment manifests, observability, security, and production readiness checks. Use when creating Python IoT Edge modules, deploying edge manifests, processing telemetry at the edge, handling disconnected operation, or validating IoT Edge readiness.

paulasilvatech 9e98ff9 3 files · 10.2 KB Updated Sep 17, 2026

Install

Press C to copy

$ npx skillmds@latest add paulasilvatech/python-azure-iot-edge-modules

Installs into ~/.claude/skills (or .claude/skills inside a project). Restart Claude Code to pick it up.

＋ Add to collection

README badge

[![SkillMD](https://skillmd.com/badge/paulasilvatech/python-azure-iot-edge-modules.svg)](https://skillmd.com/skills/paulasilvatech/python-azure-iot-edge-modules)

Trust & safety

Audits pending

Not yet audited · commit 9e98ff9

Works with: Claude Code Claude.ai OpenAI Codex +

File contents

Python Azure IoT Edge modules

Designs, implements, and validates Python-based Azure IoT Edge modules for telemetry processing, local inference, protocol translation, command orchestration, and edge-to-cloud integration.

When to invoke

"quiero crear un modulo Python para IoT Edge"
"como despliego modulos edge con manifest"
"necesito filtrar/agregar telemetria antes de subirla"
"como manejo desconexiones y reintentos en edge"
"Validate this Python IoT Edge module for production readiness."

Prerequisites and context

Before recommending runtime behavior or deployment decisions, review current Azure IoT Edge documentation:

Before proposing Python implementation details, consult official Python sources:

https://www.python.org/
https://docs.python.org/3/
https://docs.python.org/3/reference/
https://docs.python.org/3/harness/github-copilot/
references/python-official-best-practices.md

If documentation cannot be fetched, proceed with explicit assumptions and flag them clearly.

Procedure

Define the contract: module inputs, outputs, message schema, schema versioning, routes, priorities, and desired properties.
Specify runtime and packaging: Python version target, base image, container footprint, CVE hygiene, CPU and memory bounds, startup checks, and health checks.
Design reliability: retries with exponential backoff and jitter, graceful degradation, bounded local queueing, and idempotent replay handling.
Define security controls: no plaintext secrets, least-privilege behavior, secure transport, trusted certificate chain handling, and command traceability.
Describe deployment and operations: environment-specific manifests, pilot/staged/broad rollout, rollback criteria, SLOs, alerts, and observability.
Validate with a test matrix covering functional, chaos, performance, and rollback scenarios.

Module design areas

Area	Required decisions
Use case	Protocol adapter for serial/Modbus/OPC-UA, telemetry enrichment, local anomaly detection or inference, command orchestration, or local actuator control.
Inputs and outputs	Named inputs, output routes, schema version, critical telemetry priority, and normal telemetry route.
Configuration	Desired properties for dynamic config; reported properties for status and current config.
Packaging	Python runtime, image base, dependency pinning, startup command, health probe, and restart behavior.
Resources	CPU and memory bounds that match the edge device.
Operations	SLOs, alert conditions, logs, metrics, and rollout/rollback stages.

Reliability and security rules

Concern	Rule
Network variability	Use exponential backoff with jitter; avoid tight retry loops.
Offline mode	Buffer locally only with a bounded queue and clear drop policy.
Replay	Make processing idempotent for repeated messages.
Upstream failure	Degrade gracefully and preserve local control paths when required.
Secrets	Never embed secrets in Dockerfiles, source, or deployment manifests.
Transport	Use secure transport and validate the trusted cert chain.
Commands	Authorize and trace command handling and state changes.
Rollout	Never recommend direct production rollout without a pilot stage.

Progressive disclosure and bundled resources

references/python-edge-module-template.md: output structure for implementation proposals and reviews.
references/python-official-best-practices.md: baseline Python quality criteria.

Related primitives

Name	Type	Use it when
`azure-smart-city-iot-solution-builder`	skill	The request is platform-level smart city IoT architecture and phased rollout.
`appinsights-instrumentation`	skill	The request focuses on telemetry instrumentation patterns.
`azure-resource-visualizer`	skill	The request needs architecture diagrams or dependency mapping.

Edge module quality vocabulary

Keep designs production-focused, include error-handling, and check current release/version guidance before making runtime recommendations.

Output template

### Python Azure IoT Edge module result

**Status:** design ready | implementation plan | review findings | blocked
**Context and assumptions:** <runtime, device, connectivity, documentation assumptions>

## 1. Module design brief
- Purpose: <module purpose>
- Inputs: <module inputs>
- Outputs: <module outputs>
- Message schema/version: <schema and versioning policy>

## 2. Deployment model
- Image: <base image and tag policy>
- Manifest settings: <routes, env, desired properties>
- Resource limits: <CPU/memory>

## 3. Reliability and error handling
- Retries: <backoff and jitter>
- Offline behavior: <queue, bounds, drop policy>
- Idempotency: <replay handling>

## 4. Security and operations checklist
- <identity, secrets, cert chain, command audit, health, SLOs>

## 5. Test matrix
| Test | Method | Expected result |
| --- | --- | --- |
| Functional | <case> | <result> |
| Chaos | <disconnect/restart> | <result> |
| Performance | <load> | <result> |
| Rollback | <rollback condition> | <result> |

Quality gate

Azure IoT Edge and Python official documentation were reviewed or assumptions were stated.
Module inputs, outputs, message schema, routes, and desired properties are defined.
Deployment model covers image, manifest, env settings, health probes, and restart behavior.
Reliability strategy includes backoff with jitter, bounded buffering, and idempotency.
No plaintext secrets are placed in Dockerfiles, source, or manifests.
Rollout includes pilot, staged, broad, and rollback criteria.
Test matrix covers functional, chaos, performance, and rollback tests.

References

---name: python-azure-iot-edge-modulesdescription: Build and operate Python Azure IoT Edge modules with reliable messaging, deployment manifests, observability, security, and production readiness checks. Use when creating Python IoT Edge modules, deploying edge manifests, processing telemetry at the edge, handling disconnected operation, or validating IoT Edge readiness.---# Python Azure IoT Edge modulesDesigns, implements, and validates Python-based Azure IoT Edge modules for telemetry processing, local inference, protocol translation, command orchestration, and edge-to-cloud integration.## When to invoke- "quiero crear un modulo Python para IoT Edge"- "como despliego modulos edge con manifest"- "necesito filtrar/agregar telemetria antes de subirla"- "como manejo desconexiones y reintentos en edge"- "Validate this Python IoT Edge module for production readiness."## Prerequisites and contextBefore recommending runtime behavior or deployment decisions, review current Azure IoT Edge documentation:- https://learn.microsoft.com/azure/iot-edge/- https://learn.microsoft.com/es-es/azure/iot-edge/Before proposing Python implementation details, consult official Python sources:- https://www.python.org/- https://docs.python.org/3/- https://docs.python.org/3/reference/- https://docs.python.org/3/harness/github-copilot/- `references/python-official-best-practices.md`If documentation cannot be fetched, proceed with explicit assumptions and flag them clearly.## Procedure1. Define the contract: module inputs, outputs, message schema, schema versioning, routes, priorities, and desired properties.2. Specify runtime and packaging: Python version target, base image, container footprint, CVE hygiene, CPU and memory bounds, startup checks, and health checks.3. Design reliability: retries with exponential backoff and jitter, graceful degradation, bounded local queueing, and idempotent replay handling.4. Define security controls: no plaintext secrets, least-privilege behavior, secure transport, trusted certificate chain handling, and command traceability.5. Describe deployment and operations: environment-specific manifests, pilot/staged/broad rollout, rollback criteria, SLOs, alerts, and observability.6. Validate with a test matrix covering functional, chaos, performance, and rollback scenarios.## Module design areas| Area | Required decisions || --- | --- || Use case | Protocol adapter for serial/Modbus/OPC-UA, telemetry enrichment, local anomaly detection or inference, command orchestration, or local actuator control. || Inputs and outputs | Named inputs, output routes, schema version, critical telemetry priority, and normal telemetry route. || Configuration | Desired properties for dynamic config; reported properties for status and current config. || Packaging | Python runtime, image base, dependency pinning, startup command, health probe, and restart behavior. || Resources | CPU and memory bounds that match the edge device. || Operations | SLOs, alert conditions, logs, metrics, and rollout/rollback stages. |## Reliability and security rules| Concern | Rule || --- | --- || Network variability | Use exponential backoff with jitter; avoid tight retry loops. || Offline mode | Buffer locally only with a bounded queue and clear drop policy. || Replay | Make processing idempotent for repeated messages. || Upstream failure | Degrade gracefully and preserve local control paths when required. || Secrets | Never embed secrets in Dockerfiles, source, or deployment manifests. || Transport | Use secure transport and validate the trusted cert chain. || Commands | Authorize and trace command handling and state changes. || Rollout | Never recommend direct production rollout without a pilot stage. |## Progressive disclosure and bundled resources- `references/python-edge-module-template.md`: output structure for implementation proposals and reviews.- `references/python-official-best-practices.md`: baseline Python quality criteria.## Related primitives| Name | Type | Use it when || --- | --- | --- || `azure-smart-city-iot-solution-builder` | skill | The request is platform-level smart city IoT architecture and phased rollout. || `appinsights-instrumentation` | skill | The request focuses on telemetry instrumentation patterns. || `azure-resource-visualizer` | skill | The request needs architecture diagrams or dependency mapping. |## Edge module quality vocabularyKeep designs `production-focused`, include `error-handling`, and check current `release/version` guidance before making runtime recommendations.## Output template```markdown### Python Azure IoT Edge module result**Status:** design ready | implementation plan | review findings | blocked**Context and assumptions:** <runtime, device, connectivity, documentation assumptions>## 1. Module design brief- Purpose: <module purpose>- Inputs: <module inputs>- Outputs: <module outputs>- Message schema/version: <schema and versioning policy>## 2. Deployment model- Image: <base image and tag policy>- Manifest settings: <routes, env, desired properties>- Resource limits: <CPU/memory>## 3. Reliability and error handling- Retries: <backoff and jitter>- Offline behavior: <queue, bounds, drop policy>- Idempotency: <replay handling>## 4. Security and operations checklist- <identity, secrets, cert chain, command audit, health, SLOs>## 5. Test matrix| Test | Method | Expected result || --- | --- | --- || Functional | <case> | <result> || Chaos | <disconnect/restart> | <result> || Performance | <load> | <result> || Rollback | <rollback condition> | <result> |```## Quality gate- [ ] Azure IoT Edge and Python official documentation were reviewed or assumptions were stated.- [ ] Module inputs, outputs, message schema, routes, and desired properties are defined.- [ ] Deployment model covers image, manifest, env settings, health probes, and restart behavior.- [ ] Reliability strategy includes backoff with jitter, bounded buffering, and idempotency.- [ ] No plaintext secrets are placed in Dockerfiles, source, or manifests.- [ ] Rollout includes pilot, staged, broad, and rollback criteria.- [ ] Test matrix covers functional, chaos, performance, and rollback tests.## References- [Azure IoT Edge](https://learn.microsoft.com/azure/iot-edge/)- [Azure IoT Edge Spanish documentation](https://learn.microsoft.com/es-es/azure/iot-edge/)- [Python](https://www.python.org/)- [Python 3 documentation](https://docs.python.org/3/)- [Python language reference](https://docs.python.org/3/reference/)- [Python standard library](https://docs.python.org/3/harness/github-copilot/)

paulasilvatech/awesome-harness-primitives/tree/main/harness/claude-code/skills/python-azure-iot-edge-modules commit 9e98ff92dc

Frequently asked questions

npx skillmds@latest add paulasilvatech/python-azure-iot-edge-modules