Forum Discussion
IoT Hub Device twin returning connectionState = Disconnected, when it's actually connected
- Dec 31, 2018
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
I don't send any messages from my device to the iot hub, I want to monitor my devices from the cloud so I can send an alert email when one of them is no longer connected, hence the original webjob that queried the IOT hub for disconnected devices.
Since that is supposedly not a proper way, I created event subscriptions in Iot hub to subscribe to the device disconnected and device connected events that are available, and send those messages to a queue. I created a new webjob that listens on that queue for those messages and then intern, send out an email to the appropriate email address based on the device and the connection state in the event. The problem with this is that I don't ever seem to get any disconnected events and only get connected events. Also, I ran this overnight at got many connected events and only one disconnected event, I would expect to get a one to one ratio....and I really should have not gotten any connect/disconnect events.
The goal of this is to monitor for disconnected devices and notify the user of that device that it is offline (or back online). I cleared out the queue this morning and already have 15 device connected events for 3 different iot devices. This is problematic as it will send false notifications to something that has not disconnected.
I just want to know when a device goes offline, and when it comes back up so that I can notify users of the device in a timely manner and at the same time, not spam them with messages that don't offer any benefit.
Does this make sense at what I'm trying to accomplish? the device twin query that ran every 5 minutes seem to work better than this, only that once in a while a device would report offline once every 1 hour & 5 minutes for what ever reason, giving false issues. the connected events are showing up way more frequently, and I don't even seem to get a disconnected event even when I pull the network cable for 5 minutes from a test device.
- asergazJan 04, 2019
Microsoft
Hi,
Like I mentioned above you can't rely on connectionState field (which looks like is what you are using right?).
If you don't want to Order device connection events from Azure IoT Hub using Azure Cosmos DB the other supported alternative is to implement the device heartbeat pattern:
"
If your IoT solution needs to know if a device is connected, 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). Therefore, even if a device does not have any data to send, it still sends an empty device-to-cloud message (usually with a property that identifies it as a heartbeat). On the service side, the solution maintains a map with the last heartbeat received for each device. If the solution does not receive a heartbeat message within the expected time from the device, it assumes that there is a problem with the device.
A more complex implementation could include the information from Azure Monitor and Azure Resource Health to identify devices that are trying to connect or communicate but failing, check Monitor with diagnostics guide. When you implement the heartbeat pattern, make sure to check IoT Hub Quotas and Throttles.
"
- smart_doorJan 04, 2019Brass Contributor
Yes, you are just restating what is in the documentation. Doing a heartbeat is worthless as it would require way to many messages just for a heart beat (ie every 5 minutes). I don't want to know if a device is connected, I want to know when a device is disconnected, if devices are connected, everything is good, when a device disconnects, then there is either a network issue where the device is located, or something with the code on the device crashed or something else causing it not to connect to the cloud. That is the critical issue and I want to notify the user of the device when this happens so they can validate the device is off line and remedy the situation.
I tried again disconnecting my test device from the network, and did eventually receive a disconnected event. I guess I will modify my webjob and event to only look at/get device disconnected events and send out an alert when that happens. I don't want to be constantly sending out device is online messages when the device never actually goes offline.
Again, if the iot hub is sending a device connected event, shouldn't have a devicedisconnected event being sent first (or at least being sent)….this doesn't happen, I only see many device connected events come through the queue. I would expect a 1:1 ratio of connected/disconnected events. I also wouldn't expect multiple connected events to come through on devices that are connected....seems like an IOT hub bug to me?
- asergazJan 04, 2019
Microsoft
This 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.