Wireless Industrial Sensors with MQTT: Wi-Fi, LoRaWAN, WirelessHART and Private 5G

Wireless industrial sensors let you measure temperature, vibration, pressure and level on assets that were never wired, without trenching cable through a running plant. In this guide you will compare the four radio technologies plant engineers actually choose between, understand how data from each one ends up as MQTT messages, and run a small Python bridge that forwards LoRaWAN uplinks into a structured topic tree.

Why Wireless Sensors Are Taking Over Retrofit Projects

Running a new cable in a plant is rarely just a cable. It means cable trays, conduit, hot work permits, downtime windows and sometimes hazardous-area certification. For a single vibration point on a cooling tower fan, the installation can cost far more than the sensor.

Wireless sensors change that equation. A battery-powered vibration or temperature sensor can be mounted with a magnet or a stud in minutes, and it reports for years. The trade-off is that you now have a radio network to design: range, battery life, update rate and reliability all depend on the technology you pick.

The good news is that, whatever radio you choose, the data ends up in the same place. A gateway or network server receives the radio packets and publishes them to an MQTT broker, where dashboards, historians and analytics pick them up.

Comparing Wireless Industrial Sensor Technologies

Wi-Fi sensors

Wi-Fi is the most familiar option and the only one where the sensor itself usually speaks MQTT directly. An ESP32-based sensor can open a TLS connection to the broker and publish without any intermediate gateway. The downside is power: Wi-Fi association and TLS handshakes are expensive, so battery Wi-Fi sensors either sleep for long periods or need frequent battery changes. Industrial Wi-Fi coverage also tends to be patchy around metal structures. If you are building your own, our ESP32 MQTT tutorial covers the firmware side.

LoRaWAN sensors

LoRaWAN trades bandwidth for range and battery life. Payloads are tiny, often a dozen bytes, and regional duty-cycle rules limit how often a device can transmit. Sensors send uplinks to gateways, gateways forward to a network server such as ChirpStack or The Things Stack, and the network server decodes the payload and exposes it, very often over MQTT. LoRaWAN is ideal for slow-changing values across large sites: tank levels, ambient conditions, water meters and remote pumps.

WirelessHART and ISA100

These standards were designed for process plants. They form self-healing meshes, use time-synchronised channel hopping and carry the HART device model, so a wireless pressure transmitter looks to the control system much like a wired one. Data normally arrives at a wireless gateway with Modbus TCP, OPC UA or HART-IP interfaces. To get it into MQTT you add a protocol gateway, the same way you would for any other fieldbus.

Private 5G and LTE

Private cellular networks shine when you need mobility, high density or deterministic coverage across a large campus: mobile robots, AGVs, cranes and handheld devices. Devices get IP connectivity and can run MQTT clients directly, exactly like on public cellular. The cost and spectrum questions are significant, so private 5G usually arrives as part of a broader site project rather than for a handful of sensors. The connection behaviour is similar to MQTT over cellular, including the need for sensible keepalive values.

How Wireless Sensor Data Reaches the Broker

There are three integration paths, and most plants end up using more than one:

1. Direct MQTT from the device. Wi-Fi and cellular sensors publish straight to the broker over TLS. Simple, but each device needs credentials and enough power for TLS.
2. Network server to MQTT. LoRaWAN network servers publish decoded uplinks to their own MQTT broker or integration. A small bridge republishes them into your plant topic tree.
3. Gateway plus protocol converter. WirelessHART, ISA100 and many proprietary wireless systems expose Modbus or OPC UA at the gateway. An IIoT edge gateway polls that interface and publishes MQTT.

The important design decision is not the radio but the topic structure. Whatever the source, normalise everything into one hierarchy, for example connectmq/site/area/asset/measurement, so consumers never need to know which radio a value came from.

Example: Bridge LoRaWAN Uplinks into Your Topic Tree

The script below subscribes to ChirpStack v4 uplink events on the network server's broker and republishes decoded values into an ISA-95-style tree on the ConnectMQ public broker. ChirpStack publishes uplinks on application/<application_id>/device/<dev_eui>/event/up as JSON, with decoded values in the object field when a payload codec is configured.

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

# Source: ChirpStack MQTT integration (adjust host and credentials)
SRC_HOST = "chirpstack.local"
SRC_TOPIC = "application/+/device/+/event/up"

# Destination: ConnectMQ public test broker, unique demo prefix
DST_HOST = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1/utilities"

# Map device EUIs to asset names in your hierarchy
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 codec configured, nothing to forward
    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()

Watch the output from another terminal:

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

A few details worth copying into production. Messages are retained, so a new dashboard immediately sees the last tank level instead of waiting for the next uplink, which for LoRaWAN might be fifteen minutes away. Radio quality (RSSI and SNR) travels with each value, which makes it easy to spot a sensor whose antenna has been knocked. And unknown devices land under unmapped/, so they show up rather than disappearing silently. For production, switch the destination to port 8883 with TLS and your ConnectMQ credentials, and keep the public broker for testing only, since everything there is readable by anyone.

Practical Tips for Wireless Sensor Deployments

• Survey before you buy. Walk the site with a test gateway or access point. Steel tanks, concrete and moving machinery change coverage dramatically.
• Match update rate to the physics. A tank level that changes over hours does not need second-by-second updates. Slower rates mean longer battery life.
• Publish by exception at the gateway. Forward a value only when it changes meaningfully, and use retained messages for the current state. Our report by exception guide explains the thresholds.
• Monitor the sensors, not just the process. Battery voltage, last-seen time and signal strength deserve their own topics and alert rules.
• Plan for gaps. Wireless links drop. Consumers should treat a stale timestamp as missing data rather than as the last known value.

A Broker That Handles Every Radio

Because all the radio technologies converge on MQTT, the broker becomes the one piece every team depends on. A hosted MQTT broker such as ConnectMQ gives you TLS endpoints, a live topic explorer to verify that each sensor is landing in the right place, and threshold alert rules for values such as low battery or high vibration. Its devices view groups topics by ISA-95 levels, which is a convenient way to check that LoRaWAN, Wi-Fi and WirelessHART data all follow the same hierarchy. For the wider context, read the Industrial IoT with MQTT guide.

Connect Your Wireless Sensors to ConnectMQ

Sign up at app.connectmq.com and create a free Serverless broker, no credit card needed. Point your bridge or gateway at it with the generated credentials, then use the ConnectMQ live topic explorer and dashboard to watch your wireless sensor data arrive in one structured namespace.

Frequently Asked Questions

Which wireless technology is best for industrial sensors?

It depends on the job. LoRaWAN suits slow-changing values over long distances on battery, WirelessHART suits process instrumentation in mesh networks, Wi-Fi suits mains-powered or high-rate devices, and private 5G suits mobile equipment and dense campuses.

Can LoRaWAN sensors publish MQTT directly?

No. LoRaWAN devices send small radio packets to gateways, and the network server decodes them. The network server, or a bridge like the one in this guide, then publishes the decoded values over MQTT.

How do I get WirelessHART data into MQTT?

WirelessHART gateways usually expose Modbus TCP, OPC UA or HART-IP. An edge gateway polls that interface and publishes the values to your MQTT broker.

Should wireless sensor values be retained messages?

Usually yes for current-state values such as levels and temperatures, because new subscribers get the last value immediately. Do not retain event-type messages such as alarms that should only be seen once.