Un dashboard IoT resuelve el problema de ver los datos de campo. Pero tarde o temprano surge una pregunta distinta: ¿cómo entra ese dato de oxígeno disuelto, consumo eléctrico o nivel de combustible al ERP que ya usa contabilidad, al SCADA de la planta, o al reporte de Power BI que revisa la gerencia cada lunes? La respuesta casi siempre es una API. Este artículo explica, con las piezas técnicas reales —REST, MQTT, webhooks, formatos y seguridad—, cómo se conecta una plataforma IoT con los sistemas que ya opera la empresa, sin depender de que alguien copie números a mano desde una pantalla a una hoja de cálculo.
REST: la puerta de entrada para consultar datos bajo demanda
La mayoría de plataformas IoT exponen una API REST con dos patrones básicos. El primero es la lectura puntual: un endpoint tipo GET /devices/{id}/latest que devuelve el último valor reportado por un sensor, útil para que un sistema externo pregunte “¿cuánto combustible hay ahora mismo?” en el momento en que lo necesita. El segundo es la consulta histórica: GET /devices/{id}/data?from=...&to=..., que devuelve un rango de tiempo completo —normalmente paginado, con límites de 100 a 1.000 registros por página— para alimentar un reporte mensual o comparar una temporada de siembra con la anterior.
La autenticación se maneja por capas según quién consulta: API keys estáticas para integraciones simples de un solo cliente, tokens JWT enviados como Authorization: Bearer <token> para sesiones de aplicación, y flujos OAuth2 de client-credentials cuando dos sistemas de la empresa necesitan hablar entre sí sin intervención humana. ChirpStack, uno de los network servers LoRaWAN más usados —que ya cubrimos en la guía de network servers y qué hacen—, sigue justamente este esquema: un token se genera una vez desde la interfaz web y se usa en cada llamada a su API REST/gRPC.
MQTT: cuando el dato tiene que llegar en el momento en que ocurre
REST funciona bien para “pregunte cuando quiera”, pero no para “avíseme apenas pase algo”. Ahí entra MQTT, un protocolo de publicación/suscripción sobre una conexión persistente a través de un broker: un sistema se suscribe a un tema (topic) como v3/mi-app/devices/sensor-04/up y recibe cada mensaje nuevo en cuanto el broker lo publica, sin tener que preguntar repetidamente. The Things Stack, por ejemplo, publica cada uplink en ese formato de topic sobre el puerto 8883 con TLS.
MQTT define tres niveles de QoS (calidad de servicio) que conviene entender antes de diseñar una integración: QoS 0 (“como máximo una vez”) no confirma entrega y puede perder mensajes —aceptable para telemetría frecuente donde una lectura perdida no importa, porque la siguiente llega en minutos—; QoS 1 (“al menos una vez”) confirma pero puede duplicar mensajes; y QoS 2 (“exactamente una vez”) garantiza entrega única mediante un intercambio de cuatro pasos, con más latencia, reservado para comandos críticos como abrir una válvula o apagar un aireador de forma remota, un caso que detallamos en seguridad y permisos para control remoto de bombas y aireadores.
Webhooks: la integración más simple para llevar datos a un sistema externo
Para la mayoría de integraciones empresariales —un ERP, una hoja de cálculo automatizada, una alerta a un sistema de tickets— la pieza más práctica no es MQTT ni consultar REST cada minuto, sino un webhook: la plataforma IoT hace un HTTP POST con el evento en JSON hacia una URL que la empresa configura, apenas ocurre (nuevo dato, alarma disparada, dispositivo desconectado). ChirpStack, por ejemplo, ofrece justamente esta “integración HTTP” como alternativa a MQTT para el mismo evento de uplink.
Dos detalles técnicos separan un webhook confiable de uno que pierde eventos en silencio:
- Reintentos con backoff exponencial. Si el sistema receptor está caído un momento, el emisor debe reintentar en intervalos crecientes en vez de rendirse al primer fallo o bombardear el endpoint. Stripe, como referencia de la industria, reintenta en algo como 5 min, 30 min, 2 h, 5 h, 10 h y luego cada hora, durante varios días, antes de desactivar el endpoint.
- Firma HMAC del payload. Para que el receptor confirme que el webhook realmente vino de la plataforma IoT y no de un tercero, se envía un encabezado con el hash HMAC-SHA256 del cuerpo crudo de la petición, calculado con una clave secreta compartida; el receptor recalcula el mismo hash y lo compara antes de procesar el evento. Sin esa verificación, cualquiera que adivine la URL del webhook podría inyectar datos falsos en el ERP.
De payload binario a JSON: el rol del decoder
Un nodo LoRaWAN no transmite JSON: transmite un payload binario compacto —unos pocos bytes en hexadecimal— para ahorrar batería y respetar el duty cycle, como explicamos en duty cycle y time on air. Antes de que ese dato llegue a cualquier API o webhook, el network server ejecuta un decoder —una función que interpreta esos bytes según el mapa de campos del sensor— y produce un objeto JSON legible: {"temperatura": 27.3, "humedad_suelo": 42, "bateria": 3.6}. Ese es el momento exacto en que el dato deja de ser una cadena de bits y se convierte en información que un ERP, un SCADA o una hoja de cálculo puede consumir. El JSON es hoy el formato casi universal para estas integraciones; el CSV sigue siendo el estándar cuando el destino es un reporte o una exportación para análisis histórico.
Conectar con SCADA, ERP y BI: qué protocolo usa cada uno
No todos los sistemas internos de una empresa hablan el mismo idioma:
- SCADA industrial: suele integrarse vía OPC-UA (estándar IEC 62541, puerto 4840 por defecto), diseñado con seguridad desde el protocolo —certificados X.509 en el handshake de canal seguro—, o mediante una pasarela Modbus TCP cuando el SCADA ya habla ese protocolo de planta, como detallamos en la guía de Modbus RTU, function codes y registros para PLC/SCADA.
- ERP (SAP, Odoo): normalmente vía REST o webhooks —Odoo expone endpoints JSON-RPC/XML-RPC nativos; SAP suele integrarse a través de OData o una capa intermedia (SAP CPI)— para que, por ejemplo, un consumo eléctrico medido en planta alimente automáticamente el módulo de costos.
- BI y visualización (Grafana, Power BI): Grafana se conecta directo a bases de datos de series de tiempo o a una API JSON genérica; Power BI, vía conectores REST o consulta directa a la base de datos.
- Automatización sin código (Node-RED, Zapier, Make): útiles cuando la empresa no quiere programar un receptor de webhooks desde cero, sino conectar visualmente “cuando llegue esta alarma, crea un ticket” o “cuando el nivel de combustible baje de X, envía un correo”.
Seguridad: lo que no debe faltar en ninguna integración
Abrir una API hacia sistemas internos multiplica los puntos donde algo puede salir mal si no se asegura bien:
- TLS/HTTPS obligatorio en toda comunicación, sin excepción, incluidos los webhooks salientes.
- Tokens con alcance limitado (scoped) por integración: el sistema que solo necesita leer temperatura no debería tener el mismo token que puede accionar una válvula remota.
- Rotación periódica de API keys, para que una credencial filtrada tenga una ventana de exposición corta.
- Límite de tasa (rate limiting) por clave, para que una integración mal configurada —o un intento de abuso— no sature la plataforma.
- Lista blanca de IPs para integraciones especialmente sensibles, como una escritura hacia SCADA o ERP.
Conclusión
Conectar sensores IoT con los sistemas internos de una empresa no exige elegir una sola tecnología: exige elegir la correcta para cada caso. REST para consultas bajo demanda e históricos, MQTT para telemetría y comandos en tiempo real, webhooks para avisar a un ERP o a una herramienta de automatización apenas ocurre un evento, y un decoder que convierta el payload binario del sensor en JSON utilizable antes de que cualquiera de esas rutas entre en juego. Sin esa arquitectura, el dato de campo se queda atrapado en un dashboard bonito que nadie más que el operador llega a ver.
En Yubox integramos nuestros nodos IoT, gateways LoRaWAN y equipos de control remoto con Yubox Cloud, que expone estas mismas rutas de integración —REST, MQTT y webhooks— para que sus datos de campo lleguen directo al ERP, SCADA o BI que ya usa su empresa. Si necesita conectar sus sensores con un sistema interno específico, conversemos sobre su proyecto.