Those years might actually be about 3h 30m exactly the same as the ESP8266.
When uint64_t was added back in May for the ESP8266 I asked Ivan (ESP god) on GitHub if deepSleep was now 585m years. I notice “Austrian Andreas” has 585K years. Similar crazy timeframe with a significant shift of decimal place somewhere along the lines.
My excuse is that working with 64 bit numbers on a regular calculator can be difficult and it’s easy to lose your way with the decimal place. My actual mistake was that deepSleep is in microseconds and not seconds. Taking this into account I concur with Andreas at just 585K years.
However just because a variable is set as a data type of uint64_t it doesn’t mean the firmware will use the full size of the data type, only that it is at least 1 unit bigger than the next smallest data type (uint32_t).
At uint32_t it was a little under 72m and for the ESP8266 the 585K years is actually around 3h 30m.
I believe the ESP32 has several RTC’s but the one associated with deepSleep appears to be 150Khz (0.15Mhz). This compares with a 26Mhz RTC for the ESP8266. IF the calculation for deepSleep is the same for the 2 models then the ESP32 could sleep for 173 times longer (26Mhz / 0.15Mhz). This would give 36330m or 25 days. Much longer but not 585K years
deepSleep for the ESP32 is confirmed as having the same 3% timing error as the ESP8266.
In years to come the ESP32 or it’s successor will be a popular chip, but revision 0 and even revision 1 released in Feb 2017 have some nasty bugs. It will be many years before all these chips disappear from the resellers in the Far East. Our advice, if you need ESP32 features and are prepared to work with the bugs then go with it, if not stick with ESP8266.
99.9% certain it’s approx 3.5 hours for the ESP8266 but it’s not an exact figure as it’s based on actual RTC speed and it varies not just from chip to chip but the same chip from second to second. I believe this is why you get the 3% error, but it’s always around 3% short, never longer.
I have used deepSleep on various projects for a few years. One has been on my desk flashing up an OLED for 12 months or more (72m intervals, which will be around 70 clock minutes) and I have been running the 3.5 hour version for the last few days on another ESP8266.
I don’t use the ESP32 so I can’t test deepSleep so it’s speculation as to the maximum duration but it’s safe to say it isn’t 585K years.
Edit: just as a reminder for most users it will be a little under 72m max deepSleep for ESP8266. The longer duration is from a different branch of the ESP8266 Arduino core.
Well, thanks to @Fettkeewl and @Jamin, I have some new (for me) ESP toys on the way, so I fully plan on learning how to do some of this OTA and DeepSleep stuff… much easer to assist others when I actually have a clue So heads up, I may come seeking your wisdom
@dandan ı read the post büt ı found some tricks
1- firstly , if you use deepsleep in setup function arduino will never go loop function and your timer will not trigger anytime.
2- you can go sleep more than 3.5 h with esp8266 but you can not set sleep time when use this long deepsleep time. You must to trigger gpio16 with external chip like ds3231.
3- light sleep or modemsleep not working as expected blynk with esp because chip can’t go light sleep because of server handling.
So If you need wakeup in exact time and need sleep more than 3.5h you need to use external etc.
Also if you need power management for Long battery time still need external rtc or another chip .
I think basic way is using ds3231 . It has alarm function and it can trigger esp8266 for waking forever deepsleep option.
Is there a way (within a repeated cycle of one hour of esp8266 deep sleep ) to wake up two units (!) of sleeping devices so they will sync to the exact time as the day - so they will wake up together the next “wakeup” times - even without any wifi connection … and go to sleep together … till next cycle.
I am using two wemos mini … and blynk RTC widget and blynk Bridge widget.
it should be like this :
//unit 1-code 1
1.wake up
2.if there is a wifi connection - get RTC and make compensation for next wake
3.blink an LED each second - for 10 seconds… ALSO - use blynk Bridge to
simultaneously ( as much as possible ) blink LED for 10 seconds on the 2nd device .
4.go to sleep for one hour.
//unit 2- code 2
1.wake up
2.if there is a wifi connection - get RTC and make compensation for next wake.
3.if there is a wifi connection -wait (=do nothing for 10sec) for unit 1 to bridge blink LED on both simultaneously.
if no connection - blink LED for 10 seconds.
4.go to sleep for one hour.
I’m guessing you don’t really want to blink an LED for 10 seconds as that sounds rather pointless.
Nonetheless yes it should work within a tolerance of a few seconds. All ESP’s are out by around 3% but they are not out by exactly the same amount of time. You will have to test and then one device will need to wait a few seconds for the other one to wake up.
So heads up, I may come seeking your wisdom 
