mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #543] Crazy next update times #2555
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#2555
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @skiphansen on GitHub (Jan 20, 2026).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/543
Just saw the above. The configured update times for the tags are:
021F822A3B17 hourly updates, 7E22CC6BB294 30 min, 4467090000361816 every hour, 4467090000029884 every 3 hours, 7290810422600 every three hours.
I have no idea now to reproduce it.
A few days ago I changed the update time on 7290810422600 from once an hour to every three hours and the tag stopped updating for several days before I reset it. I now suspect the AP sent a bogus sleep time to the tag and it was sleeping for way more than one hour.
I'm running a local build from commit
bfff2ef0b9.After a while 7E22CC6BB294 seems to have updated correctly, but the next update time is still crazy.
@nlimper commented on GitHub (Jan 20, 2026):
It looks like it works as designed, except for the situation you described with the tag that stopped updating.
You can set 'Maximum sleep' in the config to make it sleep shorter if you prefer, apparently it's currently set at 1 hour. The sleep can be even longer if 'No updates between' is configured.
To debug, have a look at the serial output. There, the amount of time that a tag is set to sleep is mentioned. The sleep command is generated 10 seconds before the expected next update time, if I remember it correctly, so as soon as the tag wakes up, it is put to sleep again, for a timespan that takes into account the max sleep time, the 'no updates between' time, and the expected next update time.
@skiphansen commented on GitHub (Jan 21, 2026):
Thanks Nic ... I'm afraid I had a senor moment when I created this ticket ... I was reading the next update as the number of hours until an update rather than the time of day for the next update! Ugh.
In any case I now have a serial port and reset connected on my tag that froze and I'll try to duplicate freeze.
Of course it had to be the tag that I had recently put in a picture frame. Taking it apart to reset it was annoying but I won't have to do that again until I need to change the batteries.