Allow to use "connectionState" to identify conected devices
Certain applications requires to know if device is disconnected with accuracy<1 minute. By implementing heartbeat pattern as advised (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry) with large amount of devices it creates enormous volumes of heartbeat messages and it results in generating 99.9% of quota messages just to know when device goes offline (Disconnected).
We are considering improving the connection information provided by IoT Hub.
I think the recommendation against using connectionState in the documentation should be removed.
Instead the limitations should be documented clearly everywhere (as they are at https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry).
There should be quiet a few use cases where connectionState is "good enough".
Also I'd like to see improvements in documentation regarding whether those 5 minutes only apply to disconnected or also connects and what the average delay for propagation of a connect is
I see a comment from John from 2017 about improving the connection information by IotHub team.
As far as I can see, connection state information is still not perfect.
Events in IotHub are still coming out of order and sometimes with a few minutes delay.
Any update on improvements here?
Nave Yosef commented
Any update on this one?
Any update/ETA on this ?
As mentionned earlier, event grid subscription is not even reliable because of the delay that it can take to route an event.
Ping/heartbeat solution is also not reliable
There should have a way to be notified with a reasonable delay when the connectivityState changes, moreover even if it's not for production use connectionState seems pretty accurate...
pete X. commented
You can create an event grid subscription for IoT Hub which will give you feedback about (dis)connect events which is made available using the storage queue. Disadvantage is the unknown delay introduced by the underlying broker which can be up to 5 minutes.
Rudy Lu commented
I want this feature as well, does anyone here figure out how to achieve with IoT Central (https://azure.microsoft.com/en-us/services/iot-central/) or I need to implement this with IoT Hub?
Thanks in advance.
We recommend leveraging Event Grid and use “device disconnected” events to trigger alerts – use the push mechanism and same on polling for device connection state. Please see documentation here https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-event-grid. We will update existing documentation around heartbeat soon.
I agree with this. We need something built into the PAAS solution that provides an efficient/effective way to interact with device connection state that is usable in a production level environment.
David Baumgarten commented
Saw the message above about using the device twin to get device state. Just checked my devices and it says:
Devices are up and communicating. Also worth mentioning, I have devices "connected" but not transmitting messages. It would be awesome to have access to timestamp for the last message received. The documentation for lastActivityTime says...
"A temporal indicator, showing the date and last time the device connected, received, or sent a message."
but it appears that this value is updated when the operationtimeout for deviceclient lapses.
There are some options to check for connectivity.
If you need to know the connection state of few devices, you can implement a direct method (a "ping"). This is the most reliable way to test for connectivity for individual devices.
If you need to query all devices of their state, we now replicate the connectionState in the device twin so you can query it as any other property. Please note that connectionState only works for AMQP and MQTT devices that use telemetry, and the twin can be updated with a few minutes delay.
Unfortunately, checking for disconnection is a hard problem at scale (think about a gateway machine recycling and losing ~100k connections).
It really depends on your scenario.
Massive requirement for us. If we can easily achieve this via Sockets why shouldn't we be able to do this here?