Forum Discussion
IoT Hub Device twin returning connectionState = Disconnected, when it's actually connected
Hi!
You should have a look here: Device heartbeat
"
The IoT Hub identity registry contains a field called connectionState. Only use the connectionState field during development and debugging. IoT solutions should not query the field at run time. For example, do not query the connectionState field to check if a device is connected before you send a cloud-to-device message or an SMS. We recommend subscribing to the device disconnected event on Event Grid to get alerts and monitor the device connection state. Use this tutorial to learn how to integrate Device Connected and Device Disconnected events from IoT Hub in your IoT solution.
"
Hope that helps!
Thanks
MicrosoftThis is not a bug and the two options I shared with you are the supported ones.
The connect\disconnect events will sometimes show in a reverse order (mainly when the connect\disconnect of a device takes less than 3 seconds) and 1:1 ratios are not guaranteed when using connectionState field. There is not much we can do about this because of the mechanics here (device may reconnect to a different gateway in which case the disconnect and connect events may race). One option is to check the timestamp of the connectionState messages coming in the IoTHub but unfortunately even that is not super deterministic because of potential clock skew between the gateway VMs.
Thanks.
asergaz if there is no guaranty to use connectionState which would be the field where I can have that guarantee otherwise what is the sense of having a Disconnected event if that event is
never raised?
I am having the same issue mentioned by smart_door a lot of message with state Connected and no one showing device Disconnected.
Thanks a lot for the help!
ederfdias you do receive the notifications, only they come often, and aren't very reliable. Ie, for my system, I wanted to notify the user when the device was offline. If I just used that notification, it would send tons of notifications every time it disconnected for any amount of time (or when it thought it did).
What I ended up implementing was a function that has a queue trigger on the hubconnectionqueue. When it triggers, it checks to see if the message was "deviceconnected", if not (device is disconnected), then it tries to get a status of the device (command on the device, like a ping), if it doesn't respond in 5 minutes, it will then send out a device disconnected message to the user. This prevents sending many false readings, so the device has to be offline for at least 5 minutes before it will send an email.
If the device is offline, then it sends the notification, and adds it to an offline list.
If the message is a deviceConnected message, then I check to see if that device is in the disconnected device list (add from above), and if it is, I remove it from the list and send out a device back online message. This way only devices that I've notified the user that it was disconnected will be sent a connected message.
hope that makes sense, seems to do the job for me as the other way was just not reliable at all.
