Sensores industriales inalámbricos con MQTT: Wi-Fi, LoRaWAN, WirelessHART y 5G privado

Los sensores industriales inalámbricos te permiten medir temperatura, vibración, presión y nivel en activos que nunca se cablearon, sin abrir zanjas para tender cable a través de una planta en funcionamiento. En esta guía compararás las cuatro tecnologías de radio entre las que realmente eligen los ingenieros de planta, entenderás cómo los datos de cada una acaban convertidos en mensajes MQTT y ejecutarás un pequeño bridge en Python que reenvía los uplinks de LoRaWAN a un árbol de topics estructurado.

Por qué los sensores inalámbricos dominan los proyectos de retrofit

Tender un cable nuevo en una planta rara vez es solo un cable. Implica bandejas, conductos, permisos de trabajos en caliente, ventanas de parada y, a veces, certificación para zonas peligrosas. Para un único punto de vibración en el ventilador de una torre de refrigeración, la instalación puede costar mucho más que el sensor.

Los sensores inalámbricos cambian esa ecuación. Un sensor de vibración o temperatura a batería puede montarse con un imán o un espárrago en minutos y reportar durante años. La contrapartida es que ahora tienes una red de radio que diseñar: el alcance, la autonomía de la batería, la frecuencia de actualización y la fiabilidad dependen de la tecnología que elijas.

La buena noticia es que, elijas la radio que elijas, los datos acaban en el mismo sitio. Un gateway o un servidor de red recibe los paquetes de radio y los publica en un broker MQTT, donde los recogen los paneles, los historiadores, la analítica o un gemelo digital 3D de la planta.

Comparativa de tecnologías de sensores industriales inalámbricos

Sensores Wi-Fi

Wi-Fi es la opción más conocida y la única en la que el propio sensor suele hablar MQTT directamente. Un sensor basado en ESP32 puede abrir una conexión TLS con el broker y publicar sin ningún gateway intermedio. El inconveniente es el consumo: la asociación Wi-Fi y los handshakes TLS son costosos, así que los sensores Wi-Fi a batería o bien duermen durante largos periodos o bien necesitan cambios de batería frecuentes. Además, la cobertura Wi-Fi industrial suele ser irregular alrededor de estructuras metálicas. Si vas a construir el tuyo, nuestro tutorial de MQTT con ESP32 cubre la parte del firmware.

Sensores LoRaWAN

LoRaWAN sacrifica ancho de banda a cambio de alcance y autonomía. Los payloads son minúsculos, a menudo una docena de bytes, y las normas regionales de ciclo de trabajo limitan la frecuencia con la que un dispositivo puede transmitir. Los sensores envían uplinks a los gateways, los gateways los reenvían a un servidor de red como ChirpStack o The Things Stack, y el servidor de red decodifica el payload y lo expone, muy a menudo por MQTT. LoRaWAN es ideal para valores que cambian despacio en emplazamientos extensos, como una mina en Chile o una finca agroindustrial en Colombia: niveles de depósitos, condiciones ambientales, contadores de agua y bombas remotas.

WirelessHART e ISA100

Estos estándares se diseñaron para plantas de proceso. Forman mallas autorreparables, usan salto de canal sincronizado en el tiempo y transportan el modelo de dispositivo HART, de modo que un transmisor de presión inalámbrico se ve en el sistema de control de forma muy parecida a uno cableado. Los datos suelen llegar a un gateway inalámbrico con interfaces Modbus TCP, OPC UA o HART-IP. Para llevarlos a MQTT se añade un gateway de protocolos, igual que con cualquier otro bus de campo.

5G y LTE privados

Las redes celulares privadas destacan cuando necesitas movilidad, alta densidad o una cobertura determinista en un recinto grande: robots móviles, AGV, grúas y dispositivos portátiles. Los dispositivos obtienen conectividad IP y pueden ejecutar clientes MQTT directamente, igual que en la red celular pública. Las cuestiones de coste y espectro son importantes, así que el 5G privado suele llegar como parte de un proyecto más amplio del emplazamiento y no para un puñado de sensores. El comportamiento de la conexión es similar al de MQTT sobre red celular, incluida la necesidad de valores de keepalive razonables.

Cómo llegan al broker los datos de los sensores inalámbricos

Hay tres vías de integración, y la mayoría de las plantas acaban usando más de una:

1. MQTT directo desde el dispositivo. Los sensores Wi-Fi y celulares publican directamente en el broker sobre TLS. Es sencillo, pero cada dispositivo necesita credenciales y energía suficiente para TLS.
2. Del servidor de red a MQTT. Los servidores de red LoRaWAN publican los uplinks decodificados en su propio broker MQTT o integración. Un pequeño bridge los vuelve a publicar en el árbol de topics de tu planta.
3. Gateway más convertidor de protocolos. WirelessHART, ISA100 y muchos sistemas inalámbricos propietarios exponen Modbus u OPC UA en el gateway. Un gateway edge IIoT consulta esa interfaz y publica MQTT.

La decisión de diseño importante no es la radio, sino la estructura de topics. Sea cual sea el origen, normaliza todo en una única jerarquía, por ejemplo connectmq/site/area/asset/measurement, para que los consumidores nunca necesiten saber de qué radio procede un valor.

Ejemplo: bridge de uplinks LoRaWAN a tu árbol de topics

El script siguiente se suscribe a los eventos de uplink de ChirpStack v4 en el broker del servidor de red y vuelve a publicar los valores decodificados en un árbol de estilo ISA-95 en el servidor MQTT público gratuito de ConnectMQ, pensado para pruebas y no para datos de producción. ChirpStack publica los uplinks en application/<application_id>/device/<dev_eui>/event/up como JSON, con los valores decodificados en el campo object cuando hay un codec de payload configurado.

import json
import uuid
import paho.mqtt.client as mqtt

# Origen: integración MQTT de ChirpStack (ajusta el host y las credenciales)
SRC_HOST = "chirpstack.local"
SRC_TOPIC = "application/+/device/+/event/up"

# Destino: broker de pruebas público de ConnectMQ, prefijo de demo único
DST_HOST = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1/utilities"

# Asocia los EUI de los dispositivos con nombres de activos de tu jerarquía
ASSETS = {
    "a84041000181c061": "tank-farm/tank03",
    "a84041000181c062": "cooling/fan02",
}

dst = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-dst-{uuid.uuid4().hex[:6]}")
dst.connect(DST_HOST, 1883, keepalive=60)
dst.loop_start()

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected to ChirpStack:", reason_code)
    client.subscribe(SRC_TOPIC, qos=1)

def on_message(client, userdata, msg):
    event = json.loads(msg.payload)
    dev_eui = event["deviceInfo"]["devEui"]
    values = event.get("object")
    if not values:
        return  # no hay codec configurado, nada que reenviar
    asset = ASSETS.get(dev_eui, f"unmapped/{dev_eui}")
    rx = (event.get("rxInfo") or [{}])[0]
    for name, value in values.items():
        payload = {
            "value": value,
            "ts": event.get("time"),
            "rssi": rx.get("rssi"),
            "snr": rx.get("snr"),
        }
        topic = f"{PREFIX}/{asset}/{name}"
        dst.publish(topic, json.dumps(payload), qos=1, retain=True)
        print(topic, payload)

src = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-src-{uuid.uuid4().hex[:6]}")
src.on_connect = on_connect
src.on_message = on_message
src.connect(SRC_HOST, 1883, keepalive=60)
src.loop_forever()

Observa la salida desde otro terminal:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM \
  -t 'connectmq/demo/+/site1/#' -v

Hay algunos detalles que merece la pena copiar en producción. Los mensajes son retenidos, así que un panel nuevo ve de inmediato el último nivel del depósito en lugar de esperar al siguiente uplink, que en LoRaWAN podría llegar dentro de quince minutos. La calidad de radio (RSSI y SNR) viaja con cada valor, lo que facilita detectar un sensor cuya antena ha recibido un golpe. Y los dispositivos desconocidos van a parar a unmapped/, así que aparecen en lugar de desaparecer en silencio. Para producción, cambia el destino al puerto 8883 con TLS y tus credenciales de ConnectMQ, y reserva el servidor público solo para pruebas, ya que cualquiera puede leer todo lo que hay en él.

Consejos prácticos para desplegar sensores inalámbricos

• Haz un estudio de cobertura antes de comprar. Recorre el emplazamiento con un gateway o un punto de acceso de prueba. Los depósitos de acero, el hormigón y la maquinaria en movimiento cambian drásticamente la cobertura.
• Ajusta la frecuencia de actualización a la física. Un nivel de depósito que cambia a lo largo de horas no necesita actualizaciones segundo a segundo. Frecuencias más bajas significan baterías más duraderas.
• Publica por excepción en el gateway. Reenvía un valor solo cuando cambie de forma significativa y usa retained messages para el estado actual. Nuestra guía de report by exception explica los umbrales.
• Monitoriza los sensores, no solo el proceso. La tensión de la batería, la hora de la última comunicación y la intensidad de la señal merecen sus propios topics y reglas de alerta.
• Planifica los huecos. Los enlaces inalámbricos se caen. Los consumidores deben tratar una marca de tiempo obsoleta como un dato que falta y no como el último valor conocido.

Un broker que gestiona todas las radios

Como todas las tecnologías de radio convergen en MQTT, el broker se convierte en la pieza de la que dependen todos los equipos. Un broker MQTT gestionado como ConnectMQ te ofrece endpoints TLS, un explorador de topics en vivo para comprobar que cada sensor llega al lugar correcto y reglas de alerta por umbral para valores como batería baja o vibración alta. Su vista de dispositivos agrupa los topics por niveles ISA-95, una forma cómoda de comprobar que los datos de LoRaWAN, Wi-Fi y WirelessHART siguen la misma jerarquía. Para el contexto general, lee la guía de IoT industrial con MQTT.

Conecta tus sensores inalámbricos a ConnectMQ

Regístrate en app.connectmq.com y crea un broker Serverless gratuito, sin tarjeta de crédito. Apunta tu bridge o tu gateway hacia él con las credenciales generadas y usa el explorador de topics en vivo y el panel de ConnectMQ para ver cómo llegan los datos de tus sensores inalámbricos a un único espacio de nombres estructurado.

Preguntas frecuentes

¿Qué tecnología inalámbrica es la mejor para sensores industriales?

Depende del trabajo. LoRaWAN encaja con valores que cambian despacio a largas distancias y con batería, WirelessHART con la instrumentación de proceso en redes de malla, Wi-Fi con dispositivos alimentados desde la red o de alta frecuencia, y el 5G privado con equipos móviles y recintos densos.

¿Pueden los sensores LoRaWAN publicar MQTT directamente?

No. Los dispositivos LoRaWAN envían pequeños paquetes de radio a los gateways y el servidor de red los decodifica. Después, el servidor de red, o un bridge como el de esta guía, publica los valores decodificados por MQTT.

¿Cómo llevo los datos de WirelessHART a MQTT?

Los gateways WirelessHART suelen exponer Modbus TCP, OPC UA o HART-IP. Un gateway edge consulta esa interfaz y publica los valores en tu broker MQTT.

¿Deben ser retained messages los valores de los sensores inalámbricos?

Normalmente sí para los valores de estado actual, como niveles y temperaturas, porque los nuevos suscriptores reciben el último valor de inmediato. No retengas los mensajes de tipo evento, como las alarmas, que solo deberían verse una vez.