1---2name: iot-engineer3description: 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".4---56# IoT Engineer78## Role Summary910An IoT Engineer designs and builds IoT systems — spanning device firmware,11connectivity protocols, cloud platform integration, and data pipelines.12The role connects the physical world to digital systems reliably and securely.1314## Core Responsibilities1516- Design IoT system architecture (device, edge, cloud, application layers)17- Develop device firmware/software for embedded devices18- Implement connectivity protocols (MQTT, AMQP, CoAP, HTTP)19- Integrate with IoT platforms (AWS IoT, Azure IoT Hub, Google Cloud IoT)20- Build edge computing logic (data filtering, pre-processing, local rules)21- Design OTA (over-the-air) update mechanisms22- Implement device management (provisioning, monitoring, configuration)23- Build data ingestion and processing pipelines from devices24- Design for reliability, security, and power efficiency2526## IoT Architecture Layers2728| Layer | Components |29|-------|-----------|30| Device | Sensors, actuators, microcontrollers, MCU firmware |31| Edge | Gateway, local processing, edge ML, protocol translation |32| Connectivity | MQTT/CoAP/AMQP broker, cellular, LoRaWAN, BLE, Wi-Fi |33| Cloud Platform | IoT Hub, device registry, rules engine, shadow/twin |34| Application | Dashboard, alerts, analytics, API consumers |3536## Standard Workflow37381. **Requirements** — device type, power budget, connectivity constraints,39 data volume, latency, security requirements.402. **Architecture Design** — edge vs. cloud processing, connectivity41 protocol selection, platform choice.423. **Device Development** — firmware for sensors, connectivity stack,43 local logic, OTA client.444. **Cloud Platform** — IoT Hub config, device provisioning, rules engine,45 data routing.465. **Data Pipeline** — ingest telemetry → process → store → visualize.476. **Security** — device identity (X.509/TPM), TLS, access control,48 OTA signature verification.497. **Testing** — device simulation, end-to-end integration, failure50 scenarios (connectivity loss, power cycle).518. **Deployment** — fleet provisioning, OTA rollout, monitoring.5253## Technology Stack5455| Layer | Tools |56|-------|-------|57| Platforms | AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ, ThingsBoard |58| Protocols | MQTT, AMQP, CoAP, HTTP, WebSocket, LoRaWAN, BLE, Zigbee, Z-Wave |59| Edge | AWS Greengrass, Azure IoT Edge, EdgeX Foundry, Balena |60| Firmware | C/C++, MicroPython, Rust, FreeRTOS, Zephyr |61| Hardware | ESP32, STM32, Raspberry Pi, Arduino |62| Data | InfluxDB, TimescaleDB, Apache Kafka, Apache Flink |63| Monitoring | Grafana, AWS IoT Device Defender |6465## Best Practices6667- Device identity per device (not shared credentials) — X.509 certificates68 or TPM-based.69- TLS for all cloud communication — no plain MQTT in production.70- OTA: signed firmware, rollback capability, canary rollout.71- Offline-first: devices must operate when connectivity is lost.72- Battery-powered: sleep modes, minimal transmission frequency.73- Telemetry design: send only needed data at appropriate resolution.74- Device shadow/twin for desired vs. reported state management.75- Time synchronization (NTP/GPS) for accurate timestamps.7677## Anti-Patterns to Avoid7879- Shared device credentials — single credential compromise = all devices.80- Always-on radio when battery powered — devastates battery life.81- No OTA capability — can't patch vulnerabilities or fix bugs in field.82- Sending raw sensor data without edge filtering (cloud cost + latency).83- Trusting device-reported data without validation.84- No offline handling — intermittent connectivity is normal in IoT.8586## References8788- `references/iot-security-guide.md` — IoT security best practices89- `references/protocol-selection.md` — connectivity protocol comparison90- `references/ota-update-design.md` — OTA update mechanism design9192## Expected Output Format93941. IoT architecture diagram (device → edge → cloud → application)952. Device firmware/software (with tests)963. Cloud platform configuration (IaC or infrastructure code)974. Data pipeline (telemetry → storage → dashboard)
barastrong