Adventures in deep sleep with ESP8266 and a temperature sensor

One of the small ESP8266 projects I did was the creation of a simple temperature sensor.

I build a simple circuit, following the guidance from the following articles:

I opted to use a probe on a long wire rather than using the little component. I ordered some of these from Amazon – https://amzn.to/2IiYEQs. I thought these would give me more flexibility when it came to positioning the probe.

The plan is to build a couple of these sensors and put then around my house. Mostly out of curiosity. I want to see how the house warms and cools during the coarse of the day and what impact the heating & occupancy has (more sensors!)

I had come across this article – https://openhomeautomation.net/esp8266-battery – which describes how an ESP8266 can run for years on a large battery. Seemed very straight forward and I figured that I could use a 9v battery to power one of these units for a few months at the very least.

I built the circuit and wrote the code using VSCode and the amazing PlatformIO plug-in. Essentially, my code connects to my WiFi, connects to an MQTT server (running on Hassio) and sends the temperature value. It will then go into a deep sleep for five minutes and repeat the process. This felt straight forward.

I put the circuit together on a breadboard to ensure I got the temperature reading working. I then moved the assembly onto a small circuit board and soldered it all in.

The 8266 comes requires 3.3v to operate, but comes with an in-built power regulator allowing you to power it with anything between 3.3v and 12v.

This is what I connected my 9v battery to. Everything seemed to work perfectly and my Hassio instance was recording the temperature coming from the sensor.

Temperature logged every 30 seconds until about 6am

Leaving it over night, I checked it in the morning. The temperature was logged every 30 seconds (I initially went for this to test its behaviour) until about 6am, when it went dead.

Some quick investigation showed the 9v battery had drained too much and the ESP8266 was no longer able to connect to the WiFi. That wasn’t what I expected. I knew it would use power when it was connected to the WiFi etc. but to drain a battery in a day? I decided to try and work it out.

First, let’s assume it’s running all the time. According to my multi meter, it’s drawing ~80mA.

This didn’t seem like a whole lot, until I checked this page – http://www.techlib.com/reference/batteries.html – and discovered that there are only 500mA hours in one of those batteries. So, at 80mA draw, the battery would supply the ESP8266 for 500/80 = 6.

Wow. Six hours wasn’t what I had in mind!

I’m not reading the temperature all the time, using a deep sleep as I mentioned before, to reduce its power usage between temperature reads. So if we assume it draws next to nothing when its asleep, let’s work out the power consumption over the course of an hour.

It takes about ten seconds to connect to the WiFi, connect to MQTT and send the temperature reading. This happens every thirty seconds, to in total, it’s essentially forty seconds between each read Read (10) | Sleep (30) | Read (10) etc.

So in an hour, we’ll take 90 readings.

This means we run at ~80mA for 90 x 10s or 15 minutes, per hour. This means our 500mA battery should run for about 24 hours. Except, it didn’t.

Using the multi meter again, I discovered the 8266 was drawing ~11mA when it was in deep sleep.

This was much, much higher than the power consumption outlined by the articles I had read online. Some further researching showed other people have the same problem.

It means the 8266 draws 11mA for 45 minutes of every hour. Out 500mA battery could only run for about forty five hours. That’s not even two days. It should be able to run for over a year on a battery when it’s asleep.

More reading on t’internet about the NodeMCU and one of the comments in this post (https://openhomeautomation.net/esp8266-battery) mentions the voltage regulator on the board draws ~11mA. Something called
Quiescent Current. I was supplying the board with 9v input to the GND/VIN pins, which would require the voltage regulator to kick in. Could this be the problem?

Using my bench power supply, I connected it directly to the 3.3v input and set the voltage to a constant 3.3v. I also removed the temperature sensor hardware and replaced it with a fixed software measurement to ensure no current was drawn through the board.

Zero Effect!

Still drawing 11mA in deep sleep. Note discrepancy between bench and multi-meter

Using the bench power supply did make me aware of one thing. The current readings were different across the two devices.

I had received delivery of some Wemos D1 modules, which other people had reported some success with. I wired up one of these and loaded on the same program (with temperature reading code completely removed).

According to my multi meter, it was using over 150mA, but wasn’t actually working (no message being sent via MQTT). This threw me completely!

In the spirit of clueless experimentation, I moved the input on the multi-meter from mA to 10A and, lo and behold, the current dropped and my MQTT subscriber started getting data. I got some help from @themainframe via Twitter and he told me this down to impedance and quite normal. I made a note to research this topic a little further.

Sending the temperature uses some power

The deep sleep also dropped the current being drawn to a level so low that it didn’t register on my bench supply. Result!!

Nothing being consumed in Deep Sleep

The next step was to re-enable the code and circuity that actually took the temperature reading. In my original design, I was feeding power to the probe from a 3.3v output on the ESP dev board. Following the circuits others designed, this time around I would power the circuit from the power supply directly.

Temperature probe connected to directly to power supply

This worked like a treat! Measuring the current, I could see the draw whilst it was measuring and transmitting the temperature was very low.

Really small power draw

The next step was moving from bench power to battery power. I recalled another blog post where the author had used a very large lithium ion battery to power his IoT device. I found the same battery and ordered a pair and also got some holders for them. It’s an 18650 type, which is 3.7v with a large 2000mAh capacity.

I also needed a way to drop from 3.7v to 3.3v. I had used a voltage regulator on my smart lamp project (blog post pending) so that seemed like what I wanted. I came across the MCP1700-3302E regulator, which seemed perfect. They seemed like they would deliver the 3.3v I needed from the 3.7v battery. They were also able to handle 250mA, which was more than enough for my setup.

Putting it all together and I had a working circuit!

Battery powered temperature with deep sleep (finally working!)

Next step was reducing this down to fit in the little box. I bought some veroboard and set to work.

Using some vero board to create a complete circuit.
I used pin holders rather than soldering the D1 directly to the board.
With battery and sensor attached
The board and battery back into the original box.

Leaving the unit over night and logging to the same Hass.io queue, I was delighted to discover when I came down in the morning that the device was still transmitting. It was interesting to see my kitchen falling to around 15 degrees.

The raw data being written
A smoother graph in Hass, which looks nicer!

With it all packaged up, the last step is to charge the LiPo battery fully before I “deploy” the device.

Once it’s been running for a week or so, I’ll have a much better idea of how reliable it is and then I will look at the next steps. I want to design a PCB for the sensor and get a better box to house it all. The software could also be improved, for example, only sending an updated temperature if it has actually changed. I would also like a way to dynamically alter the sleep period, for example, checking very 30 minutes between midnight and 5am.

It has been interesting to get back into some electronics. I forgot how much I really enjoy experimenting and learning with physical stuff, not just software!

Advertisements

Best laid plans, part 2

After my little boo-boo with measurements, I purchased a new Wiska junction box from RS, this time with a little more width and the Sonoff relay fit perfectly! I also picked up some IP66 glands to help secure the wire from the LED strip.

IMG_5011

This junction box had a membrane covering each hole, so I pierced a hole in it and fed the table through. The gland then screwed into the threaded hole (what makes these Wiska boxes so great).

IMG_5013

I tightened it all up.

Sadly, I didn’t take any pictures of my SWA cable gland process as I did it at lunch time. This was the tricky part of my installation since it required a hacksaw. I found a great YouTube (https://www.youtube.com/watch?v=epmxqFiD9JI)  video and followed that as best I could. I didn’t have the “glanding spanners” as recommended, but I made do with pliers. I do plan on using another armoured cable to connect to the other side of the garden, so I’ll take photos of that.

Anyway, with everything installed, I dropped the box in the garden.

IMG_5014

You can see the thick black SWA cable and the thin LED cable. I should point out that this is not the final resting place of this box!

IMG_5017

The lights look pretty nice in the snow and light the garden pretty well.

This weekend I plan on getting a few metres of SWA and using the small junction box to hook up the lights on the other side of the garden!