CAPÍTULO 6 · Los datos empiezan a llegar
Los dispositivos llegan por una puerta diferente
Hasta ahora hemos pensado principalmente en personas que consultan o configuran. Un dispositivo no se sienta frente a un formulario de login ni puede resolver una validación leyendo un mensaje. Necesita un contrato estable para enviar información y una forma de identificarse con el alcance mínimo necesario para su trabajo.
Diseñamos la ingesta con sus propios datos de entrada y credenciales técnicas. Antes de guardar una medición comprobamos lo que el sistema necesita saber sobre su origen y contenido. Las reglas de modelos, serializers y servicios que construimos antes encuentran aquí una aplicación concreta. Los reintentos también dejan de ser una posibilidad abstracta cuando interviene una red.
La plataforma puede recibir eventos, pero recibirlos no significa comprenderlos. Una lectura tiene unidades y un momento de medición que puede no coincidir con la hora en que llegó. Si no resolvemos esa diferencia, el histórico podría contar una secuencia equivocada aunque todos los registros se hubieran guardado correctamente.
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
Del dispositivo al dato validado
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Dispositivo. Produce una medición
- Credencial técnica. Identifica al emisor
- Ingesta. Valida contrato y duplicados
- Medición. Persiste el dato aceptado
01 / EL PROBLEMA
¿Para qué sirve?
Un gateway no es una persona navegando por la web. Necesita credenciales, revocación y alcance apropiados, además de validación de las mediciones.
02 / COMPRENDER
El concepto, explicado
La ingesta resuelve el sensor registrado, valida unidades y timestamps y persiste dato crudo. El dispositivo no debería decidir libremente a qué organización pertenece el registro.
Autenticación comprueba origen; no asegura calidad de medición. También necesitas límites de tamaño, frecuencia, identificación de evento y controles de formato.
03 / CONSTRUIR
Implementación paso a paso
- Define un payload pequeño.
- Asocia una credencial a un gateway o sensor.
- Valida con Serializer antes de guardar.
- Invoca el servicio idempotente y registra resultado.
04 / APLICAR
Ejemplo en SensorHub
# telemetria/serializers.py
from rest_framework import serializers
class ReadingInput(serializers.Serializer):
sensor_code = serializers.CharField(max_length=40)
event_key = serializers.UUIDField()
occurred_at = serializers.DateTimeField()
value = serializers.FloatField(min_value=-273.15, max_value=10000)
# Payload del gateway:
# {"sensor_code": "TEMP-01", "event_key": "<uuid>",
# "occurred_at": "2026-10-11T05:00:00Z", "value": 24.5}Cómo leer el ejemplo
- El serializer es entrada de caso de uso, no necesariamente ModelSerializer.
- El servicio resuelve sensor_code y autoriza su alcance antes de store_reading.
- Una validación adicional debe verificar math.isfinite(value).
Error habitual
Basic codifica con Base64, no cifra. Si lo eliges, usa TLS y credenciales limitadas; evita una clave compartida para todos los dispositivos cuando necesites revocación individual.
05 / PRACTICAR
Tu turno
Envía un sensor inexistente y una lectura sin fecha.
Ver solución orientativa
La entrada se rechaza y no se crea un sensor automáticamente ni se inventa una fecha industrial.
06 / VERIFICAR
Cómo sabes que funciona
- Un gateway no puede escribir para un sensor fuera de su alcance.
- Reintentos no duplican registros.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Timestamps, calibración y datos históricos →Continuar en modo relato