Deepsleep delayed by >15secs when called from rule

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
ao16
Normal user
Posts: 19
Joined: 03 Oct 2018, 23:51

Deepsleep delayed by >15secs when called from rule

#1 Post by ao16 » 23 Mar 2022, 23:42

Hi all,

I have an issue that when I call "deepsleep" from a rule in my code as last action,
the ESP still needs >15secs to go really into deepsleep.
Do you have an idea what could be the root cause for that behaviour?

I am using an ESP32 and "ESP_Easy_mega_20211224_display_ESP32_4M316k Dec 24 2021".

Basically, what the application does (or shall do):
1. wake up ESP32
2. read out values of ADS1115 ADC and BME280 through I2C and display them on OLED
3. transmitt the values via SentToHTTP to ThingSpeak
4. if a dedicated GPIO input (StayAwake#State) is not set to LOW, go into deepsleep, otherwise stay away (I use that for doing debugging or extending the code)


This is the code I am using:

Code: Select all

On Rules#Timer=3 do     // stay awake until StayAwake#state is FALSE
   TimerSet,3,0
   Pulse,13,1,20
   Pulse,13,0,150
   Pulse,13,1,20
   if [StayAwake#State]=1
      TimerSet,3,2
   else
      TimerSet,3,0
      event,GeheSchlafen
   endif
endon
   
on GeheSchlafen do
   TimerSet,1,0
   TimerSet,2,0
   TimerSet,3,0
   TimerSet,4,0
   Pulse,13,1,20
   Pulse,13,0,150
   Pulse,13,1,20
   oledframedcmd,display,off
   gpio,19,0   // +3V3_SW
   gpio,18,0   // GSM_Wakeup
   gpio,27,0
   Deepsleep,30                //go to deepsleep for x seconds 
endon

Looking into the weblog, this happens (deepsleep is called at line 31368):

Code: Select all

....
31311: Pulse,13,1,20
31311: Par1: 13 Par2: 1 Par3: 20 Par4: 0 Par5: 0
31333: GPIO : port 13. Pulse set for 20 ms
31338: ACT  : oledframedcmd,display,off
31339: Command: oledframedcmd
31339: oledframedcmd,display,off
31340: Par1: 1073420576 Par2: 1073420576 Par3: 0 Par4: 0 Par5: 0
31346: ACT  : gpio,19,0
31348: Command: gpio
31348: gpio,19,0
31348: Par1: 19 Par2: 0 Par3: 0 Par4: 0 Par5: 0
31349: GPIO : port#19: set to 0
31354: ACT  : gpio,18,0
31355: Command: gpio
31355: gpio,18,0
31355: Par1: 18 Par2: 0 Par3: 0 Par4: 0 Par5: 0
31356: GPIO : port#18: set to 0
31360: ACT  : gpio,27,0
31362: Command: gpio
31362: gpio,27,0
31362: Par1: 27 Par2: 0 Par3: 0 Par4: 0 Par5: 0
31363: GPIO : port#27: set to 0
31368: ACT  : Deepsleep,30
31370: Command: Deepsleep
31370: Deepsleep,30
31370: Par1: 30 Par2: 0 Par3: 0 Par4: 0 Par5: 0
31371: EVENT: Time#Set
31962: EVENT: Time#Set Processing time:592 milliSeconds
31967: EVENT: ADC#VBatt=12.97
32433: EVENT: ADC#VBatt=12.97 Processing time:467 milliSeconds
32437: EVENT: ADC#VBatt=12.97
32860: EVENT: ADC#VBatt=12.97 Processing time:423 milliSeconds
32864: EVENT: ADC#VBatt=12.97
33329: EVENT: ADC#VBatt=12.97 Processing time:465 milliSeconds
33333: EVENT: ADC#VBatt=12.83
33779: EVENT: ADC#VBatt=12.83 Processing time:446 milliSeconds
33784: EVENT: BME280_1#Temp=25.1
34244: EVENT: BME280_1#Temp=25.1 Processing time:461 milliSeconds
34248: EVENT: BME280_1#Hum=21
34669: EVENT: BME280_1#Hum=21 Processing time:421 milliSeconds
34673: EVENT: BME280_1#Pres=1032
35088: EVENT: BME280_1#Pres=1032 Processing time:414 milliSeconds
35091: EVENT: ADC#VBatt=12.93
35542: EVENT: ADC#VBatt=12.93 Processing time:451 milliSeconds
35546: EVENT: ADC#VBatt=12.97
35936: EVENT: ADC#VBatt=12.97 Processing time:390 milliSeconds
35940: EVENT: ADC#VBatt=12.97
36368: EVENT: ADC#VBatt=12.97 Processing time:428 milliSeconds
36372: EVENT: ADC#VBatt=12.97
36731: UDP  : 60:01:94:9E:61:77,192.168.1.113,113
36769: EVENT: ADC#VBatt=12.97 Processing time:397 milliSeconds
36773: EVENT: ADC#VBatt=12.97
37176: EVENT: ADC#VBatt=12.97 Processing time:403 milliSeconds
37180: EVENT: BME280_1#Temp=25.1
37350: UDP  : 5C:CF:7F:78:65:D2,192.168.1.105,105
37620: EVENT: BME280_1#Temp=25.1 Processing time:440 milliSeconds
37624: EVENT: BME280_1#Hum=21
38020: EVENT: BME280_1#Hum=21 Processing time:396 milliSeconds
38024: EVENT: BME280_1#Pres=1032
38410: EVENT: BME280_1#Pres=1032 Processing time:386 milliSeconds
38414: EVENT: ADC#VBatt=12.85
38839: EVENT: ADC#VBatt=12.85 Processing time:425 milliSeconds
38844: EVENT: ADC#VBatt=12.97
39230: EVENT: ADC#VBatt=12.97 Processing time:387 milliSeconds
39234: EVENT: ADC#VBatt=12.90
39619: EVENT: ADC#VBatt=12.90 Processing time:385 milliSeconds
39623: EVENT: ADC#VBatt=12.97
40050: EVENT: ADC#VBatt=12.97 Processing time:427 milliSeconds
40054: EVENT: ADC#VBatt=12.89
40442: EVENT: ADC#VBatt=12.89 Processing time:388 milliSeconds
40446: EVENT: BME280_1#Temp=25.1
40832: EVENT: BME280_1#Temp=25.1 Processing time:386 milliSeconds
40836: EVENT: BME280_1#Hum=21
41263: EVENT: BME280_1#Hum=21 Processing time:427 milliSeconds
41267: EVENT: BME280_1#Pres=1032
41655: EVENT: BME280_1#Pres=1032 Processing time:388 milliSeconds
41659: EVENT: ADC#VBatt=12.83
42041: EVENT: ADC#VBatt=12.83 Processing time:382 milliSeconds
42046: EVENT: ADC#VBatt=12.97
42472: EVENT: ADC#VBatt=12.97 Processing time:427 milliSeconds
42476: EVENT: ADC#VBatt=12.97
42859: EVENT: ADC#VBatt=12.97 Processing time:383 milliSeconds
42863: EVENT: ADC#VBatt=12.83
43073: UDP  : F4:CF:A2:D0:5A:09,192.168.1.158,158
43264: EVENT: ADC#VBatt=12.83 Processing time:401 milliSeconds
43268: EVENT: ADC#VBatt=12.97
43709: EVENT: ADC#VBatt=12.97 Processing time:441 milliSeconds
43713: EVENT: ADC#VBatt=12.97
44102: EVENT: ADC#VBatt=12.97 Processing time:389 milliSeconds
44107: EVENT: ADC#VBatt=12.97
44493: EVENT: ADC#VBatt=12.97 Processing time:387 milliSeconds
44497: EVENT: ADC#VBatt=12.97
44609: UDP  : 5C:CF:7F:78:6E:22,192.168.1.108,108
44952: EVENT: ADC#VBatt=12.97 Processing time:455 milliSeconds
44956: EVENT: ADC#VBatt=12.97
45350: EVENT: ADC#VBatt=12.97 Processing time:394 milliSeconds
45354: EVENT: BME280_1#Temp=25.1
45779: EVENT: BME280_1#Temp=25.1 Processing time:425 milliSeconds
45783: EVENT: BME280_1#Hum=20
46041: UDP  : 80:7D:3A:67:E4:20,192.168.1.118,118
46183: EVENT: BME280_1#Hum=20 Processing time:400 milliSeconds
46187: EVENT: BME280_1#Pres=1032
46353: UDP  : 50:02:91:7A:0F:52,192.168.1.152,152
46600: EVENT: BME280_1#Pres=1032 Processing time:413 milliSeconds
46604: EVENT: ADC#VBatt=12.97
47054: EVENT: ADC#VBatt=12.97 Processing time:450 milliSeconds
47058: EVENT: ADC#VBatt=12.97
47442: EVENT: ADC#VBatt=12.97 Processing time:384 milliSeconds
47446: EVENT: ADC#VBatt=12.97
47475: UDP  : 60:01:94:75:23:A5,192.168.1.110,110
47869: EVENT: ADC#VBatt=12.97 Processing time:423 milliSeconds
47873: EVENT: ADC#VBatt=12.97
47889: UDP  : C4:4F:33:8C:A7:69,192.168.1.140,140
48332: EVENT: ADC#VBatt=12.97 Processing time:459 milliSeconds
48336: EVENT: ADC#VBatt=12.97
48766: EVENT: ADC#VBatt=12.97 Processing time:430 milliSeconds
48770: EVENT: System#Sleep
So after calling "deepsleep,30", still many events via I2C from the ADC and the BME280 are visible
altough I did not call them and also during the other stages of the program, they do not occur in such
a high frequency than now after calling deepsleep.


Do you have any idea for the root cause why the deepsleep of my ESP32 is delayed by >15sec after calling the command?

Any advice is appreciated.

Thanks in advance,

AO16

P.S.: The timers 1..4 that I set to zero are already set to zero during earlier rules
- so this here in the last rule is just a last "cleanup" as I thought that maybe a false timer is blocking me from deepsleep.
The "pulse command" is connected to a LED that I also use for debugging, so here to see when "GeheSchlafen" has beed called.

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

Re: Deepsleep delayed by >15secs when called from rule

#2 Post by TD-er » 23 Mar 2022, 23:51

Deepsleep will call to flush any data in the queue of the controllers.
So you may want to experiment with the queue depth and timeout (and retries) to verify it is indeed the root cause of the delay you're seeing.

ao16
Normal user
Posts: 19
Joined: 03 Oct 2018, 23:51

Re: Deepsleep delayed by >15secs when called from rule

#3 Post by ao16 » 25 Mar 2022, 16:20

Thanks TD'er for that hint.

I tried it, reduced in the controller tab the max.queue depth to 1,
max retries to 1, client timeout to 1000ms however now change.
I then also disabled the controller tab and the notify tab credentials and commented-out
the notify as well as the SendToHTTP (for the Thingspeak) in my rules, however the delayed deepsleep did not improve.

I blanked (4MB) and reflashed the -factory.bin into the ESP32 but this time instead of the _display_ version
the _normal_ version as I finally do not use any of the special displays.
The standard framed OLED is fine - however this also did not change the above behaviour.

Now I will start commenting-out the different functions within the rules to narrow down the issue.
Maybe it is related to the several timers I am using?!

I use several timers to generate a kind of flow and order,
e.g. if one event is finished, go to the next timerevent that does another code.
Every other timer is set to 0 (deactivated) before using the next one, so no timer should run in parallel to the other.

I am doing this with the timers because I have some dependenties, e.g.
I setup the WiFi and try to connect the AP that could take a few seconds, depending if I am in coverage range or not.
Then another timer is to wait (when connected) a bit after I sent to ThingSpeak via SendToHTTP command.
In case the WiFi-AP is not found, then some states (via GPIO's) shall be sent via an external GSM-Module, however not via ThingSpeak as
the GSM module is just notifing via a fixed SMS depending on some inputs states.

And then I want to put the whole unit back into deepsleep
to save battery power until the next wakeup cycle starts.
So the timers I am using are to not set the ESP to deepsleep to fast - to allow some time for the different events
- but on the other hand also to not block the module and stay awake as some event did not take place or takes too long time.


I will dig again in the rules and let you know my findings, maybe somebody else also experienced a similar issue.

ao16
Normal user
Posts: 19
Joined: 03 Oct 2018, 23:51

Re: Deepsleep delayed by >15secs when called from rule

#4 Post by ao16 » 26 Mar 2022, 15:17

two questions:

1. Do the controller settings (max queue depth, retries, client timout) still have an effect
if the controller is not enabled at the checkbox in the controller tab?

I mean when this command within a rule is used:

SendToHTTP,api.thingspeak.com,80,'/update?api_key=xyz&field1=[ADC#VBatt]&field2=[BME280v#Temp]&field3=[BME280v#Hum]&field4=[BME280v#Pres]&field5=[BME280h#Temp]'

are the above controller settings in the tab then still applicable/effective?


2. Why is the message "timeStringToSeconds: "12" - -> invalid" in the log happening?
I do have an if with several elseif's to different actions and this message appears at the log
when parsing the different if's. Instead of "12", also other numbers are shown there, depending which elseif branch is parsed.

Code: Select all

   if [ADC#VBatt]<=12.8
      TaskValueSet,VoltBelow,High,1  // BattVoltage below Threshold 1=YES

   elseif [ADC#VBatt]<12.3
      TaskValueSet,VoltBelow,Mid,1  // BattVoltage below Threshold 1=YES
      TaskValueSet,Dummy,BattLowAlarm,1  // Batterie Low Alarm 1=YES
      ....
in the syslog, I get above message:

Code: Select all

DEBUG DEV: Parsed String='if 12.84'
RuleDebug: 000: if 12.84<=12.8
timeStringToSeconds: "12" --> invalid
timeStringToSeconds: "12" --> invalid
conditionMatch: "12.84<=12.8" --> "12.84" <= "12.8" --> false (12.84 <= 12.8)
conditionMatchExtended: false "12.84<=12.8"
Lev.1: [if false]=false
RuleDebug: 000: taskvalueset,voltbelow,high,1
DEBUG DEV: Parsed String='elseif 12.84'
RuleDebug: 000: elseif 12.84<12.3
timeStringToSeconds: "12" --> invalid
timeStringToSeconds: "12" --> invalid
What is the meaning of this "StringToSeconds" --> invalid? "

Thanks in advance for you advice

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Deepsleep delayed by >15secs when called from rule

#5 Post by Ath » 26 Mar 2022, 15:52

1. No, the SendToHTTP command has no relation to Controller settings. The "SendToHTTP wait for ack" setting has, as it waits for confirmation of the command being accepted by the 'other side'.
Disabled controllers should get no CPU cycles, because they are disabled.

2. The internal parser first tries to determine if a compare-value is a time value, setting the log level to DEBUG shows all these internal messages that are only of interest during debugging the software, not for normal use, the regular log level should either be INFO, ERROR or NONE. If this was an error, it would be logged as an ERROR (and shown red in the web log viewer).
/Ton (PayPal.me)

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

Re: Deepsleep delayed by >15secs when called from rule

#6 Post by TD-er » 26 Mar 2022, 15:58

SendToHttp does not use the controller queue mechanism.
N.B. the "publish" command for MQTT does use the queue mechanism

About the timeStringToSeconds, I have to check the code to see whether it is left over debugging code from when I wrote it.
It does try to parse the strings and see whether you're comparing 2 time values.
At first glance, I would say it is just harmless debug code, as it does log every single check made to parse numbers in the rules processing.

ao16
Normal user
Posts: 19
Joined: 03 Oct 2018, 23:51

Re: Deepsleep delayed by >15secs when called from rule

#7 Post by ao16 » 26 Mar 2022, 23:29

Thanks to you both for explaining - got it :-)

I tried quite a lot of different things for narrowing down the cause why a deepsleep command
within a rule does not immediatly take action and is delayed.

Besides removing the "notify" and "sendtohttp to Thingspeak"
I also tried if unpowering the I2C devices (they are connected to a GPIO) makes a difference,
however then other events (states of Tasks and dummy variables) appeared in the weblog
that kept the ESP32 still awake for >15secs until it really went into deepsleep and system#sleep was triggered.

Lastly, I cut down all the 4 rules to one rule.
Most of these rules and functions defined there contained many if-conditions checks
depending on the values coming from the ADC or the BME280 and/or the GPIO-states/digital inputs.

Now with a cut down and minimum of code in one rule (see below),
deepsleep starts around 1sec after firing the command.
However in the weblog it still can be seen that some events arrived
altough the I2C devices were already unpowered shortly before through GPIO set to LOW.
And after that arrived events, then system#sleep was finally triggered.

=> So for me it looks that the more code and rules are defined,
the more events still arrive after firing the deepsleep command and these events seem to keep the ESP32 still awake
and delay the system#sleep.
Is this an expected behaviour?


If anybody has an idea how this delay in triggering system#sleep after firing the deepsleep-command
can be avoided or what could be the root cause for that issue, any advice is welcome.
Because 15sec delay is quite a lot for my planned duty-cycle as I'd like to get as much life as possible out of my battery.

P.S.: "%iswifi%"-system variable always results in a value of "2", but never in "7" or "3" or "1", if this is a helpful information.


Please find attached the little reduced code that still results in a few arriving events after firing deepsleep:

Code: Select all

on System#Boot do
   gpio,19,1       // GPIO19: +3v3 ON for external I2C Devices (ADC, BME280, OLED)
   gpio,13,0       // GPIO13: Batt_Low_Alarm
   TimerSet,1,10   // wait for 10s to allow setting up WiFi connection
endon

On Rules#Timer=1 do 
   event,ShortOn
endon

On ShortOn do       // Short ON and immediatly back into DeepSleep
   Pulse,25,1,20    // Some LED flashing for debugging
   Pulse,25,0,150
   Pulse,25,1,20
   Pulse,25,0,150
   Pulse,25,1,20

   TaskValueSet,14,3,%iswifi%
   //if [Status#WiFi]>=0
   //   gpio,18,1 //debug
   //endif

    if [BME280v#Hum]=0 OR [BME280v#Pres]=0 OR [BME280h#Hum]=0
      //TaskRun,2 //update BME280v
      //TaskRun,3 //update BME280h
      //TaskRun,4 //update ADC
    elseif [Dummy#BattLowAlarm]=0 AND [Status#WiFi]<1
      // do nothing - go to end
    endif
    
   gpio,25,0 //Debug
   TimerSet,3,3
endon

On Rules#Timer=3 do     // stay ON till StayAwake Switch =FALSE
   TimerSet,3,0
   Pulse,25,1,20       // some LED flashing for debugging
   Pulse,25,0,150
   Pulse,25,1,20
   if [StayAwake#State]=1
      TimerSet,3,2
   else
      event,GeheSchlafen
   endif
endon

on GeheSchlafen do
   TimerSet,1,0
   TimerSet,2,0
   TimerSet,3,0
   TimerSet,4,0
   Pulse,25,1,350  // some LED flashing for debugging when here
   Pulse,25,0,150
   Pulse,25,1,20
   Pulse,25,0,150
   Pulse,25,1,20
   Pulse,25,0,150
   Pulse,25,1,350
   oledframedcmd,display,off
   gpio,19,0   // +3V3_SW for I2C devicess OFF
   gpio,18,0   // GSM_Wakeup OFF
   gpio,27,0
   Deepsleep,30                //go to deepsleep for x seconds 
endon

and here's the weblog:

Code: Select all

2671: WiFi : Scan finished, found: 15
2676: WiFi : Best AP candidate: xxxxxxxxxxxxxxx yy:yy:yy:yy:yy:yy Ch:11 (-44dBm) WPA2/PSK
2677: WIFI : Connecting xxxxxxxx yy:yy:yy:yy:yy:yy Ch:11 (-44dBm) WPA2/PSK attempt #0
2684: IP : Static IP : 192.168.1.166 GW: 192.168.1.1 SN: 255.255.252.0 DNS: 192.168.1.1
2692: WIFI : Arduino wifi status: WL_DISCONNECTED 6 ESPeasy internal wifi status: DISCONNECTED
3546: WIFI : Static IP: 192.168.1.166 (166-CC-Batt-Control-166) GW: 192.168.1.1 SN: 255.255.252.0 duration: 3500 ms
3559: UDP : Start listening on port 65500
3561: firstLoopConnectionsEstablished
3580: EVENT: TaskInit#StayAwake=5,1
3826: NTP : NTP replied: delay 21 mSec Accuracy increased by 0.725 seconds
3828: Time set to 1648330989.725 Time adjusted by 30998.61 msec. Wander: 0.000 msec/second Source: NTP
3830: Local time: 2022-03-26 22:43:09
3841: EVENT: Clock#Time=Sat,22:43
4040: BME280: dew point 3.04C
4240: EVENT: TaskInit#OLEDon=6,1
4449: BME280 : Address: 0x76
4452: BME280 : Temperature: 26.4
4455: BME280 : Humidity: 22
4458: BME280 : Barometric Pressure: 1032
4498: EVENT: TaskInit#SendeMail=7,1
4752: EVENT: TaskInit#DoorOpen=8,1
4963: EVENT: TaskInit#Dummy=12,1
5157: EVENT: TaskInit#VoltBelow=13,1
5357: EVENT: TaskInit#Status=14,1
5554: EVENT: ADC#VBatt=12.84
5792: EVENT: StayAwake#State=0
5986: EVENT: OLEDon#State=1
6177: EVENT: SendeMail#State=0
6402: EVENT: DoorOpen#State=1
6824: EVENT: Dummy#OLEDon=0
7098: EVENT: Dummy#BattLowAlarm=0
7307: EVENT: Dummy#SendeMail=0
7490: EVENT: Dummy#StayAwake=0
7731: EVENT: VoltBelow#High=0
7942: EVENT: VoltBelow#Mid=0
8125: EVENT: VoltBelow#Low=0
8336: EVENT: VoltBelow#Lowest=0
8530: EVENT: Status#ShortOn=0
8773: EVENT: Status#LongOn=0
8987: BME280: dew point 2.98C
9021: EVENT: Status#WiFi=2
9213: BME280 : Address: 0x76
9216: BME280 : Temperature: 26.4
9219: BME280 : Humidity: 22
9222: BME280 : Barometric Pressure: 1032
9260: EVENT: Status#=0
9449: EVENT: ADC#VBatt=12.84
9754: EVENT: ADC#VBatt=12.84
10013: EVENT: WiFi#Connected
10247: EVENT: Time#Set
10441: EVENT: ADC#VBatt=12.98
10642: EVENT: BME280v#Temp=26.4
10888: EVENT: BME280v#Hum=22
11062: EVENT: Rules#Timer=1,1
11095: ACT : event,ShortOn
11097: EVENT: ShortOn
11130: ACT : Pulse,25,1,20
11153: GPIO : port 25. Pulse set for 20 ms
11158: ACT : Pulse,25,0,150
11310: GPIO : port 25. Pulse set for 150 ms
11315: ACT : Pulse,25,1,20
11337: GPIO : port 25. Pulse set for 20 ms
11386: ACT : Pulse,25,0,150
11538: GPIO : port 25. Pulse set for 150 ms
11543: ACT : Pulse,25,1,20
11565: GPIO : port 25. Pulse set for 20 ms
11569: ACT : TaskValueSet,14,3,2
11978: ACT : gpio,25,0
11980: GPIO : port#25: set to 0
11984: ACT : TimerSet,3,3
12249: EVENT: BME280v#Pres=1032
12530: EVENT: ADC#VBatt=12.98
12942: EVENT: ADC#VBatt=12.98
13198: EVENT: ADC#VBatt=12.93
13410: EVENT: ADC#VBatt=12.84
13616: EVENT: ADC#VBatt=12.98
13926: EVENT: BME280v#Temp=26.4
14125: EVENT: BME280v#Hum=22
14288: EVENT: BME280v#Pres=1032
14463: EVENT: ADC#VBatt=12.98
14658: EVENT: ADC#VBatt=12.98
14907: BME280: dew point 2.97C
14930: EVENT: ADC#VBatt=12.98
15131: BME280 : Address: 0x76
15134: BME280 : Temperature: 26.4
15137: BME280 : Humidity: 22
15140: BME280 : Barometric Pressure: 1032
15167: EVENT: Rules#Timer=3,1
15260: ACT : TimerSet,3,0
15262: TIMER: disable timer
15267: ACT : Pulse,25,1,20
15290: GPIO : port 25. Pulse set for 20 ms
15295: ACT : Pulse,25,0,150
15447: GPIO : port 25. Pulse set for 150 ms
15452: ACT : Pulse,25,1,20
15474: GPIO : port 25. Pulse set for 20 ms
15566: ACT : event,GeheSchlafen
15569: EVENT: GeheSchlafen
15692: ACT : TimerSet,1,0
15694: TIMER: disable timer
15698: ACT : TimerSet,2,0
15700: TIMER: disable timer
15703: ACT : TimerSet,3,0
15706: TIMER: disable timer
15710: ACT : TimerSet,4,0
15712: TIMER: disable timer
15716: ACT : Pulse,25,1,350
16069: GPIO : port 25. Pulse set for 350 ms
16127: ACT : Pulse,25,0,150
16280: GPIO : port 25. Pulse set for 150 ms
16286: ACT : Pulse,25,1,20
16308: GPIO : port 25. Pulse set for 20 ms
16313: ACT : Pulse,25,0,150
16465: GPIO : port 25. Pulse set for 150 ms
16470: ACT : Pulse,25,1,20
16492: GPIO : port 25. Pulse set for 20 ms
16497: ACT : Pulse,25,0,150
16650: GPIO : port 25. Pulse set for 150 ms
16655: ACT : Pulse,25,1,350
17007: GPIO : port 25. Pulse set for 350 ms
17066: ACT : oledframedcmd,display,off
17074: ACT : gpio,19,0
17077: GPIO : port#19: set to 0
17081: ACT : gpio,18,0
17084: GPIO : port#18: set to 0
17088: ACT : gpio,27,0
17090: GPIO : port#27: set to 0
17094: ACT : Deepsleep,30
17097: EVENT: ADC#VBatt=12.98
17278: EVENT: ADC#VBatt=12.98
17456: EVENT: ADC#VBatt=12.98
17609: EVENT: BME280v#Temp=26.4
17768: EVENT: BME280v#Hum=22
17943: EVENT: BME280v#Pres=1032
18102: EVENT: System#Sleep
>> NetworkError when attempting to fetch resource. <<
I am using an ESP32 DEVKIT1 (modified with a Holtek low quiscent current voltage regulator)
running "ESP_Easy_mega_20211224_normal_ESP32_4M316k Dec 24 2021"

And this are the defined tasks - just for reference:
166-CC-Batt-Control.jpg
166-CC-Batt-Control.jpg (144.06 KiB) Viewed 6327 times

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

Re: Deepsleep delayed by >15secs when called from rule

#8 Post by TD-er » 27 Mar 2022, 22:29

It is for sure not intended to have multiple events keeping the device from entering deep sleep, but I think I can imagine why this may be happening.
But to be sure, I have to look at the code and this is actually the first time in quite a while I'm sitting behind my computer again (see the announcement topic, about me moving to a new home)
So I guess this might be a bug, but we need to find what's causing it.
I think having some kind of timeout to enter deep sleep no matter what is still a good feature to have as sending data from a controller queue may also take quite a while in the worst case scenario.

ao16
Normal user
Posts: 19
Joined: 03 Oct 2018, 23:51

Re: Deepsleep delayed by >15secs when called from rule

#9 Post by ao16 » 24 Apr 2022, 15:42

> So I guess this might be a bug, but we need to find what's causing it.

Thanks for this information and your looking into the code.

> first time in quite a while I'm sitting behind my computer again (see the announcement topic, about me moving to a new home)

Don't worry, take your time - I also was away now for some time due to other obligations.
Just got aware of your announcement topic and your moving - ouoo - hold your socks, that was indeed a challenge!!
I hope all worked well and you're settled again.

Regarding the deep sleep topic, currently I will workaround that 'prolonged delay before going into deep sleep'
by using a larger ratio of "deep sleep/awake" duty cycle to conserve my battery capacity as much as possible
but still get measurements in a reasonable time.

If there's once an update or the bug is found in the code, I will be happy to update my system then :-)

best regards and take care!

Post Reply

Who is online

Users browsing this forum: No registered users and 23 guests