Repository navigation
Deep sleep wake interval drifts ~9-11s per hour (consistently early) on reTerminal E1001 #42
Description
Hardware: reTerminal E1001
Firmware: OpenDisplay 0D7CB085, FW 0 1.71
Sleep configuration: Deep sleep, wake interval set to 60 minutes
Description
The device wakes up consistently earlier than the configured 60 minute interval. Posting the log data in case it's useful for tracking this down.
Observed data
I run a daemon on a Raspberry Pi that listens for the device's BLE advertisement and logs the timestamp on each wake. Over a 29 hour window (29 consecutive wake cycles), I measured the interval between wakes:
Expected interval: 3600 s (60 min)
Actual interval: consistently between 3585 s and 3595 s
Average interval: ~3590 s
Average drift: -9.7 s per cycle (i.e. about 0.27% fast)
Drift is consistent cycle to cycle, not randomly scattered between -5s and -15s.
Sample log (timestamps from BLE advertisement reception on the Pi side):
2026-06-19 03:05:10
2026-06-19 04:04:57 (Δ 3587s, drift -13s)
2026-06-19 05:04:52 (Δ 3595s, drift -5s)
2026-06-19 06:04:44 (Δ 3592s, drift -8s)
2026-06-19 07:04:35 (Δ 3591s, drift -9s)
...
2026-06-20 07:00:39 (Δ 3591s, drift -9s)
2026-06-20 08:00:28 (Δ 3589s, drift -11s)
Over the full 29 cycle window, total drift was -282 s, i.e. roughly 9.7 s lost per hour on average.
Additional notes
The drift seems pretty consistent cycle to cycle (always somewhere between -5 s and -15 s), rather than jumping around randomly. Not sure if that's expected behavior or something worth looking into.
Happy to provide more log data, battery voltage readings, or test a patched build if that would help.
Activity
jonasniesner commentedon Jun 20, 2026
Thank you for reporting it. Is that a problem for your application/do you need the wakeup to be synchronised with something specific? You are actually one of the first using deep sleep so there might still be some things to iron out.
Bortinio commentedon Jun 20, 2026
@jonasniesner Thanks for the quick reply!
Yes, it does matter for my use case. My setup generates a fresh dashboard about 5 minutes before the full hour. The idea was to have the display wake up right at the full hour, so it picks up the freshly generated dashboard within the ~2 minute BLE advertising window via my daemon.
With a drift of about 9-10s per hour (so roughly 230s/day), that 5 minute buffer gets eaten up after about 1-2 days. After that, the device would wake up before the new dashboard is even generated, and would just get served the previous (now outdated) one.
So for my application it's not just cosmetic, it actually breaks the sync within a couple of days and I'd need to manually realign the wake time again.
Highly appreciating your efforts here and happy to help test anything if that's useful.
jonasniesner commentedon Jun 20, 2026
I will have to think about a solution for your usecase in this case. Do you use py-opendisplay or your own integration? For your usecase a "next update at" would probably better then a static sleep time.
Bortinio commentedon Jun 20, 2026
Yes, I'm using py-opendisplay as the base for my integration.
A "next update at" approach instead of a static sleep duration sounds like it would solve this nicely, that way the device could align itself to the actual data refresh instead of relying on a fixed interval staying accurate over time.
As far as I can tell, py-opendisplay currently only exposes the static sleep interval via the device config (write_config), there's no concept of a target wake timestamp in the library yet, right? So that part would likely need to be added on both the firmware and library side?
jonasniesner commentedon Jun 20, 2026
Yes, this would need to be added to both, firmware and py-opendisplay. And I will do that now that I know that there is a a usecase for it. I just focused more on the NRF side of the firmware for now because it does not need any workarounds like the ESP side does. But since this is mostly feature complete, I have more time to improve the ESP side
Bortinio commentedon Jun 20, 2026
That’s great to hear, thanks for taking this on! Let me know whenever there’s something to test, happy to try it on my E1001 setup.
IDragonfire commentedon Jul 6, 2026
I have the same use case, If I should test something, let me know.
davelee98 commentedon Jul 30, 2026
There have been many improvements to firmware. That said, ultimately the deep sleep timer is based on a millis() tick, and not an actual clock. So there is meaningful drift vs. an actual clock. There is no good way to fix this without a hardware clock that I can think of.
andreasbrett commentedon Jul 31, 2026
What if we allow deep sleep duration to be manually set from HA through a service call (=overriding the current cycle's deep sleep interval)? Once device wakes up*, an HA automation could calculate seconds until next wake up (based on HAs clock), then send that deep sleep duration to the device. That way we can bring drift back to course once it crosses a certain threshold (or always) and it also allows for dynamic deep sleep intervals to shave off some more mAhs. I personally would love to not have my displays wake up at night for example. If I could send them to sleep for 6h at night, that would save precious battery.
*) I would love if there was an event entity that exposes events like "going to sleep for x seconds" or "woke up from sleep after x seconds"
davelee98 commentedon Jul 31, 2026