PicoMQTT is a lightweight MQTT library for Arduino/PlatformIO optimized for ESP8266 and ESP32. It not only supports the MQTT Client mode like most existing solutions but also the MQTT Broker mode which transforms an ESP8266 or ESP32 board into an MQTT gateway replacing a Raspberry Pi board or an IoT gateway typically used for this task.
The library follows MQTT 3.1.1 specification, supports the publishing and consuming of arbitrary-sized messages, can deliver thousands of messages per second, and supports easy integration with the ArduinoJson library to publish and consume JSON messages.
MQTT Broker code example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
#include <Arduino.h> #include <PicoMQTT.h> PicoMQTT::Server mqtt; void setup() { // Usual setup Serial.begin(115200); WiFi.mode(WIFI_STA); WiFi.begin("MyWiFi", "password"); // Subscribe to a topic pattern and attach a callback mqtt.subscribe("#", [](const char * topic, const char * payload) { Serial.printf("Received message in topic '%s': %s\n", topic, payload); }); // Start the broker mqtt.begin(); } void loop() { // This will automatically handle client connections. By default, all clients are accepted. mqtt.loop(); if (random(1000) == 0) mqtt.publish("picomqtt/welcome", "Hello from PicoMQTT!"); } |
There are some limitations to the implementation due to constrained resources in the ESP8266 and ESP32, notably:
- Client only supports MQTT QoS levels 0 and 1
- Broker only supports MQTT QoS level 0, ignores will and retained messages.
Another downside highlighted by the developer is that only ESP8266 and ESP32 boards are supported.
Developer Michał Leśniewski further told Hackster.io that PicoMQTT doesn’t have all the features that Mosquitto has and it’s much slower than a Raspberry Pi, but it’s good enough for a few devices that do not send a large number of messages. He found his own setup with a few ESP boards to be very stable. You’ll find the source code, documentation, and a benchmark sample on GitHub with everything licensed under GNU LGPLv3.
The benchmark consists of ESP boards in Broker mode, and a PC sending a flood of messages with different parameters. What’s really odd is that the ESP8266 can handle several thousand messages per second for small payloads (<=10 bytes) using up to 5 consumers, but the ESP32 struggles much more only being able to handle several hundred messages per second, or even less, under the same conditions.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Are the graphs labeled correctly? Seems ESP8266 is more powerfull (higher throughput) than ESP32
I find it odd as well, but both the data and the charts on GitHub show ESP8266 is faster.
Hi guys, I’m the author of the library.
The broker throughput on the ESP32 is actually lower than on ESP8266. There are two main reasons for this.
First, the library was originally written with ESP8266 in mind primarily and has been optimized for it. Performance on ESP32 could be improved a bit by optimizing the code for ESP32’s network implementation. Tuning the settings in
config.hshould also help a bit.Second, the ESP32 IP stack and the general architecture is much more complex compared to ESP8266. Although the message throughput is lower, the ESP32 can run additional tasks without a significant throughput drop.
As the ESP32 has two cores, one of which is dedicated to wifi and networking, I assume the drop in throughput is caused by context switching and contention between the cores. As you identified, this likely does leave available CPU for other tasks.
While I’ve not played with it, I know you can pin tasks to specific cores. For example, if each subscriber’s publish effort were broken in a task and transmitted from the same core as the networking/wifi core, throughput should significantly improve. Likewise, this should avoid task migration between the cores. And if your reception task is on the same core, and the messages are dispatched for processing (the fast/slow approach), it may also help.
See: xTaskCreatePinnedToCore
esp-idf also has a native mqtt lib if i am not mistaken.
esphome also (still) supports mqtt while the native api might be better suited for most in 2020 and later.
https://esphome.io/components/api.html#advantages-over-mqtt
It looks like ESPHome has an MQTT client implementation, I can’t see anything about an MQTT Broker implementation.
ESPHome does not have a broker solution. Home Assistant’s default solution is Mosquitto. A higher performance alternative is readily available in the addons.
Not sure it’s related with the dual core, but the Arduino ESP32 software includes FreeRTOS inside. So your arduino sketch runs as a task. Unfortunately, they didn’t allow to really capitalize on that in the examples and tutorials, meaning that what is said here about “running additional tasks” is not in a separate thread or making use of teh two cores. But the weak performance is indeed linked to context switching, memory management and the like. I’d suspect that you would see similar counter-performance of ESP32 for many other examples that run on both ESP8266 and ESP32.
The graphs basically also tell you that the ESP32 can send about 300 messages/sec (irrespective of length) as long as you don’t reach 100bytes/message, but performance drastically degrades for longer messages. ESP8266 OTOH is more “linear” in terms of traffic, meaning it can send roughly 20kB/s of data total, where you have to consider #messages x (average) length
In any case, I’m more confident in dedicating a super cheap ESP8266 to the broker role than adding that to a raspberry Pi or ESP32 that is also doing other tasks. Thanks Michal, exactly what I was looking for.