So how long would a simple configuration last running on batteries…
Only one way to find out.
The circuit is very basic. An ESP12 module on a carrier, the required pull up/down resistors, and a HTU21D humidity/temperature sensor. Power source is 2 alkaline C-cells. No regulator, just powered direct from the batteries.
The two C-cells measured about 3.15V to start and the ESP data sheet says it runs down to 2.5V. Data is read from the sensor every 3-min then posted by UDP packet to a local Influx-DB on a Raspberry-Pi. UDP because its fast and the occasional lost packet is not an issue for this function.
This is the 1st (nearly) 6-months.
The steps at 1,2,3 were because when the ESP wakes up from sleep and tries to connect, on these occasions the local WiFi was missing so instead of just going back to sleep, it kept trying to connect. This had a significant impact on the battery. I found it interesting that after the battery takes a bigger discharge-hit, it recovers somewhat in the time after. This can be over several days or a week or more.
4 was when i decided to tweak the software and fix the constant-retries issue but then I discovered that a breaking-change happened when I upgraded from ESP (arduino) 2.74 to 3.02.
Now WiFi defaults to WiFi OFF at the start of a sketch so every connect takes longer. Another battery-hit from that one! Till I found the fix to change behaviour back to the old-method of WiFi ON at startup.
The green spikes are WiFi connect time. These vary considerably. This is a closer view of number 4 above.
Some connect times (in the early days) are over 10-sec which is a terrible waste of battery power. This is now changed so if no connection by 2.5-sec, it just goes back to sleep. No more retries if it fails (1,2,3 above), it now just shuts-down and tries again later. 2.5-sec is probably still too high as the green spikes for connect times are about 1.2-sec. It looks like if its not connected by 1.5-sec then its not going to happen is a sensible timescale.
This is 24hrs at the head of the graph. Almost all of the connect times are 253ms. This is slightly longer after the V3.02 changes. 247ms was the V2.74 baseline. Sometimes a 1.2-sec connection but the vast majority are pretty fast. Some gaps due to missing packets which could be because its UDP (and not a great environment), or possibly >2.5-sec WiFi timeouts. The time is measured from when millis() starts counting (prior to the user sketch beginning) till just before the UDP post.
Now the constant-retries has been fixed, and the attempt-connect time reduced to 2.5-sec it seems believable that I might get a year from this set of batteries. Battery voltage is now down to 2.85V from the starting 3.15V.
The early discharge rate was quite steep due to a combination of software (constant retries) and the initial discharge behaviour of the batteries but this has flattened out now. The major step (1) in the first graph probably lost a month or more of runtime.
Apart from my dodgy software, its doing a lot better than I thought it would. Running a WiFi sensor from batteries had never seemed that practical to me but it looks like it is more realistic than I had initially thought. Maybe it will manage a year, maybe not. Time will tell.
12/Apr/2022
One year later and still going…
I’ve searched for days and days for this articles this good. Can you say how to modify your code in the previous post that presumably works on 2.74 please? It doesn’t look very easy to go back to 2.74 now I’m on 3.02.
Hi,
Sorry, my mistake for not actually detailing that step. It’s quite simple but took me some time to find it.
All you need to add to the sketch is the line:
enableWiFiAtBootTime();
I just added it as the first line in my setup(). This reverts the WiFi to be on by default at boot-time as it was back at 2.74
The details are at:
https://arduino-esp8266.readthedocs.io/en/stable/esp8266wifi/generic-class.html
Thanks. I see it’s clear in the code. I should have studied it first. Also I appreciate the prompt reply.
Actually, I only just added it after your comment so thanks for drawing my attention to it 🙂
Hi,
I made a esp + ds18b20 + liion + small solar panel to measure outside temperature, but i never manage to have a small enough power draw: the battery runs out in a couple of months. Yours is a very documented and well done project. Could you please post the code using the htu21d sensor? I upload the values on thingspeak which i assume takes a lot and time (and power) but i just want to try your code.
Hi Dan,
I will tidy it up and post it when time permits (within the next week I expect).
Its very likely that the unit directly posting to Thingspeak is your problem. The connection time (ie time your device is awake) can easily be 2~3 seconds.
A more battery-efficient way is to not post directly to the internet but to send the data to an intermediate device. An ESP01 or WeMos mini is fine for this. This device can be permanently powered and on the same network. It is this extra device that does the actual logging to Thingspeak. It does not matter if it takes many seconds as it is not on batteries.
The battery powered device should not be awake more than 300ms if it is set up correctly.
I set up my battery-powered unit to do a UDP post (because its very fast) to a collector unit (a wemos-mini) that receives the posts from multiple different sensors.
I have been happy with the results which were better than expected.
You have not mentioned your power-supply method.. How do you power your monitor from the battery? what type of regulator?
The power-supply method can also be a issue as a constant low level parasitic battery drain can end up using as much as the circuit itself.
This was the reason I ended up using 2 C-cells and no regulator. It acheived (so far) a year running time.
Lipo’s self discharge about 4~5% a month. Alkaline cells are ~2% a year.