We will try to optimise time<\/strong> that our meter is \"awake\" and for that we need to know, first of all, what operating times we are talking about.<\/p>\n\n\n\n In the previous article, we got our CO2 meter to work with one 18650 battery for 12 days<\/strong>reporting values via MQTT every minute<\/strong>The first step is a simple experiment. <\/p>\n\n\n\n These are the rules we used for the previous experiment (there might be some difference because, unfortunately, I didn't save them):<\/p>\n\n\n And here you can see the time our microcontroller was on and its power consumption.<\/strong> (1mV=1mA consumption with an offset of approx. 8mV):<\/p>\n\n\n\n Let me explain, in detail, how to interpret this graph<\/strong> so that you can interpret this graph and the following graphs yourself. There is a lot of useful information in the graph and, depending on your powers of observation, you may detect a lot more than I am describing in this article, as the amount of information it contains is analogue (infinite):<\/p>\n\n\n\n In the vertical scale<\/strong> you have some numbers, such as 0.004, -0.016, -0.036, etc. These numbers represent the consumption of the entire meter at any given moment. As you can see, each horizontal division is separated by 20 millivolts, which represents 20 milliamps of consumption (1mV=1mA).<\/p>\n\n\n\n These values have an offset (deviation) of 8mA, caused by the measuring instruments.<\/p>\n\n\n\n If at a given moment on the scale you see -0.026V, this means that the consumption at that moment was 26mA.<\/p>\n\n\n\n In the horizontal scale<\/strong> you have the time in seconds. Each division on the horizontal scale is 1.12 seconds.<\/p>\n\n\n\n The times refer to the moment at which the data capture <\/strong>(before the meter is switched on).<\/p>\n\n\n\n You will see, for example, that the meter starts up at second 4.35 and starts with a small consumption peak of about 30mA followed by another peak of about 40mA and another peak of 118mA and then goes down to about 26mA and stays there for a few seconds.<\/p>\n\n\n\n As you can see the meter is on a total of 10,186 seconds<\/strong>.<\/p>\n\n\n\n As I am doing these experiments with ESP Easy<\/strong>The first thing I am going to do, before we start communicating with the CO2 sensor, sending data via wifi, MQTT and so on, is to do a first analysis in which I will put a rule in ESP Easy (in System#Boot) that will put the microcontroller back into deep sleep mode, without doing anything else.<\/p>\n\n\n\n This will help me to check which is the minimum time that ESP Easy allows me to keep the microprocessor awake<\/strong>.<\/p>\n\n\n\n ESP Easy is like an operating system. It has its own start-up procedure in which it does its own business, initialisation, creation of its data structures, searching for available plugins, etc. and this takes some time.<\/p>\n\n\n\n We assume that we cannot claim to have the same control over the microcontroller as we would have by programming it directly, in C++.<\/strong>for example, where we own every microsecond that the microcontroller uses. That is the price to pay for a system as simple as ESP Easy, which no programming required<\/strong>.<\/p>\n\n\n\n Although the first thing we do, when ESP Easy starts and we have control, is to put the microcontroller back into deep sleep mode (running a rule in System#Boot), this will take some time and that time will be that baseline or minimum time, over which we will start to add other things that will consume time (communications with the CO2 sensor, connection to the wifi network, sending data, etc.).<\/p>\n\n\n\n In this case, I have added the following rule:<\/p>\n\n\n This rule is executed as soon as ESP Easy starts up (or wakes up from deep sleep) and checks if SleepEnable#State<\/em> is equal to 1 (this is a switch I have placed on one of the pins to enable and disable deep sleep mode at will). If SleepEnable#State<\/em> is equal to 1 returns to deep sleep mode for 30 seconds.<\/p>\n\n\n\n This is the result:<\/p>\n\n\n\n As you can see, the microcontroller is awake during 2,133 seconds<\/strong>. This is the minimum time <\/strong>time it takes to start ESP Easy, run the rule and return to deep sleep state without doing anything else<\/strong>.<\/p>\n\n\n\n Is there room for optimisation of this part? There might be. I'll have to do some more testing, playing with some values in the ESP Easy configuration and even compiling a custom version that doesn't include support for any sensors that are not essential.<\/p>\n\n\n\n The next test I am going to perform is to see how much longer it takes to I do add the measurement of the CO2 sensor<\/strong>.<\/p>\n\n\n\n I have several options here, and I'm going to try some of them...<\/p>\n\n\n\n The first test will consist of enabling the device corresponding to the Senseair Sunrise sensor I am using in the Devices tab, with its default values, and force the sensor reading from the rule.<\/p>\n\n\n\n During this test I am going to keep the sensor on and permanently enabled so that it is ready to provide the measurement and avoid the waiting time while the sensor starts up and provides the measurement (the ENable pin of the Senseair Sunrise connected to +5V). This time will probably be minimal, but I don't want it to influence.<\/p>\n\n\n\n This is the rule I am going to use:<\/p>\n\n\n This rule is the same as the one I used in the previous example, but note that I include the line \"taskrun,1<\/em>\". This command, in case you are not familiar with it, tells ESP Easy to read the measurements from sensor number 1 in the Devices tab (in this case sensor number 1 in the tab is the Senseair Sunrise, ESP Easy lists them as \"Task\"):<\/p>\n\n\n\n And this is the result:<\/p>\n\n\n\n hmmm... this has really changed a lot... see?<\/p>\n\n\n\n To start with, where before we had an almost flat consumption line, now we have a consumption line full of periodic peaks (the sensor consumption) and, above all, now our ESP8266 is awake for much longer...<\/p>\n\n\n\n I have marked, with red circles, two pieces of information that I want you to see:<\/p>\n\n\n\n The first one on the upper right is the time that ESP8266 has been awake 8,533 seconds<\/strong> (previously it was 2.133 seconds). This time is the time elapsed between the first green vertical line (marked \"a\") and the second green vertical line (marked \"b\").<\/p>\n\n\n\n The second one, in the central part, is the consumption of these peaks of the Senseair Sunrise, 6mA<\/strong>. It is the difference between the two horizontal green lines (which limit the top and bottom of these peaks).<\/p>\n\n\n\n By the way, in case you don't know and as a \"general gadgetry culture\", those green lines, which oscilloscopes show to help measure differences, values, etc., are the ones you can see in the oscilloscope. are called cursors<\/em><\/strong>.<\/p>\n\n\n\n The increase in time for reading the sensor has been of 6.4 seconds, unacceptable.<\/strong> Further tests will have to be done to see if it is possible to reduce this time.<\/p>\n\n\n\n The above examples were good because they allowed us to establish a baseline from which to start, but they were quite useless<\/strong>from a functionality point of view.<\/p>\n\n\n\n The ESP8266 would wake up, read the sensor, go back to sleep, and so on and so forth (without doing anything at all). nothing <\/strong>with these measures, which were lost like tears in the rain).<\/p>\n\n\n\n In this experiment we will send measurements<\/strong> by wifi <\/strong>to a server using the MQTT<\/strong>.<\/p>\n\n\n\n Remember that this involves activating the ESY Easy MQTT driver, which will force you to connect to the MQTT broker, and this takes time.<\/p>\n\n\n\n These are the rules I will use for this experiment:<\/p>\n\n\n This rule is executed when the event occurs. \"MQTT#Connected\".<\/em>which generates automatically <\/strong>ESP Easy when connecting to the MQTT server<\/strong> (why do anything before this point?), and what it does is to send two MQTT messages and return to deep sleep mode for another 30 seconds.<\/p>\n\n\n\n Once the MQTT controller is activated, the consumption is as follows:<\/p>\n\n\n\n As you can see, I have separated the cycle with two cursors so that you can differentiate the time in high consumption (which corresponds to the maximum wifi activity), which has the greatest impact on the battery. On the right edge of the image you can see that the increase in time between cursor \"b\" and cursor \"c\", which corresponds to the area of maximum consumption, is 3.578 seconds.<\/p>\n\n\n\n Below, you can see two complete cycles<\/strong>where our meter wakes up, reads the sensor, sends the data via MQTT, goes back to deep sleep, wakes up, reads, sends, and goes back to deep sleep. This will allow you to see how long the deep sleep state lasts and its consumption:<\/p>\n\n\n\n As you will see I have placed cursors on the oscilloscope at the beginning and end of every \"wake up<\/em>\"<\/strong> so that you can check these times (on the right edge you can see the time increments between them, e.g. that the deep sleep time between the two \"awakenings<\/em>\"is 20.067 seconds).<\/p>\n\n\n\n If you found this interesting, don't miss the next post:<\/strong><\/p>\n\n\nThe previous experiment<\/h2>\n\n\n\n
\nOn [Sunrise#PPM] do\n publish,%sysname%\/Sunrise\/PPM,[Sunrise#PPM] \/\/publish CO2\n publish,%sysname%\/Battery,[Battery#Volts] do publish,%sysname%\/Battery,[Battery#Volts] \/\/publish CO2\n publish,%sys\n If [SleepEnable#State]=1\n deepsleep,60 \/\/go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)\n EndIf\nEndon\n\nOn MQTT#Connected Do \/\/when the broker is connected\n If [SleepEnable#State]=1\n publish,%sysname%\/status, \"Deepsleep Enabled\" \/\/publish information\n timerSet,1,1\n Else\n publish,%sysname%\/status, \"Deepsleep Disabled\" \/\/publish information\n EndIf\nEndOn\n\nOn Rules#Timer=1 Do\n deepsleep,60 \/\/go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)\nEndOn\n\nOn System#Wake Do\n publish,%sysname%\/status, \"Wake\" \/\/publish information\nEndOn\n\nOn System#Boot Do\n publish,%sysname%\/status, \"Boot\" \/\/publish information\nEndOn\n\nOn System#Sleep Do\n publish,%sysname%\/status, \"Sleep\" \/\/publish information\nEndOn\n<\/pre><\/div>\n\n\n
![\"\"](\"https:\/\/emariete.com\/wp-content\/uploads\/2021\/04\/Anatomia-Lectura-y-Transmision.png\"){kind=spacer}
<\/a><\/figure>\n\n\n\nBaseline (starting point of consumption)<\/h2>\n\n\n\n
\nOn System#Boot Do\n If [SleepEnable#State]=1\n deepsleep,30 \/\/go to deepsleep\n EndIf\nEndOn\n<\/pre><\/div>\n\n\n
<\/a><\/figure>\n\n\n\nReading the CO2 sensor<\/h2>\n\n\n\n
\nOn System#Boot Do\n If [SleepEnable#State]=1\n taskrun,1\n deepsleep,30 \/\/go to deepsleep\n EndIf\nEndOn\n<\/pre><\/div>\n\n\n
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\nRead CO2 sensor and send measurement<\/h2>\n\n\n\n
\nOn MQTT#Connected Do \/\/when the broker is connected\n If [SleepEnable#State]=1\n publish,%sysname%\/status, \"Deepsleep Enabled\" \/\/publish information\n publish,%sysname%\/Sunrise\/PPM,[Sunrise#PPM] \/\/publish CO2\n deepsleep,30 \/\/go to deepsleep\n EndIf\nEndOn\n<\/pre><\/div>\n\n\n
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\n