Devices Analytics

Introduction

Device Analytics service aims to analyse the behaviour of your devices and provide an aggregated view of your fleet’s activity.


Interactive
Figure 1. High level view of Device Analytics service


This service relies on machine learning and some algorithms may not be relevant to specific device behaviors

Only metadata from network info and/or data message will be analysed. Business data are not processed.

Network information may be incomplete.

Once a week, you will receive an email report with several sections providing insights about your fleet.

There is a Premium option that will show additional sections (e.g. fleet’s devices classification : '2 messages per day').

Analytics Report Email

The weekly email contains several sections, based on fleet connectivity and traffic analysis.

For instance, for LoRa connectivity, the join request / join accept network messages will be analysed; as well as the correlation between the loss ratio and the Signal-to-Noise Ratio.

For MQTT devices The ONLINE / OFFLINE connectivity will be aggregated and reported.

If you have subscribed to a premium option, your fleet’s communication patterns are analyzed by a machine learning algorithm.

Attached to the report, an Excel file contains the details, device per device, of the analysis.


device_analytics_report
Figure 2. Sample sections of a report for a LoRa fleet

LoRa: Messages lost

LoRa messages have an incrementing frame counter. When a frame counter is missing, it may indicate that a message has been lost.

This section displays the % of messages lost for the fleet’s devices (over a 14-day period) and the link between message loss and network connectivity issue:

  • weak signal strength with a low signal over noise ratio

  • minimal network coverage (limited number of gateways receiving the message).

LoRa: Join anomalies

Some devices have anomalies on the Join Request / Join Accept procedure during the observation period.

  • Join Requests with no Join Accept cycles : the Join Accept / Join Requests ratio is <50%

  • multiple Join Requests and Join Accepts cycles : the number of Join Request/Accept cycles is >1 on average over the period

These issues may come from a low network coverage or bad device configuration and may kill the device battery. If any, they should be resolved.

LwM2M: DTLS packet lost

Available for LwM2M over DTLS. DTLS records (the basic units of data exchange in DTLS) have an incrementing sequence number. When a sequence number is missing, it indicates that a DTLS record has been lost. As there may be retransmissions (at CoAP level), this does not necessarily mean that some application data has been lost.

This section shows the % of DTLS records lost for the fleet devices. It is calculated over a 14-day period and is defined as follows: (number of lost records over the analysis period) / (number of received and lost records over the analysis period)

Traffic analysis

This section shows the fleet’s devices daily message rate. It focuses on devices that sent at least one message during the observation period. For the LwM2M protocol, only the Send and Notify messages are taken into account.

Communication pattern analysis

Device communication frequency and regularity are analyzed based on the messages sent by the devices. We offer two kinds of analysis: a regularity analysis based on each device independently, and a cluster analysis that groups devices with similar communication patterns. Your email report contains the analysis that delivers the best results for your fleet.

Some devices are excluded from these analyses :

  • devices that did over communicate (several hundreds of messages per day).

  • devices that started to send messages only few days ago (a minimum consistent time window is required)

For the LwM2M protocol, command and registration messages are not taken into account.

Regularity analysis

This analysis uses a machine learning algorithm designed to detect regular communication patterns.

Explanation of regular classification patterns: For example, "1 msg / 1 h" means that the device sends 1 new message every hour.

'Minor patterns' are communication patterns used by less than 5% of the fleet.

If your devices communicate in a non-regular pattern, such as based on human activity, they will be classified as 'undetected'.

When no regular pattern has been detected for a device, it is defined as 'undetected' and some additional details are provided per device in the attachment file :

  • FEW_INTERARRIVALS : not enough messages have been sent by the device to be able to detect a pattern

  • LORA_TOO_MANY_LOSS : based on frame counters, too many messages have been lost to be able to detect a pattern

  • SPREADED_INTERARRIVALS : the communication pattern seems to be erratic and can not be defined as regular

Other statuses can also be attached to the device, like 'silent' or 'traffic limit reached'.

The evolution of these communication patterns in the fleet is also analyzed. It is interesting to follow over time these trends to monitor the stability of the fleet. Here is the list of transitions criticality, with some examples of corresponding previous/current patterns :

Criticality Transition Previous pattern Current pattern

Critical Critical

Devices gone silent

Any

Silent

Warn Warn

Devices no longer regular

Regular

Undetected

Info Info

Devices changed pattern

Other regular
Silent

Regular
Undetected

Improvement Improvement

Devices no more silent or undetected

Silent
Undetected

Any Regular

The email report contains a table with samples from each category.

Cluster analysis

This analysis uses an AI to group devices with similar communication patterns into clusters.

For example, a cluster may be defined as "devices that send between 20 and 30 messages per day, with a regularity of about one message every hour". Another cluster may be "devices that send around 5 messages every weekday morning, with no daily regularity".

When a cluster’s devices share a common regular pattern, the cluster is classified with this pattern. When there is no link to a regular pattern, the cluster is classified as 'irregular'.

A device that does not fit into any cluster, is classified as 'atypical', as its communication pattern is too different from the other devices.

The report includes an example of each cluster, based on the device that represents the cluster best.

The evolution of devices regarding these clusters is also analyzed. Here is the list of transitions criticality, with some examples of corresponding previous/current clusters :

Criticality Transition Previous pattern Current pattern

Critical Critical

Devices gone silent

Any

Silent

Warn Warn

Devices became atypical

Recognized

Atypical

Warn Warn

Devices became irregular

Regular

Irregular

Info Info

Devices changed regular cluster

Regular

Regular

Info Info

Devices changed irregular cluster

Irregular

Irregular

Improvement Improvement

Devices no more silent or atypical

Silent
Atypical

Any Recognized

Improvement Improvement

Devices no more irregular

Irregular

Regular

The email report contains a table with samples from each category.

Outliers analysis

This analysis is focused on the fleet outliers. Outlier devices could be the consequence of low network coverage, hardware/software device issues…​ We consider especially two families:

  • low communicating devices: the devices that sent less than 50% of messages than the lowest rate major communication pattern of the fleet

  • high communicating devices: the devices that sent more than 50% of messages than the highest rate major communication pattern of the fleet

Devices interface status

(Cf. interface object model)

This section focuses on the fleet’s devices status.

As it is a 'daily' representation of devices status, this is the most significant status of the day for each device which is recorded.

For instance, a MQTT, LwM2M or SMS device which has been ONLINE at least once in a day, will be considered as an ONLINE device for this day.

For LORA devices, it is the ACTIVATED status which will be taken into account if the device had this status during the day.

There is also a specific FLAKY status which is recorded when a device has too many status changes per minute.

Analysis details per device (Excel file)

In the 'Alarms & reports' section of the portal you can download an Excel file with information for each fleet’s devices. Parts of this file will also be attached to the email report.

Field Description type Example

device

Device ID

String

urn:lo:nsid:lora:80BBD540F351AC07

groupPath

Device group

String

/site_A

msgs_per_day

Mean Data Messages count per day over the analysis period

Double

23.4

current_pattern

Only for premium reports, if regular analysis works best for your fleet. Detected regular communication pattern

String

1 msg every 1h

pattern_transition_from

Only for premium reports, if regular analysis works best for your fleet. Previous regular communication pattern if it has changed over the last weeks.

String

undetected : FEW_INTERARRIVALS

pattern_transition_trend

Only for premium reports, if regular analysis works best for your fleet. In case of a recent pattern change, define the trend of the transition.

String

Improving behavior

current_cluster

Only for premium reports, if cluster analysis works best for your fleet. Detected cluster

String

[1] period of almost 12h

cluster_transition_from

Only for premium reports, if cluster analysis works best for your fleet. Previous cluster if it has changed over the last weeks.

String

[3] irregular

cluster_transition_trend

Only for premium reports, if cluster analysis works best for your fleet. In case of a recent cluster change, define the trend of the transition.

String

Improving behavior

last_status

Device interface status of the last day of the analysis period

String

ACTIVATED

detected_lost_msgs_per_day

Only for LORA devices. computed with frame counter. Mean value of lost messages per day over the analysis period

Double

0.3

counter_loss_ratio

Only for LORA devices. computed with frame counter. Mean value of lost messages ratio over the analysis period.

Double

0.05

join_request_per_day

Only for LORA devices. Mean join request messages per day over the analysis period.

Double

0.33

join_accept_per_day

Only for LORA devices. Mean join accept messages per day over the analysis period

Double

0.33

missing_join_accept

Only for LORA devices. Missing join accept has been detected for this device

Boolean

false

too_many_join_cycles

Only for LORA devices. Too many join request/join accept cycles have been detected for this device

Boolean

false

snr_mean

Only for LORA devices. Mean Signal-to-Noise Ratio value over the analysis period.

Double (decibel)

1.1

gtw_mean

Only for LORA devices. Mean number of gateways the device is linked to over the analysis period.

Double

3.81

rssi_mean

Only for LORA devices. Mean Received Signal Strength Indicator over the analysis period.

Double

-109.8

sf_mean

Only for LORA devices. Mean Spreading Factor over the analysis period.

Double

10.6

detected_lost_dtls_packet_per_day

Only for LwM2M devices. Average number of lost DTLS packets per day over the analysis period. Lost DTLS packets are detected based on the DTLS sequence number. Note that a lost DTLS packet does not necessarily mean a loss of application data (LwM2M) as there may be retransmissions.

Double

0.3

counter_dtls_loss_ratio

Only for LwM2M devices. Ratio of lost DTLS packets to the received packets over the analysis period. Lost DTLS packets are detected based on the DTLS sequence number. Note that a lost DTLS packet does not necessarily mean a loss of application data (LwM2M) as there may be retransmissions.

Double

0.05

days_used_for_analysis

Number of days of data used to perform analysis.

Integer

14

Analytics Rule

You can create Analytics Rules that will define :

  • targeted fleet of devices : all targeted devices in a fleet are assumed to have similar behavior in order to better categorize and highlight outliers.

  • report email settings : you will be able to set the language and recipients of the report

Deleting an Analytics Rule will delete all associated reports, analyses and statistics. Re-creating a new Analytics Rule will trigger new analyses and will require few weeks to generate a new traffic history.

If you just want not to receive the report, you can simply disable the Analytics Rule instead of deleting it. You will be able to re-enable it later and keep the history of your analyses.

API

You can refer to the swagger documentation to list all available APIs.


Create a new Analytics Rule
POST /api/v1/device-analytics/rules
{
	"name": "...",
	"fleet": {
		"connectors": [...],
		"groupPaths": [...]
	},
	"report": {
		"recipients": {...},
		"language": "..."
	},
	"enabled": ...
}
JSON Params Description

name

Mandatory. user-defined name for the rule, must be unique and not empty.

fleet

Mandatory. defines the targeted devices of a this AnalyticsRule.

fleet.connectors

Mandatory. analyse only devices with these connectivity. 1 and only 1 connector must be defined.

fleet.groupPath

Optional. analyse only devices that belong to this group.

report

Mandatory. defines the analytics report email parameters.

report.recipients

Mandatory. at least one recipient must be set.

report.language

Mandatory. language of the report : either 'en' or 'fr'.

enabled

Optional. activate or deactivate the rule (default is false).
Version 2026.7.0 • Updated date 2026-08-11 12:37:29 UTC