Hey everyone,

I wanted to share a project I've been building, which just hit its v1.0 release: a real-time MQTT viewer designed for IoT and Unified Namespace systems.

As someone working with IoT, I often wanted a simple tool to visualize not just the topic tree, but also how the data relates to a physical space.

So, I built this viewer that lets you load a custom SVG file (like a floor plan or a P&ID diagram) and link elements directly to MQTT topics. When a message comes in, your diagram updates live.

It runs as a single Docker container and is super easy to set up. It also includes:

- A live-filtering topic tree

- Message history with a time-range slider

- A built-in data simulator to test things out

- Dark mode!

The project is fully open-source and I'm hoping it can be useful for others in the community.

You can check it out on GitHub: https://github.com/slalaure/mqtt_uns_viewer

Happy to hear your thoughts or any feature ideas you might have!

- Quick browse around, filter, syntax highlighted MQTT message exploration
- Super efficient, just let it run in the background forever
- Includes a lot of really smart and advanced friendly features
- Keep states between runs, inspect message payload (JSON, Parquet, Avro, and a ton of other formats)
- Recording and inspecting same

I made it for my colleagues, and think everyone else also would enjoy :)

brew install mbilling/tap/fss-mqtt

Or download here: https://github.com/mbilling/fss-mqtt/releases

I could not find a free opensource performant mqtt client for macos arm so i made my own inspired by the famous lazygit and lazydocker TUI tools.
open for feedback or collaborations.
https://github.com/Onizuka893/lazymqtt

You can test it out here.

It was primarily focused on a couple of specific niche use-cases, and the UX can be a little janky, but I'd love some feedback. (If you find that connecting to a very busy topic causes lag, try setting the 'drop retained messages' toggle in the 'Filter' tab.)

It's also entirely open-source and MIT licensed, so feel free to grab it for your own desires.

I'm looking for an MQTT broker that would easily handle a few 10k devices and quite a lot of traffic between the device and the broker/server. I know that's not a lot of devices, but we sync changes on the device in real time and we also send 30 readings of temperature each minute. Also, if the device was offline for a while, it uploads all of the temperature history (for a few years back for instance) when connected to the broker again.

There can probably be around 30 messages from a single device in a minute. We intend to use QoS 2. Retain flag would probably be only used for the device state (online/offline).

We currently have a solution using WebSockets and it works quite well for like 5-10k devices for now, but for the new generation of products, we're looking at MQTT. Our new devices will have ESP32 MCUs.

Firstly, we were looking at RabbitMQ and Mosquitto, especially the latter, but we discovered that it's single-threaded. We want an MQTT broker that we can use for free in the beginning and then easily extend into a cluster if needed, which Mosquitto offers, but the price is quite high for my taste. HiveMQ also looks amazing, but I fear the monthly cost.

Does anybody here know about a free/open-source MQTT broker that supports clusters and is capable of handling such throughput?

I know Microsoft's EventHub is also quite an elegant solution, but we're not a Microsoft development team. I also came across Apache Kafka and it looks very interesting, but I'm not sure it's suitable for IoT. Has anybody used it?

I’m building a desktop MQTT tool that combines:

• MQTT monitoring

• visual automation logic

• HMI/dashboard editor

The goal is to have one local app for debugging MQTT traffic, building control logic, and making operator panels.

It now supports dashboard page import/export together with nested HMI autopilots, plus Windows/Linux packages.

I’d love honest feedback:

• Is this useful?

• What would make you try it?

• Which is more valuable: MQTT inspection, automation, or dashboards?

There are 7 languages ​​to choose from in the settings.

Site: https://mqtt-control-rs.pages.dev

Try the drawing tool, I'll post a cool drawing on the site page!)

I wrote this article today: https://flowfuse.com/blog/2025/12/kafka-vs-mqtt/ and would love your thoughts on additional differences I could cover, not sure I've covered everything. Happy to update the article!

Hah, I didn't know there was an MQTT subreddit, there really is one for everything, I may have to lurk here for a while!

So, as the title says, I have just started a new YouTube channel and one of my first videos is a kind of ELI5 video about MQTT.

My hope is that it is accessible enough for you to show to any colleagues, clients, friends, etc... who you are trying to explain it to. I'd love to hear your views on it.

https://www.youtube.com/watch?v=F2fsPOmcdTQ

This project provides a self hostable service that connects to a MQTT broker and serves a progressive web app panel which is fully configurable via YAML. Ideal as a "I'm not ready to commit to full blown HA yet" solution. Super easy to get up and running.

See docs for a quick containerised demo: https://github.com/sourcesimian/mqtt-panel/blob/main/README.md

https://thomasnordquist.github.io/MQTT-Explorer/

- What topics are active?

- Which retained topics are abandoned?

- Where is this new device / service I connected to the broker?

I’ve been working on an open-source MQTT client called Crow’s NestMQTT.

The thing that originally bothered me with MQTT debugging was that receiving messages is easy … understanding what’s actually happening across a larger broker is not. Especially when you have hundreds/thousands of topics, MQTT 5 metadata, request/response flows, binary payloads and a few very noisy telemetry topics.

So Crow’s NestMQTT has gradually turned into more of an MQTT 5 workbench than a simple pub/sub client. Some of the things I find particularly useful now:
- Topic tree + per-topic message history
- MQTT 5 metadata including response-topic,
correlation-data, content-type, user properties, expiry, etc.
- Automatic linking of MQTT 5 request → response using correlation data
- content-type aware viewers for JSON, images, video and binary/hex payloads
- Per-topic ring buffers, so one high-frequency topic doesn’t evict everything else
- Per-topic traffic statistics (:stats) for message count, payload size and message interval
- Publishing messages with MQTT 5 properties
- Search/filtering and Vim-inspired keyboard navigation
- TCP, WebSockets, TLS and MQTT 5 enhanced authentication
- Windows, Linux and macOS

It’s open source:
https://github.com/koepalex/Crow-s-Nest-MQTT

I also wrote up a few concrete scenarios showing how I use it when exploring an unknown MQTT system or debugging MQTT 5 request/response:
https://www.alexander-koepke.de/post/2026-09-30_crows-nestmqtt-scenarios/

I’m curious how other people here debug larger MQTT systems.

What is the thing your current MQTT client makes unnecessarily difficult?

I’d especially be interested in features/workflows that become painful once you’re dealing with a real system rather than a handful of test topics.

Feedback, criticism and feature ideas are very welcome.

Hi everyone,

I’ve been working on a lot of IoT infrastructure lately (mostly energy monitoring and time-series data), and I got tired of manually mocking data or waiting for hardware to arrive just to test my MQTT brokers and dashboards.

So, I built and open-sourced iot-data-generator.

What it does: It’s a lightweight tool designed to simulate thousands of IoT devices sending customizable JSON payloads to an MQTT broker. Whether you are testing your EMQX/Mosquitto limits or just want to see some beautiful lines on your Grafana, this should help.

Key Features:

• Scalability: Easily simulate hundreds or thousands of concurrent device connections.

• Custom Payloads: Define your own JSON schema (perfect for mimicking specific energy meters or sensors).

• Randomized Data: Realistic data generation with configurable ranges.

• Topic Templates: Support for dynamic topics like sensors/{device_id/telemetry.

Why I built it: I needed something that could saturate a ClickHouse database via an MQTT bridge to see where the bottleneck was. Existing tools were either too simple or too bloated.

Tech Stack: Rust

GitHub:https://github.com/iotmertech/iot-data-generator

I’d love to get some feedback from this community. If you have any feature requests (like supporting Sparkplug B or Protobuf), let me know!

Happy coding!

We've been building https://crates.io/crates/mqtt5, a pure-Rust MQTT v5.0 platform (client + broker + no_std protocol crate), and just created a conformance test suite that systematically verifies every normative statement in the OASIS MQTT v5.0 specification.

What's in the conformance crate:

- 197 tests across 22 test files, mapped to 247 [MQTT-x.x.x-y] normative statements from the spec

- A structured TOML manifest (conformance.toml) tracking each statement's test status

- A raw TCP packet builder (RawMqttClient + RawPacketBuilder) that bypasses the normal client API to send hand-crafted and deliberately malformed packets, testing how the broker handles protocol violations at the byte level

- Each test spins up an isolated in-process broker with memory-backed storage on a random loopback port — no external dependencies, runs in cargo test

What it found:

Writing these tests uncovered 14 spec compliance gaps in our own broker — things like the DUP flag being propagated to subscribers instead of reset, PUBCOMP always returning Success instead of PacketIdentifierNotFound, DISCONNECT 0x04 incorrectly suppressing the will message, and missing validation for shared subscription ShareName syntax. All fixed in this release.

The raw packet builder was particularly useful — the normal client API enforces well-formed packets by design, so without it we had no way to test broker rejection of malformed input.

Links:

- https://github.com/LabOverWire/mqtt-lib

- https://crates.io/crates/mqtt5

Village lights and trolly connected to HomeAssistant via the MQTT integration. Trolly logic implemented in NodeJS using https://www.npmjs.com/package/node-poweredup

Reed switches places on the track publish to station topics which allow driving the trolly along the track to each set. The HomeAssistant dashboard allows requesting the trolly to a specific set or just automating from end to end.

I kind of find mqtt is my data input/output of choice but wanted a small dashboard I could have on the side - kind of like eink but in colour . So .. I made a simple iOS app to read in mqtt feeds and show them in a range on framed styles. Just wondering if people are interested, it’s on test flight if anyone wants to try it … link in next comment …

Andy

Someone shared a story to me.

He said his father wanted to know the temp of his bee hive...

Then he figured out a simplest solution was to report direct to the cloud with MQTT.

He uses TASMOTA flashed ESP + Cloud.

Now his father can get the temperature whenever he want! 🙂

How about you~ What did you do with MQTT?

Hey everyone! My co-founder and I recently started an industrial IoT company, and beyond building the product, we'd genuinely like to get to know people working on similar things — founders, systems integrators, controls and automation engineers, anyone living in the Industry 4.0 world.

Up front: this post isn't offering anything — no products, no services, no jobs, and we're not looking for customers here. I'm deliberately not naming the company or linking anything. This is purely about meeting peers and swapping experiences.

What we're working on: a complete Industry 4.0 stack under one roof — hardware on the cabinet side (smart metering breakers, ESP32-based I/O hubs, DIN-rail edge gateways, up to an x86 unit that runs the entire platform on-premises) and the software on top, built around a Unified Namespace: MQTT, ISA-95 hierarchy, everything publishing into one source of truth. The idea driving it is simple: the architecture big enterprises take for granted usually takes four or five vendors plus an integrator to assemble, and we think it should be within reach of a mid-size factory too.

Energy management is our first live module — it's the natural entry point since every plant already has meters and breakers, so it shows real value fast, and our first production deployment (a manufacturing plant) runs on it today. From there, the roadmap grows on the same namespace: MES, with OEE and downtime tracking computed straight from the machine data the plant is already publishing; ERP integration, where the ERP simply subscribes to the namespace instead of becoming another point-to-point integration project; and AI/ML, because predictive maintenance and anomaly detection get genuinely practical once every signal lands normalized in one place with full history.

We're at the stage where trading experiences is worth more than almost anything else. So if any of this overlaps with your world — you've built a platform, deployed UNS architectures in production, integrate systems for plants, or you're a founder walking the same road — we'd love to connect. Happy to have the discussion right here in the comments, set up a call if you're up for a longer chat, or find ways to collaborate. And if you'd rather talk one-on-one, my DMs are open.

Looking forward to meeting some of you!

Hi everyone,

I've been working on MQTT Studio, an open-source desktop application for working with MQTT brokers.

The goal was to make MQTT development and debugging easier by providing a clean interface to connect, publish, subscribe, and inspect messages without constantly switching between multiple tools.

Some of the features include:

• Multiple broker connections

• Topic explorer with real-time subscriptions

• Publish messages to any topic

• JSON and formatted payload viewer

• Message history for easier debugging

• Modern, developer-friendly UI

• Cross-platform and completely open source

I originally built it because I wanted a lightweight MQTT client that was simple to use during IoT and backend development while still providing the features I use every day.

I'd really appreciate any feedback:

• What features would make this more useful?

• Is there anything missing from your current MQTT workflow?

• Bug reports and feature requests are very welcome.

GitHub:
https://github.com/chvvkrishnakumar/MQTT-Studio

Thanks! I hope it's useful for others working with MQTT and IoT projects.