Marcas de tiempo, lecturas tardías y duplicadas

Cada lectura se guarda con una hora. Esta página explica qué hora es esa, qué lecturas se rechazan por su hora, cómo se gestionan los duplicados y qué ocurre con las lecturas que llegan tarde.

Hora del dispositivo o hora de recepción

Lo que envía el dispositivo	Guardado en
Un objeto plano, por ejemplo `{"temperature": 21.5}`	La hora en que la plataforma recibió el mensaje
`{"ts": 1759572000000, "values": {...}}`	`ts`: la hora propia del dispositivo
Un array con las dos formas	Cada elemento con su propia hora

ts es un entero en milisegundos desde el 1 de enero de 1970, UTC. Cualquier otro ts (segundos, una cadena, un número negativo) descarta ese registro como bad_ts. Consulte Referencia de temas y cargas MQTT.

Envíe ts solo cuando el reloj del dispositivo esté sincronizado. Un dispositivo sin reloj fiable debe enviar objetos planos y dejar que la plataforma les asigne la hora. Un reloj que se desvía produce lecturas en el lugar incorrecto de los gráficos y puede ser rechazado.

En un flujo, la hora del registro es msg.metadata.recordTs y la hora de recepción msg.metadata.ts. El bloque Guardar telemetría guarda la hora del registro por defecto; su ajuste ts puede cambiarlo a la hora de recepción, y ts_path puede reasignar la hora de un registro a partir de un valor del mensaje.

Lecturas del futuro

Un registro con una marca de tiempo más de 10 minutos por delante de la hora de llegada se descarta como bad_ts. Nunca se corrige a «ahora». Para cambiar la tolerancia, vaya a Configuración > Telemetría (Configuración de telemetría IoT):

Ajuste	Valor por defecto	Rango
Tolerancia de marca de tiempo futura (minutos)	10	1 a 1.440
Lectura aceptada más antigua (días)	0 (cualquier antigüedad)	0 a 36.500

Un registro anterior en más de Lectura aceptada más antigua (días) a su llegada se descarta como bad_ts. Úselo para evitar que un dispositivo reenvíe datos antiguos almacenados en búfer. La página requiere los permisos Ver configuración de telemetría IoT y Cambiar configuración de telemetría IoT (por defecto, Administrador). Los cambios llegan a la ingesta en un minuto.

Lecturas del pasado

Una lectura más antigua que su clase de retención de datos en bruto la rechaza el almacén como too_old, independientemente de los ajustes anteriores:

Clase de retención	Se rechaza una lectura cuando es más antigua que
7 días	7 días
30 días	7 días
90 días	30 días
365 días	90 días
1.095 días	90 días

Las lecturas dentro de la ventana en bruto se guardan aunque sean antiguas, y se agregan en los resúmenes por minuto, hora y día. Consulte Cuánto tiempo se conservan los datos.

Duplicados

Un dispositivo, una pasarela o un reintento pueden enviar la misma lectura dos veces. Hermetry lo gestiona en dos puntos:

Antes del flujo. Un mensaje de dispositivo cuyo identificador ya se vio en los últimos 60 segundos, o, si no tiene identificador pero incluye su propio ts, cuyo contenido ya se vio, se confirma sin ejecutar el flujo. Una lectura sin identificador ni ts nunca se trata como repetida: el mismo valor dos veces son dos lecturas.
En el almacén. Un mensaje con los mismos valores en la misma hora para el mismo dispositivo se guarda una sola vez. Un mensaje reentregado o reproducido no cambia nada.

Dos mensajes distintos con la misma marca de tiempo se conservan ambos. Cuando la API lee valores en bruto, devuelve un punto por marca de tiempo. El último valor conserva el primero que vio para esa marca de tiempo.

Lecturas desordenadas

Un dispositivo que almacena lecturas en búfer sin conexión y las envía después las entrega tras datos más recientes. Se guardan en el histórico en sus propias horas. No sustituyen a un último valor más reciente. Las reglas de alarma tratan los registros anteriores al último evaluado como backfill: no se evalúan en vivo, y una regla con backfill activado registra alarmas a partir de ellos sin notificar a nadie. Consulte Condiciones de cierre y lecturas tardías.

Lecturas retrasadas por una interrupción

Los mensajes esperan en una cola mientras un worker de procesamiento está caído. Cuando la plataforma se pone al día, un mensaje de dispositivo que esperó más que su tiempo de vida (5 minutos por defecto) es un mensaje tardío:

Sigue ejecutándose por su flujo raíz y se guarda. El backlog son sus datos, por lo que nunca se descarta allí.
Se marca como tardío (msg.metadata.late). Los bloques que actúan fuera de la plataforma lo omiten: sin notificación, sin comando al dispositivo, sin llamada HTTP ni publicación MQTT (salvo que el ajuste late del bloque sea send), y sin evento emitido.
El bloque Reglas de alarma lo evalúa como backfill: las alarmas se escriben en el histórico, se marcan como Backfilled y nadie recibe aviso por el pasado. Una alarma que siga abierta cuando se reanudan las lecturas en vivo se anuncia entonces.
Otros flujos que reaccionarían a él (por ejemplo, un listener de alarm) lo descartan y lo cuentan como Demasiado antiguo.

Consulte Protecciones y mensajes fallidos.

Zonas horarias

Todo se guarda en UTC. La consola, los paneles y las exportaciones muestran las horas en la zona del usuario. Los agregados diarios van de medianoche a medianoche en UTC; consulte Agregados y resúmenes para leer días locales.

Resolución de problemas

Síntoma	Causa probable
Falta una lectura, pero las demás del mismo dispositivo están	Su `ts` estaba en el futuro o fuera de rango (`bad_ts`), o es más antigua que la ventana en bruto (`too_old`). Revise los registros de ejecución del flujo raíz.
Las lecturas aparecen con horas o un día de diferencia	El dispositivo envía `ts` en hora local o en segundos. Envíe milisegundos UTC, o objetos planos.
El último valor no cambia aunque lleguen lecturas nuevas	Las lecturas nuevas traen un `ts` anterior o igual al almacenado.
Una corrección no aparece	Se envió con el mismo `ts` que el original; el último valor conserva el primero. Envíe la corrección con un `ts` nuevo.

Consulte también Horas incorrectas y huecos.