starred/OpenEPaperLink
1
0
Fork 0
mirror of https://github.com/OpenEPaperLink/OpenEPaperLink.git synced 2026-03-21 00:04:28 +01:00
Code Issues 472 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #525] New dayahead refresh stops around 13:45 every day #885

New Issue
Closed
opened 2026-03-20 18:14:01 +01:00 by sascha_hemi · 9 comments
sascha_hemi commented 2026-03-20 18:14:01 +01:00
Owner
Copy Link

Originally created by @cthulu on GitHub (Nov 16, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525

Hi, based on suggestion from @benv666 I am raising this as a new issue. I've forked the current master and tagged it to create my own release using GH Actions. This is thus no different to what is in master right now.

After installing this on my Yellow AP I was able to get the dayahead pricing showing with 15 mins intervals on my tags. But strangely, this refresh seems to stop every day around 13:45 or 14:15 and I have no idea why this happens. Force refreshes or AP reboot doesn't fix it until the new day starts.

I am not sure why this is happening. The only suspicious fact is that new price data is usually available around 13-14:00 but that didn't cause issues in the past.

@benv666 sorry to bug you here but with the changes merged in master and installed, In my setup the refresh stops at 13:45 or 14:15. It happened a few days after eachother. Can it be that there is some issue upstream, as I believe the new prices are known around 13-14:00. I think there is a Google Script that might be failing or something?

I have 4 tags here displaying the prices (with various settings), they've been running fine for weeks on my desk next to the AP.
A week ago the AP was moved to a different floor (in order to improve coverage there), but now the ones on my desk occasionally stop updating until I press a button (on the 4.2" ones) to force a refresh on them. Weirder, when they refresh they seem to pick up old timestamps (e.g. from 11:00 -> 11:!5 -> 11:30 while it's already 17:00)
Not exactly sure what's going on there, I'll try to dive into this, but don't have a lot of spare time on my hands right now.
Either way I'd argue this warrants a new ticket, and might be unrelated to the pricing update itself. (other than causing more refreshes).

Originally posted by @benv666 in #517

Originally created by @cthulu on GitHub (Nov 16, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525 Hi, based on suggestion from @benv666 I am raising this as a new issue. I've forked the current `master` and tagged it to create my own release using GH Actions. This is thus no different to what is in `master` right now. After installing this on my Yellow AP I was able to get the dayahead pricing showing with 15 mins intervals on my tags. But strangely, this refresh seems to stop every day around 13:45 or 14:15 and I have no idea why this happens. Force refreshes or AP reboot doesn't fix it until the new day starts. I am not sure why this is happening. The only suspicious fact is that new price data is usually available around 13-14:00 but that didn't cause issues in the past. > [@benv666](https://github.com/benv666) sorry to bug you here but with the changes merged in master and installed, In my setup the refresh stops at 13:45 or 14:15. It happened a few days after eachother. Can it be that there is some issue upstream, as I believe the new prices are known around 13-14:00. I think there is a Google Script that might be failing or something? > > I have 4 tags here displaying the prices (with various settings), they've been running fine for weeks on my desk next to the AP. > A week ago the AP was moved to a different floor (in order to improve coverage there), but now the ones on my desk occasionally stop updating until I press a button (on the 4.2" ones) to force a refresh on them. Weirder, when they refresh they seem to pick up old timestamps (e.g. from 11:00 -> 11:!5 -> 11:30 while it's already 17:00) > Not exactly sure what's going on there, I'll try to dive into this, but don't have a lot of spare time on my hands right now. > Either way I'd argue this warrants a new ticket, and might be unrelated to the pricing update itself. (other than causing more refreshes). _Originally posted by @benv666 in [#517](https://github.com/OpenEPaperLink/OpenEPaperLink/issues/517#issuecomment-3538503539)_
sascha_hemi added the bug label 2026-03-20 18:14:01 +01:00
sascha_hemi commented 2026-03-20 18:14:02 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 17, 2025):

This is also present in the latest released firmware 2.84. I have re-configured a tag, made it 'dayahead prices' and it fails to refresh after 14:15. Also, all other tags stay frozen at 14:00 and the AP restarts frequently.

<!-- gh-comment-id:3542371856 --> @cthulu commented on GitHub (Nov 17, 2025): This is also present in the latest released firmware 2.84. I have re-configured a tag, made it 'dayahead prices' and it fails to refresh after 14:15. Also, all other tags stay frozen at 14:00 and the AP restarts frequently.
sascha_hemi commented 2026-03-20 18:14:02 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 17, 2025):

This is on the serial if I force-refresh the dayahead tag after 14:00:

gACK> ok, 32ms
I (58642) MAIN: RDY? In
zlib: compressed 6 into 0 bytes in 0 ms
Guru Meditation Error: Core  1 panic'ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (loopTask)
Core  1 register dump:
PC      : 0x400570ea  PS      : 0x00060f36  A0      : 0x8205b4e8  A1      : 0x3fcea0d0
A2      : 0x3fcea10c  A3      : 0x00000000  A4      : 0x00000084  A5      : 0x3fcea11c
A6      : 0x00000005  A7      : 0x00000008  A8      : 0x00000000  A9      : 0x00000020
A10     : 0x00060123  A11     : 0x00000000  A12     : 0x00060120  A13     : 0x00000000
A14     : 0x02cee2cc  A15     : 0x00ffffff  SAR     : 0x00000020  EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000  LBEG    : 0x400570e8  LEND    : 0x400570f3  LCOUNT  : 0x00000006


Backtrace: 0x400570e7:0x3fcea0d0 0x4205b4e5:0x3fcea0e0 0x4205bd30:0x3fceb6b0 0x4205c540:0x3fceb970 0x4205cf7e:0x3fceb9a0 0x42022fb2:0x3fceba00 0x42023ba5:0x3fceba30 0x4201be4a:0x3fcebc80 0x4201f22d:0x3fcedca0 0x4201f79d:0x3fceded0 0x42022953:0x3fcedf60 0x420621b1:0x3fcedfa0




ELF file SHA256: 33be6dc1890c87d8

Rebooting...
<!-- gh-comment-id:3542422070 --> @cthulu commented on GitHub (Nov 17, 2025): This is on the serial if I force-refresh the dayahead tag after 14:00: ``` gACK> ok, 32ms I (58642) MAIN: RDY? In zlib: compressed 6 into 0 bytes in 0 ms Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception). Debug exception reason: Stack canary watchpoint triggered (loopTask) Core 1 register dump: PC : 0x400570ea PS : 0x00060f36 A0 : 0x8205b4e8 A1 : 0x3fcea0d0 A2 : 0x3fcea10c A3 : 0x00000000 A4 : 0x00000084 A5 : 0x3fcea11c A6 : 0x00000005 A7 : 0x00000008 A8 : 0x00000000 A9 : 0x00000020 A10 : 0x00060123 A11 : 0x00000000 A12 : 0x00060120 A13 : 0x00000000 A14 : 0x02cee2cc A15 : 0x00ffffff SAR : 0x00000020 EXCCAUSE: 0x00000001 EXCVADDR: 0x00000000 LBEG : 0x400570e8 LEND : 0x400570f3 LCOUNT : 0x00000006 Backtrace: 0x400570e7:0x3fcea0d0 0x4205b4e5:0x3fcea0e0 0x4205bd30:0x3fceb6b0 0x4205c540:0x3fceb970 0x4205cf7e:0x3fceb9a0 0x42022fb2:0x3fceba00 0x42023ba5:0x3fceba30 0x4201be4a:0x3fcebc80 0x4201f22d:0x3fcedca0 0x4201f79d:0x3fceded0 0x42022953:0x3fcedf60 0x420621b1:0x3fcedfa0 ELF file SHA256: 33be6dc1890c87d8 Rebooting... ```
sascha_hemi commented 2026-03-20 18:14:02 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 18, 2025):

Same issue if I disabled the BLE functionality. Can it be that the amount of data available post 14:00 is too much to fit?

<!-- gh-comment-id:3547821333 --> @cthulu commented on GitHub (Nov 18, 2025): Same issue if I disabled the BLE functionality. Can it be that the amount of data available post 14:00 is too much to fit?
sascha_hemi commented 2026-03-20 18:14:03 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 19, 2025):

Okay I think the problem is quite tricky:

  1. I did have an older setup of the tag and I've opened the web interface on my mobile
  2. I think the HTML/JS assests were cached as it did not show the new config options (Display interval and Cheap block hours)
  3. I've hit save and for some reason this was causing issues after 14:00

When I've opened the Web interface in an incognito window on the desktop, I saw the new config options and I've set them to some value. After saving, the refresh started working.

So I think there was some kind of corruption of the settings - they may have been incompletely saved in the Tag DB, leading to some memory curruption downstream?

<!-- gh-comment-id:3552795150 --> @cthulu commented on GitHub (Nov 19, 2025): Okay I think the problem is quite tricky: 1. I did have an older setup of the tag and I've opened the web interface on my mobile 2. I think the HTML/JS assests were cached as it did not show the new config options (`Display interval` and `Cheap block hours`) 3. I've hit save and for some reason this was causing issues after 14:00 When I've opened the Web interface in an incognito window on the desktop, I saw the new config options and I've set them to some value. After saving, the refresh started working. So I think there was some kind of corruption of the settings - they may have been incompletely saved in the Tag DB, leading to some memory curruption downstream?
sascha_hemi commented 2026-03-20 18:14:03 +01:00
Author
Owner
Copy Link

@nlimper commented on GitHub (Nov 19, 2025):

That's a great find, thanks!
IMHO, it would be better for the AP to fail gracefully without crashing when the parameter is not set (by using some default value). More people will experience the same situation, causing it to be a repeating support question.
@benv666 if you got a chance, it would be great to have it fixed.

<!-- gh-comment-id:3552825339 --> @nlimper commented on GitHub (Nov 19, 2025): That's a great find, thanks! IMHO, it would be better for the AP to fail gracefully without crashing when the parameter is not set (by using some default value). More people will experience the same situation, causing it to be a repeating support question. @benv666 if you got a chance, it would be great to have it fixed.
sascha_hemi commented 2026-03-20 18:14:03 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 19, 2025):

I am not 100% absolutely sure the missing setting was the actual issue, but after setting it things have started to work ¯\_(ツ)_/¯

<!-- gh-comment-id:3552833763 --> @cthulu commented on GitHub (Nov 19, 2025): I am not 100% absolutely sure the missing setting was the actual issue, but after setting it things have started to work `¯\_(ツ)_/¯`
sascha_hemi commented 2026-03-20 18:14:04 +01:00
Author
Owner
Copy Link

@benv666 commented on GitHub (Nov 19, 2025):

@cthulu Great find indeed, that's something to go on.
@nlimper Will try to make a fix coming weekend, won't have much time before then.

Thought I checked for the existance of these config values and had defaults, but might have missed one - to be continued.

<!-- gh-comment-id:3552915190 --> @benv666 commented on GitHub (Nov 19, 2025): @cthulu Great find indeed, that's something to go on. @nlimper Will try to make a fix coming weekend, won't have much time before then. Thought I checked for the existance of these config values and had defaults, but might have missed one - to be continued.
sascha_hemi commented 2026-03-20 18:14:04 +01:00
Author
Owner
Copy Link

@benv666 commented on GitHub (Nov 23, 2025):

I've been trying to come up with a few scenarios that might have triggered the stack overflow posted by @cthulu:
There were 3 settings added by my code, updatefreq, interval, and cheapblock

updatefreq is unlikely to be your issue, it would only manifest in weird update intervals.
cheapblock I'm also combing over, but this one has bound checks in place, so probably not the issue.

The ~14:00 issue indicates having a lot of samples, so most likely the averaging code had to deal with an interesting value for the interval setting is my guess, especially if parsing the absent value led to a high number in targetIntervalMinutes. The code expects either 0, 30 or 60 there - and assumed it wasn't anything else. That said, the usual "load setting" checking was in place there, but it's possible that an empty value or some other unexpected thing got stored regardless, and then parsed in interesting ways.

I'm going to add a few sanity and bounds checks to make this more robust, won't be finished today though. WIP.
(also would like to be able to reproduce the new settings load error to confirm this was the problem)

<!-- gh-comment-id:3567973469 --> @benv666 commented on GitHub (Nov 23, 2025): I've been trying to come up with a few scenarios that might have triggered the stack overflow posted by @cthulu: There were 3 settings added by my code, `updatefreq`, `interval`, and `cheapblock` `updatefreq` is unlikely to be your issue, it would only manifest in weird update intervals. `cheapblock` I'm also combing over, but this one has bound checks in place, so probably not the issue. The ~14:00 issue indicates having a lot of samples, so most likely the averaging code had to deal with an interesting value for the `interval` setting is my guess, especially if parsing the absent value led to a high number in targetIntervalMinutes. The code expects either 0, 30 or 60 there - and assumed it wasn't anything else. That said, the usual "load setting" checking was in place there, but it's possible that an empty value or some other unexpected thing got stored regardless, and then parsed in interesting ways. I'm going to add a few sanity and bounds checks to make this more robust, won't be finished today though. WIP. (also would like to be able to reproduce the new settings load error to confirm this was the problem)
sascha_hemi commented 2026-03-20 18:14:04 +01:00
Author
Owner
Copy Link

@cthulu commented on GitHub (Nov 23, 2025):

Definitely an interesting find! Thanks for checking that out.

On Sun, 23 Nov 2025 at 14:47, BenV @.***> wrote:

benv666 left a comment (OpenEPaperLink/OpenEPaperLink#525)
https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525#issuecomment-3567973469

I've been trying to come up with a few scenarios that might have triggered
the stack overflow posted by @cthulu https://github.com/cthulu:
There were 3 settings added by my code, updatefreq, interval, and
cheapblock

updatefreq is unlikely to be your issue, it would only manifest in weird
update intervals.
cheapblock I'm also combing over, but this one has bound checks in place,
so probably not the issue.

The ~14:00 issue indicates having a lot of samples, so most likely the
averaging code had to deal with an interesting value for the interval
setting is my guess, especially if parsing the absent value led to a high
number in targetIntervalMinutes. The code expects either 0, 30 or 60 there

  • and assumed it wasn't anything else. That said, the usual "load setting"
    checking was in place there, but it's possible that an empty value or some
    other unexpected thing got stored regardless, and then parsed in
    interesting ways.

I'm going to add a few sanity and bounds checks to make this more robust,
won't be finished today though. WIP.
(also would like to be able to reproduce the new settings load error to
confirm this was the problem)

—
Reply to this email directly, view it on GitHub
https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525#issuecomment-3567973469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAI7OEEK7GZJMHFCQH2R35D36G3GVAVCNFSM6AAAAACMIUDEVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRXHE3TGNBWHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

<!-- gh-comment-id:3568016202 --> @cthulu commented on GitHub (Nov 23, 2025): Definitely an interesting find! Thanks for checking that out. On Sun, 23 Nov 2025 at 14:47, BenV ***@***.***> wrote: > *benv666* left a comment (OpenEPaperLink/OpenEPaperLink#525) > <https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525#issuecomment-3567973469> > > I've been trying to come up with a few scenarios that might have triggered > the stack overflow posted by @cthulu <https://github.com/cthulu>: > There were 3 settings added by my code, updatefreq, interval, and > cheapblock > > updatefreq is unlikely to be your issue, it would only manifest in weird > update intervals. > cheapblock I'm also combing over, but this one has bound checks in place, > so probably not the issue. > > The ~14:00 issue indicates having a lot of samples, so most likely the > averaging code had to deal with an interesting value for the interval > setting is my guess, especially if parsing the absent value led to a high > number in targetIntervalMinutes. The code expects either 0, 30 or 60 there > - and assumed it wasn't anything else. That said, the usual "load setting" > checking was in place there, but it's possible that an empty value or some > other unexpected thing got stored regardless, and then parsed in > interesting ways. > > I'm going to add a few sanity and bounds checks to make this more robust, > won't be finished today though. WIP. > (also would like to be able to reproduce the new settings load error to > confirm this was the problem) > > — > Reply to this email directly, view it on GitHub > <https://github.com/OpenEPaperLink/OpenEPaperLink/issues/525#issuecomment-3567973469>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAI7OEEK7GZJMHFCQH2R35D36G3GVAVCNFSM6AAAAACMIUDEVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRXHE3TGNBWHE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
88MZ100 FW
ARM Tag FW
ap fw
bug
documentation
enhancement
good first issue
nRF FW
pull-request
Mirrored from GitHub Pull Request
 question
tag fw
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sascha_hemi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#885
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?