Episode Details

A machine sends temperature readings, vibration data, cycle counts, power consumption, and operating states every few seconds. Then the gateway suddenly disconnects. Are all of those messages simply “events”? Technically, you could describe them that way. Architecturally, that can create serious problems. Azure IoT Hub Message Routing and Azure Event Grid solve different problems. One path is designed around preserving and distributing operational data. The other is designed around notifying systems that something changed and may require a response. Treating them as interchangeable can leave you with expensive workflows processing routine sensor data—or important signals buried inside a telemetry pipeline nobody is actively watching. In this episode of M365 FM, we follow a manufacturing machine through a real Azure IoT architecture and explain where IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions, and Logic Apps actually belong.

WHAT YOU WILL LEARN
In this episode, we explore:

• Why machine telemetry and discrete business or lifecycle events require different architecture patterns
• How Azure IoT Hub Message Routing works as part of a telemetry data plane
• Where Azure Event Grid fits into event-driven and reactive architectures
• Why message ordering matters for manufacturing telemetry
• Why Event Grid should not become your primary high-volume telemetry bus
• Why IoT Hub routing should not be forced into every notification workflow
• How IoT Hub and Event Grid can work together in the same architecture
• How Event Hubs can support independent stream-processing consumers
• Why raw telemetry should often be retained for traceability and later investigation
• How Microsoft Fabric and Power BI can consume prepared operational data
• Why MES, ERP, and asset models provide context that device data alone cannot provide
• How device disconnect events should be interpreted without automatically assuming production stopped
• How duplicate delivery, retries, timestamps, and idempotency affect reliable industrial architectures
• How to design condition monitoring, predictive maintenance, quality traceability, and production-disruption workflows
• How to decide whether a message belongs on the data plane, the response path, or both

TELEMETRY IS A RECORD OVER TIME
Telemetry is not valuable because one temperature reading arrived. It becomes valuable because thousands of readings together describe what happened. A production machine may continuously report:

• Temperature and vibration measurements
• Motor current and energy consumption
• Cycle counts and production counters
• Running, idle, stopped, or faulted states
• Source timestamps and sequence information
• Diagnostic and equipment-health information

A single temperature value might mean very little. The sequence around that reading tells the story. Was the machine warming up? Was it already producing? Was vibration increasing at the same time? Did cycle time begin to increase? Did the machine stop shortly afterward? Telemetry therefore needs a path designed around sequence, retention, replay, independent consumers, and traceability.

EVENTS EXIST TO START A RESPONSE
An event serves another purpose. An event says: Something changed. A system or person may need to react. Examples include:

• A new device was registered
• A gateway disconnected from IoT Hub
• A device reconnected
• A device was deleted
• A monitoring process detected a condition requiring investigation
• An inspection completed and another workflow can begin

The recipient usually does not need hours of telemetry before starting the first step. It needs enough information to identify what happened and determine the appropriate response. That response mi