In part 1 and 2 of this series, I sketched how to be very energy efficient when using a battery (part 1) and how to periodically gather sensor data and send that to a server through http (part 2).
In this part 3 I will show how to use an energy thrifty ESP8266 sketch to send sensor data via MQTT.
Again I am using the sketch from part 1, that has a section for ‘read data’ or ‘do stuff’ and a section for ‘send data’ and I just insert the necessary code.
All in all it is quite straight forward. This time I will not be using a BME280 sensor, but that good old DHT11.
As usual, you have to insert your own wifi credentials, and in this case also the ip number and port of your MQTT broker.
I laced the sketch with print statement that should help you in case of problems, but once you have the sketch up and running you can remove those.
There is a possibility for a bit more enerdy saving:
I use the following 2 statements to read and send the sensor data:
However, the DHT11 isn’t a really fast sensor and the read is while we are connected to WiFi. You could probably shave off a bit of connection time (and thus current) by reading the sensors in the ‘do stuff’ section, store them each into a global variable and use those variables in your MQTT publish.
Do that as follows:
//global float t; float h; //do stuff t=dht.readTemperature(); h=dht.readHumidity(); //when connected client.publish("home/sleep/stat/temp",String(t).c_str(),false); client.publish("sleep/sleep/stat/humid",String(h).c_str(),false);
This would also allow you to check for false readings with
and take corrective action. But that is not really the subject of this HowTo. Don’t forget a 5.1k pull-up resistor. As the DHT11 draws about 0.5mA, you could decide to feed it from one of the gpio pins and just switch it on when needed. (0.5mA comes to 12mAh over a day). However, also take into account that the DHT11 may need a bit of time to get ready.
Also, this sketch only publishes MQTT messages, it does not subscribe to any messages. DeepSleep and receiving subscribed MQTT messages comes with its own set of problems, but it is not impossible. Perhaps that I will write about that in the future.
You will find the link to this program here.
Part 1 -DeepSleep General
Part 2 -DeepSleep HTTP publishing
Part 3 -DeepSleep MQTT Publishing
Part 4 -DeepSleep MQTT Subscribing
Part 5 -DeepSleep ESP-NOW
Part 6 -Power Down
14 thoughts on “Very Deep Sleep and energy saving on ESP8266 – Part 3: MQTT”
I hope you write part 4 with best practices to deepSleep and receiving subscribed MQTT messages. Great job !!!
I think the best practises are covered in part 1, or maybe we have different ideas about what that is.
Receiving messages is not impossible with deep sleep, but it poses some problems. I just have put some code together but needs some testing to mske sure it is robust
I understant that you could sleep and then wake up periodically to “listen” any suscribed message, couldn’t you?
Yes that is the principle behind it but the problem comes as you may wake up when the broker isnt sending anything to your client and you do not know how long to wake up. But yes, the principle is correct: everything the esp8266 does is when its awake, not when its asleep.
Anyway, part 4 – deepsleep and receiving mqtt messages is now published
Very deep sleep part-4 Subscribing to mqtt messages
Great article, thanks so much, bought a real Christmas tree in a pot last year so will need to monitor it’s water level in the summer time, thinking about modifying this example to read a soil sensor! 🙂
Glad you like it. Easy soil sensor would be two carbon rods. Can also get capacitive sensors
Yup, got a capacitive sensor, going to see if I can solar power it with an 18650 battery. I only need one reading a day I guess i.e “THE TREE IS DRY!!!!” 🙂
One or two usually enough. Using solar power not so hard. 5 volt panel a small chargecontroller with attery protector, an 18650 and a 3v3 stabilizer. I suggest HT7833
Thanks for that, I read your article about LDOs – I’ll look into the HT7833 – I used to use the LM1117 🙂
Can, but definitely no low drop.
Using MCP1826 LDO regulators here – much like the HT series but rated at 1A. I’m finding typical drop while a module is transmitting to be about 200mV.
Thank you. I will put it in the list
Beautiful code! Format and comments are awesome. Along with your write-up of all the components, ie, LDO’s, etc. This makes for an easy reference for all. Thanks for the work, I look forward to implementing this!
Thank you for your kind words. Goodluck implementing