MQTT, RS485, Modbus: ¿qué protocolo elegir para tus sensores de campo?

· 14 min de lectura
14 min read
Equipo Eziwan
Equipo Eziwan
Infraestructura IoT

Conectar sensores industriales a la nube suele equivaler a establecer un diálogo entre dos mundos: el OT, con sus robustos buses serie, sus controladores lógicos programables y sus equipos existentes; y el IT, con sus redes IP, sus brokers, sus bases de datos en tiempo real y sus paneles de control en la nube.

El enfoque adecuado no consiste necesariamente en sustituir la instalación de campo. En muchos proyectos de IIoT, lo más eficaz es mantener RS485/Modbus en el lado de campo y utilizar MQTT en el lado de la nube, con una pasarela capaz de traducir, filtrar y publicar los datos correctamente.

RS485, Modbus, MQTT: tres conceptos que no hay que confundir​

Antes de elegir un protocolo, hay que distinguir tres niveles que a menudo se confunden:

TérminoFunciónEjemplo de uso
RS485Capa física serieConectar varios equipos a un bus de dos hilos
Modbus RTUProtocolo de aplicación en conexión serieLeer registros de un contador o un sensor
MQTTProtocolo de publicación/suscripción sobre IPPublicar mediciones en un broker en la nube

A tener en cuenta RS485 transmite la señal, Modbus RTU estructura las comunicaciones con los dispositivos de campo y MQTT envía los datos a sistemas informáticos o a la nube.

RS485 / Modbus: la base de la tecnología operativa (OT) de los equipos industriales​

RS485: una conexión en serie resistente para el campo​

El RS485 es una conexión serie diferencial que se utiliza desde hace mucho tiempo en la industria. Sigue siendo muy habitual porque es robusto, económico y adecuado para entornos en los que los equipos están repartidos por un armario, un taller o una instalación remota.

Se utiliza con frecuencia para conectar:

  • controladores industriales;
  • contadores de energía;
  • inversores;
  • variadores de frecuencia;
  • sensores de temperatura, presión, caudal o humedad;
  • analizadores de aire, agua o energía.

La distancia máxima teórica de un bus RS485 puede alcanzar aproximadamente 1 200 metros en buenas condiciones, pero depende en gran medida de la velocidad de transmisión, la calidad del cable, la topología, la terminación y el nivel de ruido electromagnético.

Modbus RTU: lectura y escritura de registros​

En RS485, el protocolo más habitual es Modbus RTU. Define una forma estandarizada de consultar los equipos esclavos desde un maestro: dirección del esclavo, función de lectura o escritura, dirección del registro, valor y control de errores.

Ventajas y limitaciones de Modbus RTU​

PuntoLectura sobre el terreno
RobustezAdecuado para entornos industriales y largas distancias controladas
InteroperabilidadMuy extendido en sensores, contadores, variadores y controladores lógicos programables
SimplicidadLectura clara de los registros, fácil de diagnosticar con las herramientas adecuadas
Limitación principalNo es nativo de IP: se necesita una pasarela para integrarlo en la nube
Aspecto a tener en cuentaUna terminación incorrecta, un cableado en estrella o unos parámetros serie incoherentes pueden degradar considerablemente la comunicación

MQTT: el protocolo ideal para la publicación en la nube​

MQTT es un protocolo de publicación/suscripción diseñado para transmitir mensajes ligeros a través de TCP/IP. Se utiliza ampliamente en arquitecturas de IoT e IIoT, ya que separa a los productores de datos de los consumidores.

El principio es sencillo:

  • un cliente MQTT publica mensajes;
  • los mensajes se envían a temas;
  • un broker MQTT recibe, distribuye y protege las comunicaciones;
  • las aplicaciones suscritas consumen los datos: supervisión, base de series temporales, alertas, datalake, herramientas de negocio.

¿Por qué MQTT complementa bien a Modbus?​

Modbus es muy eficaz para consultar dispositivos de campo. MQTT es más adecuado para publicar datos en aplicaciones remotas.

NecesidadProtocolo más adecuado
Leer los registros de un sensor RS485Modbus RTU
Consultar un controlador lógico mediante EthernetModbus TCP
Enviar mediciones a la nubeMQTT
Separar la recopilación de datos sobre el terreno de la gestión informáticaMQTT
Mantener los equipos industriales existentesRS485 / Modbus

Por lo tanto, MQTT no es un sustituto directo de RS485. Más bien actúa como capa de transporte de aplicaciones hacia los sistemas informáticos, una vez que los datos de campo se han recopilado, normalizado y contextualizado.

La función de la pasarela Eziwan: servir de puente entre la OT y la nube​

La pasarela Eziwan permite conectar equipos de campo y enviar sus datos a servicios remotos. En una arquitectura típica, desempeña tres funciones:

  1. Recopilación OT: consulta de equipos Modbus RTU a través de RS485 o Modbus TCP en la red local.
  2. Normalización: conversión de los registros en valores procesables con etiqueta, unidad, marca de tiempo y calidad.
  3. Publicación en TI: envío de los datos a un broker MQTT, una plataforma en la nube o un sistema de supervisión.

Configuración de Modbus a MQTT: los parámetros que hay que dominar​

1. Definir el sondeo Modbus​

El primer paso consiste en describir los equipos a los que se va a realizar la consulta:

  • dirección Modbus de cada esclavo;
  • tipo de registro: registro de retención, registro de entrada, bobina, entrada discreta;
  • dirección del registro;
  • formato de datos: entero de 16 bits, entero de 32 bits, flotante de 32 bits, booleano;
  • orden de las palabras y los bytes, si es necesario;
  • unidad física;
  • intervalo de lectura;
  • nombre de la etiqueta publicada en el lado MQTT.

Aspecto a tener en cuenta Dos equipos pueden mostrar una misma medida en formatos diferentes. Por lo tanto, siempre hay que consultar la documentación del fabricante: dirección exacta, base de indexación, tipo de registro, factor de escala y endianidad.

2. Ejemplo de configuración JSON​

{
  "modbus": {
    "baud_rate": 9600,
    "parity": "none",
    "stop_bits": 1,
    "slaves": [
      {
        "slave_id": 1,
        "registers": [
          {
            "address": "0x0001",
            "type": "holding",
            "format": "float32",
            "tag": "temperature",
            "unit": "°C"
          },
          {
            "address": "0x0003",
            "type": "holding",
            "format": "float32",
            "tag": "humidity",
            "unit": "%"
          }
        ]
      },
      {
        "slave_id": 2,
        "registers": [
          {
            "address": "0x0010",
            "type": "input",
            "format": "int16",
            "tag": "pressure",
            "unit": "mbar"
          }
        ]
      }
    ]
  },
  "mqtt": {
    "broker": "mqtt.example.com",
    "port": 8883,
    "tls": true,
    "base_topic": "site/{site_id}/gateway/{device_id}/sensors"
  }
}

3. Publicar datos estructurados​

Una vez leído el valor, la pasarela puede publicar un mensaje MQTT estructurado:

Tema: sitio/parís/puerta de enlace/eziwan-01/sensores/temperatura
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

Una carga útil en claro facilita a continuación la integración con:

  • una base de datos de series temporales;
  • un panel de control de Grafana;
  • un flujo de Node-RED;
  • un sistema SCADA en la nube;
  • una aplicación de negocio;
  • una plataforma de supervisión centralizada.

Modbus RTU frente a Modbus TCP: ¿en qué se diferencian?​

Modbus se utiliza principalmente en dos modalidades en los proyectos industriales: Modbus RTU y Modbus TCP.

CriterioModbus RTUModbus TCP
SoporteRS485 / RS232Ethernet o red IP
Modo de direccionamientoDirección de esclavoDirección IP + puerto
TramaCompacta, con CRCEncapsulada en TCP
Uso típicoSensores, contadores, equipos de campoPLC, variadores, equipos Ethernet
DiagnósticoAnalizador serie, comprobador Modbus RTUPing, escaneo de red, cliente Modbus TCP
Aspectos a tener en cuentaCableado, terminación, velocidad, paridadEnrutamiento, cortafuegos, VLAN, latencia de red

En una arquitectura Eziwan, ambos enfoques pueden coexistir: el bus RS485 para los equipos de campo existentes y la red IP local para los equipos Ethernet.

Ejemplo de arquitectura: fábrica con equipos mixtos​

Una planta industrial puede combinar varias generaciones de equipos:

  • un contador de energía con Modbus RTU;
  • un controlador lógico programable (PLC) conectado a un bus serie;
  • un variador accesible mediante Modbus TCP;
  • un sistema de supervisión en la nube que recibe los datos a través de MQTT.

Esta arquitectura evita tener que sustituir los equipos que ya están en funcionamiento. La pasarela se convierte en el punto de recogida, traducción y publicación.

Cómo elegir el protocolo adecuado en función de tu contexto​

Situación sobre el terrenoOpción recomendadaPor qué
Equipos existentes con puerto RS485Modbus RTUCompatible con numerosos sensores, contadores y controladores lógicos programables
Equipos industriales con puerto EthernetModbus TCPMás fácil de integrar en una red local IP
Nuevos sensores conectadosMQTT nativo, si está disponiblePublicación directa a un broker o una plataforma en la nube
Sistema SCADA existente que hay que mantenerAcceso remoto seguro o VPNContinuidad con la arquitectura ya implantada
Datos a Grafana, InfluxDB o Node-REDMQTTDesacoplamiento limpio entre la recopilación y el análisis
Instalación aislada o móvilPasarela con conectividad móvilRecopilación sobre el terreno sin depender de una red cableada local

Seguridad: aspectos fundamentales para una pasarela de campo​

Conectar el OT a la nube requiere un enfoque prudente. El objetivo no es solo transmitir datos, sino hacerlo con un nivel de control adecuado al contexto industrial.

Buenas prácticas recomendadas​

  • Segmentar las redes de TI y OT para evitar accesos demasiado amplios desde la nube hacia las instalaciones.
  • Limitar los flujos salientes a los servicios necesarios: broker MQTT, supervisión, actualizaciones o administración.
  • Aplicar el principio del privilegio mínimo: un equipo o un usuario solo debe acceder a los recursos que le sean útiles.
  • Registrar las conexiones y los eventos para facilitar la auditoría y el diagnóstico.
  • Prever la revocación de los accesos en caso de cambio de proveedor, pérdida de equipos o incidente.
  • Cifrar las comunicaciones MQTT cuando los datos salgan de la red local.
  • Supervisar el estado de la conectividad: latencia, reconexiones, pérdidas de señal, colas locales.

A tener en cuenta Una conexión 4G o LTE puede ser intermitente en función de la cobertura, la antena, el entorno radioeléctrico y la carga de la red. Por lo tanto, es necesario prever una estrategia de reconexión, almacenamiento local en búfer y marcación de fecha y hora de los datos cuando sea importante la continuidad de la medición.

Errores frecuentes en un proyecto de Modbus a MQTT​

Confundir la dirección de registro con la dirección documental​

Algunos fabricantes documentan los registros en base 1, otros en base 0. Por lo tanto, una medida esperada en 40001 puede corresponder a una dirección real diferente según la herramienta utilizada.

Ignorar el orden de las palabras​

Los valores de 32 bits, especialmente los de tipo flotante, pueden codificarse con diferentes órdenes de palabras. Una configuración incorrecta puede dar lugar a valores incoherentes sin que la comunicación Modbus presente ningún error.

Orinar con demasiada frecuencia​

Un bus RS485 compartido no debe consultarse como una API HTTP. Un sondeo demasiado agresivo puede saturar el bus, aumentar los errores CRC u ocultar los dispositivos más lentos.

Publicar temas MQTT demasiado vagos​

Un tema como «data/value1» se vuelve rápidamente inutilizable. Es mejor estructurar los temas indicando el sitio, la pasarela, el equipo y la etiqueta.

site/{site_id}/gateway/{gateway_id}/equipment/{asset_id}/metric/{tag}

Olvidarse de la calidad de los datos​

Un valor sin indicador de calidad puede interpretarse erróneamente. Añadir un campo quality, una marca de tiempo y, en su caso, un código de error facilita el análisis por parte del equipo de supervisión.

Arquitectura tipo recomendada​

CapaFunciónEjemplo
CampoMedición y automatizaciónSensores, contadores, PLC, variadores
Recopilación en el bordeLectura Modbus, filtrado, marca de tiempoPasarela Eziwan
TransportePublicación MQTT seguraBroker MQTT
ProcesamientoHistorización, alertas, transformaciónInfluxDB, Node-RED, plataforma en la nube
VisualizaciónSupervisión y toma de decisionesGrafana, SCADA en la nube, aplicación de negocio

Esta separación hace que la arquitectura sea más clara: el entorno local se mantiene estable, la pasarela traduce los datos y la nube los procesa.

Preguntas frecuentes — MQTT, RS485 y Modbus​

¿Se pueden utilizar Modbus RTU y MQTT a la vez en una misma pasarela?​

Sí. De hecho, es uno de los escenarios clásicos de una pasarela IIoT: recopilar los datos de campo en Modbus RTU a través de RS485 y, a continuación, publicarlos en MQTT hacia un broker o una plataforma en la nube. Los dos protocolos no tienen la misma función: Modbus sirve para consultar los equipos, mientras que MQTT sirve para transportar los datos hacia las aplicaciones.

¿Cuál es la diferencia entre RS485 y Modbus RTU?​

RS485 es la capa física: cableado, señales eléctricas, topología de bus. Modbus RTU es el protocolo de aplicación: estructura de las tramas, direccionamiento de los esclavos, funciones de lectura o escritura, control de errores. Se puede utilizar RS485 con otros protocolos, pero la combinación de RS485 y Modbus RTU sigue siendo muy habitual en entornos industriales.

¿Cuántos dispositivos se pueden conectar a un bus RS485?​

La respuesta depende de los transceptores, de la carga eléctrica del bus, de la longitud del cable, del caudal y de la calidad de la instalación. El límite que se suele citar para un segmento RS485 clásico es de 32 cargas unitarias, pero los equipos modernos de baja carga y los repetidores pueden permitir arquitecturas más extensas. En la práctica, hay que validar la topología con las especificaciones de los equipos y las limitaciones del emplazamiento.

¿Es adecuado MQTT si la conexión 4G es intermitente?​

MQTT puede adaptarse a conexiones intermitentes si la arquitectura se diseña correctamente: calidad de servicio adecuada, reconexión correcta, marca de tiempo local, cola en el lado de la pasarela y supervisión del estado de la red. Sin embargo, no hay que confundir la robustez del protocolo con la disponibilidad de la señal de radio: la calidad de la cobertura móvil sigue siendo un factor determinante.

¿Es mejor elegir MQTT u OPC UA?​

Los dos protocolos no responden exactamente a la misma necesidad. MQTT es ligero y muy eficaz para publicar mensajes en un broker. OPC UA ofrece más posibilidades a la hora de modelar equipos, exponer una semántica industrial e integrar determinados sistemas de automatización. En muchos proyectos, se opta por MQTT para la publicación en la nube, mientras que OPC UA sigue siendo relevante en lo que respecta a la supervisión industrial o la integración de máquinas.

¿Cómo se puede proteger una publicación MQTT industrial?​

Como mínimo, es necesario cifrar las conexiones cuando los datos salen de la red local, autenticar a los clientes, limitar los derechos por tema, registrar las conexiones y prever la revocación de los accesos. La seguridad también debe abarcar la propia pasarela: administración protegida, actualizaciones controladas, segmentación de la red y supervisión de eventos.

Ir más allá con Eziwan​

¿Tienes equipos RS485, Modbus RTU, Modbus TCP o MQTT que quieres integrar en una arquitectura en la nube? El enfoque adecuado consiste en analizar los protocolos existentes, identificar las limitaciones sobre el terreno y, a continuación, definir una pasarela adecuada entre OT e IT.

Recursos adicionales​