Testing MQTT on ESP8266 with arduino

A project log for Movuino

A low cost Open-Hardware wireless sensor board + online Machine Learning platform for Citizen research on motion.

Kevin LhosteKevin Lhoste 07/09/2016 at 20:240 Comments

Movuino BLE streaming speed are limited by the relative low bandwith of the ble (theoritically ~1Mbits/s) and we managed to stream data at 10hz using BLE112 module which not so fast considering that accelerometers caneasily get data at 100Khz.

In order to increase streaming speed (and thus sampling rate) wifi modules (such as esp8266) can be a good solution.

Now there is many solutions for streaming data to a the cloud and getting beautiful charts (plotly,, adafruit, etc..). However those services limit the number of data sent to 1/sec which more than enought for logging temperature but not enought for "real time" plotting. So I chose to try the MQTT protocol as it seems to be made for transferring iot data at high speed.

MQTT installation is not so straightforward yet ! On windows the MQTT broker (the server in MQTT terminology) is Mosquitto . This step by step tutorial worked perfectly for me :

The other essential tool for MQTT is MQTT lens which is a MQTT client in the form of a chrome extension.

It is the perfect tool for testing the data pipeline between the different MQTT pieces.

In this setup the esp8266 will be a MQTT client that sends data over wifi to the MQTT broker on the local network and on the same machine a MQTT client in chrome receive data.

On the esp8266 side the code running is the mqtt_esp8266 example from the Adafruit MQTT library.

I managed to get everyhhing working together but the data rate is very low : when i print the ellapsed time on the arduino console , there is one data going every ~200 ms

This is deceiving considering that MQTT is made to send short data frames fast and still not enought for streaming live accelerometer data at a resonble sampling rate. Here the maximum sampling rate would be 5 hz which is worst than in BLE.

It seems that i am not the only one who got this problem :

I will explore more why there is such a delay but i guess it might be because of a bad implementation of a library (for instance a callback that is waiting for a reply before sending another packet and timeout).