IoTEdge Device shows offline in Service SDK

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

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

[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).

[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