[GH-ISSUE #255] Calendar always generates a new image #695

Closed
opened 2026-03-20 18:11:48 +01:00 by sascha_hemi · 2 comments
Owner

Originally created by @jhbruhn on GitHub (Mar 1, 2024).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/255

Originally assigned to: @nlimper on GitHub.

Describe the bug
The Calendar type always generates and queues a new image, even if the contents have not changed. The display updates, but no blocks are transferred.

To Reproduce
Steps to reproduce the behavior:

  1. Configure a calendar tag
  2. set the interval to 2 minutes so it is easily observable
  3. do not change the calendar events the image is based on
  4. observe the logs to see that the image is generated every 2 minutes

Expected behavior
Images should only be updated and queued if the contents change.

Additional context
latest 2.5 beta 3, my M2 2.9" (fw: 38 0x26), >= 2.6V, LUTs: auto

10:01:53 000002BCD3D53B1A reports xfer complete
10:01:30 new image: /current/000002BCD3D53B1A_689082.pending
10:01:28 get calendar
10:01:28 Updating 000002BCD3D53B1A
10:00:14 00000218CEDD3B10 reports xfer complete
09:59:16 new image: /current/00000218CEDD3B10_554997.pending
09:59:12 get calendar
09:59:12 Updating 00000218CEDD3B10
09:59:01 0000028E21477434 reports xfer complete
09:58:34 new image: /current/0000028E21477434_513302.pending
09:58:27 get calendar
09:58:27 Updating 0000028E21477434
09:54:22 00000218CEDD3B10 reports xfer complete
09:54:14 new image: /current/00000218CEDD3B10_252497.pending
09:54:12 get calendar
09:54:12 Updating 00000218CEDD3B10
Originally created by @jhbruhn on GitHub (Mar 1, 2024). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/255 Originally assigned to: @nlimper on GitHub. **Describe the bug** The Calendar type always generates and queues a new image, even if the contents have not changed. The display updates, but no blocks are transferred. **To Reproduce** Steps to reproduce the behavior: 1. Configure a calendar tag 2. set the interval to 2 minutes so it is easily observable 3. do not change the calendar events the image is based on 4. observe the logs to see that the image is generated every 2 minutes **Expected behavior** Images should only be updated and queued if the contents change. **Additional context** latest 2.5 beta 3, my M2 2.9" (fw: 38 0x26), >= 2.6V, LUTs: auto ``` 10:01:53 000002BCD3D53B1A reports xfer complete 10:01:30 new image: /current/000002BCD3D53B1A_689082.pending 10:01:28 get calendar 10:01:28 Updating 000002BCD3D53B1A 10:00:14 00000218CEDD3B10 reports xfer complete 09:59:16 new image: /current/00000218CEDD3B10_554997.pending 09:59:12 get calendar 09:59:12 Updating 00000218CEDD3B10 09:59:01 0000028E21477434 reports xfer complete 09:58:34 new image: /current/0000028E21477434_513302.pending 09:58:27 get calendar 09:58:27 Updating 0000028E21477434 ``` ``` 09:54:22 00000218CEDD3B10 reports xfer complete 09:54:14 new image: /current/00000218CEDD3B10_252497.pending 09:54:12 get calendar 09:54:12 Updating 00000218CEDD3B10 ```
sascha_hemi added the bugap fw labels 2026-03-20 18:11:48 +01:00
Author
Owner

@jjwbruijn commented on GitHub (Mar 6, 2024):

The behaviour on the AP side might change in the future, for now,

Updating to v0027 of the Tag FW will stop the 'refresh' of the image at least

https://github.com/jjwbruijn/OpenEPaperLink/wiki/M2-Tag-Firmware-changelog

<!-- gh-comment-id:1981495686 --> @jjwbruijn commented on GitHub (Mar 6, 2024): The behaviour on the AP side might change in the future, for now, Updating to v0027 of the Tag FW will stop the 'refresh' of the image at least https://github.com/jjwbruijn/OpenEPaperLink/wiki/M2-Tag-Firmware-changelog
Author
Owner

@nlimper commented on GitHub (Mar 18, 2024):

fixed

<!-- gh-comment-id:2004257331 --> @nlimper commented on GitHub (Mar 18, 2024): fixed
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#695