Battery goes down WAY too fast on ESP

Moderators: grovkillen, Stuntteam, TD-er

Message
Author
izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Battery goes down WAY too fast on ESP

#1 Post by izeman » 24 Nov 2019, 12:28

I'm a bit helpless. I now try for some time to run an ESP-12 and/or Wemos on battery for a pool thermometer. I want it to run over the whole season ideally. It's powered by a 3000mAh 18650 lico cells. Then an MCP1700 to output 3.3V for the ESP.
A voltage divider of 100k & 300k is used to connect battery raw voltage to A0.
A DS18B20 is connected to D1 (with the required 4.7k resistor over VCC/D1).

I have a high quality DMM to measure current, and I can confirm that I see around 80mA when the ESP is booting and running and around 80uA when in deep sleep. I know this is more then what can be expected, but i guess that's because of the voltage divider.

It's set to wake up every 10min. With ESPEASY it takes very long to obtain an IP, send the measurement to MQTT and power down again. So it's about 5s, that's around 30s every hour. And it will be consuming 0.08mA for 3600s (-30s).
So it consumes 30x80 + 3600x0.08 mA = 2688mAs or 0.747mAh. Correct? That would mean it could run 167days or around half a year.

But reality proves me wrong. This is the graph for 24h. It loses 50mV PER DAY. So it would deplete within 4.20-3.00 = 1.20/0.05 = 24days, assuming linear depletion, which will not happen. This is for the ESP-12. Wemos of course is much worse with FTDI and DC regulator still connected.

Image

User avatar
grovkillen
Core team member
Posts: 3332
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: Battery goes down WAY too fast on ESP

#2 Post by grovkillen » 24 Nov 2019, 12:56

Outside temperature will also be a factor.
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#3 Post by izeman » 24 Nov 2019, 12:58

grovkillen wrote:
24 Nov 2019, 12:56
Outside temperature will also be a factor.
Thanks. Sure. But it's INSIDE for testing. So 22°C. I'm still building/testing it.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#4 Post by TD-er » 24 Nov 2019, 13:32

What is the discharge curve of these batteries?
Most batteries have quite a significant voltage drop in the first 10 - 20% of the discharge and also at the last 10 - 20%.

About speeding up the DHCP, you could try to use a fixed IP address.
I will later store the BSSID and last used channel in the RTC memory, which will also speed-up connection time by roughly 2 seconds. (if unchanged)

What is the quiescent current of the MCP1700 + all capacitors and sensors (so without the ESP) ?
Maybe you can switch the connected sensors power line using a FET and make sure one pin is set to high immediately after boot to activate the sensors.

I just assume your average voltage from the 18650 is 3.7V, although it may get there already at 50% of the discharge.
According to the datasheet it needs at least 178 mV as voltage drop, so at 3.3 + 0.178 = 3.478 V you may no longer be able to boot the ESP (possibly before that), which may be long before the cell is considered fully discharged.
Which is probably a good thing, to protect the cell, but I cannot tell what the ESP will do when it crashes due to brownout. (may continue to try booting?)

Total resistance over the voltage divider (assuming there is no resistor in the ESP itself over the analog input) is 400k.
Assuming 4V battery, that's 10 uA constant current.
That's quite a bit compared to the rest of the circuit, but the most you can gain here is about 12% less current.


Another thing to keep in mind with 18650 cells.
Some of them (quite a lot actually) should be considered "Chinese mAh" or "exaggerated" or whatever term you want to put to it.
So apart from the fact you cannot use it all, you also should take into account the true capacity is quite a bit less due to "marketing blah" and temperature.
My estimate would be roughly 40 - 50 days, based on the numbers you just gave.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#5 Post by izeman » 24 Nov 2019, 14:00

@TD-er I was hoping for you to chime in, as I read some posts from you on this topic already.
Unfortunately most (if not all) you wrote is already considered by me. Could you maybe try to confirm my calculation? Maybe I did it wrong and my 70uA deep sleep and 70mA add up to the current there is.

To answer some of your questions/regards: The batteries are genuine ones and not chinese stuff bought from nkon.nl. I know that discharge voltage is not linear, and is faster when fully charged. The situation we see here is at 3.8V which is quite close to nominal voltage a 3.65V so it should be stable.

Regarding the quiescient current of the MCP (which is a chinese one) it should be some uA only. But as i MEASURED the "real" current, this includes EVERYTHING. From dc/dc to resistor of the DS18B20, the voltage divider (EDIT: as i write that: Actually THIS is not included) and the ESP itself. But as you wrote the voltage divider should only have 10uA influence. This would no remove much from the runtime.

Regarding the minimum input voltage of the MCP. Yes, this is an issue. You have to stop discharge at 3.5V. I haven't checked what happens below 3.5V, but I'd get a warning from my home automation system anyhow and can react. But this is another topic.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#6 Post by TD-er » 24 Nov 2019, 15:14

izeman wrote:
24 Nov 2019, 12:28
[...]
It's set to wake up every 10min. With ESPEASY it takes very long to obtain an IP, send the measurement to MQTT and power down again. So it's about 5s, that's around 30s every hour. And it will be consuming 0.08mA for 3600s (-30s).
So it consumes 30x80 + 3600x0.08 mA = 2688mAs or 0.747mAh. Correct? That would mean it could run 167days or around half a year.
[...]
Let's work out the average current over the period of an hour.
That's (30 * 80 + (3600 - 30) * 0.08) / 3600 = 2685.6 / 3600 = 0.746 mA on average.
So it is indeed 0.746 mAh over the period of one hour.

Let's assume you can actually use 50% of battery capacity, then you only have 1500 mAh to consume, which is roughly 2000 hours (~80 days)

First question: Is your assumption correct that the ESP is on for 5 seconds on average?
Second: Is your assumption correct that the average "on" current is 80 mA?

With these assumptions (30 sec on time per hour @80 mA), you're using 10x as much as during sleep.
So I would first focus on the "on time".

I think the 80 mA estimate is quite a good one, as I also see about 70 mA when the ESP is connected.
You could enable "eco" mode, which does drop the current to roughly 30 - 50 mA, but that happens only after a while and then you're already back to sleep.

I think your setup would benefit the most from no longer having to wait for DHCP and being able to reconnect to the last known BSSID/channel.
Still, it could be the "on time" will not be shortened by the amount of time needed to connect to WiFi, as the sensors need to be read and the data to be sent.

Maybe you can also have a look at the capacitors used over the 3v3 line, to help the voltage regulator, since it is only capable of 250 mA.
When performing RF calibration, the ESP does draw a lot more current, so maybe it is actually crashing and rebooting a few times?
Adding more (or larger) capacitors may also not be the solution here, since charging empty capacitors is almost like a short circuit.
Do you have some tools to measure the actual power consumption in mAh?
For example some of those USB meters?
Something like this one: https://www.aliexpress.com/item/3296830 ... 373cYbynE2

Too bad the high resolution one (the TC66 I linked) only has an USB C connector on the output, which makes it hard to connect.
The older one (UM25) has more usable connectors, but less resolution (10 uA vs. 100 uA resolution)
But both should be able to give proper readings around the 80 mA range.

FanOfHue
Normal user
Posts: 73
Joined: 06 Oct 2018, 10:08

Re: Battery goes down WAY too fast on ESP

#7 Post by FanOfHue » 24 Nov 2019, 15:46

It would be nice to see more project samples along with true battery life charts, so we could learn which way is best for battery operated sensor devices. I'm working on this LSC doorsensor mod that now is turned into a temperature//humidity sensor:
DoorSensorMod.png
DoorSensorMod.png (296.62 KiB) Viewed 1625 times
I only have data for the last month, so i don't know the actual long term battery life for this mod
DoorSensorModBatteryLife.png
DoorSensorModBatteryLife.png (87.39 KiB) Viewed 1625 times
But i could try to estimate, based on following calculations:

The sensor works until battery voltage has dropped down to 2.3 Volts.
Taking a 100 mV decline in the charts, from 3.0 to 2.9, took 16 days.
Working range for the sensor: 3100 - 2300 = 800 mVolts
So in theory, it may come down to 8 * 16 days = 128 days, considering a linear decline from here onwards
That would be quite ok i guess.

The sensor uses AAA batteries with a much lower capacity than your 18650 cell, likely around 850 mAH.
It uses an SI7021 for fast temperature measurements and ESPNOW as protocol. (the SI7021 sensor is not connected in this picture)
Updates every 10 minutes, so 144 measurements per day.
Current idle current is 40 uA.
Working on an update with different settings for the ATTiny and it will be reduced to 20 uA.
The ESP and SI7021 are only powered during measurements.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#8 Post by TD-er » 24 Nov 2019, 15:54

ESPNOW as protocol
There's your biggest change.
That saves a lot of time.
Roughly 2.7 sec connection time down to ~500 msec ?
Not sure if you also perform the RF calibration (can be seen in power consumption).
If you don't take WiFi startup time, the connection time of ESPNOW is roughly 200 msec.
Also it doesn't need DHCP delays, which may also take up-to 3 seconds in worst-case scenarios (I have ~50 msec here, since I am using 100 msec delay after WiFI connect event)

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#9 Post by izeman » 24 Nov 2019, 19:45

TD-er wrote:
24 Nov 2019, 15:14
First question: Is your assumption correct that the ESP is on for 5 seconds on average?
TBH 5s is the max. I had a self written code running that could boot, measure, send out MQTT and go back to sleep in UNDER ONE second.
Second: Is your assumption correct that the average "on" current is 80 mA?
At least this is what my DMM says. Of course there is a short millisecond long peak when booting, but for 99% of the time it's using 80mA
With these assumptions (30 sec on time per hour @80 mA), you're using 10x as much as during sleep.
Actually it's even 1000 times more.
I think your setup would benefit the most from no longer having to wait for DHCP and being able to reconnect to the last known BSSID/channel. Still, it could be the "on time" will not be shortened by the amount of time needed to connect to WiFi, as the sensors need to be read and the data to be sent.
As written above. I have a code which is online for less than a second. It doesn't help either. Voltage goes down a little slower, but still way to fast (and about 10x as fast as it should)
Maybe you can also have a look at the capacitors used over the 3v3 line, to help the voltage regulator, since it is only capable of 250 mA.
When performing RF calibration, the ESP does draw a lot more current, so maybe it is actually crashing and rebooting a few times?
Adding more (or larger) capacitors may also not be the solution here, since charging empty capacitors is almost like a short circuit.
Do you have some tools to measure the actual power consumption in mAh?
For example some of those USB meters?
Something like this one: https://www.aliexpress.com/item/3296830 ... 373cYbynE2

Too bad the high resolution one (the TC66 I linked) only has an USB C connector on the output, which makes it hard to connect.
The older one (UM25) has more usable connectors, but less resolution (10 uA vs. 100 uA resolution)
But both should be able to give proper readings around the 80 mA range.
It just doesn't make any sense to me. There must be something going on when i just don't watch ;)

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#10 Post by izeman » 24 Nov 2019, 19:48

FanOfHue wrote:
24 Nov 2019, 15:46
It would be nice to see more project samples along with true battery life charts, so we could learn which way is best for battery operated sensor devices. I'm working on this LSC doorsensor mod that now is turned into a temperature//humidity sensor
AFAIK this device is a much more advanced approach where the whole CPU and surroundings are completely turned off. It's not even using deep sleep. It's just off and woke up externally. This would need some extra hardware for the ESP-12.
And I totally agree: Everyone claims "let your ESP run on batteries for years", but i haven't seen any long time graphs where they show the prove.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#11 Post by TD-er » 24 Nov 2019, 21:12

Actually it's even 1000 times more.
But the "deep sleep time" is also 100x as long as the awake time.
What I meant was, from the total power consumption, the mAh's consumed during sleep is 1/10th of the consumption while awake.
Meaning, 90% of the energy is consumed when awake, so there's where we should look first.

Just wondering, how do you measure the current?
Do you have something to use for the current measurement?
You cannot use the shunt in your DMM to measure the uA currents. Anything below 1 mA should be considered highly inaccurate, unless you don't have a regular DMM.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#12 Post by izeman » 24 Nov 2019, 21:31

Ok. Got you. And you're correct. Power consumed by online mode is 10x higher than in deep sleep over time.
I assume that a DMM that has a mode for A, mA and uA is capable of measuring exactly that. To be more precise it's also a simple oscilloscope. 8-)

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#13 Post by TD-er » 24 Nov 2019, 23:02

izeman wrote:
24 Nov 2019, 21:31
I assume that a DMM that has a mode for A, mA and uA is capable of measuring exactly that. To be more precise it's also a simple oscilloscope. 8-)
Nope.
Search for "burden voltage"
The usual Youtube channels have some proper explanation of this and why you need some "micro current" device to accurately measure low currents.
Such a device is a shunt with a low noise amplifier which does turn the very low voltage drop over the shunt into a high voltage.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#14 Post by izeman » 25 Nov 2019, 13:01

I got an old Voltcraft VC-1008 for uA measurement. And it says it can measure uA with accuracy of +/-1% +8 digits. Not mentioning any special mode of measurement. So would assume it can measure that current out of the box.
So i watched that video, which explains the issues https://www.youtube.com/watch?v=fRP98k3Rh1E
But still i don't see how the burden voltage would influence my measurements. I measure the current going from the battery to the circuit into a linear voltage regulator. But that's it. Even if the input voltage of the ESP drops a bit it would still work?!?!
Could you tell me what the real issue would be?

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#15 Post by TD-er » 25 Nov 2019, 17:47

The burden voltage does cause a (significant) drop when the current increases.
So it is very well possible the sensors you think were active, were actually not because the voltage dropped below the operating voltage.
Since it is a linear voltage regulator, I guess you could increase the voltage using a power supply instead of the 18650 cell and set it to something like 5V.
Then you need a voltage drop of over 1V to get in the range where your input voltage may drop below the minimum of the voltage regulator.

chemmex
Normal user
Posts: 5
Joined: 15 Feb 2019, 16:18

Re: Battery goes down WAY too fast on ESP

#16 Post by chemmex » 26 Nov 2019, 01:27

Based on your discharge graph, you are in the upper part of the discharge curve which is very nonlinear. So 50mV drop in this region is basically nothing to worry about, you may then experience weeks at 3.7V without a sign of depletion.
In fact, voltage is not a good indicator unless you personally trained your battery 100 times and know each point on the discharge curve. A coulomb counter is a right thing for measuring battery SoC and capacity, but it's completely different story.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#17 Post by TD-er » 26 Nov 2019, 10:22

Found this site when looking for 18650 discharge curves: http://centralmesg.com/brc18650/tested18650.html

The author does mention a surprising correlation, which he verified.
The weight per actual mAh seems to be quite constant.
This article dates back to 2016, so forged batteries may now have a heavier shell, but maybe worth a try.

You also need to take into account that these kind of batteries often show some increase in actual capacity after the first few charge/discharge cycles (first 3 - 5 cycles)

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#18 Post by izeman » 26 Nov 2019, 16:52

Thanks for your thoughts about the batteries, but we can skip that. I'm all in Lithium cells for years now, and use them everywhere, from several bikes, to torches, power banks and power walls. The cells used are genuine ones, and i also wrote that i'm totally aware that voltage decrease is not linear (or parallel) to SOC (or remaining capacity).

Unfortunately, this is the graph 2 days (52h) later:

Image

You'll notice a daily decline in the range of 60mV. And yes, even though the math is not 100% correct, and i can not run the batteries from 4.2->3.0 (i need to stay above 3.5V to stay above the input treshold of the MCP1700 for 3.3) then it's 700mV or 10 days at a decline of 60mV/day. That's A LIGHTYEAR away from the "run your ESP on batteries for years" :|

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#19 Post by izeman » 26 Nov 2019, 17:02

TD-er wrote:
25 Nov 2019, 17:47
The burden voltage does cause a (significant) drop when the current increases.
So it is very well possible the sensors you think were active, were actually not because the voltage dropped below the operating voltage.
Since it is a linear voltage regulator, I guess you could increase the voltage using a power supply instead of the 18650 cell and set it to something like 5V.
Then you need a voltage drop of over 1V to get in the range where your input voltage may drop below the minimum of the voltage regulator.
Ok. So yes, we have a voltage drop caused by the burden voltage, and the way the DMM measures current. Accepted. ;) BUT: It's also true that the voltage drop raises with raising current. And current is as small as 80uA. That MAY lower the output voltage of the MCP1700 enough to make the ESP crash. True. But: This phanomenum only takes places during measurement, and a) does the ESP boot with even 3V w/o issues, and b) it does wake up correctly after deep sleep, runs it's code and goes to sleep again.
The graph i posted it WITHOUT the meter connected. So there is no burden voltage or such to be considered.
What possible error sources do remain?
.) The DMM measures sh*t (but an error factor of 10x??)
.) I still have some calculation error in it
.) The ESP does some sh*t when i don't look at it? So maybe it works fine once, but then doesn't really sleep after the 3rd reboot, 5th reboot ....
Any other ideas?

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#20 Post by TD-er » 26 Nov 2019, 17:10

izeman wrote:
26 Nov 2019, 16:52
[...]
That's A LIGHTYEAR away from the "run your ESP on batteries for years" :|
That's far!

Well, if we can assume the cells are OK, then the setup does take roughly 300 mAh per day (based on 10 days and 3000 mAh)

To quote myself:
Let's work out the average current over the period of an hour.
That's (30 * 80 + (3600 - 30) * 0.08) / 3600 = 2685.6 / 3600 = 0.746 mA on average.
So it is indeed 0.746 mAh over the period of one hour.
According to those calculations, you should see 17.9 mAh per 24h, but you're seeing roughly 17x as much.
Even if we take into account we cannot use all of the battery, then there is still a factor 10 unaccounted for.

Let's see if the curve will become more flat.
And I do believe you should get one of those USB loggers to see if the power consumption is maybe higher.
For really low currents, you may want to add a known resistor parallel to the consumer to make sure the logger is not "blind" around 0 amps.

You can also do the same for this test. Just add a resistor to the load and check if your discharge curve is changing accordingly. That will give you an estimate on the unknown power usage.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#21 Post by TD-er » 26 Nov 2019, 17:13

About the other ideas.
Maybe one of the sensors is not behaving well and keeps on running after a number of deep sleep cycles?

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#22 Post by izeman » 26 Nov 2019, 17:17

About the other ideas. Maybe one of the sensors is not behaving well and keeps on running after a number of deep sleep cycles?
Thought that myself. I got some weird readings on the sensor (which is a cheap chinese one), hopping around by 0.5°C from reading to reading. So I ordered some genuine DS18B20 and MCP1700 as well to rule out that source of error.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#23 Post by izeman » 26 Nov 2019, 17:30

FYI, and for better readability here's a graph from Graphana for the last 52 hours:

Image

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#24 Post by izeman » 26 Nov 2019, 19:07

Took the sensor off now, totally disconnected. We'll see if this is the culprit. Wait for tomorrow and check voltage then. Cross your fingers!!

obod0002c
Normal user
Posts: 31
Joined: 10 Aug 2019, 20:31

Re: Battery goes down WAY too fast on ESP

#25 Post by obod0002c » 26 Nov 2019, 21:02

after some months of using different ESP's my personal favorite is LiFePO4: easy to handle, quite safe, long lasting, no buck or boost needed. If it's feasible to post back low voltage not even an underprotection circuit is needed.
One of the outdoor ESP-12's has been running since mid June, currently at around 2.9V with an update interval of every five minutes for BME280 sensor's data.

Important: high stability of your WiFi, no downtimes or bad signal. Everything can be uploaded to elsewhere within less a second or less than five to 10 seconds. As WiFi is consuming THE energy this is the key factor.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#26 Post by izeman » 26 Nov 2019, 22:12

Thanks. I'd prefer LiFePo4 also, but they come in low capacity only. Best cells i could find are 1.600mAh. That makes 3.200mAh for two of them. I could get rid of the MCP1700 and could directly monitor the input voltage instead of using the voltage divider. Would simplify things a lot. I'll definetly consider that.
Would you mind sharing your code? As said: I now have ESPeasy running on this board, but also got my own written code, which boots, connects to Wifi, sends to MQTT and goes to sleep in well under a second. If it can't connect to Wifi right away it doesn't try forever. Same goes with MQTT. It's more or less a fire&forget thing. If you want i can post that code as well, but as this is an ESPeasy forum i'd refrain from it.
EDIT: Found some 32600/700 cells now which claim 6000-7000mAh. If they are really legit they could be a perfect fit. Quite pricey as well. Costs are around 20€+ shipping included.
Last edited by izeman on 27 Nov 2019, 10:41, edited 1 time in total.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#27 Post by TD-er » 26 Nov 2019, 22:34

Well, if we can learn from it to improve ESPEasy...

I do plan to store the BSSID/channel in RTC, to speed up wifi reconnect after deep sleep.
Is that also what you're doing?

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#28 Post by izeman » 27 Nov 2019, 10:45

This is the code. I'm using static IP address, which is much faster than waiting for DHCP from my Unifi. Shamelessy stolen from all over the internet. It's a mess for sure as I'm no programmer, but it works fine here as far as i can judge. Goes to sleep fine if it can't find WIFI, and also if it can't connect to MQTT, then wakes up again after 10min and goes through the code.

Code: Select all

#include <ESP8266WiFi.h>
#include <PubSubClient.h>

#include <OneWire.h>
#include <DallasTemperature.h>

#include "config.h"
#define ONE_WIRE_BUS D1

WiFiClient wifiClient;
PubSubClient client(wifiClient);

// Create a OneWire instance
OneWire oneWire(ONE_WIRE_BUS);

DallasTemperature sensors(&oneWire);

const int analogInPin = A0;
int sensorValue = 0;
float outputValue = 0;

int connect() {
  int result = 0;
  int counter = 0;

  Serial.print("Connecting to ");
  Serial.println(WIFI_SSID);

  /* Set to station mode and connect to network */
  WiFi.mode(WIFI_STA);
  WiFi.config(IPAddress(192, 168, 1, 75), IPAddress(192, 168, 1, 0), IPAddress(255, 255, 255, 0));
  WiFi.begin(WIFI_SSID, WIFI_PASSWD);

  /* Wait for connection */
  while ((WiFi.status() != WL_CONNECTED) && (counter < RETRY_COUNT)) {
    counter++;
    Serial.print(".");
    delay(300);
  }
  Serial.println("");

  /* Check if we obtained an IP address */
  if (WiFi.status() != WL_CONNECTED) {
    Serial.println("Failed to connect. Sleeping!");
    result = 0;
  } else {
    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());
    result = 1;
  }
  return result;
}
void setup() {

  int result = 0;
  int counter = 0;

  Serial.begin(115200);

  /* Start Dallas library */
  sensors.begin();
  sensors.setResolution(11);
  Serial.println("");
  Serial.println("ESP-01 Temperature Sensor (MQTT)");
  Serial.println("");

  /* Get ChipID and convert to char array */
  char strChipID[33];
  itoa(ESP.getChipId(), strChipID, 10);

  /* Concatenate to form MQTT topic */
  String strTopic = MQTT_TOPIC_PREFIX;
  strTopic = strTopic + "ESP" + strChipID;

  /* Attempt to connect to WiFi */
  result = connect();

  //  if (result == 1) {
  {
    /* Read Analog Pin A0 */

    sensorValue = analogRead(analogInPin);
    outputValue = map(sensorValue, 0, 1024, 0, 4117); // calibrated
    outputValue = outputValue / 1000;

    char Voltage[7];
    dtostrf(outputValue, 6, 2, Voltage);
    char Sensor[7];
    dtostrf(sensorValue, 6, 0, Sensor);

    sensors.requestTemperatures();
    float fTempC = sensors.getTempCByIndex(0);
    fTempC = fTempC + 1.5; // Sensorkorrektur

    if (fTempC != DEVICE_DISCONNECTED_C) {
      /* Valid reading */
      char strTempC[7];
      dtostrf(fTempC, 6, 2, strTempC);

      /* Connect to MQTT broker */
      client.setServer(MQTT_SERVER, MQTT_PORT);

      if (client.connect(strChipID, MQTT_USER, MQTT_PASSWD))
      {
        Serial.print("Publishing ... ");
        Serial.print("Temperature: ");
        Serial.println(strTempC);
        client.publish("Wifi.Poolthermometer/Temp", strTempC);
        client.publish("Wifi.Poolthermometer/Volt", Voltage);
        client.publish("Wifi.Poolthermometer/Sensor", Sensor);
      }
      else {
        Serial.println("Error connecting to MQTT broker");
      }
      client.disconnect();
    }
  }
  wifiClient.stop();
  Serial.println("Time to sleep!");
  Serial.print("Uptime:  ");
  long uptime = millis();
  Serial.println(uptime);
  ESP.deepSleep(DEVICE_SLEEP * 60 * 1000000);
  delay(100);
}
void loop() {
}

FanOfHue
Normal user
Posts: 73
Joined: 06 Oct 2018, 10:08

Re: Battery goes down WAY too fast on ESP

#29 Post by FanOfHue » 27 Nov 2019, 20:54

izeman wrote:
26 Nov 2019, 22:12
but also got my own written code, which boots, connects to Wifi, sends to MQTT and goes to sleep in well under a second.
I'm so jealous! Can't get anything done in less then three seconds, unless using ESPNOW.
I have to use an ESPNOW gateway, which adds another single point of failure in the loop.

This must be dependent on brand/type of Wifi Access Point ??
Currently using a TPLINK EAP225 because i must have VLAN and multiple SSID support for security reasons.

I've read somewhere that using WEP connects much faster than WPA2, but who dares to use WEP nowadays? Or use an open wifi?

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#30 Post by izeman » 27 Nov 2019, 21:23

Hmmm. Maybe my calculations are wrong. This is how i do it: I open "serial console" in Arduino IDE and check "show time" or whatever that's called. And it shows timecode in milliseconds. And the time from boot until it shows "going to sleep" is around 600ms.
Did you check my code and see how long it takes?

obod0002c
Normal user
Posts: 31
Joined: 10 Aug 2019, 20:31

Re: Battery goes down WAY too fast on ESP

#31 Post by obod0002c » 27 Nov 2019, 23:26

Forgot to mention capacity of LiFePO4, sorry:
the capacity of the 18650 I talked of for my outdoor sensor is 1.6Ah for an incredible price of less than 2€.
The one for my rain sensor is a 26650, capacity 3.3Ah for 5.50€
I checked capacity and trust it.

Bargains, I know. Shop sold it because capacity was differing a bit so they couldn't sell it to build battery packs.
Hey, I only need one at a time.

The rain sensor has a micro solar cell (only a little bit bigger than the cell itself) and a little bit of electronics attached - looks like I'll never have to recharge that one (it will become necessary, I know).

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#32 Post by TD-er » 27 Nov 2019, 23:37

When connecting using BSSID and last known channel, you can get WiFi connection in 700 - 900 msec. With a proper router, you can get DHCP in 25 - 100 msec, but with static IP you can also skip that.
Boot until you can activate WiFi takes roughly 400 msec.

If you leave persistent WiFi on, then it can be a lot faster, but your flash will wear out a lot faster too.

obod0002c
Normal user
Posts: 31
Joined: 10 Aug 2019, 20:31

Re: Battery goes down WAY too fast on ESP

#33 Post by obod0002c » 28 Nov 2019, 00:02

TD-er wrote:
26 Nov 2019, 22:34
Is that also what you're doing?
Before I started to use ESPEasy I had to learn that omnipresent hints don't work all the time:
do not use DHCP, assign a fix IP address, switch off this and that, somehow make sure you get to the lowest possible level to set almost the final bit ... for my router / network this took more than four times the time compared to using simple DHCP for the ESP's and instruct my router to assign a fix IP address for a given MAC.
I re-checked that over and over again. Hmm, no fault in my test setup nor in time measurement (might be grounded in AVM's FritzBox I'm using).

There's more time to save while connecting to the WiFi if you can avoid automated channel shifts. I considered this a valuable feature but as one of my old image for an Raspberry doesn't support it I had to deactivate it in my router ... ooops again some time saved in ESP reconnect.

If helpful I can provide you with that section of the source code but it's really that straight forward. And it might be everything but the best for other hardware combinations.

If it doesn't matter if one value gets lost: store one in RTC and upload it with the next value to come. Instantly almost 50% of WiFi time saved (btw: somewhere here in the forum I asked for the possibility to store data in RTC. Nothing urgent but could help in this regard as well).

Currently I'm using ESPEasy mainly for irrigation systems. As the pumps need the mains also those ESP's are mains-operated.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#34 Post by izeman » 28 Nov 2019, 20:03

I now connected an 18650 cell charged to 3.6V DIRECTLY to the ESP. That way I can rule out the MCP1700 as problem. We will see tomorrom morning how good that works. In the meantime I ordered some Liitokala 32700 LiFePo4 cell with 6500mAh (Lii-70A - the B-type are LiIon cells). They are really cheap when ordered from China and seem to be decent quality. I normally don't trust Aliexpress/ebay on batteries, but risking 7€ for two cells delivered to my door is ok. Then I can make a full charge/discharge and see how it goes. And i can completely skip the MCP as the cell goes from 3.65V fully charged. And you can setup an alarm when the battery is at 2.5V and stop sending voltages and let it go to deep sleep for a long time straight away. That way you won't get any measurements, but you will have enough time to recharge it.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#35 Post by izeman » 29 Nov 2019, 16:30

Bad news. The battery was drained quite quick with the directly attached battery @3.65V, It went down to 3.5V pretty fast. I now disconnected the voltage divider which I see as last source of drain. Hopefully i can start building my uV-meter soon to log the power used more precisely over a longer time to get some insight.
Could the ESP modules themselves be the problem? Some junk components that make it act that way?

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#36 Post by izeman » 29 Nov 2019, 16:48

Good news. With the voltage divider (for battery voltage measurement to A0) detached there was NO voltage drop for 10h. It was 3.5V in the morning, and is still now in the evening. I will test this some more time and let you know.
EDIT: I think i have to revise that again. Voltage has gone down around 0.1V overnight. I'm not sure where this came from, maybe from too much experimenting with too much on-time?!

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#37 Post by izeman » 01 Dec 2019, 17:52

I'm still investigating, and I'm a bit lost now to be honest. I removed EVERYTHING that potentially could cause issues. I removed the voltage divider for A0, i removed the MCP linear regulator, I replaced the temperature sensor with a genuine one.
Now I uploaded "my" code again which measures VCC (lipo is charged to 3.6V only to not destroy the ESP when directly connected). The code is really quick and goes to sleep within a second:

Code: Select all

17:29:22.239 -> Connecting to WIFI
17:29:22.239 -> .
17:29:22.538 -> 
17:29:22.538 -> WiFi connected
17:29:22.538 -> IP address: 
17:29:22.538 -> 192.168.1.75
17:29:22.903 -> Publishing ... Temperature:  27.75
17:29:22.903 -> Voltage:   3.52
17:29:22.938 -> Time to sleep!
17:29:22.938 -> Uptime:  821
300ms to connect to Wifi, 350ms for reading the temperature sensor, and 30ms more to publish it to MQTT. And 800ms after boot it's gone to sleep again.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#38 Post by TD-er » 01 Dec 2019, 21:51

Are you absolutely sure the unit is connected? Does the data actually reach the MQTT broker?
I looked at your code and for example RETRY_COUNT is nowhere to be found in the code. (except once for the test)

The same for DEVICE_SLEEP.

You you now have an energy logger to see what the actual consumption is of the ESP?

Oh and by the way, this sketch is fine for testing now, but if you run it for long, you will destroy your flash.
You need to have WiFi.persistent(false); at the start of the setup() call.
But this will add about 700 - 900 msec to the awake time :(

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#39 Post by izeman » 02 Dec 2019, 09:54

You're absolutely correct. I'm NOT sure it's connected, and it sometimes isn't. And it's not really important. I don't mind if I skip a measurement or two. Let it run, and if all goes through, then that's fine, if not, go to sleep.
Good thing now seems to be, that i've a DMM inline with the battery to monitor current. It shows 80mA during a few seconds every 10min and then 25uA when asleep. This test is running for 12h now. And I see ZERO voltage drop. Battery was at 3.640 yesterday evening, and it's 3.640 this morning. At least this is good progress :)

Regarding RETRY_COUNT: There is a seperate config.h which has those variables defined. I didn't post it, as it got user,pwd included, and no really helpful information beside that.

Code: Select all

#define DEVICE_SLEEP      10
#define RETRY_COUNT       15
If you say I have to add WiFi.persistent(false); to the code, then this would mean that the ESP doesn't save the IP address and stuff and has to gether that every reboot? Wish there was a workaround for that.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#40 Post by TD-er » 02 Dec 2019, 11:21

izeman wrote:
02 Dec 2019, 09:54
[...]

If you say I have to add WiFi.persistent(false); to the code, then this would mean that the ESP doesn't save the IP address and stuff and has to gether that every reboot? Wish there was a workaround for that.
About the missing defines. It was just to make sure they were actually defined and not via some included library set to some unknown value (like 0).

WiFi.persistent(false); does indeed make it slower.
Good news is that I worked on adding the last used channel + BSSID to RTC, so it will save roughly 2 seconds of the connection time after a warm boot (deepsleep = warm boot)
This is still roughly 900 msec slower than your current implementation.
On the other hand, if you do not use it, the flash sector used by the core library to store the same info will be rewritten at every boot and thus wear out in months (depending on the boot interval).
After that you will not be able to use that module anymore, or at least that flash chip.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#41 Post by izeman » 02 Dec 2019, 19:36

DAMN, And I thougt i found the holy grail and thought everyone else was just too stupid to do it right.
No I'm also in the 5s range:

Code: Select all

19:34:34.816 -> Connecting to Wifi
19:34:34.816 -> .......
19:34:39.035 -> 
19:34:39.035 -> WiFi connected
19:34:39.035 -> IP address: 
19:34:39.035 -> 192.168.1.75
19:34:39.400 -> Publishing ... Temperature:  23.50
19:34:39.400 -> Voltage:   3.38
19:34:39.500 -> Time to sleep! Uptime:  4816
I may need look into RTC as well 8-)

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#42 Post by izeman » 02 Dec 2019, 20:26

@TD-er: I got another question: Do you have an idea how to find out if the ESP sent a message to the MQTT server (mosquitto in my case). It seems home assistant does not update the time it got new information from mqtt in case the value is unchanged. Now with a value of 3.64V over the whole day it seems to not have received info for hours.
Looking at the temperature though reveals that it did get info as it changes regularly.
I'd just like to know then the last update happened to know if results come in really every 10min and none is lost.

TD-er
Core team member
Posts: 1946
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Battery goes down WAY too fast on ESP

#43 Post by TD-er » 02 Dec 2019, 21:01

See: https://github.com/letscontrolit/ESPEasy/pull/2792 for RTC stuff and improved MQTT

happytm
Normal user
Posts: 74
Joined: 15 Aug 2016, 17:53

Re: Battery goes down WAY too fast on ESP

#44 Post by happytm » 03 Dec 2019, 02:49

@izeman

If you open to trying something else I have solution for you.

Please look at the code at:

https://github.com/happytm/BatteryNode

Thanks.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#45 Post by izeman » 03 Dec 2019, 09:29

happytm wrote:
03 Dec 2019, 02:49
If you open to trying something else I have solution for you.
F*CK. I was sure there was something more to look into :lol:
I thought that i could close that issue, now that i have a working version, and sooooo close before mission accomplished you post this. HAHA. Thank you. I'll check it out for sure!

waspie
Normal user
Posts: 117
Joined: 09 Feb 2017, 19:35

Re: Battery goes down WAY too fast on ESP

#46 Post by waspie » 03 Dec 2019, 17:40

I don't want to detract from ESPEasy. I'm a *huge* fan.
But, for battery powered sensors, I went over to mysensors. It requires some new hardware but temperature sensors running for years on a button cell is a reality with that.
It also solved my need for motion/pir sensors. PIR sensors connected to an esp is a widely known problem with false triggers and this isn't an issue with mysensors/nrf24/atmega328

It might be something worth considering, and again, nothing wrong with ESPEasy.

happytm
Normal user
Posts: 74
Joined: 15 Aug 2016, 17:53

Re: Battery goes down WAY too fast on ESP

#47 Post by happytm » 03 Dec 2019, 18:14

@izeman

You can probably keep ESPEasy on receiving side by adding ProbeRecceiver code to ESPEasy firmware and use ProbeSender code on pool thermometer sensor. Although following videos are old but it explain the concept well.

https://www.youtube.com/watch?v=0K9q4IuB_oA&t=9s
https://www.youtube.com/watch?v=7ZcnPoZn_O0

Thanks.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#48 Post by izeman » 03 Dec 2019, 19:09

waspie wrote:
03 Dec 2019, 17:40
But, for battery powered sensors, I went over to mysensors. It requires some new hardware but temperature sensors running for years on a button cell is a reality with that.
Thanks man. I got all that stuff already. I have a mysensor gateway, i got a handful of nrf24l with and without seperate antenna, and a lot of other stuff. I never got really warm with it. And it adds another level of complexity to my system.
I got a myriad of different sensors: Wifi, 433, 868, mysensor, zigbee, infrared ... A LOT of different stuff. And I tried to bring that down to two main technologies: Wifi and Zigbee. Unfortunately they are not too happy together, as they both work on 2.4GHz. Some kind of 433Mhz receiver is still in place as it reads some old temperature sensor and remote control.
I got a small house with 200m2 on 3 floors (or 4 if you add the basement) and 3 Ubiquity APs to cover everything, and still it's hard to have a good Wifi coverage everywhere. Zigbee is even worse. 4 repeaters and still a lot of places I just can't reach.
Ok. I got a bit offtopic now, but i had write down my (self chosen) frustration - I'm sure there will be one or the other that understands it 8-) :lol:

waspie
Normal user
Posts: 117
Joined: 09 Feb 2017, 19:35

Re: Battery goes down WAY too fast on ESP

#49 Post by waspie » 03 Dec 2019, 19:21

izeman wrote:
03 Dec 2019, 19:09
waspie wrote:
03 Dec 2019, 17:40
But, for battery powered sensors, I went over to mysensors. It requires some new hardware but temperature sensors running for years on a button cell is a reality with that.
Thanks man. I got all that stuff already. I have a mysensor gateway, i got a handful of nrf24l with and without seperate antenna, and a lot of other stuff. I never got really warm with it. And it adds another level of complexity to my system.
I got a myriad of different sensors: Wifi, 433, 868, mysensor, zigbee, infrared ... A LOT of different stuff. And I tried to bring that down to two main technologies: Wifi and Zigbee. Unfortunately they are not too happy together, as they both work on 2.4GHz. Some kind of 433Mhz receiver is still in place as it reads some old temperature sensor and remote control.
I got a small house with 200m2 on 3 floors (or 4 if you add the basement) and 3 Ubiquity APs to cover everything, and still it's hard to have a good Wifi coverage everywhere. Zigbee is even worse. 4 repeaters and still a lot of places I just can't reach.
Ok. I got a bit offtopic now, but i had write down my (self chosen) frustration - I'm sure there will be one or the other that understands it 8-) :lol:
I get it! I have z-wave, mysensors, wifi (UAPs as well), espeasy, zigbee (Hue)... I'm right there with you.
My mysensors network finally got reliable when i started using ebyte modules. They've been rock solid despite coexisting with Wifi.

I'm not sure you'll find satisfaction with ESPs on batteries. I tried for about a year myself with essentially bare ESP-12s modules with a single dallas temperature sensor connected to an 18650 and I still couldn't get much more of a month out of it.

izeman
Normal user
Posts: 26
Joined: 24 Nov 2019, 12:11

Re: Battery goes down WAY too fast on ESP

#50 Post by izeman » 03 Dec 2019, 20:02

waspie wrote:
03 Dec 2019, 19:21
I'm not sure you'll find satisfaction with ESPs on batteries. I tried for about a year myself with essentially bare ESP-12s modules with a single dallas temperature sensor connected to an 18650 and I still couldn't get much more of a month out of it.
Maybe try "my" code. I now got the ESP directly connected to a LiPo charged to 3.5V and it didn't change it's voltage by 1/100 of a Volt after 48h. This makes me confident that it will run fine for several month (over a year) with one measurement every 15min, even with the awful 5s uptime from a 6000mAh LiFePo4.

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests