Cómo integrar sensores IoT en una plataforma web

Un sensor conectado no es todavía una solución IoT

Conseguir que un dispositivo envíe un valor a Internet puede ser relativamente sencillo. Construir una plataforma capaz de recibir datos de cientos o miles de dispositivos, identificar su origen, detectar errores, conservar históricos y generar alertas fiables es un problema mucho más amplio.

La integración IoT debe resolver preguntas que no aparecen en una demostración inicial. ¿Qué ocurre si el dispositivo repite un mensaje? ¿Cómo se sabe que una lectura pertenece al sensor correcto? ¿Qué pasa si llega tarde, sin unidad o con una marca temporal incorrecta? ¿Cómo se actualizan credenciales? ¿Quién recibe una alerta y cómo se evita generar cientos de avisos?

Arquitectura básica de una plataforma IoT

No todos los proyectos utilizan un gateway físico. Un dispositivo con conectividad móvil puede comunicarse directamente con la plataforma. Sin embargo, la separación conceptual sigue siendo útil para entender dónde se mide, dónde se transporta, dónde se transforma y dónde se interpreta.

La solución de Integración IoT y Sensores de ARVELA aborda estas capas desde el dispositivo hasta el dashboard.

Diferenciar activo, dispositivo y sensor

Un error habitual es utilizar estos conceptos como si fueran equivalentes. El activo es aquello que la organización quiere supervisar: una máquina, un animal, un depósito, una parcela, un vehículo o una sala. El dispositivo es el equipo físico conectado. El sensor es el elemento que mide una variable.

Un dispositivo puede incorporar varios sensores y cambiar de activo durante su vida útil. Por eso la plataforma debería mantener la asignación entre dispositivo y activo, incluyendo fechas de instalación, sustitución y mantenimiento.

Elegir la conectividad

La red debe seleccionarse según distancia, consumo, volumen de datos, movilidad, cobertura, latencia y coste. La mejor opción no es la más moderna, sino la que responde al entorno.

Qué hace un gateway IoT

El gateway actúa como puente entre dispositivos y plataforma. Puede recibir Bluetooth, Modbus, LoRa, serie u otros protocolos y convertirlos a MQTT, HTTP o un formato común.

También puede:

• Filtrar o agregar lecturas.
• Almacenar datos si se pierde la conexión.
• Ejecutar reglas locales.
• Convertir unidades y formatos.
• Gestionar dispositivos de una instalación.
• Enviar solo eventos relevantes.
• Actualizar configuración de sensores.

El gateway introduce capacidad, pero también un nuevo elemento que debe desplegarse, actualizarse y monitorizarse.

MQTT frente a HTTP

MQTT y HTTP pueden convivir dentro de la misma solución. MQTT es habitual para telemetría y eventos continuos. HTTP es muy útil para APIs, configuración, consultas y operaciones administrativas.

Diseñar temas MQTT

Los topics deben permitir enrutar mensajes sin incluir información sensible ni crear una estructura imposible de mantener. Una organización frecuente separa entorno, organización, dispositivo y tipo de mensaje.

produccion/organizacion-42/dispositivo-928/telemetria
produccion/organizacion-42/dispositivo-928/eventos
produccion/organizacion-42/dispositivo-928/estado
produccion/organizacion-42/dispositivo-928/comandos

La estructura exacta depende del broker, la multitenencia y las reglas de autorización. Los permisos deben limitar qué topics puede publicar y consumir cada identidad.

Diseñar el formato de los mensajes

Un mensaje debe incluir información suficiente para interpretarse, pero no repetir datos estáticos innecesariamente. Conviene versionar el esquema para permitir cambios futuros.

{
  "schema_version": "1.0",
  "device_id": "sensor-928",
  "timestamp": "2026-08-06T10:30:00Z",
  "sequence": 18422,
  "measurements": {
    "temperature_c": 21.4,
    "humidity_pct": 57.2
  },
  "battery_pct": 78,
  "signal_dbm": -91
}

Los campos habituales incluyen identificador, fecha del dispositivo, número de secuencia, mediciones, unidad, batería, cobertura, firmware y calidad. La plataforma puede enriquecer el mensaje con organización, activo y ubicación.

Marcas temporales y orden de eventos

En IoT existen al menos dos tiempos relevantes: cuándo ocurrió la medición y cuándo la recibió la plataforma. Pueden diferir si el dispositivo trabaja sin cobertura y envía datos más tarde.

La plataforma debería conservar ambos. También debe gestionar mensajes duplicados, fuera de orden y relojes incorrectos. Un número de secuencia o identificador de evento facilita la deduplicación.

La capa de ingesta

La ingesta recibe mensajes, autentica al dispositivo, valida el formato y los convierte a un modelo interno. Debe ser rápida y resistente, evitando que una operación lenta bloquee la recepción.

Las tareas típicas son:

• Autenticación y autorización.
• Validación del esquema.
• Normalización de unidades.
• Deduplicación.
• Enriquecimiento con metadatos.
• Envío a almacenamiento o colas.
• Registro de errores y mensajes rechazados.

En arquitecturas de mayor volumen es habitual desacoplar recepción, procesamiento y persistencia mediante colas o sistemas de eventos.

Diseñar el modelo de datos

La plataforma necesita almacenar configuración y telemetría. La configuración cambia lentamente: usuarios, activos, dispositivos, sensores y reglas. La telemetría puede crecer con rapidez.

Base relacional o series temporales

No siempre hace falta una tecnología especializada. Una base relacional puede gestionar volúmenes moderados si se particiona, indexa y modela correctamente. Una base de series temporales puede facilitar retención, agregación y consultas por intervalos.

La decisión depende de:

• Número de dispositivos.
• Frecuencia de mensajes.
• Duración del histórico.
• Consultas y agregaciones.
• Necesidad de tiempo real.
• Coste operativo y experiencia del equipo.

Motor de reglas y alertas

Las reglas convierten datos en eventos. Pueden basarse en umbrales, duración, variaciones, ausencia de mensajes, geovallas, combinación de sensores o modelos de IA.

Una alerta debe tener ciclo de vida: abierta, reconocida, en revisión, resuelta o descartada. Sin este flujo, la plataforma genera notificaciones, pero no gestiona incidencias.

Tiempo real, WebSockets y actualización de dashboards

Para mostrar datos nuevos sin recargar la página pueden utilizarse WebSockets o Server-Sent Events. Sin embargo, el dashboard no necesita recibir cada lectura si el usuario solo requiere una actualización agregada.

Es importante separar la frecuencia de captura de la frecuencia de visualización. Un sensor puede reportar cada segundo, mientras la interfaz muestra un promedio cada minuto.

Diseño de APIs para IoT

Las APIs permiten consultar activos, dispositivos, telemetría, eventos y alertas. También pueden utilizarse para aprovisionamiento y configuración.

GET  /api/v1/assets/{assetId}
GET  /api/v1/devices/{deviceId}/telemetry
GET  /api/v1/alerts?status=open
POST /api/v1/devices/{deviceId}/commands
POST /api/v1/webhooks/integrations

Las APIs deben incluir autenticación, paginación, filtros, límites, versionado y respuestas de error consistentes. Los datos de varias organizaciones deben aislarse correctamente.

Comunicación desde la plataforma hacia el dispositivo

Algunos proyectos necesitan enviar configuración o comandos. Esto introduce nuevas responsabilidades: autorización, confirmación, expiración, reintentos y seguridad.

La plataforma debe distinguir entre comando solicitado, entregado, ejecutado y confirmado. Un mensaje publicado no garantiza que el dispositivo haya realizado la acción.

Seguridad de extremo a extremo

Cada dispositivo debe tener una identidad propia o un mecanismo seguro de pertenencia. Compartir credenciales entre toda una flota dificulta revocar un equipo comprometido.

• Cifrado en tránsito.
• Credenciales individuales o certificados.
• Rotación y revocación.
• Permisos mínimos por topic o endpoint.
• Firma o validación de firmware.
• Actualizaciones seguras.
• Auditoría de comandos y configuración.
• Segmentación de red para gateways.

La seguridad debe considerarse desde el aprovisionamiento hasta la retirada del dispositivo.

Monitorizar la propia plataforma

Una solución IoT debe supervisar tanto los activos como su infraestructura. Conviene medir mensajes recibidos, errores, latencia, dispositivos activos, colas, almacenamiento y reglas ejecutadas.

Indicadores útiles:

• Última comunicación por dispositivo.
• Porcentaje de mensajes rechazados.
• Latencia entre medición e ingesta.
• Duplicados y mensajes fuera de orden.
• Consumo de almacenamiento.
• Alertas generadas y reconocidas.
• Versión de firmware por flota.

Cómo preparar el escalado

Escalar no significa solo añadir servidores. También implica altas de dispositivos, soporte, actualizaciones, mantenimiento, límites de red y costes de almacenamiento.

Conviene estimar:

• Dispositivos activos y crecimiento anual.
• Mensajes por dispositivo y día.
• Tamaño medio de cada mensaje.
• Retención de datos brutos y agregados.
• Número de reglas y alertas.
• Usuarios simultáneos y frecuencia de consultas.
• Coste de conectividad y soporte.

Casos de uso

Ganadería inteligente

Collares GPS, bolos y estaciones ambientales pueden integrarse con mapas, geovallas, actividad y alertas. La solución AVEGA es un ejemplo de plataforma sectorial construida sobre datos IoT.

Industria

Sensores de vibración, consumo, presión o temperatura pueden alimentar mantenimiento, históricos y detección de desviaciones.

Edificios y Smart City

Calidad ambiental, presencia, energía, alumbrado, riego o aforos pueden centralizarse en cuadros de mando y sistemas de actuación.

Logística

Posición, apertura, temperatura y golpes pueden relacionarse con vehículos, rutas, pedidos y mercancías.

Cómo empezar con un piloto

Errores habituales

• Guardar lecturas sin modelar activos y dispositivos.
• Confiar únicamente en la fecha de recepción.
• No versionar el esquema de mensajes.
• Compartir credenciales entre todos los dispositivos.
• No gestionar duplicados y mensajes fuera de orden.
• Mostrar cada lectura en tiempo real sin necesidad.
• Crear alertas sin ciclo de vida.
• Olvidar firmware, batería y mantenimiento.
• Escalar antes de validar conectividad y operación.
• Depender de un proveedor sin acceso exportable al dato.

Preguntas frecuentes sobre integración IoT

Conclusión

Integrar sensores IoT en una plataforma web exige coordinar hardware, conectividad, protocolos, seguridad, modelos de datos, APIs, reglas y experiencia de usuario. La dificultad real no está en recibir el primer dato, sino en mantener una solución fiable durante toda la vida de los dispositivos.

Una buena arquitectura conserva identidad, tiempo, contexto y trazabilidad. También diferencia la telemetría de los eventos, las alertas y las acciones. Empezar con un piloto permite validar cobertura, autonomía, formato, utilidad y costes antes de ampliar el despliegue.