Horodatages, mesures tardives et doublons

Chaque mesure est enregistrée à un instant précis. Cette page explique quel est cet instant, quelles mesures sont refusées en raison de leur horodatage, comment les doublons sont traités et ce qui arrive aux mesures reçues en retard.

Heure de l’appareil ou heure de réception

Ce que l’appareil envoie	Enregistré à
Un objet plat, par exemple `{"temperature": 21.5}`	L’heure à laquelle la plateforme a reçu le message
`{"ts": 1759572000000, "values": {...}}`	`ts` : l’heure propre à l’appareil
Un tableau des deux formes	Chaque élément à sa propre heure

ts est un entier en millisecondes depuis le 1er janvier 1970, UTC. Tout autre ts (secondes, chaîne de caractères, nombre négatif) écarte cet enregistrement avec bad_ts. Voir Référence des sujets et charges utiles MQTT.

N’envoyez ts que si l’horloge de l’appareil est synchronisée. Un appareil sans horloge fiable doit envoyer des objets plats et laisser la plateforme les horodater. Une horloge qui dérive produit des mesures au mauvais endroit sur les graphiques et peut être refusée.

Dans un flux, l’heure de l’enregistrement est msg.metadata.recordTs et l’heure de réception msg.metadata.ts. Le bloc Save telemetry enregistre par défaut l’heure de l’enregistrement ; son réglage ts peut basculer sur l’heure de réception, et ts_path peut redater un enregistrement à partir d’une valeur du message.

Mesures provenant du futur

Un enregistrement horodaté de plus de 10 minutes dans le futur par rapport à son heure d’arrivée est écarté avec bad_ts. Il n’est jamais corrigé en « maintenant ». Pour modifier la tolérance, allez dans Settings > Telemetry (IoT Telemetry Settings) :

Réglage	Par défaut	Plage
Future timestamp tolerance (minutes)	10	1 à 1 440
Oldest accepted reading (days)	0 (tout âge)	0 à 36 500

Un enregistrement antérieur de plus de Oldest accepted reading (days) à son arrivée est écarté avec bad_ts. Ce réglage permet d’empêcher un appareil de rejouer des données tamponnées très anciennes. La page nécessite les permissions View IoT telemetry settings et Change IoT telemetry settings (Admin par défaut). Les modifications atteignent l’ingestion en moins d’une minute.

Mesures provenant du passé

Une mesure plus ancienne que votre classe de rétention conservant les données brutes est refusée par le stockage avec too_old, quels que soient les réglages ci-dessus :

Classe de rétention	Une mesure est refusée lorsqu’elle est plus ancienne que
7 jours	7 jours
30 jours	7 jours
90 jours	30 jours
365 jours	90 jours
1 095 jours	90 jours

Les mesures comprises dans la fenêtre brute sont enregistrées même lorsqu’elles sont anciennes, et intégrées aux synthèses par minute, par heure et par jour. Voir Durée de conservation des données.

Doublons

Un appareil, une passerelle ou une nouvelle tentative peut envoyer deux fois la même mesure. Hermetry gère cela à deux niveaux :

Avant le flux. Un message d’appareil dont l’identifiant de message a déjà été vu dans les 60 secondes, ou, lorsqu’il n’a pas d’identifiant mais porte son propre ts, dont le contenu a déjà été vu, est acquitté sans exécution. Une mesure sans identifiant ni ts n’est jamais considérée comme un doublon : la même valeur deux fois représente deux mesures.
Dans le stockage. Un message ayant les mêmes valeurs à la même heure pour le même appareil n’est enregistré qu’une fois. Un message redélivré ou rejoué ne modifie rien.

Deux messages différents ayant le même horodatage sont tous deux conservés. Lorsque l’API lit les valeurs brutes, elle renvoie un seul point par horodatage. La dernière valeur conserve le premier point vu pour cet horodatage.

Mesures arrivées dans le désordre

Un appareil qui tamponne des mesures pendant qu’il est hors ligne et les envoie plus tard les livre après des données plus récentes. Elles sont enregistrées dans l’historique à leurs propres instants. Elles ne remplacent pas une dernière valeur plus récente. Les règles d’alarme traitent les enregistrements plus anciens que le dernier évalué comme du rattrapage : ils ne sont pas évalués en direct, et une règle avec rattrapage activé enregistre les alarmes à partir d’eux sans notifier personne. Voir Conditions de levée et mesures tardives.

Mesures retardées par une panne

Les messages attendent dans une file d’attente lorsqu’un worker de traitement est arrêté. Lorsque la plateforme rattrape son retard, un message d’appareil ayant attendu plus longtemps que sa durée de vie (5 minutes par défaut) est un message tardif :

Il passe toujours par son flux racine et est enregistré. Un retard accumulé fait partie de vos données, il n’est donc jamais écarté à cette étape.
Il est marqué comme tardif (msg.metadata.late). Les blocs qui agissent hors de la plateforme l’ignorent : pas de notification, pas de commande d’appareil, pas d’appel HTTP ni de publication MQTT (sauf si le réglage late du bloc vaut send), pas d’événement émis.
Le bloc Alarm rules l’évalue comme du rattrapage : les alarmes sont écrites dans l’historique, marquées Backfilled, et personne n’est appelé pour le passé. Une alarme encore ouverte lorsque les mesures en direct reprennent est annoncée à ce moment-là.
Les autres flux qui réagiraient à ce message (par exemple un écouteur alarm) l’écartent et le comptent comme Too old.

Voir Protections et messages en échec.

Fuseaux horaires

Tout est stocké en UTC. La console, les tableaux de bord et les exports affichent les heures dans le fuseau du spectateur. Les agrégats journaliers vont de minuit à minuit en UTC ; voir Agrégats et cumuls pour lire des journées locales.

Dépannage

Symptôme	Cause probable
Une mesure manque, les autres du même appareil sont présentes	Son `ts` était dans le futur ou hors plage (`bad_ts`), ou plus ancien que la fenêtre brute (`too_old`). Consultez les enregistrements d’exécution du flux racine.
Les mesures apparaissent décalées de plusieurs heures ou d’un jour	L’appareil envoie son `ts` en heure locale ou en secondes. Envoyez des millisecondes UTC, ou des objets plats.
La dernière valeur ne change pas alors que de nouvelles mesures arrivent	Les nouvelles mesures ont un `ts` plus ancien ou égal à celui qui est stocké.
Une valeur corrigée ne s’affiche pas	Elle a été envoyée avec le même `ts` que l’original ; la dernière valeur conserve la première. Envoyez la correction avec un nouveau `ts`.

Voir aussi Heures incorrectes et trous.