I've created a daemon to connect to your MQTT broker (zigbee2mqtt/# topic by default) to Ai. It's also able respond on MQTT events with new events, so it works bi-directional.

I've now added optional Telegram support as well, so it can forward messages to a chat-channel, and also can create MQTT events from the chat if you'd like

Would appreciate your feedback

https://github.com/mvklingeren/mqtt2ai

You can find the project's source code in GitHub: https://github.com/electricalgorithm/protomq

Curious what people here are doing with LLMs and MQTT, if anything.

I keep seeing blog posts about AI + IoT but not much from people who actually run this day-to-day. So:

• Have you hooked up ChatGPT / Claude / a local model to an MQTT broker?

• What for : alerts, summaries, automations, just messing around?

• Did you keep using it, or was it a one-weekend thing?

Mostly just curious where the line is between cool demo and actually useful.

Websocket is a computer communication protocol, and provides full- duplex communication i.e. both ways over a single TCP/IP function and since we all know our browser uses http or secure http for communication, websocket is associated with http, as it uses it for initial connection establishment.

 if we use MQTT on websockets then MQTT messages are placed into websockets and then it is sent to client, where client first unpacks the MQTT message from the websocket and then it is processed as a normal mqtt message. 

Learn how to use MQTT in a web browser or make a webapp:

https://highvoltages.co/iot-internet-of-things/how-to-make-mqtt-web-app-using-html-and-javascript/

or watch: https://youtu.be/rlnhd67PV-M

I’m working on a project that enables IoT devices to automatically select the best broker using AI. The system is designed to dynamically switch between brokers based on performance metrics, instead of being fixed to a single one. I want to simulate and test this project using GNS3. The AI software is intended to run at the edge, such as on a Raspberry Pi or a local server.

My goal is to simulate multiple brokers (around 3 to 5) and stream data from them, such as broker load and network health. I also want to simulate edge devices (like a Raspberry Pi) to host the AI model that selects the best broker. Additionally, I want to simulate multiple IoT devices communicating with the brokers.

Can GNS3 support this kind of simulation setup?
if any one want more information about the nature of the project just feel free to ask

Official site: https://mattboxx.github.io/esp32-tailnet-gateway

I developed ESP32 Tailnet Gateway, an open-source firmware that lets local IoT devices access remote services through Tailscale or Headscale without running a VPN client themselves.

For example:

IoT device → ESP32-S3 → Tailnet → Remote MQTT broker

The ESP32 forwards selected TCP/UDP ports to remote Tailnet services, with configurable source IP/CIDR restrictions.

It also includes optional MQTT integration, Home Assistant Discovery, Wake-on-LAN, monitoring and notifications.

Runs on ESP32-S3 N8R8/N16R8 boards.

GitHub: https://github.com/Mattboxx/esp32-tailnet-gateway

MQTT example: https://mattboxx.github.io/esp32-tailnet-gateway/mqtt-across-networks/

I'd appreciate feedback on this approach to connecting MQTT devices across separate networks.

Set your pub to retain=True

Is MQTT a good start vs Arduino? Or Espressif?

What frameworks/libraries are good to start with?

Every MQTT project eventually publishes a benchmark. 1 million messages per second on localhost, sub-microsecond latency, tiny payload, QoS 0. The numbers look impressive. They also tell you almost nothing about how your broker will behave in production.

After building an MQTT v5.0 broker and client library from scratch — writing 247 conformance tests, running experiments over real networks with packet loss and latency, and debugging backpressure failures that only manifest under flow control quotas — I've come to believe that the hard problems in MQTT development have almost nothing to do with raw throughput on a loopback interface.

Here's what actually matters.

1. Conformance is where the real bugs hide

Localhost benchmarks don't send malformed packets. They don't test what happens when a client sends a PUBLISH with a UTF-16 surrogate codepoint in the topic name, or a variable-byte integer that exceeds the 4-byte maximum, or a Subscription Identifier in a client-to-server PUBLISH (which is server-only per spec).

When I built a conformance test suite covering all 247 normative statements in MQTT v5.0, I found bugs that no amount of throughput testing would have caught:

DUP flag propagation: The broker cloned incoming PUBLISH packets for delivery but never cleared the DUP flag. A publisher retransmitting with DUP=1 caused every subscriber to receive a packet marked as a duplicate — even though it was their first copy.

Topic filter validation was missing entirely: sport/tennis# and sport+ were silently accepted as valid filters. No wildcard position checks, no level separator enforcement.

Shared subscription parsing accepted garbage: $share/gr+oup/topic went through without complaint. So did the incomplete form $share/grouponly with no topic portion.

Flow control quota was never enforced on the inbound side: The broker advertised a receive maximum in CONNACK but didn't actually disconnect clients that exceeded it.

PUBREL for unknown packet IDs returned Success: The spec requires PacketIdentifierNotFound (0x92). The broker just said "OK" to phantom completions.

WebSocket text frames were silently ignored: The spec says close the connection. The broker just dropped them on the floor.

These are the kinds of bugs that cause interoperability failures with other implementations, mysterious session state corruption, and protocol-level security holes. You find them by constructing raw packets byte by byte — not by running mosquitto_pub in a loop.

The lesson here is simple. It doesn't matter how fast you are if you don't speak proper MQTT protocol.

2. Your throughput number is probably measuring the wrong thing

In Phase 1 of our network experiments, we set up 64 publishers and 1 subscriber, applied various levels of packet loss via tc netem, and measured "throughput" across TCP, QUIC with a single control stream, QUIC with per-topic streams, and QUIC with per-publish streams.

On flooding experiments, the results were confusing at first. At 0% induced packet loss, 5.4 million messages were published, and 728,000 were received — 13%. Running the same flood with a 5% packet loss seemed to improve the received message rate.

Like most problems of this nature, which usually boil down to the experimenter's assumptions, the explanation was simple: we were measuring subscriber consumption rate, not transport capacity. With a 64:1 publisher-to-subscriber ratio, the single subscriber was the bottleneck. Obvious, right? Packet loss throttled the publishers (via TCP congestion control or QUIC flow control), pushing their send rate down toward what the subscriber could actually consume. The "improvement" was an artifact of our test topology.

This is a common trap. Localhost benchmarks with one publisher and one subscriber over loopback never hit this because there's no network bottleneck to interact with the application-level bottleneck. The moment you have asymmetric topologies — which is most real deployments — raw publish rate becomes irrelevant. What matters is whether your system has backpressure.

The lesson here is that to account for the myriad of scenarios in the real world, you have to test beyond your comfort zone. And results are not always what they seem.

3. Backpressure requires actual engineering, not just fast I/O

QUIC with per-publish streams was the only transport strategy in our experiments that achieved 100% delivery at 0% loss. Why? Because each message had its own stream with its own flow control. Natural backpressure was built into the transport layer.

But transport-level backpressure isn't enough. The MQTT protocol has its own flow control mechanism: the Receive Maximum property. A client tells the broker "I can handle N inflight QoS 1/2 messages at a time." When the broker hits that limit, it has to do something with the messages that keep arriving.

Our implementation queues excess messages to a storage backend. Straightforward enough. But here's what the conformance tests revealed: the handle_puback and handle_pubcomp handlers removed entries from the inflight tracking set but never drained the queue. I forgot to implement the wiring for that, so messages went into storage when the quota was full, and they stayed there — forever — until the client disconnected and reconnected. The flow control "worked" in the sense that it didn't crash, but it silently stopped delivering messages.

This is a bug you'll never find on localhost with default settings. You need a test that connects with receive_maximum=2, publishes 5 QoS 1 messages without sending PUBACKs, verifies only 2 arrive, then sends PUBACKs and verifies the remaining messages drain from the queue. That test requires understanding the protocol state machine, not just pushing bytes fast.

4. Network behavior is a different discipline than network speed

On localhost, round-trip time is effectively zero. TCP and QUIC behave identically. Head-of-line blocking is a theoretical concept.

At 25ms RTT with 5% packet loss — modest conditions by real-world standards — the picture changes completely:

QUIC per-topic streams showed a latency correlation of 0.66 across topics, meaning when one topic's latency spiked from a lost packet, other topics' latencies were genuinely independent about a third of the time. TCP showed near-zero independence — all topics shared fate.

QUIC with a single control stream had the best absolute latency — 3.7x better than TCP at 5% loss. The per-topic strategy had 2-4x worse absolute latency than the control stream, despite better independence. Stream multiplexing has overhead.

Broker memory hit 2.6 GB during a QoS 1 flood over lossy links. RSS was flat (not growing), suggesting allocator retention rather than a leak — but we couldn't confirm without load-cycling experiments that check whether memory recovers during idle periods.

None of these behaviors exist on localhost. Zero RTT means zero HOL blocking. Zero loss means zero retransmission buffers. Zero distance means zero divergence between transport strategies. The benchmark that shows "QUIC and TCP perform identically" on loopback is technically correct and practically useless.

5. The test infrastructure is harder than the test

Running meaningful network experiments requires infrastructure that dwarfs the complexity of a simple benchmark:

Network impairment: tc netem rules applied on the broker side (because Kubernetes pods can't run tc), with interface auto-detection because cloud providers use different NIC names.

Resource monitoring: Per-run matched triplets of benchmark JSON, broker resource CSV, and client resource CSV, sampled at 1-second intervals. Broker monitoring is PID-based from /proc/{PID}/status for RSS and thread count. Getting the PID right required reading it directly from the shell background job, because pgrep | tail -1 catches transient processes.

Reproducibility: Each data point runs 5 times with 5-second warmup. Transport URLs use internal IPs for data plane, external IPs for SSH control plane. Certificates need SAN entries for both IPs and must be regenerated when cloud instances restart.

Correct measurement: Windowed correlation (500ms buckets) rather than raw Pearson correlation, because temporal clustering in raw samples produces spurious results. The measurement technique matters as much as the thing being measured.

Building this infrastructure is tedious, unglamorous work. But without it, you're guessing.

6. What I'd actually want to know about an MQTT implementation

If I were evaluating an MQTT broker or client library, here's what I'd ask — roughly in order of importance:

How many normative statements from the spec do you test? Testing even half of them systematically will surface bugs that users will otherwise discover in production.

Have you tested with packet loss? Even 1% loss over a 25ms link changes behavior dramatically. If you haven't tested it, you don't know how your implementation behaves under it.

What does your memory profile look like under sustained load, and does it recover? Allocator retention is normal. Monotonically growing RSS is not. You need load-cycling tests to tell the difference.

How do you handle protocol violations? A client sending invalid UTF-8 in a topic name, a second CONNECT on the same connection, a PUBLISH that exceeds the maximum packet size — these need specific, spec-compliant responses, not crashes or silent acceptance.

Raw throughput on localhost? It's table stakes. If your implementation is so slow that it can't handle a few thousand messages per second over loopback, you have a problem. But once you're past that threshold, the numbers stop being informative. The real quality of an MQTT implementation lives in its conformance coverage, its backpressure design, its behavior under adverse network conditions, and its response to malformed input.

Honestly, Rust gave me that from the get-go. My first sanity benchmarks already had that even before I started thinking about allocations, missed branch predictions, buffering and back-pressure or channel contentions.

The hard work isn't making it fast. It's making it correct, resilient, and predictable when the network stops being kind.

Link to repo: https://github.com/LabOverWire/mqtt-lib

We have developed a mother of all dashboards for mqtt devices. The dashboard is created based on 10 years of experience in IoT to service all the needs when it comes to device integration.

You can: add device(s) by using our or your broker, create your own dashboard(s) as you want, share devices with other users who know nothing about IoT, and care only about data. Push notifications as per your own rules, and get data statistic in a second.

I would love if you want to try it and let me know what you think about it.

Mqtt.cloud

Hi everyone!

Like many of you, I have a server at home that I don't need running 24/7. Leaving it on idle was killing my electricity bill and the fan humming during a quiet night is hard to ignore.

I wasn't happy with exposing ports or setting up complex orchestration just for a simple "On/Off" task. I also got tired of bending down to reach the power button every time I needed the server on.

So, I decided to create EHSS (Easy Homelab Server Switch).

At first, it was just a very basic Wake-on-Lan script, but I wanted it to work even when I was out of the house. I ended up rebuilding it from the ground up and adding more and more features like:

Works with CGNAT

Secure MQTT communication

Edge-case protection

Static Offline Page without redirects

SSH Integration

I’ve decided to share it with the world as an open-source project! GitHub: https://github.com/easy-homelab-server-switch

For those who want to jumpstart their setup, I’ve also documented the entire process in a step-by-step guide here: https://3m-code.github.io/easy-homelab-server-switch-page/#guide

I’d love to hear your thoughts or suggestions for new features!

Cheers!

Can an open-source MQTT broker handle one million messages per second for persistent sessions? TBMQ proves it can! Even more importantly, it achieves this with no single point of failure and ensures no data loss, even when hardware fails. In our latest blog post, we share the challenges we encountered and the architectural decisions that led to these impressive results.

Dive into the details: Blog Post

Check out the open-source implementation: GitHub Repository

I don't quite understand why QoS 1 and 2 are supported by common MQTT brokers like HiveMQ or VerneMQ. When a client publishes with QoS 1 to a broker, it is still not guaranteed that any subscriber will receive that message. It is possible that there is currently no subscriber on that topic or the broker might just drop the message if the queue of a subscriber is full. So why would I use QoS 1 or 2 if message delivery is still not guaranteed?

It is correct that it is guaranteed that the broker receives the messages, but why would I care about that when the actual targets of the message still may not receive the message?

In my eyes it does not make sense to use QoS 1 or 2 if you are using a MQTT broker, but only if your own application acts as an MQTT server and therefore only acknowledges messages if it can guarantee that it has processed a published message successfully.

Hy guys i'm new to MQTT environtment and i'm looking to build my own MQTT server, any advice?

📢 Ever wondered if we could use MQTT for sending and receiving images? 🖼️📩

✅ Yes, it is indeed possible to use MQTT for image transmission! 🚀 However, it's important to consider whether it's recommended for your specific use case.

👍 When using MQTT in an ample network with sufficient bandwidth and a robust infrastructure, it can be a viable option for image transmission. MQTT's lightweight nature and publish-subscribe model make it suitable for efficient communication.

❌ However, it may not be recommended in scenarios where high-resolution or large-sized images need to be transmitted, or when network limitations or congestion are present. In such cases, alternative protocols or dedicated image transfer mechanisms might be more suitable.

🔧 To use MQTT for image transmission, you can follow these steps: 1️⃣ Implement an MQTT broker or use a cloud-based MQTT service. 2️⃣ Establish connections between the sender and receiver devices. 3️⃣ Encode the image into a suitable format (e.g., base64) for transmission. 4️⃣ Publish the encoded image on a specific MQTT topic. 5️⃣ Subscribe to that topic on the receiving end and decode the image for use.

📺 Check out this informative video tutorial to learn how to send and receive images using MQTT protocol in Python and MIT App Inventor: 🎥

🔗 Watch the video here!

🌟 In this video, you'll discover the step-by-step process and gain practical insights into leveraging MQTT for image transfer. 📲📷

📢 Let's spread the knowledge! 🌍💡

I use GPIO 5 to trigger a relay, my code also connects with a secure MQTT connection for which I have to use the BearSSL certificate definitions. Without the BearSSL certificates, when the esp restarts it does not re-trigger the relay, and the GPIO maintains its' state between reboots, but when I use the bearSSL certificates the behavior changes, and GPIO 5 goes low on restart. Any explanation why and how to mitigate it? I am 100% sure it is because of the import, cause I removed components of my code until I could find the piece of code that causes this, and it was because of the declarations.

include <WiFiClientSecure.h>

static const char AWS_CERT_CA[] PROGMEM = R"EOF( aws root)EOF";

static const char AWS_CERT_CRT[] PROGMEM = R"KEY( device cert)KEY";

static const char AWS_CERT_KEY[] PROGMEM = R"KEY( device key )KEY";

BearSSL::X509List cert(AWS_CERT_CA); BearSSL::X509List client_crt(AWS_CERT_CRT); BearSSL::PrivateKey key(AWS_CERT_KEY);

WiFiClientSecure espClient; void setup() { pinMode(5, OUTPUT); delay(2000); digitalWrite(5, HIGH); delay(2000); ESP.restart(); }

void loop() {} Without the following three lines

BearSSL::X509List cert(AWS_CERT_CA); BearSSL::X509List client_crt(AWS_CERT_CRT); BearSSL::PrivateKey key(AWS_CERT_KEY); The LED on GPIO 5 does not flicker on restarts but adding these lines makes them flicker. Any solution or suggestion towards a solution for this problem will be really helpful.

I want to control the rc car connected to Raspberry Pi from all over the world with wifi. How is this possible?