Iotedge: IoTEdge Device shows offline in Service SDK

[MPapst]

I am using the RegistryManager from the Microsoft.Azure.Devices Package to get informations about the running IoT Edge Devices.
This works very well except the device status. This one is always disconnected (even if the portal shows connected).

I am not sure if this is a SDK issue or an iotedge issue.

Expected Behavior

Device instance requested by RegistryManager shows actual Connection State.

Current Behavior

Shows always Disconnected

Steps to Reproduce

C# RegistryManager mgr = RegistryManager.CreateFromConnectionString(""); var dev = await mgr.GetDeviceAsync("IoTEdge-0002"); Console.WriteLine(dev.ConnectionState);

Context (Environment)

Device (Host) Operating System

Windows 10

Architecture

Container Operating System

Windows

Runtime Versions

iotedged

1.0

Edge Agent

1.0

Edge Hub

1.0

Docker

18.03.1-ce

[dsajanice]

This looks like an SDK issue. Could you please open an issue https://github.com/Azure/azure-iot-sdk-csharp/issues. We'll keep this issue open until there is resolution. Thanks.

[dsajanice]

The underlying issue here is that the Edge device never opens a telemetry link on behalf of the Edge device with the cloud. It only operates on behalf of modules. So the traditional approach of querying the device status would not work here. The way to monitor the connectivity of the Edge device would be to get the $edgeAgent module's twin and look at the reported properties. That should give the status of all modules running on the edge device. Hope this helps.

[MPapst]

How does it work for the azure Portal? Here is the Connection State shown.

[dsajanice]

The portal uses the reported properties in the $edgeAgent's twin to print connection status.

[WilliamBerryiii]

@dsajanice - should developers really be relying on the device twin connection status? We explicitly suggest in the documentation that the property should only be used in development and debugging scenarios: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry#device-heartbeat

[dsajanice]

The challenge with this issue is that device connection status is not relevant to edge devices because the edge device never sends data to the cloud. It only sends data on behalf of modules and leaf devices. So one could certainly use the GetModuleAsync call on a module to determine if the module is connected.

[WilliamBerryiii]

@dsajanice - It feels then like the implementation is not aligned with the conceptual abstraction. So the root of the issue being that Edges, are seemingly not modeled as devices even though they fundamentally are - particularly from an operations perspective (which i'd guess is the use case above).

If a Device has a connection state, then so does an IoT Edge Device. So theoretical design question: "Why do I have to use a property accessor in one context (devices) and be forced to use a device twin (edge device) in another?"

cc/ @pierreca for additional perspective.

Thanks!

[pierreca]

@WilliamBerryiii thanks for the tag! Bringing @nberdy and @simonporter into the fun :)

my 2cts:

1. caveat emptor: even for regular devices, the ConnectionState property can be unreliable so it's not recommended to use this in production. TBH, we have no perfect way to surface that information right now (Ops monitoring messages could come out of order, the ConnectionState property could be out of sync...( see the end of this comment as to why)
2. this being said, even if i'ts unreliable, I agree with you that this field should behave the same for regular devices and edge devices.
3. In theory, the SDK could "fill that gap" by querying the twin when it's an edge device and "correcting" the connection state. I don't like this idea because twin queries are throttled and that means hiding multiple REST calls behind one method call, which is generally frowned upon.
4. it sounds like the idea of measuring the connection state by the establishment of the telemetry link doesn't make sense anymore: even as a regular, non-edge device, I don't necessarily open a telemetry link. I think it should rather hinge on a connection+authentication criteria (CBS/X509...) @simonporter to comment on whether we have plans or how we could fix this.

why is the ConnectionState field unreliable?

• it relies on fully-connected protocols (MQTT and AMQP) and has no valid behavior if the device is using HTTP
• when a device is forcefully disconnected without terminating the connection, there is a timeout period during which the device is showed as connected when it really isn't

[MPapst]

Wouldn't it be better than to add a new ConnectionState enum entry, that shows when the ConnectionState is unreliable?

• When a device is connected using a protocol with a logical channel, the ConnectionState will show connected or disconnected.
• When the last connection was made with a loose connection, the ConnectionState shows something like Unreliable
• A property with the last connection Timestamp could show for both types of connections when the last connection has been established

Surely, this would be a change in every sdk and in the IoTHub itself, but wouldn't it suit all needs?

[varunpuranik]

@pierreca Yes, I agree that we should fix this in the service side, and I don't think the SDK should do it.
Essentially the service needs to do something like this -

• Consider a device is "connected" if _any_ link is open on the connection (not just the events link)
• Consider an IoT Edge device to be connected if any of its modules are connected (or maybe any of the system modules).

[angellmethod]

I am seeing something that seems similar in terms of reporting connectivity. In VS Code, I can see that my module is sending data, in the portal I can see that it says the device is disconnected, and I can also see in the portal that the module is being reported by the device.

[MPapst]

Info: Azure/azure-iot-sdk-csharp#567 has been closed as "by design".

[myagley]

This is unlikely to be changed anytime soon. It requires a change in how IoT Hub calculates connection status. There are no short or medium term plans to change this behavior in IoT Hub.