Testing of the setup detailed here and here has uncovered some rather serious issues with power consumption and heat production.

Initial testing had the ESP8266 board running from a USB power supply, however it was always intended to swap this for a small battery, as it would be far more compact. Initially, I went for a single CR2025, but quickly discovered that the 3V battery was not, in fact, “close enough” to the 3.3V minimum required to run the ESP8266. After some research and a friendly chat with the local electronics store, I was reminded that voltage is cumulative, and that multiple 1.5V batteries would provide the voltage I needed, while not exceeding the 6V limit of the board. I grabbed a 4 x AAA battery setup and hooked it up to the board. It was far larger and heavier than I’d been hoping to achieve, but it was better than the USB power supply.

Once set up, I noticed that the temperatures were reading high. They had been doing so on the USB power supply as well, when I looked at the data. The ESP8266 was generating quite a lot of heat, and the DHT11 sensor was reading it. Noting this for further investigation, I left the setup to run overnight. The following morning, when I went to move it to a different location to see if it was a position issue, I noticed it was not working. The batteries had been drained below the necessary voltage in less than 12 hours, and the data showed that the readings were steadily less accurate as the battery drained.

This sent me into research mode. The DHT11 project is the “Hello World” of sensor projects, yet there was a dismaying dearth of information on power management for them, leading me to conclude that very few projects actually get put to work beyond hobbyists learning the ropes. I was quite convinced that the heat was being generated by the wireless chip on the ESP8266 board sending and receiving packets almost constantly, and that if I lengthened the communication interval it would necessarily decrease power usage and heat production. In my research, I also discovered the ESP8266 has a few sleep modes. The code is painfully simple, but what it does is enormously powerful. By putting the ESP8266 into deep sleep mode for 100 seconds between sending each reading, the heat issue is solved, with the sensor reporting accurate temperatures, no matter where it is located. I have also sourced a battery housing for 2 CR2025 batteries, which is much smaller and lighter than the 4 x AAA setup. I will be changing the deep sleep interval to 900 seconds (15 minutes) for the next test, and hooking up the new battery housing, and I expect battery life to be markedly improved.

An interesting quirk of the deep sleep mode is the jumper required between the RST and D0 on the ESP8266 board, to allow the board to send itself the signal to wake up after the assigned interval. Once I had this in place, I had numerous issues updating the sketch from the Arduino IDE. I initially thought that the ESP8266 was asleep while I was trying to update it, but it turned out that the jumper was interfering with the reset function, so I need to remember to disconnect it while updating the sketch, and reconnect afterwards.

I’m currently undertaking the final course of my degree, which happens to be Data Visualisation. This has brought me to the awareness that my dashboard violates almost every rule of visualising data, and needs a complete overhaul, so when I get the local server set up, I will also be devoting some time to tidying up the presentation of the sensor data.

Ultimately, I’m glad to see this project developing in complexity. I was wanting to sink my teeth into something “more complex” once this was finished, but doing it well has become a satisfying challenge.