You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|[Python](https://github.com/Azure/azure-iot-sdk-python/tree/master/azure-iot-device/samples)|Always supports MQTT by default |
46
46
47
+
### Default keep-alive timeout
48
+
49
+
In order to ensure a client/IoT Hub connection stays alive, both the service and the client regularly send a *keep-alive* ping to each other. The client using IoT SDK sends a keep-alive at the interval defined in this table below:
Following [MQTT spec](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718081), IoT Hub's keep-alive ping interval is 1.5 times the client keep-alive value. However, IoT Hub limits the maximum server-side timeout to 29.45 minutes (1767 seconds) because all Azure services are bound to the Azure load balancer TCP idle timeout, which is 29.45 minutes.
60
+
61
+
For example, a device using the Java SDK sends the keep-alive ping then loses network connectivity. 230 seconds later, the device misses the keep-alive ping because it's offline. However, IoT Hub doesn't close the connection immediately - it waits another `(230 * 1.5) - 230 = 115` seconds before disconnecting the device with the error [404104 DeviceConnectionClosedRemotely](iot-hub-troubleshoot-error-404104-deviceconnectionclosedremotely.md).
62
+
63
+
The maximum client keep-alive value you can set is `1767 / 1.5 = 1177` seconds. Any traffic will reset the keep-alive. For example, a successful SAS token refresh resets the keep-alive.
64
+
47
65
### Migrating a device app from AMQP to MQTT
48
66
49
67
If you are using the [device SDKs](https://github.com/Azure/azure-iot-sdks), switching from using AMQP to MQTT requires changing the protocol parameter in the client initialization as stated previously.
@@ -147,7 +165,7 @@ Mosquitto_subscribe: to see events occurring in an Azure IoT hub.
147
165
148
166
Connecting to IoT Hub over MQTT using a module identity is similar to the device (described [above](#using-the-mqtt-protocol-directly-as-a-device)) but you need to use the following:
149
167
150
-
* Set the client id to `{device_id}/{module_id}`.
168
+
* Set the client ID to `{device_id}/{module_id}`.
151
169
152
170
* If authenticating with username and password, set the username to `<hubname>.azure-devices.net/{device_id}/{module_id}/?api-version=2018-06-30` and use the SAS token associated with the module identity as your password.
153
171
@@ -313,7 +331,7 @@ For more information, see [Device twins developer's guide](iot-hub-devguide-devi
313
331
314
332
## Update device twin's reported properties
315
333
316
-
To update reported properties, the device issues a request to IoT Hub via a publication over a designated MQTT topic. After processing the request, IoT Hub responds the success or failure status of the update operation via a publication to another topic. This topic can be subscribed by the device in order to notify it about the result of its twin update request. To implement this type of request/response interaction in MQTT, we leverage the notion of request id (`$rid`) provided initially by the device in its update request. This request id is also included in the response from IoT Hub to allow the device to correlate the response to its particular earlier request.
334
+
To update reported properties, the device issues a request to IoT Hub via a publication over a designated MQTT topic. After processing the request, IoT Hub responds the success or failure status of the update operation via a publication to another topic. This topic can be subscribed by the device in order to notify it about the result of its twin update request. To implement this type of request/response interaction in MQTT, we leverage the notion of request ID (`$rid`) provided initially by the device in its update request. This request ID is also included in the response from IoT Hub to allow the device to correlate the response to its particular earlier request.
317
335
318
336
The following sequence describes how a device updates the reported properties in the device twin in IoT Hub:
Copy file name to clipboardExpand all lines: articles/iot-hub/iot-hub-troubleshoot-connectivity.md
+31-28Lines changed: 31 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,26 +1,26 @@
1
1
---
2
-
title: Diagnose and troubleshoot disconnects with Azure IoT Hub
3
-
description: Learn to diagnose and troubleshoot common errors with device connectivity for Azure IoT Hub
2
+
title: Monitor and troubleshoot disconnects with Azure IoT Hub
3
+
description: Learn to monitor and troubleshoot common errors with device connectivity for Azure IoT Hub
4
4
author: jlian
5
5
manager: briz
6
6
ms.service: iot-hub
7
7
services: iot-hub
8
8
ms.topic: conceptual
9
-
ms.date: 07/19/2018
9
+
ms.date: 01/30/2020
10
10
ms.author: jlian
11
11
# As an operator for Azure IoT Hub, I need to know how to find out when devices are disconnecting unexpectedly and troubleshoot resolve those issues right away
12
12
---
13
-
# Detect and troubleshoot disconnects with Azure IoT Hub
13
+
# Monitor, diagnose, and troubleshoot disconnects with Azure IoT Hub
14
14
15
-
Connectivity issues for IoT devices can be difficult to troubleshoot because there are many possible points of failure. Device-side application logic, physical networks, protocols, hardware, and Azure IoT Hub can all cause problems. This article provides recommendations on how to detectand troubleshoot device connectivity issues from the cloud side (as opposed to device side).
15
+
Connectivity issues for IoT devices can be difficult to troubleshoot because there are many possible points of failure. Application logic, physical networks, protocols, hardware, IoT Hub, and other cloud services can all cause problems. The ability to detect and pinpoint the source of an issue is critical. However, an IoT solution at scale could have thousands of devices, so it's not practical to check individual devices manually. To help you detect, diagnose, and troubleshoot these issues at scale, use the monitoring capabilities IoT Hub provides through Azure Monitor. These capabilities are limited to what IoT Hub can observe, so we also recommend that you follow monitoring best practices for your devices and other Azure services.
16
16
17
17
## Get alerts and error logs
18
18
19
-
Use Azure Monitor to get alerts and write logs when device connections drop.
19
+
Use Azure Monitor to get alerts and write logs when devices disconnect.
20
20
21
21
### Turn on diagnostic logs
22
22
23
-
To log device connection events and errors, turn on diagnostics for IoT Hub.
23
+
To log device connection events and errors, turn on diagnostics for IoT Hub. We recommend turning on these logs as early as possible, because if diagnostic logs aren't enabled, when device disconnects occur, you won't have any information to troubleshoot the problem with.
24
24
25
25
1. Sign in to the [Azure portal](https://portal.azure.com).
26
26
@@ -38,9 +38,9 @@ To log device connection events and errors, turn on diagnostics for IoT Hub.
38
38
39
39
To learn more, see [Monitor the health of Azure IoT Hub and diagnose problems quickly](iot-hub-monitor-resource-health.md).
40
40
41
-
### Set up alerts for the _connected devices_ count metric
41
+
### Set up alerts for device disconnect at scale
42
42
43
-
To get alerts when devices disconnect, configure alerts on the **connected devices (preview)** metric.
43
+
To get alerts when devices disconnect, configure alerts on the **Connected devices (preview)** metric.
44
44
45
45
1. Sign in to the [Azure portal](https://portal.azure.com).
46
46
@@ -52,43 +52,46 @@ To get alerts when devices disconnect, configure alerts on the **connected devic
52
52
53
53
5. Select **Add condition**, then select "Connected devices (preview)".
54
54
55
-
6.Finish setting up your desired thresholds and alerting options by following prompts.
55
+
6.Set up threshold and alerting by following prompts.
56
56
57
-
To learn more, see [What are classic alerts in Microsoft Azure?](../azure-monitor/platform/alerts-overview.md).
57
+
To learn more, see [What are alerts in Microsoft Azure?](../azure-monitor/platform/alerts-overview.md).
58
+
59
+
#### Detecting individual device disconnects
60
+
61
+
To detect *per-device* disconnects, such as when you need to know a factory just went offline, [configure device disconnect events with Event Grid](iot-hub-event-grid.md).
58
62
59
63
## Resolve connectivity errors
60
64
61
-
When you turn on diagnostic logs and alerts for connected devices, you get alerts when errors occur. This section describes how to resolve common issues when you receive an alert. The steps below assume you've set up Azure Monitor logs for your diagnostic logs.
65
+
When you turn on diagnostic logs and alerts for connected devices, you get alerts when errors occur. This section describes how to look for common issues when you receive an alert. The steps below assume you've set up Azure Monitor logs for your diagnostic logs.
66
+
67
+
1. Sign in to the [Azure portal](https://portal.azure.com).
62
68
63
-
1.Go your workspace for **Log Analytics** in the Azure portal.
69
+
1.Browse to your IoT hub.
64
70
65
-
2. Select **Log Search**.
71
+
1. Select **Logs**.
66
72
67
-
3. To isolate connectivity error logs for IoT Hub, enter the following query and then select **Run**:
73
+
1. To isolate connectivity error logs for IoT Hub, enter the following query and then select **Run**:
68
74
69
75
```kusto
70
-
search *
71
-
| where ( Type == "AzureDiagnostics" and ResourceType == "IOTHUBS")
72
-
| where ( Category == "Connections" and Level == "Error")
76
+
AzureDiagnostics
77
+
| where ( ResourceType == "IOTHUBS" and Category == "Connections" and Level == "Error")
73
78
```
74
79
75
80
1. If there are results, look for `OperationName`, `ResultType` (error code), and `ResultDescription` (error message) to get more detail on the error.
76
81
77
82
78
83
79
-
2. Use this table to understand and resolve common errors.
84
+
1. Follow the problem resolution guides for the most common errors:
80
85
81
-
| Error | Root cause | Resolution |
82
-
|-------|------------|------------|
83
-
| 404104 DeviceConnectionClosedRemotely | The connection was closed by the device, but IoT Hub doesn't know why. Common causes include MQTT/AMQP timeout and internet connectivity loss. | Make sure the device can connect to IoT Hub by [testing the connection](tutorial-connectivity.md). If the connection is fine, but the device disconnects intermittently, make sure to implement proper keep alive device logic for your choice of protocol (MQTT/AMPQ). |
84
-
| 401003 IoTHubUnauthorized | IoT Hub couldn't authenticate the connection. | Make sure that the SAS or other security token you use isn't expired. [Azure IoT SDKs](iot-hub-devguide-sdks.md) automatically generate tokens without requiring special configuration. |
85
-
| 409002 LinkCreationConflict | A device has more than one connection. When a new connection request comes for a device, IoT Hub closes the previous one with this error. | In the most common case, a device detects a disconnect and tries to reestablish the connection, but IoT Hub still considers the device connected. IoT Hub closes the previous connection and logs this error. This error usually appears as a side effect of a different, transient issue, so look for other errors in the logs to troubleshoot further. Otherwise, make sure to issue a new connection request only if the connection drops. |
86
-
| 500001 ServerError | IoT Hub ran into a server-side issue. Most likely, the issue is transient. While the IoT Hub team works hard to maintain [the SLA](https://azure.microsoft.com/support/legal/sla/iot-hub/), small subsets of IoT Hub nodes can occasionally experience transient faults. When your device tries to connect to a node that's having issues, you receive this error. | To mitigate the transient fault, issue a retry from the device. To [automatically manage retries](iot-hub-reliability-features-in-sdks.md#connection-and-retry), make sure you use the latest version of the [Azure IoT SDKs](iot-hub-devguide-sdks.md).<br><br>For best practice on transient fault handling and retries, see [Transient fault handling](/azure/architecture/best-practices/transient-faults). <br><br>If the problem persists after retries, check [Resource Health](iot-hub-monitor-resource-health.md#use-azure-resource-health) and [Azure Status](https://azure.microsoft.com/status/history/) to see if IoT Hub has a known problem. If there's no known problems and the issue continues, [contact support](https://azure.microsoft.com/support/options/) for further investigation. |
87
-
| 500008 GenericTimeout | IoT Hub couldn't complete the connection request before timing out. Like a 500001 ServerError, this error is likely transient. | Follow troubleshooting steps for a 500001 ServerError to the root cause and resolve this error.|
* If you have access to the problematic devices, either physically or remotely (like SSH), follow the [device-side troubleshooting guide](https://github.com/Azure/azure-iot-sdk-node/wiki/Troubleshooting-Guide-Devices) to continue troubleshooting.
This article describes the causes and solutions for **400027 ConnectionForcefullyClosedOnNewConnection** errors.
17
+
18
+
## Symptoms
19
+
20
+
Your device-to-cloud twin operation (such as read or patch reported properties) or direct method invocation fails with the error code **400027**.
21
+
22
+
## Cause
23
+
24
+
Another client created a new connection to IoT Hub using the same credentials, so IoT Hub closed the previous connection. IoT Hub doesn't allow more than one client to connect using the same set of credentials.
25
+
26
+
## Solution
27
+
28
+
Ensure that each client connects to IoT Hub using its own identity.
0 commit comments