ESP32 - MQTT Broker

[mnfisher]

I've been playing with MQTT recently - and I used a Raspberry Pi as a broker....

However - I could use an esp32 as a lightweight broker. Espressif have recently ported 'Mosquitto' to a component.

To run:

Create a new esp32 project (I called mine esp32_mqtt_broker) and cd to it's directory.

Add the component:

Code: Select all

idf.py add-dependency espressif/mosquitto

Rebuild the program (might need an idf.py fullclean first)

The very small program attached - creates an access point (or connect to local wifi) - ESP32Access with password pswd1234

I used IO MQTT Panel to connect (get the ip address by opening the esp32 COM port using PuTTY) - and created a switch and a text panel - with the switch sending 'on' or 'off' to sensor/toggle.

Other devices can connect / subscribe / publish although it probably can't handle large numbers of connections simultaneously. If required - it is possible to subscribe to a topic on the same device - to get notifications of new posts (I haven't tested this yet!)

One snag I hit - FC's CAL_IO defines A and B - as does the mbed component in the espressif libraries (this is a problem with C - symbols are program wide)
I got around this by undefining A and B (in supplementary code) -before importing the mqtt component. Then I redefined them (as 0 and 32)

Martin

[chipfryer27]

Hi Martin

This would be great if I were controlling "something" remotely, or publishing data to my phone or the like.

Regards

[mnfisher]

I added a 'client' task and here I subscribe to sensor/toggle.

On my phone I have a switch that posts 'on' or 'off' to the broker - and also a text panel that subscribes to this topic and displays 'on' or 'off' (correctly)

I used the MQTTClient component - and I hit a couple of issues. Here I use 127.0.0.1 as the broker address (Loopback) - although it also works with the ip address.

Using the component - the client gets timed out (despite the 'keep alive') - to counter this I do a ping every 1s. (Note the phone has a timeout of 300s - and doesn't)

Also - the payload received - has additional characters (on / off / onf / offck / onfck) - someone more au fait with MQTT might know what I'm doing wrong here?

A while ago - I wrote some event driven MQTT code for the esp32 and I might try that - I did manage to get the correct payload data (and it might be a component issue?)

The code has a couple of long (5s) waits to allow wifi and then the broker to 'stabilise' before the next step - an event approach would be better here?

This version just demonstrates possible errors in the MQTTClient component?

Martin

[chipfryer27]

Hi

I noticed that as a client, if I "read" a topic I would then disconnect, forcing me to resubscribe. I was too busy to chase this further at the time but intend to go back and check if it was "me" or an issue.

Regards

[mnfisher]

... and an event driven version. I changed my previous code to use the client from the Mosquitto component.

This correctly reports (to UART) all messages received by the broker.

You'll need to add SSID and PASSWORD (in Initialise)

Supplementary code has an event handler that extracts topic and payload and puts them in a queue - MQTT_Client runs as a task which waits on data appearing in this queue.

Here it just outputs the data to UART - a real world device would do more (or nothing!)

Martin

[BenR]

Wow Martin,

This is very cool and certainly incredibly handy, many thanks for sharing

I'll be keeping my eye on this one and hope to have a go with it soon.