|
| 1 | +--- |
| 2 | +title: Monitor device status - Azure IoT Hub |
| 3 | +description: Use Event Grid or heartbeat patterns to monitor IoT Hub device connection states. |
| 4 | +author: kgremban |
| 5 | +ms.author: kgremban |
| 6 | +ms.topic: reference |
| 7 | +ms.service: iot-hub |
| 8 | +ms.date: 09/13/2022 |
| 9 | +--- |
| 10 | + |
| 11 | +# Monitor device status |
| 12 | + |
| 13 | +Azure IoT Hub supports several methods for monitoring the status of your devices. This article presents the different monitoring methods and provides guidance to help you choose the best option for your IoT solution. |
| 14 | + |
| 15 | +The following table introduces three ways to monitor your device connection status: |
| 16 | + |
| 17 | +| Method | Status frequency | Cost | Effort to build | |
| 18 | +| --- | --- | --- | --- | |
| 19 | +| Device twin connectionState property | Intermittent | Low | Low | |
| 20 | +| Event Grid | 60 seconds | Low | Low | |
| 21 | +| Custom device heartbeat pattern | Custom | High | High | |
| 22 | + |
| 23 | +Because of its reliability, low cost, and ease of use we recommend Event Grid as the preferred monitoring solution for most customers. However, there are certain limitations to monitoring with Event Grid that may disqualify it for some IoT solutions. Use this article to understand the benefits and limitations of each option. |
| 24 | + |
| 25 | +## Device twin connectionState |
| 26 | + |
| 27 | +Every IoT Hub device identity contains a property called **connectionState** that reports either **connected** or **disconnected**. This property represents IoT Hub's understanding of a device's connection status. |
| 28 | + |
| 29 | +The connection state property has several limitations: |
| 30 | + |
| 31 | +* The connection state is updated only for devices that use MQTT or AMQP. |
| 32 | +* Updates to this property rely on protocol-level pings and may be delayed as much as five minutes. |
| 33 | + |
| 34 | +For these reasons, we recommend that you only use the **connectionState** field during development and debugging. IoT solutions shouldn't query the field at run time. For example, don't query the **connectionState** field to check if a device is connected before you send a cloud-to-device message or an SMS. |
| 35 | + |
| 36 | +## Event Grid |
| 37 | + |
| 38 | +We recommend subscribing to the **deviceConnected** and **deviceDisconnected** events on Event Grid to get alerts and monitor the device connection state. |
| 39 | + |
| 40 | +Use the following articles to learn how to integrate device connected and disconnected events in your IoT solution: |
| 41 | + |
| 42 | +* [React to IoT Hub events by using Event Grid](iot-hub-event-grid.md) |
| 43 | +* [Order device connection events by using Cosmos DB](iot-hub-how-to-order-connection-state-events.md) |
| 44 | + |
| 45 | +Device connection state events are available for devices connecting using either the MQTT or AMQP protocol, or using either of these protocols over WebSockets. Requests made only with HTTPS won't trigger device connection state notifications. |
| 46 | + |
| 47 | +* For devices connecting using the Azure IoT SDKs for Java, Node, or Python: |
| 48 | + * MQTT: connection state events are sent automatically. |
| 49 | + * AMQP: a [cloud-to-device link](iot-hub-amqp-support.md#invoke-cloud-to-device-messages-service-client) should be created to reduce delays in reporting connection states. |
| 50 | +* For devices connecting using the .NET SDK, connection state events won't be reported until an initial device-to-cloud message is sent or a cloud-to-device message is received. |
| 51 | +* For devices connecting using the C SDK, connection state events won't be reported. |
| 52 | + |
| 53 | +Outside of the Azure IoT SDKs, in MQTT these operations equate to SUBSCRIBE or PUBLISH operations on the appropriate messaging topics. Over AMQP these operations equate to attaching or transferring a message on the appropriate link paths. |
| 54 | + |
| 55 | +IoT Hub doesn't report each individual device connect and disconnect, but rather publishes the current connection state taken at a periodic 60-second snapshot. Receiving either the same connection state event with different sequence numbers or different connection state events both mean that there was a change in the device connection state during the 60-second window. |
| 56 | + |
| 57 | +### Event Grid limitations |
| 58 | + |
| 59 | +Using Event Grid to monitor your device status comes with the following limitations: |
| 60 | + |
| 61 | +* Event Grid doesn't report each individual device connect and disconnect event. Instead, it polls for device status every 60 seconds and publishes the most recent connection state if there was a state change. For this reason, state change reports may be delayed up to one minute and individual state changes may be unreported if multiple events happen within the 60-second window. |
| 62 | +* Devices that use MQTT start reporting device status automatically. However, devices that use AMQP need [cloud-to-device link](iot-hub-amqp-support.md#invoke-cloud-to-device-messages-service-client) before they can report device status. |
| 63 | +* The IoT C SDK doesn't have a connect method. Customers must send telemetry to begin reporting accurate device connection states. |
| 64 | +* Event Grid exposes a public endpoint that can't be hidden. |
| 65 | + |
| 66 | +If any of these limitations impact your ability to use Event Grid for device status monitoring, then you should consider building a custom device heartbeat pattern instead. |
| 67 | + |
| 68 | +## Device heartbeat |
| 69 | + |
| 70 | +If you need to know the connection state of your devices but the limitations of Event Grid are too restricting for your solution, you can implement the *heartbeat pattern*. In the heartbeat pattern, the device sends device-to-cloud messages at least once every fixed amount of time (for example, at least once every hour). Even if a device doesn't have any data to send, it still sends an empty device-to-cloud message, usually with a property that identifies it as a heartbeat message. On the service side, the solution maintains a map with the last heartbeat received for each device. If the solution doesn't receive a heartbeat message within the expected time from the device, it assumes that there's a problem with the device. |
| 71 | + |
| 72 | +> [!NOTE] |
| 73 | +> If an IoT solution uses the connection state solely to determine whether to send cloud-to-device messages, and messages are not broadcast to large sets of devices, consider using the simpler *short expiry time* pattern. This pattern achieves the same result as maintaining a device connection state registry using the heartbeat pattern, while being more efficient. If you request message acknowledgements, IoT Hub can notify you about which devices are able to receive messages and which are not. |
| 74 | +
|
| 75 | +### Device heartbeat limitations |
| 76 | + |
| 77 | +Since heartbeat messages are implemented as device-to-cloud messages, they count against your [IoT Hub message quota and throttling limits](iot-hub-devguide-quotas-throttling.md). |
| 78 | + |
| 79 | +## Additional monitoring options |
| 80 | + |
| 81 | +A more complex implementation could include the information from [Azure Monitor](../azure-monitor/index.yml) and [Azure Resource Health](../service-health/resource-health-overview.md) to identify devices that are trying to connect or communicate but failing. To learn more about using these services with IoT Hub, see [Monitor IoT Hub](monitor-iot-hub.md) and [Check IoT Hub resource health](iot-hub-azure-service-health-integration.md#check-health-of-an-iot-hub-with-azure-resource-health). For more specific information about using Azure Monitor or Event Grid to monitor device connectivity, see [Monitor, diagnose, and troubleshoot device connectivity](iot-hub-troubleshoot-connectivity.md). |
| 82 | + |
0 commit comments