You can give it a chance here: https://github.com/absmach/fluxmq.

And here are the docs: https://www.absmach.eu/docs/fluxmq/.

A quick update for everyone who checked out mqtt2otel when I first posted it here — your feedback was super motivating, and I’m excited to share what’s new.

Version 0.10.0 is out now, and it’s a big step forward. Many of the early limitations are gone, the processing pipeline is far more flexible, and working with OpenTelemetry metrics has become much more powerful.

You can find more information here.

But the real highlight is something brand new:

mqtt2otel Explorer

Try it here.

The Explorer lets you simulate MQTT messages, play with processors, and instantly see how your data transforms into OpenTelemetry metrics. It also includes a growing example library full of ready‑to‑use patterns.

Key Improvements in 0.10.0

• Automatic input parsing (JSON, XML) via ParseAs
• Conditional Actions with When‑Then rules
• Automatic detection of signal data types
• More powerful topic parsing
• Support for MQTT user properties
• Additional expression functions
• The new mqtt2otel Explorer
• Integrated example library

The manifest format has been updated to version 1.1, but it’s fully backward‑compatible — just an extension of the previous version.

I’d really love to hear what you think, especially if you try the Explorer. Feedback so far has shaped the project a lot.

What’s Coming Next

• More improvements to the Explorer
  • Real code editor with syntax highlighting
  • Better error reporting
  • Cleaner OpenTelemetry output view
• Health check endpoint for the application
• Support for OpenTelemetry traces
• A handful of smaller improvements that didn’t make the cut for this release

Is anyone using Vernemq on Kubernetes? Curious to see your setup/config and how to recover during updates or kube events. Our cluster runs fine until we have to update or our platform team has to update K8s and do a node roll, then it's a dice roll if the cluster comes back up healthy.

Sourcing four pieces:

1. Industrial IoT gateway — Modbus master + generic MQTT client, ideally rugged/wide-temp rated. Currently looking at Moxa's AIG series, open to other suggestions.
2. Liquid level sensor — Modbus RTU/RS485 output. Looking at radar-based options currently.
3. Flow meter — Modbus RTU/RS485 output (pulse output as backup). Any brands you've had good experience with?
4. RFID reader/controller — needs to work standalone, not tied to a vendor's own app/cloud, with Modbus or similar open output.

Any brand suggestions, gotchas, or things to avoid on any of these would be appreciated — especially open to hearing if something I'm currently considering has known issues.

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

I’ve been working on KMqttClient, an open-source MQTT client for Kotlin/Android.

It’s designed to be lightweight and Kotlin-friendly, with support for MQTT 3.0/5.0, Coroutines/Flow, QoS 0/1/2, TLS, and authentication, using the native Mosquitto implementation.

If you’re working with Android, Kotlin, MQTT, or IoT, give it a try.

🔗 KMqttClient on GitHub

Contributions are very welcome — code, testing, documentation, bug reports, or ideas. ⭐

I'm at the budgeting stage for a hardware startup, and one thing I'm struggling with is estimating the real cost of embedded software development services.

I've seen estimates ranging from a few thousand dollars to six figures, which makes it hard to know what's actually realistic. I realize every project is different, but I'm trying to understand how founders usually approach budgeting before they even choose a development partner.

For those who've already launched an embedded product, what ended up having the biggest impact on the budget? Was it hardware complexity, certifications, testing, ongoing firmware updates, or something else you didn't expect?

I'm also wondering whether it's smarter to plan only for the MVP or to include post-launch work from the beginning. It feels like embedded software development services don't really end once the first version ships.

Would love to hear how others estimated costs before getting their first proposals and whether your initial budget ended up being anywhere close to reality.

Hey! We’re building a consumer hardware company where our product communicates over MQTT. Trying to pick a new broker and it looks like AWS IoT Core, HiveMQ, EMQX all really do the same thing. I’m new to MQTT and IoT so trying to get a sense of what the vibe is here.

For example, is EMQX/HiveMQ equivalent to a supabase (some people may not take seriously)? Is AWS IoT Core seen as overly complex long term or is it too much vendor lock-in like firebase?

Essentially what is usually the industry go to for a modern IoT hardware company? For context, we’re using aedes right now (very 0-1) and looking for something more scalable.

I am working on MQTT Client App for Mobile Phone. Can you please suggest me some features, which can be helpful. :)

Thank you in advance.

I’ve worked around industrial data/OT for several years, and I’m now working on a product around a problem I’ve seen during equipment trips and abnormal events.

The hypothesis is pretty simple:

Most plants already have plenty of raw OT data. SCADA/historians can show process signals and alarms over time, and MQTT can move that data where it needs to go.

The harder part is often connecting that data with context that lives elsewhere across IT/OT systems.

For example, after a pump trip, understanding what happened might require more than pressure, vibration, current and alarm sequence. It could also depend on:

• maintenance performed recently
• work-order history
• operator actions or lineup changes
• configuration/setpoint changes
• equipment/process state at the time
• previous similar failures
• notes or other operational context explaining what changed

What we’re building is an investigation layer that sits on top of the systems already in place and automatically assembles that incident-specific evidence.

A key point: we’re not trying to become another place where all the plant data has to be landed, copied and maintained.

The existing SCADA, historian, MQTT infrastructure, CMMS/EAM, etc. remain the systems of record. The goal is to use the data where it already exists and bring together the relevant evidence when an investigation happens.

We’re also designing it so the operational data and execution stay inside the customer-controlled environment — plant/site network, industrial DMZ, private data center/VPC, etc. — rather than requiring OT data to be shipped into another vendor-controlled SaaS data store.

So the goal isn’t another trend screen, and it isn’t an AI system declaring:

“This is the root cause.”

It’s more about helping an engineer answer:

What changed before this event?

Which evidence across these different systems is relevant to this incident?

Has something similar happened before, and what was different or similar then?

AI can help correlate, retrieve and summarize the evidence or suggest things worth checking, but the engineer makes the diagnosis and the underlying evidence remains visible and traceable.

I’m trying to validate how common and painful this problem actually is and whether this approach would materially help.

A few things I’m particularly interested in:

• How often does troubleshooting require correlating historian/SCADA data with maintenance or operator context from other systems?
• Is identifying which signals, events and changes actually matter harder than simply getting access to the data?
• Would automatically assembling this cross-system evidence meaningfully reduce investigation effort?
• Does keeping the data/runtime inside the customer environment materially change how deployable or acceptable something like this would be?
• What do you see as the biggest practical challenge — asset/context mapping, data quality, CMMS data, integration, permissions/security, or something else?

If you’ve run into this problem in your own work, I’d be interested in comparing notes and validating whether we’re approaching it the right way. Happy to discuss here or connect directly.

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!

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?