[deepSleep] Make deepSleep work again with 2.5.0 and refactor delay var #2217

clumsy-stefan · 2019-01-06T10:59:40Z

Make deepSleep work again with Core 2.5.0. Changed ESP.deepSleep() to ESP.deepSleepInstant().

Refactor delay variable to dsdelay to avoid conflicts with the delay() function.

Added a delay(100) before going to sleep to give the node time to send the last log messages.

Make deepSleep work again with Core 2.5.0. Changed ESP.deepSleep() to ESP.deepSleepInstant(). Refactor delay variable to dsdelay to avoid conflicts with the delay() function. Added a delay(100) before going to sleep to give the node time to send the last log messages.

added #ifdefs to make build happy also for versions <2.5.0

TD-er · 2019-01-06T13:00:43Z

Maybe you can also add a check for the deepSleepMax() ?
See ThingPulse - Max deep sleep for ESP8266 and these discussions:

Then we can also try to extend the max. deepsleep in ESPeasy's settings to allow longer deepsleep.

N.B. in the code we have some kind of flush built in before entering deep sleep:

ESPEasy/src/ESPEasy.ino

Lines 547 to 560 in 4d2a76a

    
             if (readyForSleep()){ 
        
               if (Settings.UseRules) 
        
               { 
        
                 String event = F("System#Sleep"); 
        
                 rulesProcessing(event); 
        
               } 
        
               // Flush outstanding MQTT messages 
        
               runPeriodicalMQTT(); 
        
               flushAndDisconnectAllClients(); 
        
               deepSleep(Settings.Delay); 
        
               //deepsleep will never return, its a special kind of reboot 
        
             } 
        
           }

clumsy-stefan · 2019-01-06T13:04:03Z

I'll have a look at the deepSleepMax() value/settings...

The flush does not seem to work for the log which is on line 177
addLog(LOG_LEVEL_INFO, F("SLEEP: Powering down to deepsleep..."));
in syslog it shows up only after I inserted the delay() after that line.

TD-er · 2019-01-06T13:09:54Z

OK, so maybe we should "fix" that in flushAndDisconnectAllClients() ?
Do you read the log from serial? That is now buffered, so we may also check for the buffer of the serial output and the HW buffer.
No need to keep waiting for worst-case scenario, when we can determine when it is done.

Allow to specify sleep times up deepSleepMax() on core 2.5.0

TD-er · 2019-01-06T20:27:44Z

Hmm, the core 2.5.0 builds fail with this:

/home/travis/build/letscontrolit/ESPEasy/src/Misc.ino: In function 'void deepSleepStart(int)':
/home/travis/build/letscontrolit/ESPEasy/src/Misc.ino:397:38: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (dsdelay > ESP.deepSleepMax() || dsdelay < 0)
^
Compiling .pioenvs/hard_core_250_beta_Shelly_1_2M256/FrameworkArduino/FS.cpp.o
cc1plus: some warnings being treated as errors
*** [.pioenvs/hard_core_250_beta_Shelly_1_2M256/src/ESPEasy.ino.cpp.o] Error 1

It's a bit harsh, but in this case I can understand it, since the resulting value of uint64_t deepSleepMax() (and it will overflow 32-bit unsigned int)

src/Misc.ino

clumsy-stefan · 2019-01-06T20:50:25Z

Of course . Right, sorry...

It was too late I guess,, I did not yet review it t thoroughly... Sorry for that..

Will amend it tomorrow!

Fix type errors of #999e43a and (hopefully) cast all types correctly now.... Keep deep sleep delay below INT_MAX for parameter storage compatibility.

clumsy-stefan · 2019-01-07T07:46:33Z

@TD-er wrote:

OK, so maybe we should "fix" that in flushAndDisconnectAllClients() ?
Do you read the log from serial? That is now buffered, so we may also check for the buffer of the serial output and the HW buffer.
No need to keep waiting for worst-case scenario, when we can determine when it is done.

Basically I agree, but when I understand the code correctly, the flushAndDisconnectAllClients() is not called anymore once the deepSleepStart()function is called. It goes immediately to sleep after the addLog() in there.

So basically if you want to have that in flushAndDisconnectAllClients() you would need to call it instead of just a delay(100) and I'm not sure if it's guaranteed that this function returns in a reasonable time, when it tries to flush everything...

TD-er · 2019-01-07T10:01:42Z

So basically if you want to have that in flushAndDisconnectAllClients() you would need to call it instead of just a delay(100) and I'm not sure if it's guaranteed that this function returns in a reasonable time, when it tries to flush everything...

Then we should include a timeout there.
Also this function is one of the few actually allowed to run as many delay calls as needed to finish the job.
My point is, it is better to get stuff flushed and shutdown early as possible, instead of waiting N msec to go to sleep even if it isn't needed.

clumsy-stefan · 2019-01-07T10:05:18Z

My point is, it is better to get stuff flushed and shutdown early as possible, instead of waiting N msec to go to sleep even if it isn't needed.

Sure I think it depends on the point of view... If you want to have deepSleep units because they run on battery and save energy you probably don't want to wait too long before shutdown, even if not all logs are done or all clients disconnected. On the other habnd you want to make sure, that at least the values are sent to the controller... seems to be kind of a trade-off here...

The 'old' limit of 4294 seconds was 2^32 usec. By casting it to an uint32, you may get unexpected results when multiplying it by 10^6 again. So better to use uint64 as variable and work on that one, now the deepsleep functions support uint64.

TD-er · 2019-01-07T10:48:41Z

I just pushed a new commit to it.
Maybe you can test it?

About the 'trade-off', I am not saying we shouldn't wait. Only try to wait as much as needed to get all buffers flushed and no longer.

clumsy-stefan · 2019-01-07T11:24:04Z

I just pushed a new commit to it.
Maybe you can test it?

sure, thanks!! I'm jsut compiling and installing now.. will report if it works..

looks more or less the same for me, done a bit differently... except that you allocate a uint64_t and multiplying the int instead of allocating "only" an ìntand dividing the uint64_t`into it... thaugt it takes less memory the other way round...

the adding of the max possible value to the web interface I also changed but did not yet commit/push it ;) same thought though...

TD-er · 2019-01-07T11:59:53Z

The memory usage isn't an issue here, since it is just very local and on the stack too. (allocation on the heap takes time, on the stack doesn't)

The main issue why I changed it to do all on the 64-bit value was because of this:

ESP.deepSleepInstant((uint32_t)dsdelay * 1000000, WAKE_RF_DEFAULT);

In this call, any value of dsdelay of over 4294 would result in something unexpected, since it would overflow. (and you would not notice it)
So when working on a 64 bit int, you know for sure it will not overflow inbetween.

clumsy-stefan · 2019-01-07T12:21:48Z

great!

up to now it seems to run without issues...at least this part...

TD-er · 2019-01-07T12:30:16Z

OK, so I can merge it?

clumsy-stefan · 2019-01-07T12:46:40Z

from my point of view yes, It compiles also in the Arduino framework and runs on my nodes for about 2 hours now, including deepSleep nodes..

TD-er · 2019-01-07T15:49:28Z

@Barracuda09 I was almost certain I did change that one too, but apparently not.
Also I agree with your remarks about adding curly braces to indicate the scope.
Usually I try to change those when I see them.

pieman64 · 2019-01-14T12:50:08Z

@TD-er I understand the 32 bit overflow of microseconds that gives uint32_t a maximum of 4294 seconds (or approx 71 minutes). Previously I was wrongly thinking we were able to go to a 64 bit value but I guess it's actually just 33 bits. Does this mean the new maximum sleep is around 8590 seconds (approx 143 minutes)? I am using the new code set at 18000 seconds (5 hours) with the expectation of the ESP8266 waking after 143 minutes. Two hours to wait before I have the results.

TD-er · 2019-01-14T13:33:57Z

@pieman64 See the links I posted in this reply: #2217 (comment)

pieman64 · 2019-01-14T13:43:55Z

Thanks @TD-er
From https://thingpulse.com/max-deep-sleep-for-esp8266/ it states:
13612089337μs ≙ 13612s ≙ 3.78h ≙ 3h 46min
That rings true with the 3 to 4 hours I had in mind some months ago when I looked into it.

pieman64 · 2019-01-14T15:58:44Z

I got 3 hours 33 minutes from my first run as shown from the blurb below:

/*
14:20:30.585 ->     ___  __          __
14:20:30.632 ->    / _ )/ /_ _____  / /__
14:20:30.632 ->   / _  / / // / _ \/  '_/
14:20:30.678 ->  /____/_/\_, /_//_/_/\_\
14:20:30.725 ->         /___/ v0.5.4 on Arduino
14:20:30.772 -> 
14:20:32.162 -> [1706] Connecting to mysecretserver.com:80
14:20:32.407 -> [1928] Ready (ping: 83ms).
14:20:33.588 -> Uptime: 3s
14:20:34.476 -> Sleep
14:20:35.034 -> Long sleep                       ****** 3hours 33 minutes
17:53:12.153 ->     ___  __          __
17:53:12.187 ->    / _ )/ /_ _____  / /__
17:53:12.187 ->   / _  / / // / _ \/  '_/
17:53:12.223 ->  /____/_/\_, /_//_/_/\_\
17:53:12.257 ->         /___/ v0.5.4 on Arduino
17:53:12.291 -> 
17:53:13.727 -> [1708] Connecting to mysecretserver.com:80
17:53:14.135 -> [2091] Ready (ping: 83ms).
17:53:15.315 -> Uptime: 3s
17:53:16.035 -> Sleep
17:53:16.586 -> Long sleep

*/

#define ESP8266
#define CORE_2_5_0 

void sleep()
{
    //ESP.deepSleep(60000000 * 15 * (900 / 872)); // old format 15 minutes sleep 900 / 872 is tolerance 
    // details below taken from: https://github.com/clumsy-stefan/ESPEasy/blob/cf95d0ca37726f1c3e188987960ac99b08a5d7f0/src/Misc.ino
    // 1 million microseconds in a second
    unsigned long dsdelay = 18000; // 4294 seconds max approx 71 minutes before core 2.5.0
                                   // try 5 hours (18000 seconds) for core 2.5.0
    // Max is now approx 13612089337μs ≙ 13612s ≙ 3.78h ≙ 3h 46min from https://thingpulse.com/max-deep-sleep-for-esp8266/                               
    myTerminal.println("Sleep");
    myConsole.println("Sleep");
    delay(500);                   // give the node time before going to sleep
    display.clearDisplay();
    display.display();     
    #if defined(ESP8266)
      #if defined(CORE_2_5_0)
        uint64_t deepSleep_usec = dsdelay * 1000000ULL;    // 4294 seconds * 1000000
        Serial.println(F("Long sleep"));         // debugging
        if ((deepSleep_usec > ESP.deepSleepMax()) || dsdelay < 0) {
          deepSleep_usec = ESP.deepSleepMax();
        }
        ESP.deepSleepInstant(deepSleep_usec, WAKE_RF_DEFAULT);
      #else
        if (dsdelay > 4294 || dsdelay < 0)
          dsdelay = 4294;   //max sleep time ~71 minutes
          Serial.println(F("Short sleep"));         // debugging
        ESP.deepSleep((uint32_t)dsdelay * 1000000, WAKE_RF_DEFAULT);
      #endif
    #endif    
}

pieman64 · 2019-01-15T09:00:45Z

The second cycle was broadly similar to the first but slightly shorter at about 3.5 hours. Unfortunately the third cycle failed and after 7 hours the ESP8266 was still sleeping.

I have dropped the 18,000 seconds to 12,000, which in theory is 3 hours 20 minutes. Due to the poor time keeping of these devices the first cycle with these settings was timed at 3 hours and 8 minutes. The second cycle was 3 hours and 14 minutes. It has just started the third cycle and I will see if it wakes this time.

TD-er · 2019-01-15T09:10:03Z

The internal clock is not that accurate.
It depends on a number of factors like temperature and more likely with these cheap modules, the quality of the crystal.

fluppie · 2019-01-18T12:52:29Z

Maybe we can extend the time by working with loops like the guys from LowPowerLab do?
See send_loops code in https://github.com/LowPowerLab/RFM69/blob/master/Examples/WeatherNode/WeatherNode.ino

clumsy-stefan added 2 commits January 6, 2019 11:58

[deepSleep] only use deepSleepInstant for 2.5.0

c2c311e

added #ifdefs to make build happy also for versions <2.5.0

TD-er added Category: Stabiliy Things that work, but not as long as desired Category: Energy Related to reduce power as much as possible. labels Jan 6, 2019

[deepSleep] Allow for sleeptimes up to deepSleepMax()

999e43a

Allow to specify sleep times up deepSleepMax() on core 2.5.0

TD-er requested changes Jan 6, 2019

View reviewed changes

src/Misc.ino Show resolved Hide resolved

[deepSleep] fix type errors of #999e43a

1ac0a96

Fix type errors of #999e43a and (hopefully) cast all types correctly now.... Keep deep sleep delay below INT_MAX for parameter storage compatibility.

[deepSleep] Prevent overflow issues

cf95d0c

The 'old' limit of 4294 seconds was 2^32 usec. By casting it to an uint32, you may get unexpected results when multiplying it by 10^6 again. So better to use uint64 as variable and work on that one, now the deepsleep functions support uint64.

TD-er merged commit 91a24fd into letscontrolit:mega Jan 7, 2019

clumsy-stefan deleted the deepSleep branch January 21, 2019 06:40

[deepSleep] Make deepSleep work again with 2.5.0 and refactor delay var #2217

[deepSleep] Make deepSleep work again with 2.5.0 and refactor delay var #2217

Uh oh!

Conversation

clumsy-stefan commented Jan 6, 2019

Uh oh!

TD-er commented Jan 6, 2019

Uh oh!

clumsy-stefan commented Jan 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TD-er commented Jan 6, 2019

Uh oh!

TD-er commented Jan 6, 2019

Uh oh!

Uh oh!

clumsy-stefan commented Jan 6, 2019

Uh oh!

clumsy-stefan commented Jan 7, 2019

Uh oh!

TD-er commented Jan 7, 2019

Uh oh!

clumsy-stefan commented Jan 7, 2019

Uh oh!

TD-er commented Jan 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clumsy-stefan commented Jan 7, 2019

Uh oh!

TD-er commented Jan 7, 2019

Uh oh!

clumsy-stefan commented Jan 7, 2019

Uh oh!

TD-er commented Jan 7, 2019

Uh oh!

clumsy-stefan commented Jan 7, 2019

Uh oh!

TD-er commented Jan 7, 2019

Uh oh!

pieman64 commented Jan 14, 2019

Uh oh!

TD-er commented Jan 14, 2019

Uh oh!

pieman64 commented Jan 14, 2019

Uh oh!

pieman64 commented Jan 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pieman64 commented Jan 15, 2019

Uh oh!

TD-er commented Jan 15, 2019

Uh oh!

fluppie commented Jan 18, 2019

Uh oh!

Uh oh!

clumsy-stefan commented Jan 6, 2019 •

edited

Loading

TD-er commented Jan 7, 2019 •

edited

Loading

pieman64 commented Jan 14, 2019 •

edited

Loading