A temperature reading, a vibration sample, a machine cycle, and a device disconnect may all be described as events, but they do not represent the same architectural problem. In industrial IoT and manufacturing environments, confusing continuous telemetry with discrete events can create noisy workflows, incomplete production histories, unnecessary processing, and systems that react without enough context.
In this episode, we break down the architectural difference between Azure IoT Hub Message Routing and Azure Event Grid by following a realistic manufacturing scenario. A press line continuously sends temperature, vibration, cycle count, energy consumption, and machine-state information through an industrial gateway. Those measurements create an operational history that engineers, data teams, maintenance teams, and production systems may need to analyze later. A device disconnect is different because it represents a change that may require another system or person to react.
TELEMETRY IS A RECORD, NOT AN ALERT
Telemetry represents repeated measurements over time. A single temperature value or vibration measurement usually tells you very little on its own. The real information exists in the sequence: how quickly values changed, what the machine was doing at that moment, what happened before a stop, whether measurements disappeared during a network interruption, and whether the same behavior appeared in earlier production runs.
Typical industrial telemetry includes:
• Temperature, vibration, pressure, energy consumption, and current draw
• Machine states such as running, idle, stopped, or faulted
• Cycle counts, production counters, and process measurements
• Source timestamps, device identifiers, sequence numbers, and correlation information
Those records may later support condition monitoring, quality investigations, energy analysis, OEE calculations, Microsoft Fabric analytics, Power BI reporting, and production optimization. That is why telemetry needs retention, replay, duplicate handling, independent consumers, and a reliable way to reconstruct the production timeline.
IOT HUB MESSAGE ROUTING AS THE TELEMETRY DATA PLANE
Azure IoT Hub provides the controlled device-to-cloud boundary. Devices and gateways authenticate with their own identities, send device-to-cloud messages, maintain device-management state, and can participate in controlled cloud-to-device communication.
Once a telemetry message reaches IoT Hub, Message Routing determines where that data should go. Routing can inspect message properties, system properties, parts of the message body, and device twin information. This makes it possible to separate production telemetry, energy measurements, diagnostics, or other message classes before they reach downstream consumers.
A common architecture might look like this: Industrial gateway → Azure IoT Hub → Message Routing → Event Hubs or Storage → Processing → Microsoft Fabric.
One consumer may perform near-real-time analysis while another keeps a raw archive. A third consumer may prepare curated operational data for Microsoft Fabric. Each consumer can work independently without turning every telemetry reading into a workflow invocation.
WHY ORDERING MATTERS
Industrial telemetry is particularly sensitive to sequence. Imagine a machine reporting that it entered a running state, then transmitting several cycle counts, followed by a process deviation and finally a stopped state. If those records are reconstructed incorrectly, a downstream system could conclude that the machine produced parts while stopped or that a process deviation happened after production had already ended.
The same problem affects downtime calculations, OEE, production counts, and condition monitoring. You therefore need to distinguish between when the source observed something, when IoT Hub received the message, and when a downstream system processed it.
A robust telemetry architecture should therefore consider:
• Source timestamps and cloud receipt timestamps
• Stable partitioning appropriate to the asset or workload
• Message IDs or sequence numbers for duplicate detection
• Idempotent consumers capable of handling at-least-once delivery
Network interruptions make this especially important. A gateway may buffer telemetry and send it when connectivity returns, which means Azure arrival time may be much later than the actual machine timestamp.
EVENT GRID SOLVES A DIFFERENT PROBLEM
Azure Event Grid is designed around publish-and-subscribe notifications. Instead of continuously reconstructing the state of a machine from thousands of readings, Event Grid tells interested systems that something changed and gives subscribers an opportunity to react.
Examples in an IoT environment include device creation, device deletion, connection, disconnection, or carefully selected telemetry-derived conditions. A device-created event might trigger an asset onboarding process. A device-disconnected event might start a technical investig...
