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 might involve:

• Starting an Azure Function
• Triggering a Logic App
• Opening a support investigation
• Updating an asset record
• Checking the current device state
• Calling an external application through a webhook
• Notifying the team responsible for the affected system

The event starts the investigation. It does not necessarily contain every fact needed to make the final operational decision.

WHY “EVERYTHING IS AN EVENT” BREAKS DOWN
Sending every sensor measurement into event-triggered workflows can look attractive during a proof of concept. Then production scale arrives. Every reading triggers another Function. Another Logic App evaluates something. Another integration receives another message. Maintenance creates its own subscription. Quality creates another. Energy management creates another. Soon, every team has slightly different filtering, state management, retry handling, and storage logic. A temperature measurement is not automatically an incident. It may contribute to an incident later, but the continuous measurements should remain available as evidence. When routine telemetry starts generating constant notifications, users can also begin ignoring alerts because the system has trained them to expect noise rather than actionable information. 

WHAT AZURE IOT HUB ACTUALLY DOES
Azure IoT Hub provides the device-facing cloud boundary. It supports areas such as:

• Secure device identities
• Device-to-cloud messaging
• Cloud-to-device communication
• Device management
• Device twins
• Controlled access between connected equipment and Azure services

IoT Hub knows that an authenticated device sent a message. It does not automatically understand what that message means to production. A gateway might report: state = running But “running” could mean:

• Producing approved parts
• Dry cycling
• Running setup
• Performing rework
• Moving without material

That context usually comes from additional systems such as the MES, ERP, asset model, or production application.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.