I have many azure IOT central devices among them 2 of the devices are getting disconnected frequently, But could someone please tell me if there is a way to create a genuine alert if event_status is disconnected for more than 5 mins.
Thank you
I have many azure IOT central devices among them 2 of the devices are getting disconnected frequently, But could someone please tell me if there is a way to create a genuine alert if event_status is disconnected for more than 5 mins.
Thank you
In IoT Central rules can be applied only to Telemetry values on devices targeted by their associated template and optionally by their reported properties. The device connection/disconnection events are available via data export but then the rule logic needs to run external to the app in Azure function or logic app, api, etc.
Unless you have heartbeat telemetry coming as a boolean or numeric from the device you cannot time aggregate count to infer disconnection event using the built-in rules functionality. A hacky and non-ideal approach is to count number of times a metric appeared in the time aggregation window say 5 minutes and if its less than 1 infer that as a disconnected device. This will not work if telemetry frequency for that metric is higher than aggregation window.
As an example, if humidity measurement is received at-least once by the device in the aggregation window then it can be used to infer a disconnected device by counting how many times it was received in the 5min time aggregation window.
The following screen snippet is an example of using the Device Connectivity Events in the Data Export feature (mentioned by @humblejay's answer) for your device connectivity watchdog:
As the above picture shows, the concept is very simple, when the device is disconnected, the watchdog message (such as the CloudEvents message) with the TimeToLive (5 minutes) is sent to the watchdog queue. In the case, when the device is reconnected within the watchdog time, the message is deleted from the watchdog queue, otherwise the message is forwarded to the Alert queue when its TTL is expired.
Note, that the device connectivity events is generated with some limitations, see more details here.
1a. Destination - Webhook:
1b. Data Transform:
Also, I do recommend to add one more destination target, such as the endpoint of the Azure Event Grid custom topic with a CloudEvents input schema, see the following screen snippet:
Moving the above HttpTrigger Azure Function to the AEG subscriber is giving for your solution a Pub/Sub flexibility for distributing the device connectivity events such as a filtering, etc.