Implement IoT Edge
What you must know
IoT Edge has three parts: the IoT Edge runtime (edgeHub and edgeAgent), modules (your code), and the deployment manifest. Understand that edgeAgent pulls the deployment and manages modules, while edgeHub handles local routing and buffering. Know the $edgeHub and $edgeAgent twins and how desired properties drive deployment.
Know module-to-module routing syntax: FROM /messages/modules/modA/* INTO BrokeredEndpoint("/modules/modB/inputs/input1"), and the route priority and time-to-live settings. Understand offline capabilities: edgeHub stores messages when disconnected and forwards them later. Know device-to-cloud vs. module-to-cloud routes and the upstream route.
Traps
- Forgetting that edgeHub needs a route to $upstream to send data to IoT Hub.
- Assuming modules can talk to each other without a route - they cannot; routes are explicit.
- Confusing deployment at scale (automatic deployment with priority and target condition) with a single-device deployment manifest.
- Assuming the runtime can be updated by pushing a module - runtime updates use the iotedged update path or device update for IoT Hub.
Rule of thumb
Every working edge deployment needs at least: an edgeAgent image, an edgeHub image, and a route from the module output to $upstream. If any of the three is missing, the deployment will not deliver telemetry.
Worked example
A module tempFilter outputs filtered readings. To send them to the cloud, add the route FROM /messages/modules/tempFilter/outputs/filtered INTO $upstream. Without this route, edgeHub buffers the messages locally and the hub never sees them.