Deepsleep

DeepSleep support up to 136 Years (deepsleep=xxx [sec]). Support also 1day or more deepsleep. Just define deepsleep e.g. 1 day = 86400. (wakes up every hour for <0.3 seconds until time reached. just set deepsleep through serial or MQTT to a value in sec from 10 - 4.294.967.295 (136 Years :-))

The general ESP8266 has a limitation of ~71minutes maximum deepsleep. To overcome the limitation there is a small wakeup required, decrease remaining time and go to sleep again. The remaining time is stored in RTC memory. As long as the battery is connected this should work fine. It makes no sense to store in Flash, because of frequency and the start time to ready the flash takes much longer than RTC roundtrip.

The value of deepsleep defines the time where it wakes up. This cannot be changed! For example, if you define a deepsleep the device will wake-up exact at the full hour. e.g. 8:00am, 9:00am. If you define deepsleep 3600*24 it will wake-up exact at 0:00am UTC time. Not your local time. If deepsleep is 600 it will wake-up every 10 minutes. e.g. 8:00, 8:10, 8:20 and so on.

It also makes it easier to "reset". Just disconnect for a second from power and RTC is wiped on next reboot. Alternative you can define a deepsleep switch for temporarily disable deepsleep. See below.

Please be aware that minimum deepsleep time is 15 Seconds and that for a wakeup as always you have to connect the RST pin with the D0/GPIO16 pin because the wake-up signal is sent through D0/GPIO16 to RST

If you want temporary to disable the deepsleep mode you can use any PIN and connect this through a 10k resistor to ground. Also using the GPIO16 like in ESPeasy is valid. You can define the PIN in the configuration window as shown below.

If you want to execute some command or a special script BEFORE the device goes into deepsleep you can use FUNC_SAVE_BEFORE_RESTART as a predefined hook to implement your own procedure. For sure there is a code change required. If you want to use rules you can use the event System#Save. This will be executed just before deepsleep

General Timing of deepsleep algorithm

Let's assume you have set deepsleep to 3600 and teleperiod 300. The first start of the device will be 8:00 am. The device will start and connect Wifi. Next, a correct time must be got from one of the NTP server and a successful connect to MQTT must be established. Now the device has all prerequisites for going into deepsleep. The Trigger of a deepsleep is the TELEPERIOD event. In this case, the teleperiod will occur after 300seconds (5minutes). Data will be measured and send through MQTT. Now, deepsleep can happen. It changes the LWT topic on MQTT to Offline and calculates the new sleeping time to wake-up at 9:00 am (3600sec after the last wakeup). At 9:00 am all things happen again. If you want to minimize the uptime you can decrease TELEPERIOD down to 5 seconds. Time will count AFTER MQTT connected. Also, in this case, the device will wake up at 9:00 am even if the uptime was much smaller. If the device missed a wake-up it will try a start at the next event. In this case 10:00 am.

I found some side-effects on the WEMOS D1 that I want to share. I use one GPIO to trigger a BC337 transistor to switch OFF all of my connected devices during deepsleep. I found out that not all PIN behave the same during deepsleep. Some PINs go HIGH, some LOW, some FOLLOW the relay but work only on FET transistors. As soon as current flow they go LOW. Here is the list of found behavior (D0 excluded because of the wake-up pin):

• D1: KEEP STATE, go LOW if resistance to ground < infinite
• D2: KEEP STATE, go LOW if resistance to ground < infinite
• D3: HIGH
• D4: HIGH
• D5: HIGH, go LOW if resistance to ground < infinite
• D6: HIGH, go LOW if resistance to ground < infinite
• D7: HIGH, go LOW if resistance to ground < infinite
• D8: LOW

Explanation of loglevel 5 Output:

13:08:43 MQT: hm/status/sonoff/INFO3 = {"RestartReason":"Deep-Sleep Wake"}

MQTT connect set the system to READY. In this case, is TELEPERIOD=5, therefore in 5sec from now reporting will start.

13:08:44 APP: Boot Count 84

13:08:44 CFG: Saved to flash at F4, Count 96, Bytes 3824

TELEPERIOD==5 is reached, MQTT=UP and DATETIME is ok. Go for reporting

13:08:48 MQT: tele/sonoff/STATE = {"Time":"2019-09-04T13:08:48","Epoch":1567595328,"Uptime":"0T00:00:14","UptimeSec":14,"Heap":24,"SleepMode":"Dynamic ","Sleep":50,"LoadAvg":20,"MqttCount":1,"Wifi":{"AP":1,"SSId":"MyWLAN","BSSId":"AA:FF:AA:AA:AA:AA","Channel":11,"RSSI":100,"LinkCount":1,"Downtime" :"0T00:00:08","DeepSleep":300,"Heap":25160}}

13:08:48 MQT: tele/sonoff/SENSOR = {"Time":"2019-09-04T13:08:48","Epoch":1567595328,"ANALOG":{"A0":8}}

All send. Now start shutdown procedure. First, send MQTT offline

13:08:48 MQT: state/sonoff/LWT = Offline

Deepsleep is 300 sec. Therefore +-30 sec is allowed as the deviation between proposed time between wakeup and real-time between wakeup. Reporting in 0.1sec. In this case wakeup was 1 sec late.

13:08:48 Timeslip 0.1 sec:? -300 < -10 < 300

If the error is in the range this is tagged as a normal wakeup where drift can we recalculated

13:08:48 Normal deepsleep? 1

Recalculate a new drift that is a multiplier for the next wakeup in 1/10000. In this case, the multiplier is 1.0257

13:08:48 % RTC new drift 10257

Just for information: New target wakeup time

13:08:48 Next wakeup 2019-09-04T13:13:33

Based on runtime and the error in the last loop a new sleeping time will be calculated. This will be multiplied with the deepsleep_slip and ideally, the device will wake up at the time above.

13:08:48 Sleeptime 285 sec, deepsleep_slip 10257

The effectiveness of the compensation can be seen here. Instead of typically 160-200sec you get it most time better than 10sec. In a 1h deepsleep cycle