CAPÍTULO 6 · Los datos empiezan a llegar
El dato tiene una historia anterior a su llegada
Una medición comienza en el dispositivo, no cuando Django la inserta en una tabla. Puede viajar con retraso o necesitar una transformación para expresarse en la unidad que utiliza el equipo. Si solo conservamos la hora de recepción, perdemos parte del contexto que permite interpretar qué estaba sucediendo en el proceso medido.
Diferenciamos el tiempo de medición del tiempo de llegada y establecemos cómo manejar zonas horarias, unidades y calibración. Las funciones compartidas de UTIL_LIB ayudan a mantener cálculos coherentes, mientras el modelo conserva el significado de la información. No queremos que dos pantallas interpreten de forma distinta el mismo valor.
El histórico empieza a representar una secuencia que podemos explicar. Ahora surge una expectativa natural de quien observa la plataforma: ver los cambios cuando ocurren, sin recargar continuamente la página. Para responder necesitamos revisar cómo se comunica el servidor con un navegador que permanece conectado.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una medición conserva su contexto
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Medición. Valor original observado
- Tiempo. Identifica instante y zona
- Calibración. Versión aplicada al valor
- Snapshot. Permite interpretar el histórico
01 / EL PROBLEMA
¿Para qué sirve?
Una lectura recibida hoy puede corresponder a ayer. Cambiar una calibración tampoco debe alterar silenciosamente el significado de datos antiguos.
02 / COMPRENDER
El concepto, explicado
occurred_at es hora del evento; created_at es hora de persistencia. Almacena timestamps aware y presenta zona local de manera explícita.
Un snapshot de coeficientes junto a la lectura conserva qué corrección se aplicó. Los coeficientes futuros no deberían reinterpretar el histórico sin una operación deliberada.
03 / CONSTRUIR
Implementación paso a paso
- Guarda fecha industrial y recepción.
- Versiona o copia coeficientes usados.
- Define una ventana para actualizar estado vivo.
- Conserva histórico tardío sin retroceder el dashboard.
04 / APLICAR
Ejemplo en SensorHub
from datetime import timedelta
def eligible_for_live(*, occurred_at, received_at, latest_at=None):
age = received_at - occurred_at # ambos timestamps aware
if abs(age) > timedelta(minutes=2):
return False
return latest_at is None or occurred_at >= latest_at
# Snapshot conceptual al persistir:
# corrected = gain * raw_value + offset
# guardar raw_value, gain, offset y correctedCómo leer el ejemplo
- La tolerancia de dos minutos es una elección del ejemplo, no un estándar universal.
- Una lectura puede persistirse aunque no sea elegible para vivo.
- Los timestamps iguales y los relojes desviados requieren una regla explícita.
Error habitual
Comparar naive con aware produce errores. No elimines timezone para “arreglar” la comparación.
05 / PRACTICAR
Tu turno
Recibe una lectura de ayer después de una actual.
Ver solución orientativa
Guárdala en el archivo histórico, pero no actualices el display vivo ni el estado de la alarma con ella.
06 / VERIFICAR
Cómo sabes que funciona
- Históricos conservan contexto de calibración.
- Los datos tardíos no sustituyen el estado actual.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
ASGI y WebSockets →Continuar en modo relato