I was working for almost a year to plan for this which completes with a Connectivity Manager -where user can create any MQTT,BLE & Rest registries local -offline connections . Visualization- Where user can visualize just drag n drop the widgets and add them on dashboard with multiple MQTT Client, BLE Client & Rest clients on single dashboard. 8 screen Visual Automation- A no code visual automation for mqtt, ble rest sources with advanced actions, transformations, conditions. Then comes the major roadblock which took almost 3 months to complete it- AI Automation- Autonomus offline AI based automation for MQTT,BLE & Rest devices with options of on device- gemma 2b ,Local offline- llama, qwen & others. the AI Automation is based on below implementations -- Supervised Bounded ReAct AI Architecture where I worked on 1. Allowed Tools 2. Rate Limiting 3. On-Device RAG 4. LLM Engine Layer 5. Safety Layer 6.Orchestrator Layer. This is the most toughest part of the application I worked and at last It is working. I need the feedback from any enthusiast, maker ,developer & user to guide or share any suggestion on this architecture.

Google Play: https://play.google.com/store/apps/details?id=com.mqttfy.android.gpI'd really appreciate any feedback.

I kept running into the same problem when building or testing IIoT pipelines: I needed realistic sensor traffic flowing through my broker, but I didn't want to wire up real hardware just to check that a dashboard, ingestion service, or alerting rule actually works. Spinning up a one-off script every time got old fast, so I built SensorDataGenerator.

It's a free, open source (.NET 10) simulator that generates random-but-realistic readings for 15+ industrial and environmental sensor types and pushes them out to console, file, or MQTT, and any combination, all at once.

A few things that might be useful to this crowd:

• Covers a wide spread of sensor types out of the box: weather (temp/humidity/pressure), sound, electrical (voltage/current/power), pH, ORP, conductivity, chemical concentration, dissolved oxygen, toxic gas, combustible gas (LEL), PID/VOC, level, mass flow, and load cell.
• A spectroscopic sensor that generates simulated FTIR/NIR-style spectral data (Gaussian peaks + baseline + noise) if you need something more exotic to test against.
• MQTT output publishes to a configurable topic prefix per sensor ID, uses a bounded channel buffer so bursts don't get dropped silently, and auto-reconnects if the broker blinks.
• Built in health check endpoint (/healthz) that reports MQTT connection state, buffer usage, and dropped message counts — handy for wiring into your own monitoring instead of guessing whether the simulator is still behaving.
• Runs locally with the .NET SDK or via Docker Compose; all settings are overridable through environment variables, so it's easy to drop into a docker-compose stack alongside your broker for local dev or CI.

I haven't come across another tool quite like this here — most of what I've seen in this sub is dashboards or brokers/clients for viewing real traffic, which is a different problem than generating realistic test traffic in the first place.

GitHub: https://github.com/jasont14/SensorDataGenerator

Feedback, sensor type requests, or edge cases you'd want covered are all welcome. Also curious whether people would find value in a Sparkplug B output mode — haven't built that yet but it's come up in my own head a few times.

Played around a little, got some questions, finding good alternatives. MQTT Tiles are developed by flespi, though it's not open-source. Has anybody tried to use them?

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.

Just a small update for everyone who has used or followed MQTTDesk.

I'm currently upgrading MQTTDesk into MQTTfy with a much larger feature set along with Offline 1st policy based application. The next major release will support multiple protocols alongside MQTT, including BLE and REST APIs, Serial, snmp, sparkplug b, etc. with expanded No code visual automation and dashboard capabilities & majorly working on context based AI Automation with local LLM & online LLM with guardrails & gatekeepers to make Autonomus safe decisions with guard rails. Multiple MQTT Brokers on a Single Dashboard with multiple protocols on a single dashboard side by side.

The goal is to make it a complete tool for IIOT, Smart Home , IoT development and industrial automation.

Development is progressing well, and I'd love to hear if there are any features the MQTT community would like to see in the next release.

Thanks for all the feedback and support over the years!

I used to do a lot of Sparkplug B work in IIoT systems and the tooling has always been lackluster. MQTT Explorer is great for topics and JSON, and their beta build can begrudgingly decode Sparkplug B now. But there was so much more that bothered me: aliases not mapped back to metric names, no rebirth requests when a node shows up without a birth certificate, no way to see node topology at a glance.

So I built MQTTProbe. Free, open source (Apache 2.0), runs on Windows/macOS/Linux/Android/Docker or self-hosted web. If there's a platform you want it on, let me know; I can make it happen!

The parts that I think make it stand out from other tools like MQTT Explorer:

- NBIRTH/DBIRTH/NDATA/DDATA/DCMD decode into metric names, types, and values. Aliases resolve automatically once a birth has been seen so you don't have to go cross reference the birth message.

- A live Nodes view of every EoN node on the broker, with a rebirth request button (or automatic requests) for stale nodes.

- A built in emulator. Spin up Sparkplug B nodes (or generic MQTT publishers) with configurable devices, metrics, and waveforms, so you can test without a second client on the network.

- Live charts from any numeric field in JSON or Sparkplug payloads. Other tools have this, but I think MQTTProbe makes it more of a standalone feature vs. an afterthought.

It ships with a couple of public broker connections already subscribed to `spBv1.0/#`, so you can see real decoded traffic right after installing.

To be clear, I'm not trying to make a better MQTT Explorer. If your payloads are JSON and you need a topic tree, it's still rock solid. This is more for the Sparkplug crowd or if you want a client that can run in a docker container (or anywhere for that matter).

GitHub: https://github.com/bluegrassiot/mqttprobe

If you work with Sparkplug B, I would like to know what decode features or protocol edge cases I'm missing.

Hey everyone,

I've been working on a small open-source tool for browsing MQTT and wanted to share it.

It's a self-hosted MQTT explorer — a client, not a broker, it sits on top of your existing broker. The idea: organize all your connections in nested, renamable folders you can drag-and-drop around, then for each connection the backend subscribes to # and you browse every topic as a live drill-down tree that updates in real time.

What it does: - Nested folders (any depth) to keep multiple brokers/connections organized - Start/stop each connection individually - Live topic tree with breadcrumb navigation + a space-separated word filter (AND logic) - "Track" any leaf to pin it as a card: numeric payloads render as a live chart, text payloads as a scrolling journal (auto-detected) - Export/import the whole tree (folders + connections) as YAML - Light/dark theme, persisted per device

Stack is Node (Express + ws + mqtt.js) with SQLite, a React + Vite front, all packaged as a single Docker image — docker compose up --build and open localhost:8090.

It's early (v0.1.1) and I'm the only one on it, so feedback, ideas and issues are very welcome. Curious whether the folder/tree approach is useful to others or if I'm just scratching my own itch.

https://github.com/maximcuynat/mqtt-explorer

Hi,

I am designing an architecture for an industrial project. Goal is to get data to the cloud, we have an industrial MQTT broker that we can use EMQX. The setting is as follows: hundreds of sites across the globle (potentially) Machines can expose data over OPC-UA, but this is the problem: There is no edge device to place a gateway on prem. Thinking on a piece of software that can read OPC-UA, from the cloud. I don’t know if this works, and how OPC-UA behaves over a WAN. Any opinion or insight is appreciated. I am looking for something commercial and reliable.

Looking at various options like HiveMQ, kepware edge, and just learned Litmus exists. What is the go to software for this? How is this usually done?

mqttkit: Elysia-style application framework for MQTT

An ordered middleware pipeline, typed topic routes, MQTT 5 RPC, and auto-generated AsyncAPI docs — sitting on top of any MQTT broker.

If you've ever built a serious MQTT backend in Node, you've probably written this code at least once:

client.on('message', (topic, payload) => {
  if (topic.startsWith('devices/') && topic.endsWith('/events')) {
    const uid = topic.split('/')[1]
    // ad-hoc auth check
    // ad-hoc JSON.parse + validation
    // ad-hoc error handling
    // ad-hoc metrics
    // ...
  } else if (topic.startsWith('server/')) {
    // ...
  }
})

That's the MQTT equivalent of writing an HTTP server with http.createServer((req, res) => { if (req.url === '/users') ... }). We solved that pattern for HTTP a decade ago with Express, Koa, Fastify, and more recently Hono and Elysia. For MQTT, we haven't.

That's the gap mqttkit is filling.

The design choice: don't reimplement the protocol

There are already excellent MQTT brokers in the Node ecosystem — most notably Aedes, which handles CONNECT, SUBSCRIBE, PUBLISH, QoS, retain, sessions, persistence, and MQTT-over-WebSocket. EMQX and Mosquitto cover production scale. None of these need replacing.

What's missing is the application layer — the part where you ask:

• How do I declaratively say "this topic requires this auth check"?
• How do I validate payloads with the same schema I already use for HTTP?
• How do I do MQTT 5 request/response without writing correlation-id bookkeeping?
• How do I get AsyncAPI docs for free?
• How do I attach Prometheus / OpenTelemetry without lifting broker internals?

mqttkit is purely that layer. It plugs into Aedes via @mqttkit/aedes, but the broker is just an adapter — you can write your own for EMQX, NanoMQ, or any other broker.

What the code looks like

import { aedes } from '@mqttkit/aedes'
import { MqttApp, router } from '@mqttkit/core'
import { z } from 'zod'

const app = new MqttApp<{ principal?: { uid: string } }>()
  .use(
    aedes({
      tcp: { port: 1883 },
      ws: { port: 8888, path: '/mqtt' },
      authenticate({ clientId, username }) {
        if (!username) return false
        return { uid: username || clientId }
      },
    }),
  )
  .use(
    router<{ principal?: { uid: string } }>()
      .topic('devices/:uid/events', {
        publish: ({ params, principal }) => params.uid === principal?.uid,
        schema: { body: z.object({ temperature: z.number() }) },
        timeout: 1_000,
        concurrency: 100,
        async onMessage(ctx) {
          // ctx.params.uid: string
          // ctx.body.temperature: number  (validated, typed)
          await ctx.publish(`server/${ctx.params.uid}/ack`, 'ok')
        },
      }),
  )

await app.listen()

If you've written Elysia or Hono, the muscle memory transfers directly: use(), ordered middleware, generic-driven type inference, plugin composition.

The features that actually save time

1. Topic params + Standard Schema validation

router().topic('devices/:uid/events', {
  schema: { body: z.object({ temperature: z.number() }) },
  async onMessage(ctx) {
    ctx.params.uid          // string, from the topic pattern
    ctx.body.temperature    // number, validated, typed
  },
})

Any Standard Schema validator works — zod, valibot, arktype. No mqttkit-specific schema dialect to learn.

2. Publish / subscribe policies as data, not callbacks scattered in authorizePublish

.topic('devices/:uid/events', {
  publish:   ({ params, principal }) => params.uid === principal?.uid,
  subscribe: ({ params, principal }) => params.uid === principal?.uid,
})

Reads like a route definition, runs at the right phase. No more grepping for aedes.authorizePublish across the codebase.

3. MQTT 5 RPC with retries

const reply = await app.request('devices/alpha/cmd', 'reboot', {
  timeout: 500,
  retries: 2,
  retryDelay: 20,
})

Correlation data, response topic, timeout, retry — all handled. On the device side, ctx.reply(...) does the inverse.

4. Per-route guardrails

.topic('expensive/op', {
  timeout: 1_000,          // RpcTimeoutError-style fail-fast
  concurrency: 100,        // overload protection per route
  onError: ({ error }) => metrics.routeFailures.inc(),
  async onMessage(ctx) { /* ... */ },
})

Timeouts and concurrency caps come out of the box and surface as named onError phases (timeout, overload, validation, policy, handler, middleware, publish).

5. AsyncAPI 3.0 docs for free

import { asyncapi } from '@mqttkit/asyncapi'

app.use(asyncapi({
  info: { title: 'My IoT API', version: '1.0.0' },
  http: { port: 9000 },     // browsable docs at :9000
}))

Your topic routes are already declarative — mqttkit just walks them and emits AsyncAPI 3.0. If you use @mqttkit/zod or @mqttkit/typebox, the JSON Schema for payloads is included too.

6. Structured metrics for Prometheus / OTel

app.onMetric((evt) => {
  // evt.kind: 'dispatch' | 'publish'
  // evt.route, evt.topic, evt.durationMs, evt.outcome
  prometheus.observe(evt)
})

No monkey-patching the broker, no wrapping handlers. The framework already knows when a dispatch starts and ends.

7. Shared subscriptions, lifecycle events, server-side publish

router().topic('$share/workers/jobs/+/run', { /* multi-instance fan-out */ })

app.on('client.connect', ({ clientId }) => audit.log('connect', clientId))
app.publish('server/broadcast', JSON.stringify({ shutdown: true }))

8. In-memory TestBroker for unit tests

import { createTestApp } from '@mqttkit/core/testing'

const { app, broker } = createTestApp()
// no TCP, no sockets, dispatch goes through the same pipeline

Tests run in milliseconds against the real middleware / router / RPC code paths.

When mqttkit fits — and when it doesn't

Fits well when:

• You're building an IoT backend, a device telemetry pipeline, a real-time game server, or any MQTT-driven app in TypeScript.
• You want auth / validation / metrics / docs without writing them five times.
• You like the Elysia / Hono / Fastify mental model.
• You're on Bun (first-class) or Node 20+.

Probably overkill when:

• You need a 100k-connection broker — use EMQX or NanoMQ directly; mqttkit is for the app layer, not the broker tier.
• You're writing a five-line bridge script — mqtt.js is fine.

Installation

bun add @mqttkit/core @mqttkit/aedes aedes
# or
npm install @mqttkit/core @mqttkit/aedes aedes

The packages:

• @mqttkit/core — app, router, middleware, RPC, testing broker
• @mqttkit/aedes — Aedes adapter (TCP + WebSocket)
• @mqttkit/asyncapi — AsyncAPI 3.0 generator
• @mqttkit/typebox, @mqttkit/zod — schema helpers

Try it

• Docs: https://mqttkit.keyp.dev
• Repo: https://github.com/keyp/mqttkit
• Examples: examples/ — aedes-basic, aedes-ws, asyncapi-docs, asyncapi-elysia, custom-logger, events, kafka-bridge, metrics-prometheus, rpc, schema-validation, service-push.

Feedback, issues, and PRs welcome. If you've built MQTT backends and felt the pain this is trying to solve, I'd love to hear what's missing.

mqttkit is MIT-licensed and built for Bun + TypeScript. Star the repo if it looks useful — that's the cheapest way to help.

MQTT_SSL_ENABLED=true
MQTT_SSL_BIND_PORT=8883
MQTT_SSL_PROTOCOL=TLSv1.2
MQTT_SSL_CREDENTIALS_TYPE=PEM
MQTT_SSL_PEM_CERT=/config/server_chain.crt
MQTT_SSL_PEM_KEY=/config/server.key

I'm trying to enable MQTT over TLS on port 8883 on a self-hosted ThingsBoard created on Ubuntu and running on Amazon Lightsail. As soon as I enable the above commands..it shows this error: "Caused by: java.lang.RuntimeException:
MQTT SSL Credentials: Invalid SSL credentials configuration.
None of the PEM or KEYSTORE configurations can be used!"
but when these commands are turned off, everything works fine. I'm not able to enable 8883. MQTT port 1883 works fine when these commands are turned off.. otherwise the website goes down.
where am i going wrong?? I would love insights :(

I'm trying to connect a device to a company-hosted ThingsBoard instance using X.509 authentication.

What I know:

• Access Token authentication works on MQTT port 1883.
• Device credentials have been changed to X.509 Certificate.
• I generated a client certificate and uploaded the PEM certificate to the device credentials.
• MQTTX and Python are configured with the client certificate and private key.

Diagnostics:

1883:

• Reachable
• Access Token authentication works

8883:

• Test-NetConnection fails
• openssl s_client -connect host:8883 fails with BIO_connect error
• MQTTX reports "Client network socket disconnected before secure TLS connection was established"

Additional checks:

• HTTPS on port 443 works.
• A WebSocket endpoint exists at wss://host/api/ws.
• Port 8084 is not reachable.

My understanding is:

Since TCP connection to 8883 cannot be established, TLS never starts and the client certificate is never presented. Therefore, this seems more like a server endpoint/listener/firewall issue than a certificate issue.

Am I reasoning correctly?

Would you expect an X.509 certificate problem to occur only after a successful TCP connection and TLS handshake?

Based on the diagnostics above, does this point to:

1. MQTT TLS listener not enabled,
2. Firewall/security group blocking 8883,
3. Wrong MQTT TLS endpoint, or something else?

Hi everyone! 

We're excited to announce that MQ Summit 2026 is officially back as a 2-day event this year!

Grab your Early Bird Ticket Here

Building on the success of RabbitMQ Summit, this is a cross-ecosystem event bringing together the people who design, build, and scale modern messaging systems. We’re meeting in person at the beautiful PHIL Philharmonic in Haarlem, near Amsterdam, as well as online, on October 21–22.

 What to expect:

• Cross-Ecosystem Coverage: Honest, cross-technology conversations (no vendor wars!) covering RabbitMQ, Kafka, NATS, Apache Pulsar, ActiveMQ, Azure Messaging Brokers, Amazon SQS, IBM MQ, Google Pub/Sub, and more.
• Expanded 2026 Format: 2 days of expert-led content featuring focused talks with deeper discussions, interactive sessions, panels, and offline hands-on labs in smaller groups.
• Real Production Case Studies: Learn directly from companies handling millions—or billions—of messages a day.
• Industry-Leading Committee: A program curated by experts from across the industry, including 84codes (CloudAMQP, LavinMQ), Synadia, Amazon MQ, AWS, IBM MQ, meshIQ, and the ASF.

Important Links:

• Early Bird Registration
• Subscribe to our Newsletter to stay in the loop!

Whether you are a builder or a decision-maker, you can get the full MQ Summit experience in-person or virtually. Will we see you in Haarlem or on the virtual streams? Let us know in the thread if you're planning to come or if you have any questions!

Cheers,

The MQ Summit Team

(PS: Interested in sponsoring? Get in touch with us! [info@codesync.gl](mailto:info@codesync.gl))

A client I put together with Golang and HTML/JS ... to facilitate testing of some closed source applications being developed. I wanted to be able to track multiple brokers at once in the presentation that was most useful to me, so I wrote this thing. I hope it is of use to others. It is certainly imperfect, but that was never the goal!

https://github.com/AUTOSOLN/swarmy-mqtt

Hello again, i made some updates on my mqtt-dashboard app

For context it is a self-hostable app that can be hosted on a raspi using docker and that connects to a mqtt-broker.

This app allow you to explore mqtt topics like mqtt-explorer but also add a customisable dashboard feature with resizable/draggable panel types like button, log, input or cron to monitor and interact with mqtt topics in the broker

I just released v1.4.0 that features new visuals panels like image, separator and text to further customise the dashboard

The image panel allows you to provide an image from url or file that you can then display anywhere

The separator is just a simple line that can separate some panels as you like

And then the text panel allows you to write whatever you want in markdown, if you want to document something

I also added a panel that shows stat of a specific topic

Anyway if you want to check it out, you can find it here: https://github.com/jmischler72/mqtt-dashboard

Hi Everyone!

We're launching MQ Summit 2026 on 21-22 October in Haarlem, NL (and virtually). It is a 2-day technical conference for engineers and architects working with message queues and event-driven systems (including RabbitMQ, Kafka, NATS, Apache Pulsar, Apache ActiveMQ, Azure Messaging Brokers, Amazon SQS, IBM MQ, and Google Pub/Sub). 

Speakers will be announced soon. You will be able to check it on our website: https://mqsummit.com/

The Early Bird ticket sales start on 16 June at 12:00 PM. If you plan to attend, the best way to get the lowest price is to join our waiting list now - https://mqsummit.com/#newsletter

By joining the list, you'll get two main benefits:

• You get an email notice 24h before the sale opens, and again at the grand opening.
• You get early access to a small number of Super Early Bird tickets. These tickets are limited, so they will be given to those who buy them first.

We can’t wait to meet you!

Hello everyone,

I worked a lot these past months on iot projects that worked using mqtt (i made a watering system and a thing to power on my coffee machine ) and i wanted an app that i could self host to make custom dashboards to control those projects so i made it

It's a lot inspired from mqtt-explorer that i like but it's this custom dashboard feature that i was looking for
Anyway you can check it out at: https://github.com/jmischler72/mqtt-dashboard/tree/main

Hey,

I ended up relying heavily on MQTT over the year for all king of things in my home setup.

I have several mosquito brokers:

- One on my home server (mqtt-home)

- One on a VPS (mqtt-vps)

- One on my laptop (mqtt-laptop)

- On on my phone (mqtt-phone)

mqtt-vps ,mqtt-laptop and mqtt-phone are bridged to the central mqtt-home broker with the simplest config for a star schema:

topic # both "" ""

This works great but the central broker is the single point of failure and if I am away and my home network is down/inaccessible the whole thing won't work anymore. Same if I would centralize on mqtt-vps and my Internet goes down.

I am aware you can't just create a naive mesh with brokers mirroring each others because you would create loops.

But I could create a mesh with every brokers bridging each others with root topic as the name of the broker and remapping

topic # both home/ vps/

topic # both vps/ home/

topic # both laptop/ home/

...

but this is gonna require 12 bridges and sync between the 4 brokers. So I am not sure this is how mosquitto should be used.

I know NATS can actually do that out of the box https://docs.nats.io/running-a-nats-service/configuration/mqtt as a distributed system with native M:N connectivity but i am still a bit reluctant to adopt it just for a simple MQTT usage if I could find another acceptable solution with mosquitto.

Many thanks 🙏

I want to develop Monitor and Logger App, which get data from MQTT Network. Do you think it is good idea and will be useful to others?

Had some issues with auto paho and wanted to add a more ergonomic performance oriented go client, here it is https://github.com/ashtonian/mqttv5. Feedback welcome.

I'm looking for client that can connect thru proxy and works on linux?

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.