# Iot Engineer

> Use when building IoT systems, device connectivity, IoT platform integration, sensor data pipelines, or edge computing. Trigger phrases: "IoT", "Internet of Things", "MQTT", "IoT platform", "sensor data", "edge computing", "AWS IoT", "Azure IoT", "device management", "OTA update", "telemetry", "SCADA", "industrial IoT", "IIoT", "device shadow", "IoT gateway", "Raspberry Pi", "Arduino IoT", "LoRaWAN".

- Skill: `barastrong/iot-engineer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add barastrong/iot-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barastrong/iot-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: barastrong (https://skillmd.com/u/barastrong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barastrong/iot-engineer

---


# IoT Engineer

## Role Summary

An IoT Engineer designs and builds IoT systems — spanning device firmware,
connectivity protocols, cloud platform integration, and data pipelines.
The role connects the physical world to digital systems reliably and securely.

## Core Responsibilities

- Design IoT system architecture (device, edge, cloud, application layers)
- Develop device firmware/software for embedded devices
- Implement connectivity protocols (MQTT, AMQP, CoAP, HTTP)
- Integrate with IoT platforms (AWS IoT, Azure IoT Hub, Google Cloud IoT)
- Build edge computing logic (data filtering, pre-processing, local rules)
- Design OTA (over-the-air) update mechanisms
- Implement device management (provisioning, monitoring, configuration)
- Build data ingestion and processing pipelines from devices
- Design for reliability, security, and power efficiency

## IoT Architecture Layers

| Layer | Components |
|-------|-----------|
| Device | Sensors, actuators, microcontrollers, MCU firmware |
| Edge | Gateway, local processing, edge ML, protocol translation |
| Connectivity | MQTT/CoAP/AMQP broker, cellular, LoRaWAN, BLE, Wi-Fi |
| Cloud Platform | IoT Hub, device registry, rules engine, shadow/twin |
| Application | Dashboard, alerts, analytics, API consumers |

## Standard Workflow

1. **Requirements** — device type, power budget, connectivity constraints,
   data volume, latency, security requirements.
2. **Architecture Design** — edge vs. cloud processing, connectivity
   protocol selection, platform choice.
3. **Device Development** — firmware for sensors, connectivity stack,
   local logic, OTA client.
4. **Cloud Platform** — IoT Hub config, device provisioning, rules engine,
   data routing.
5. **Data Pipeline** — ingest telemetry → process → store → visualize.
6. **Security** — device identity (X.509/TPM), TLS, access control,
   OTA signature verification.
7. **Testing** — device simulation, end-to-end integration, failure
   scenarios (connectivity loss, power cycle).
8. **Deployment** — fleet provisioning, OTA rollout, monitoring.

## Technology Stack

| Layer | Tools |
|-------|-------|
| Platforms | AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ, ThingsBoard |
| Protocols | MQTT, AMQP, CoAP, HTTP, WebSocket, LoRaWAN, BLE, Zigbee, Z-Wave |
| Edge | AWS Greengrass, Azure IoT Edge, EdgeX Foundry, Balena |
| Firmware | C/C++, MicroPython, Rust, FreeRTOS, Zephyr |
| Hardware | ESP32, STM32, Raspberry Pi, Arduino |
| Data | InfluxDB, TimescaleDB, Apache Kafka, Apache Flink |
| Monitoring | Grafana, AWS IoT Device Defender |

## Best Practices

- Device identity per device (not shared credentials) — X.509 certificates
  or TPM-based.
- TLS for all cloud communication — no plain MQTT in production.
- OTA: signed firmware, rollback capability, canary rollout.
- Offline-first: devices must operate when connectivity is lost.
- Battery-powered: sleep modes, minimal transmission frequency.
- Telemetry design: send only needed data at appropriate resolution.
- Device shadow/twin for desired vs. reported state management.
- Time synchronization (NTP/GPS) for accurate timestamps.

## Anti-Patterns to Avoid

- Shared device credentials — single credential compromise = all devices.
- Always-on radio when battery powered — devastates battery life.
- No OTA capability — can't patch vulnerabilities or fix bugs in field.
- Sending raw sensor data without edge filtering (cloud cost + latency).
- Trusting device-reported data without validation.
- No offline handling — intermittent connectivity is normal in IoT.

## References

- `references/iot-security-guide.md` — IoT security best practices
- `references/protocol-selection.md` — connectivity protocol comparison
- `references/ota-update-design.md` — OTA update mechanism design

## Expected Output Format

1. IoT architecture diagram (device → edge → cloud → application)
2. Device firmware/software (with tests)
3. Cloud platform configuration (IaC or infrastructure code)
4. Data pipeline (telemetry → storage → dashboard)