Coder Legion - Recent posts tagged mqtt

Updating Radar Firmware Without a Cloud: Self-Hosted OTA over MQTT

Tue, 27 Oct 2026 23:05:42 +0000

Updating Radar Firmware Without a Cloud: Self-Hosted OTA over MQTT

Most connected devices want you to push firmware through somebody's cloud. These do not ask for that. The sleep and fall radars fetch an image from a URL you hand them, and the command arrives on the same MQTT connection the telemetry already uses. Nothing has to leave your network, and there is no vendor account in the path.

This is the practical shape of that: which units support it, the three commands involved, how to confirm an update actually landed, and the operational precautions the protocol document leaves to you.

Everything below comes from the Wi-Fi protocol documents for the sleep and fall units. Where they do not specify something, this says so rather than filling the gap.

Scope first

Unit	OTA update via this protocol
Sleep radar (60 GHz, Wi-Fi)	Yes — topic family `/Radar60SP/{DeviceID}/sys/property/{post,set}`
Fall radar (60 GHz, Wi-Fi)	Yes — topic family `/Radar60FL/{DeviceID}/sys/property/{post,set}`
Presence radar (24 GHz, Wi-Fi)	No such command appears in its protocol document

That last row matters. The presence unit's document specifies online, version, active and passive report topics plus a property/set command topic — and no update command at all. If you need to update those, that is a question for the hardware, not for this protocol.

Commands go to the unit's .../sys/property/set topic; everything it reports arrives on .../sys/property/post.

Three commands

1. Select the target module — required before every update.

{"version": "1.0", "method": "ota_set", "params": {"module": "0"}}

0 is the Wi-Fi module, 1 is the radar module; the default is 0. The documentation is explicit that this control command has to be sent before each update — it is not a one-time setting you configure and forget.

2. Hand over the image location.

{"version": "1.0", "method": "ota_set",
 "params": {"otaInform": {"firmwareUrl": "http://192.168.31.88/app.rbl", "port": "8090"}}}

The device fetches the firmware from that URL and port and starts updating. A failure comes back as:

{"version": "1.0", "opt": "otaInform", "res": "fail", "msg": "ota failed!"}

3. Observe progress. Described as an active report during update, sent with method ota_post:

{"version": "1.0", "method": "ota_post", "params": {"downloadProgress": "0"}}

Values run 0–100. Subscribe to the unit's report topic before you start; if your unit reports it somewhere else, record that during commissioning rather than assuming.

After a successful update, the module restarts and then reports its version number. Treat that report — not the arrival of 100 — as the completion signal.

Confirming the result

"Transfer finished" and "the unit now runs the new code" are two different statements.

Sleep and fall units carry firmwareVersion and firmwareVersionWiFi in their property list, and the protocol states that the post-restart report carries the version number after updating. Compare against the value you recorded before starting.
Presence units publish a version snapshot on /RadarHP/{DeviceID}/sys/version/post containing radarID, softwareVersion, firmwareVersion and protocolVersion. These are read-only — they cannot be written, only read. There is also a request command to solicit it on demand: publish {"version":"1.0","method":"get_version","params":{}} to /RadarHP/{DeviceID}/sys/property/set.

Keep the before-and-after version pair in the same commissioning record you keep for everything else. It is the only evidence you have later.

Running an update

import json
import paho.mqtt.client as mqtt

BROKER, PORT = "192.168.1.2", 1883
DEV = "<DeviceID>"                        # the MAC, printed on the label
SET_TOPIC  = f"/Radar60SP/{DEV}/sys/property/set"
POST_TOPIC = f"/Radar60SP/{DEV}/sys/property/post"

IMAGE_URL, IMAGE_PORT = "http://192.168.1.50:8090/app.rbl", "8090"
TARGET = "0"                              # "0" Wi-Fi module, "1" radar module


def command(client, method, params):
    client.publish(SET_TOPIC,
                   json.dumps({"version": "1.0", "method": method, "params": params}),
                   qos=1)


def on_message(client, userdata, msg):
    payload = json.loads(msg.payload.decode())
    params = payload.get("params", {})
    if "downloadProgress" in params:
        print("transfer:", params["downloadProgress"], "%")
    if payload.get("opt") == "otaInform" and payload.get("res") == "fail":
        print("update failed:", payload.get("msg"))
    if "firmwareVersion" in params:
        print("reported version after restart:", params["firmwareVersion"])


client = mqtt.Client()
client.username_pw_set("backend", "...")
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.subscribe(POST_TOPIC, qos=1)
client.loop_start()

command(client, "ota_set", {"module": TARGET})          # select the target first
command(client, "ota_set", {"otaInform": {"firmwareUrl": IMAGE_URL, "port": IMAGE_PORT}})
client.loop_forever()

That is the whole mechanism — two publishes and a subscription. The rest is procedure.

Declare a maintenance window. The unit is unreachable while it rewrites and restarts. Monitoring will read that as a failure unless you suppress it — see Online Says It's Connected, HeartBeat Says It Works.
Select the target deliberately. module defaults to the Wi-Fi module. Sending a radar image to it is a mistake the command will not catch for you.
Make sure the URL is reachable from the device. Same subnet or routable, firewall permits that port, and never localhost or 127.0.0.1 — the address is resolved by the radar, not by the machine issuing the command.
Stage it. One unit first. Watch downloadProgress reach 100, wait for the restart, confirm the version changed, then proceed with the rest.
Keep the previous image served. Given what is not documented below, this is your only fallback.
Do not batch-update overnight in a care deployment. A unit that comes back with different behaviour at 03:00 is discovered by nobody until morning.

A minimal image host

Nothing more than a static file server on the management network:

python -m http.server 8090 --directory ./firmware

which makes http://{host}:8090/app.rbl available to the units. Use it on a segregated network or behind whatever reverse proxy you already trust; it is plain HTTP with directory listing enabled, and it is a build artifact service, not a public endpoint.

What the documents do not say

Stated plainly, because guessing here costs hardware:

Transport. Every example uses http://. HTTPS support is not stated. Plan for plain HTTP on a network you control.
Rollback. No rollback command appears. Assume you cannot command a unit back to the previous revision — which is why keeping the old image available and piloting one unit first are not optional.
Duration and interruption. No update duration is given, and the documents describe failure only as the ota failed! response. Behaviour after power loss mid-update is undocumented.

The consequence is procedural rather than technical: update when someone is present to observe, one unit first, with the previous image still served.

Checklist

[ ] Unit confirmed to be one of the two that document this command
[ ] module selected explicitly before every update — Wi-Fi module vs radar module
[ ] Image URL and port reachable from the device's network, not from yours only
[ ] Subscribed to the report topic before publishing either command
[ ] Monitoring suppression window opened, and closed only after the version report arrives
[ ] downloadProgress observed to 100, restart observed, version compared against the pre-update record
[ ] Previous firmware image still available at a known URL
[ ] Staged: one unit, verified, then the cohort

Reading the stream these commands travel on: Reading Radar Data in Your Own Application
Managing many units: Running Several Radars in One Home
The broker underneath it: Apache Artemis setup

Full documentation: https://249263431.github.io/60GHz-Radar-SDK/

Modules and finished units: https://www.tindie.com/stores/fuxinsuo/

Online Says It's Connected, HeartBeat Says It Works: Reading Two Status Signals Instead of Guessing

Tue, 27 Oct 2026 01:03:42 +0000

title: "Online Says It's Connected, HeartBeat Says It Works: Reading Two Status Signals Instead of Guessing From Silence"
published: true
tags: iot, mqtt, radar, monitoring
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/guide/2026/10/27/online-heartbeat-radar-health.html
description: "Two fields in a mmWave radar's MQTT output — online and heartBeat — look like the same health check and are not. One proves the link; the other proves the sensor. And neither supports a timeout."

cover_image:

Two fields in a radar's MQTT output get mistaken for each other constantly, and mistaking them is how a health monitor ends up trusted when it should not be.

They answer different questions:

online answers "is the link up?"
heartBeat answers "is the radar itself working?"

	`online`	`heartBeat`
Question answered	Is this device reachable?	Is this device operating correctly?
Reported values	`"0"` offline, `"1"` online	`"0"` abnormal, `"1"` normal
Layer	MQTT connection and broker session	The radar's own operating state
Reported when	On state change only	On state change only
Available on	Sleep radar, fall radar, presence radar	Sleep radar, fall radar

The presence radar publishes its online state on a dedicated topic — /RadarHP/<DeviceID>/sys/online/post; the sleep and fall radars publish online as an attribute in the same property payload as everything else. Note the asymmetry: there is no heartBeat in the presence radar's protocol documentation. The other two report it like this:

{"version": "1.0", "method": "post", "params": {"online": "0"}}
{"version": "1.0", "method": "post", "params": {"heartBeat": "0"}}

Why this distinction is not academic

Consider what has to be true for any heartBeat message to reach your code: the radar has power, it is associated with the Wi-Fi access point, its MQTT session is established, and you are subscribed to its topic. A delivered heartBeat therefore already proves the link is working.

From that, one conclusion follows immediately:

heartBeat cannot report a connectivity failure. Physically and logically, it cannot — a radar that has lost its link has no way to deliver that news.

The reverse holds for online. An online: "0" message is not written by the radar that went offline; it is generated by the broker when the session it was holding stops answering. The radar contributes nothing to that judgement.

So neither field overlaps with the other, and neither can substitute for the other:

If you only watch online, you will see "connected" while the radar sits there reporting a fault about itself.
If you only watch heartBeat, every network outage looks like nothing at all.

The trap: silence is not evidence

Both fields are documented as reported on state change, not on a timer. That single sentence is where most monitoring code goes wrong.

Occupancy. The presence state is event-driven. A room whose state does not change for three hours produces no occupancy messages, and that is correct behaviour — not a fault.
Heartbeat. A radar that boots normally and stays normal has no reason to send heartBeat at all, because no state change occurred.
The one periodic attribute. In the sleep and fall protocols, the only attribute the documentation marks as periodically reported is workDuration (4 bytes, value range 0x3C–0xffffffff, unit seconds) — and it is marked "not yet available" in the same line. workDurationReportFrequency carries the same note. Do not build a keepalive on either of them.

So the tempting pattern — "if I have not heard from the device in 60 seconds, it must be gone" — has no foundation here. Absence of messages is the normal state of a working installation.

What you can do instead

`online`	`heartBeat`	Conclusion	Action
1	1	Link up, radar reports normal	—
1	0	Link up, radar reports a fault	Raise the higher-severity alarm; this is the case only `heartBeat` can surface
0	—	Session dropped, as judged by the broker	Investigate the link; the radar's own state is unknown
no messages	no messages	Most likely nothing changed	Nothing can be concluded

Treat the two as different classes of event with different severities. A lost link is an infrastructure ticket; a radar reporting itself abnormal is a hardware ticket, and it is the one that should wake someone up.

Two rules you must not break

1. Do not disable online or heartBeat with limit_set. The Wi-Fi protocols expose a reporting-suppression command: limit_set / limit_get, where 1 means "suppress this attribute" and 0 means "allow it". It exists for the attributes that report frequently — someoneExists, motionStatus, movementSigns, humanDistance, humanPosition — and it is a legitimate way to cut traffic and noise. Both online and heartBeat appear in that list. Suppress them and you remove the only two signals that stand between you and a timeout guess.

2. Do not try to poll heartBeat. Every neighbouring attribute in those documents — initFinish, workDuration, productMode — carries the line "this attribute supports querying" followed by a get example. heartBeat does not. The only ? it ever appears with is inside limit_get, and that question means "is reporting suppressed for this attribute", not "what is its current value". There is no documented way to ask the radar for that value on demand.

That leaves one workable approach for the things you genuinely need on demand: query the attributes that do support it. If you must confirm a radar has finished starting up, initFinish (0 not complete, 1 complete) is queryable. heartBeat is not, and no amount of polling will change that.

A minimal health monitor

Subscribe, merge the sparse payload, and raise the two classes separately:

import json, time
import paho.mqtt.client as mqtt

TOPIC = "/Radar60SP/<MAC>/#"

state = {}
last_any = {}


def on_message(client, userdata, msg):
    try:
        payload = json.loads(msg.payload.decode())
    except ValueError:
        return
    params = payload.get("params", {})
    if not params:
        return

    # Only the fields that changed are present.
    for k in ("online", "heartBeat", "initFinish"):
        if k in params:
            state[k] = params[k]

    last_any["ts"] = time.time()

    # Two different failures, two different severities.
    if params.get("online") == "0":
        raise_alarm("link", device=msg.topic, severity="infra")
    if params.get("heartBeat") == "0":
        raise_alarm("sensor", device=msg.topic, severity="high")

Note the shape: nothing here fires on elapsed time. Every action is triggered by an arriving value.

If you still want a timeout as a last resort, the threshold must come from measurement, not habit. Log the longest interval your real installation goes without any message during normal operation, then add margin to that. A number you made up will either fire constantly or never fire.

Measure these at commissioning

Two things the documentation does not state, and that you should record per installation rather than assume:

Does the radar announce heartBeat: "1" on power-up? A device that boots healthy may never have a reason to report it. Power one up on the bench with a subscriber attached and write down what actually arrives, and how long after power-up it arrives.
Does online: "1" get republished after a reconnect? If it does not, your consumer must treat the absence of a change as "still online" rather than as unknown.

Both belong in the same commissioning note as the empty-room baseline from Using Distance and Position Output to Debug a Radar Installation.

Maintenance looks like a failure

One consequence of all this that catches people out: the sleep and fall protocols support firmware update over the air — ota_set with otaModule (0 Wi-Fi module, 1 radar module, and the command must be sent before every update), otaInform giving a firmware URL and port, and downloadProgress reporting 0–100. On success the module restarts and then reports its new version number.

During that window the device is legitimately unreachable. If your monitoring treats a missing device as an alarm, a firmware update will page someone. Put planned maintenance in a suppression window, and use the version report afterwards — the presence radar's /RadarSP/<DeviceID>/sys/version/post topic, or the firmwareVersion attribute — to confirm the update actually landed.

The update server is one you host yourself; the documentation states plainly that you build the web server the firmware is fetched from.

Two controls worth knowing about

Reporting suppression (limit_set / limit_get): set 1 to suppress an attribute, 0 to allow it. Use it on the high-frequency attributes to cut traffic and clutter. Leave online and heartBeat alone.
Per-attribute QoS (control_qos in the presence protocol, qos_set / qos_get with Qos_post in the sleep and fall protocols): the default is QoS 1, where 0 is QoS 0, 1 is QoS 1 and 2 is QoS 2. The presence protocol additionally exposes per-attribute keys — Qos_online, Qos_movementSigns, Qos_breathRate, and so on. This is worth knowing because it contradicts the usual assumption that QoS is decided only by the subscriber.

Checklist

[ ] online and heartBeat handled as two separate signals with two separate severities
[ ] No logic concludes anything from the absence of messages
[ ] limit_set used, if at all, only on high-frequency attributes — never on online or heartBeat
[ ] No polling of heartBeat; anything needed on demand read from attributes that document query support
[ ] Power-up behaviour of heartBeat measured and recorded
[ ] Reconnect behaviour of online measured and recorded
[ ] Any timeout threshold derived from measured worst-case silence, not assumed
[ ] Firmware updates placed in a suppression window, and verified afterwards by version report

Where to go next

Getting the stream in the first place: Reading Radar Data in Your Own Application
The broker underneath it: Apache Artemis setup
Keeping several devices straight: Running Several Radars in One Home
Keeping the history: Storing Radar Data

This is not a medical device. A status field tells you what a radar reports about itself; it does not guarantee what the radar detects. For anyone at real risk, monitoring is an addition to a care routine, never a substitute for one.

MQTT: The Protocol Designed for a World Where Things Fail

Sun, 26 Jul 2026 17:39:08 +0000

Imagine thousands of sensors distributed across a factory, a fleet of delivery drones, or millions of smart meters in different locations. How can these devices communicate reliably when networks are slow, unreliable, and expensive? MQTT (Message Queuing Telemetry Transport) was created to solve exactly this problem.

The origin story of MQTT

The story of MQTT begins in the late 1990s, before the term IoT (Internet of Things) became popular. At that time, engineers were already trying to connect remote machines, sensors, and industrial equipment, but the available communication methods were not well suited for these environments.

Most people describe MQTT as a messaging protocol, but it was created because the physical world is unreliable. Instead of describing it feature by feature, I’ll uncover it through the questions it was designed to answer. Before that, it helps to understand the three roles involved in every MQTT system.

The publisher

A publisher is a device or application that sends information. It publishes messages to a topic without knowing who, if anyone, will receive them.

For example: a temperature sensor may publish the current temperature every minute, or an EV (Electric Vehicle) charger may publish its charging status.

The subscriber

A subscriber is a device or application that receives information. It subscribes to one or more topics and automatically receives every message published on those topics.

For example: a monitoring dashboard can subscribe to temperature readings from all sensors in a factory, while an alarm subscribes to the same data to detect overheating.

The broker

The broker is the central communication hub. Every message sent by a publisher first arrives at the broker, which then forwards it to all subscribers interested in that topic.

The broker also handles many of MQTT’s reliability features, such as keeping track of connected clients, storing messages when needed, and detecting when a client disconnects unexpectedly.

What do clients and brokers look like in practice?

None of this is as abstract as it sounds. A “client” is just anything running MQTT client software: an ESP32 microcontroller with a few kilobytes of firmware, a Raspberry Pi running Home Assistant, a smartphone app checking today’s solar production, or a few lines embedded in an industrial PLC. A commercial smart plug running Tasmota is a client. Home Assistant itself is a client too; it just happens to be one that subscribes to hundreds of topics and publishes commands back to many of them at once.

A “broker” is just as unglamorous: server software, usually a single process. Eclipse Mosquitto is the one most home labs reach for — lightweight enough to run on a Raspberry Pi, in a Docker container, or as a Home Assistant add-on, and largely forget about; it comfortably handles thousands of messages a second on hardware that costs less than the charger it’s monitoring. At the other end of the scale, EMQX and HiveMQ are broker platforms built to run clustered across many servers, handling millions of simultaneously connected clients — the kind of infrastructure a nationwide smart meter rollout would need. Cloud providers also sell brokers as a managed service — AWS IoT Core, Azure IoT Hub — so a manufacturer never has to run one at all.

None of that changes the protocol underneath. A $3 microcontroller and a clustered enterprise broker are speaking exactly the same MQTT to each other. The roles are identical; only the scale differs.

One client, multiple roles

In MQTT, a client is not limited to a single role. The same client can both publish and subscribe.

For example, a smart thermostat publishes the current room temperature while also subscribing to commands that change the desired temperature.

In practice, MQTT has only two types of participants:

Clients, which can publish, subscribe, or do both
The broker, which connects clients and manages the communications

This simple architecture is one of the reasons MQTT scales so well. Publishers never need to know who receives their messages, and subscribers never need to know who produced them. The broker takes care of connecting the two.

Looking a bit closer, MQTT implements the Pub/Sub architecture pattern. It is not something unique to MQTT; MQTT is simply one implementation of that pattern. The key idea behind this is decoupling. Publishers and subscribers do not know about each other. They only agree on a common “language” (topics or events), while a broker or message bus delivers the messages.

MQTT’s Publish/Subscribe model is closely related to several other software patterns, like the Observer Pattern, common in object-oriented programming. An object (the subject) notifies all registered observers when its state changes. You’ll find it most often in GUI frameworks. You can find the same behaviour in Event-Driven Architecture — an event-driven communication pattern applied to the physical world. Instead of software services producing business events, devices produce events about the state of the real world. The architecture is the same: something happens, an event is published, and interested systems react.

Networks fail. Power disappears. Cellular coverage comes and goes. Sensors reboot. Messages get lost. Yet industrial automation, smart cities, connected vehicles and energy systems still need to operate.

How do you know a device is still alive?

Imagine a temperature sensor installed on a remote pipeline. It may not send data every minute because the temperature hasn’t changed. If nothing arrives for an hour, is the temperature stable? Or has the device died?

MQTT answers this with the Keep Alive mechanism.

Rather than continuously transmitting data, the client periodically proves it is still connected. If the broker stops hearing from it within the agreed interval, the connection is considered lost.

What happens when a device suddenly disappears?

A factory robot loses power, a drone flies out of cellular coverage, an EV charger reboots. Nobody sends a goodbye message. How does the rest of the system know?

MQTT introduces the Last Will and Testament (LWT).

Before communication starts, the client leaves instructions with the broker:

“If I disappear unexpectedly, publish this message on my behalf.”

Other clients immediately know that the device went offline.

What happens to messages while the device is offline?

Not every message has the same value. A temperature reading from five minutes ago may be useless. A payment confirmation must never disappear. MQTT allows applications to choose. Should messages be discarded or should the broker keep them until the client reconnects?

This is where persistent sessions become important. Instead of treating disconnections as failures, MQTT treats them as temporary interruptions.

How do you know a message actually arrived?

A sensor publishes a reading. Did the broker receive it? Did the subscriber? On a shaky mobile network, packets get dropped mid-transmission all the time. MQTT doesn’t leave this to chance — it lets you choose, per message, how hard the protocol should work to make sure it lands.

At QoS 0, a message is sent once and forgotten — fire and forget. Fine for a reading that will be superseded a second later anyway.

At QoS 1, the message is redelivered until the receiver acknowledges it — guaranteed to arrive, but possibly more than once.

At QoS 2, MQTT adds an extra handshake that guarantees the message arrives exactly once — no duplicates, no drops — at the cost of more round trips.

Nobody has to pick one level for the whole system. A pipeline pressure reading might travel at QoS 0. A valve-close command might travel at QoS 2. The protocol lets the importance of the message decide how much effort goes into delivering it.

How does a system recover after failure?

A client reconnects after being offline for ten minutes. What happened to it in that time?

If it connected with a persistent session, the broker was holding onto anything sent to it at QoS 1 or QoS 2 while it was gone — those messages arrive the moment it comes back, in order. The client doesn’t need any special recovery logic; from its point of view, the outage just collapses into a slightly longer wait.

If it connected with a clean session instead, none of that history follows it. It starts fresh, subscribes again, and only sees what’s published from that point forward.

Neither choice is “correct” on its own — a factory alarm system wants the messages it missed; a live GPS tracker mostly doesn’t care what happened while it was disconnected, only where the vehicle is now. MQTT lets each client decide which kind of recovery it actually needs.

Why wasn’t HTTP enough?

HTTP is a request-response protocol: a client asks, a server answers. That model assumes the client knows who to ask, and that the server is reachable and listening right at that moment.

Neither assumption holds up well for a sensor network. A pipeline sensor doesn’t know which of several dashboards, alarms, or logging systems might care about its reading — and it shouldn’t have to know. If it had to open a connection and send a request to each one individually, adding a new subscriber would mean reconfiguring every publisher in the system.

HTTP also expects a server to be reachable on demand. Devices on a cellular or satellite link aren’t always reachable, and polling constantly to ask “did anything change?” burns bandwidth and battery for the vast majority of checks that come back with nothing new.

MQTT flips the relationship. A device doesn’t ask anyone anything — it announces what it knows, and whoever’s listening gets notified. Adding a new subscriber means one more client connecting to the broker, not any change on the publisher’s side at all.

Why does MQTT still matter, decades later?

MQTT was designed in 1999 for oil pipelines and satellite links — about as far from a smart home as you can get. And yet it’s the same protocol quietly running inside Home Assistant, inside industrial SCADA systems, inside the EV charger in someone’s garage.

That’s not nostalgia. The problem MQTT solves was never really about the technology of any particular decade — networks were unreliable in 1999 and they’re still unreliable now, just in new shapes: a Wi-Fi dropout instead of a satellite delay, a cheap microcontroller instead of a pipeline modem. The underlying pattern — decouple publishers from subscribers, let a broker absorb the unreliability, treat presence and disconnection as first-class events instead of edge cases — turned out to generalize to almost anything that produces data intermittently and needs that data to reach more than one place.

That’s why a protocol old enough to predate the term “IoT” is still the obvious choice for a new EV charger deciding when to draw power from the sun instead of the grid.

System Architecture: End-to-End Encryption in a Flutter-to-Microcontroller MQTT Bridge

Sun, 07 Jun 2026 09:04:37 +0000

As software developers, we must treat physical IoT hardware as a secured endpoint. Relying on unencrypted, local Wi-Fi connections to trigger microcontrollers leaves physical devices vulnerable to packet sniffing and local network exploits.

In this architectural overview, we outline a secure, end-to-end communication pipeline:
Local Biometric Keystore Verification: Flutter client authenticates the user locally and generates a cryptographically signed payload token via the OS secure enclave.

Encrypted Decoupling: The payload is published over encrypted MQTT (MQTTS with TLS 1.3 over Port 8883) to a secure broker.

Hardware Execution: The local microcontroller (ESP32/PCBA) subscribes to the secured topic, verifies the cryptographic signature of the token, and executes the physical command.

We also dive into integrating edge-sensing telemetry arrays (such as our local ML-driven E-Noses Precision Agriculture AI project) under the same unified gateway architecture.

Check out the full system topology and code pipeline design:
https://www.seosiri.com/2026/06/biometric-iot-security-hardware-manufacturer.html

How to Set Up MQTT With ESP8266?

Tue, 21 Apr 2026 21:12:45 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In this article, I will be demonstrating how to use MQTT with a NodeMCUv2 (ESP8266) board.

What is MQTT?

MQTT is a lightweight messaging protocol for IoT devices.

It is a publish-subscribe protocol, which means that devices can publish messages to a topic and other devices can subscribe to that topic to receive messages.

Why is MQTT needed?

As the ESP8266 is a low-cost WiFi microcontroller, it can connect to a WiFi network, and it can transmit data wirelessly.

For sending data from the ESP8266 to the cloud, we need to use the MQTT protocol.

Integrate MQTT with ESP8266

Let's start with setting up mqtt with esp8266.

We use PubSubClient library for mqtt with esp8266.

Add this in platformio.ini file.

[env:nodemcuv2]
platform = espressif8266
board = nodemcuv2
framework = arduino
upload_speed = 115200
monitor_speed = 115200
lib_deps = 
    knolleary/PubSubClient @ ^2.8

Here is the simple example of MQTT with ESP8266.

#include <Arduino.h>
#include <WiFi.h>
#include <PubSubClient.h> // <-- Added MQTT library

// --- 1. WiFi Credentials ---
const char* ssid = "Add your wifi name"; 
// !! YOU MUST CHANGE THIS to your WiFi password !!
const char* password = "Add your wifi password"; 

// --- 2. MQTT Credentials ---
const char* mqtt_server = "Add your mqtt server";
const int   mqtt_port = 1883;
const char* mqtt_user = "Add your mqtt username";
const char* mqtt_pass = "Add your mqtt password";
// This is the topic we will listen to
const char* mqtt_topic_to_subscribe = "nodemcu/messages";

// --- 3. MQTT Client Objects ---
WiFiClient espClient;
PubSubClient client(espClient);


// --- 4. Function to handle incoming MQTT messages ---
void callback(char* topic, byte* payload, unsigned int length) {
    Serial.print("Message arrived [");
    Serial.print(topic);
    Serial.print("] ");

    // Print the message payload
    for (int i = 0; i < length; i++) {
        Serial.print((char)payload[i]);
    }
    Serial.println();
}

// --- 5. Function to connect to MQTT ---
void reconnect() {
    // Loop until we're reconnected
    while (!client.connected()) {
        Serial.print("Attempting MQTT connection...");
        // Attempt to connect
        if (client.connect("esp32-client-123", mqtt_user, mqtt_pass)) {
            Serial.println("connected");
            // Subscribe to the topic
            client.subscribe(mqtt_topic_to_subscribe);
            Serial.print("Subscribed to topic: ");
            Serial.println(mqtt_topic_to_subscribe);
        } else {
            Serial.print("failed, rc=");
            Serial.print(client.state());
            Serial.println(" try again in 5 seconds");
            // Wait 5 seconds before retrying
            delay(5000);
        }
    }
}

// --- 6. setup() ---
// This runs once at the beginning
void setup() {
    Serial.begin(115200);
    delay(10);

    Serial.println();
    Serial.print("Connecting to: ");
    Serial.println(ssid);

    // Start connecting to WiFi
    WiFi.begin(ssid, password);

    // Wait for the connection to complete
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }

    // If we get here, we are connected!
    Serial.println(""); // New line
    Serial.println("WiFi connected!");
    Serial.print("IP address: ");
    Serial.println(WiFi.localIP());

    // --- Add MQTT setup ---
    client.setServer(mqtt_server, mqtt_port);
    client.setCallback(callback); // Set the function to run when a message arrives
}


// --- 7. loop() ---
// This runs over and over, forever
void loop() {
    // Check if connected to MQTT, if not, reconnect
    if (!client.connected()) {
        reconnect();
    }
    // This function processes MQTT messages
    client.loop(); 

    // Small delay to keep things stable
    delay(10); 
}

Output:

Conclusion

Finally, we could set up MQTT with ESP8266.

In the next article, we will use MQTT with PainlessMesh. To send data from one ESP8266 to another ESP8266.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

How to Send Data from PainlessMesh to the Cloud Using MQTT in an ESP8266?

Mon, 13 Apr 2026 23:52:28 +0000

In this article, I will be demonstrating how to use PainlessMesh and MQTT with a NodeMCUv2 (ESP8266) board.

What Problem we are solving?

We will be reciving data from multiple nodes and send it to cloud using MQTT.

Publish the data from received at gateway to cloud using MQTT
Scallable MQTT topics publishing

How it works?

Receive data from multiple nodes

These data will be in compressed in these format.

void onMeshReceive(const uint32_t &from, const String &msg) {
  Serial.printf("[mesh] From %u: %s\n", from, msg.c_str());

  JsonDocument doc;
  if (deserializeJson(doc, msg) != DeserializationError::Ok) {
    Serial.println("[mesh] JSON parse failed");
    return;
  }

  const char *msgType = doc["type"] | "data";
  String topic = buildTopic(from, msgType);

  if (mqttClient.connected()) {
    mqttClient.publish(topic.c_str(), msg.c_str());
    Serial.printf("[mqtt] Published → %s\n", topic.c_str());
  } else {
    Serial.println("[mqtt] Not connected — message dropped");
  }
}

Publish the data from received at gateway to cloud using MQTT

Setup wifi credentials.

#define STATION_SSID "your_ssid"
#define STATION_PASSWORD "your_password"

Connect to wifi using painlessmesh.

As painlessmesh is heavy library it will consume lot of power and data.

So we will use mesh.stationManual() to connect to wifi.

 mesh.stationManual(STATION_SSID,
                     STATION_PASSWORD); // ← key: mesh owns the STA
  mesh.setHostname("ais-gateway")

Scallable MQTT topics publishing We will use MQTT to send data from gateway to cloud.

We will use these credentials for MQTT.

#define MQTT_HOST "your_mqtt_host"
#define MQTT_PORT_TLS 8883
#define MQTT_USER "your_mqtt_user"
#define MQTT_PASS "your_mqtt_password"

We will use these topics for MQTT.

Each topic will have different meaning.

For example we will use these topics for MQTT.

For sending an industrial sensor data we will use these topics.

#define T_VERSION "v1"
#define T_TENANT "electrotech"
#define T_INDUSTRY "pcba"
#define T_SITE "plant1"
#define T_GATEWAY "gw_01"

Finally followed with config message.

{
  "type": "config",
  "schema": {
    "temp": {"type":"float","scale":10,"offset":0,"min":0,"max":51.1},
    "hum": {"type":"float","scale":10,"offset":-20,"min":20,"max":122.3},
    "gas": {"type":"float","scale":0.1,"offset":0,"min":0,"max":1023}
  }
}

/**
 * gateway.cpp — PainlessMesh Root + MQTT Bridge (HiveMQ TLS)
 *
 * Follows the official painlessMesh MQTT bridge pattern:
 *   - mesh.stationManual() hands WiFi STA management to the mesh library
 *     so it never disconnects from the router to scan for mesh peers.
 *   - MQTT connect is triggered by IP change detection in loop().
 *   - mesh.setRoot(true) called BEFORE init().
 *
 * Data flow: sensor node → mesh → gateway → HiveMQ MQTT → backend
 * Topic format: v1/{tenant}/{industry}/{site}/{gateway}/{node}/{type}
 */

#include <Arduino.h>
#include <ArduinoJson.h>
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <WiFiClientSecure.h>
#include <painlessMesh.h>

// ─── WiFi credentials ────────────────────────────────────────────────────────
#define STATION_SSID "your_ssid"
#define STATION_PASSWORD "your_password"

// ─── Mesh credentials ────────────────────────────────────────────────────────
#define MESH_PREFIX "your_mesh_prefix"
#define MESH_PASSWORD "your_mesh_password"
#define MESH_PORT 5555

// ─── MQTT credentials (from backend .env) ────────────────────────────────────
#define MQTT_HOST "your_mqtt_host"
#define MQTT_PORT_TLS 8883
#define MQTT_USER "your_mqtt_user"
#define MQTT_PASS "your_mqtt_password"

// ─── Topic routing constants ─────────────────────────────────────────────────
#define T_VERSION "v1"
#define T_TENANT "electrotech"
#define T_INDUSTRY "pcba"
#define T_SITE "plant1"
#define T_GATEWAY "gw_01"

// ─── Globals ─────────────────────────────────────────────────────────────────
painlessMesh mesh;
BearSSL::WiFiClientSecure wifiClient;
PubSubClient mqttClient(wifiClient);
IPAddress myIP(0, 0, 0, 0);
unsigned long lastMqttAttempt = 0;

// ─── Helpers ─────────────────────────────────────────────────────────────────

String buildTopic(uint32_t nodeId, const char *msgType) {
  return String(T_VERSION) + "/" + T_TENANT + "/" + T_INDUSTRY + "/" + T_SITE +
         "/" + T_GATEWAY + "/" + String(nodeId) + "/" + msgType;
}

IPAddress getStationIP() { return IPAddress(mesh.getStationIP()); }

// ─── MQTT callback (placeholder for future /cmd downlink) ────────────────────
void mqttCallback(char *topic, byte *payload, unsigned int len) {
  Serial.printf("[mqtt] Received on %s: %.*s\n", topic, (int)len,
                (char *)payload);
  // Phase 2: parse /cmd and forward to specific mesh node via mesh.sendSingle()
}

// ─── Mesh callback: forward every message to the correct MQTT topic
// ───────────
void onMeshReceive(const uint32_t &from, const String &msg) {
  Serial.printf("[mesh] From %u: %s\n", from, msg.c_str());

  JsonDocument doc;
  if (deserializeJson(doc, msg) != DeserializationError::Ok) {
    Serial.println("[mesh] JSON parse failed");
    return;
  }

  const char *msgType = doc["type"] | "data";
  String topic = buildTopic(from, msgType);

  if (mqttClient.connected()) {
    mqttClient.publish(topic.c_str(), msg.c_str());
    Serial.printf("[mqtt] Published → %s\n", topic.c_str());
  } else {
    Serial.println("[mqtt] Not connected — message dropped");
  }
}

// ─── Setup ───────────────────────────────────────────────────────────────────
void setup() {

Coder Legion - Recent posts tagged mqtt

Updating Radar Firmware Without a Cloud: Self-Hosted OTA over MQTT

Scope first

Three commands

Confirming the result

Running an update

A minimal image host

What the documents do not say

Checklist

Related reading

Online Says It's Connected, HeartBeat Says It Works: Reading Two Status Signals Instead of Guessing

cover_image:

Why this distinction is not academic

The trap: silence is not evidence

What you can do instead

Two rules you must not break

A minimal health monitor

Measure these at commissioning

Maintenance looks like a failure

Two controls worth knowing about

Checklist

Where to go next

MQTT: The Protocol Designed for a World Where Things Fail

The origin story of MQTT

The publisher

The subscriber

The broker

What do clients and brokers look like in practice?

One client, multiple roles

How do you know a device is still alive?

What happens when a device suddenly disappears?

What happens to messages while the device is offline?

How do you know a message actually arrived?

How does a system recover after failure?

Why wasn’t HTTP enough?

Why does MQTT still matter, decades later?

System Architecture: End-to-End Encryption in a Flutter-to-Microcontroller MQTT Bridge

How to Set Up MQTT With ESP8266?

What is MQTT?

Why is MQTT needed?

Integrate MQTT with ESP8266

Conclusion

How to Send Data from PainlessMesh to the Cloud Using MQTT in an ESP8266?

What Problem we are solving?

How it works?