[GH-ISSUE #290] Feature request: Keep set TTL #717

New Issue

sascha_hemi · 2026-03-20T18:12:10+01:00

sascha_hemi commented

2026-03-20 18:12:10 +01:00

Originally created by @schlaggi on GitHub (Apr 9, 2024).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/290

Originally assigned to: @nlimper on GitHub.

Is your feature request related to a problem? Please describe.
I can set the TTL (in my case via Home Assistant) and it's being honored one time. If no update comes the TTL falls back to the TTL set by the AP.

Describe the solution you'd like
Keep the set TTL indefinitely until changed.

Describe alternatives you've considered
I tried rerunning the HA script before the TTL has run out, but the TTL wasn't set again. Maybe this could be an alternative solution.

Originally created by @schlaggi on GitHub (Apr 9, 2024). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/290 Originally assigned to: @nlimper on GitHub. **Is your feature request related to a problem? Please describe.** I can set the TTL (in my case via Home Assistant) and it's being honored one time. If no update comes the TTL falls back to the TTL set by the AP. **Describe the solution you'd like** Keep the set TTL indefinitely until changed. **Describe alternatives you've considered** I tried rerunning the HA script before the TTL has run out, but the TTL wasn't set again. Maybe this could be an alternative solution.

sascha_hemi added the enhancement label 2026-03-20 18:12:10 +01:00

sascha_hemi closed this issue

2026-03-20 18:12:10 +01:00

sascha_hemi commented

2026-03-20 18:12:11 +01:00

@nlimper commented on GitHub (Apr 9, 2024):

Check your setting in the AP for 'Maximum sleepandShorten latency during config'. The TTL will never be longer than the maximum sleep time, and because HA is using a websockets connection, 'Shorten latency during config' should be disabled.

@nlimper commented on GitHub (Apr 9, 2024): Check your setting in the AP for 'Maximum sleep` and `Shorten latency during config'. The TTL will never be longer than the maximum sleep time, and because HA is using a websockets connection, 'Shorten latency during config' should be disabled.

sascha_hemi commented

2026-03-20 18:12:11 +01:00

@schlaggi commented on GitHub (Apr 9, 2024):

Thank you!
I set the maximum sleep time in the AP to 1 hour because I want most of the tags to sleep as long as possible. But the tags controlled by HA should check in more often to be up-to-date which I control via the TTL in the HA script. This works but as I said only once.
I expected the tags to keep the set TTL and not fall back to the maximum sleep time.

@schlaggi commented on GitHub (Apr 9, 2024): Thank you! I set the maximum sleep time in the AP to 1 hour because I want most of the tags to sleep as long as possible. But the tags controlled by HA should check in more often to be up-to-date which I control via the TTL in the HA script. This works but as I said only once. I expected the tags to keep the set TTL and not fall back to the maximum sleep time.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@nlimper commented on GitHub (Apr 9, 2024):

What value do you use for TTL?

@nlimper commented on GitHub (Apr 9, 2024): What value do you use for TTL?

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@schlaggi commented on GitHub (Apr 9, 2024):

I currently use 10 minutes.

@schlaggi commented on GitHub (Apr 9, 2024): I currently use 10 minutes.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@nlimper commented on GitHub (Apr 9, 2024):

Sorry, '10 minutes' is not a valid value for the parameter. I sounds like nitpicking, but to be able to reproduce, and to avoid having to search for errors that are potentially not there, I like to have a clear idea about the parameters you are using. When you answer '10 minutes' I still don't know if you maybe set TTL=600 because you expect the units are in seconds, etc.

@nlimper commented on GitHub (Apr 9, 2024): Sorry, '10 minutes' is not a valid value for the parameter. I sounds like nitpicking, but to be able to reproduce, and to avoid having to search for errors that are potentially not there, I like to have a clear idea about the parameters you are using. When you answer '10 minutes' I still don't know if you maybe set TTL=600 because you expect the units are in seconds, etc.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@schlaggi commented on GitHub (Apr 9, 2024):

Sorry here is a copy of some of the code from what I use in HA:

service: open_epaper_link.drawcustom
target:
  entity_id: open_epaper_link.AABBCCDDEEFF112233
data:
  background: white
  rotate: 0
  ttl: 10
  payload:
    <some text and multiline payload>

I initially expected the TTL to be in seconds but it obviously is in minutes which is perfectly fine.
I can see on the AP webpage that the next check in for the tag is set to 10 minutes instead of 60. But after the first ten minutes this is falling back to 60 minutes if there hasn't been an update that included the TTL and forced the tag to change something on the screen.

@schlaggi commented on GitHub (Apr 9, 2024): Sorry here is a copy of some of the code from what I use in HA: ``` service: open_epaper_link.drawcustom target: entity_id: open_epaper_link.AABBCCDDEEFF112233 data: background: white rotate: 0 ttl: 10 payload: <some text and multiline payload> ``` I initially expected the TTL to be in seconds but it obviously is in minutes which is perfectly fine. I can see on the AP webpage that the next check in for the tag is set to 10 minutes instead of 60. But after the first ten minutes this is falling back to 60 minutes if there hasn't been an update that included the TTL _and_ forced the tag to change something on the screen.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@nlimper commented on GitHub (Apr 9, 2024):

Thanks, I will look in to it.

@nlimper commented on GitHub (Apr 9, 2024): Thanks, I will look in to it.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@waroen commented on GitHub (Apr 9, 2024):

Hi,

I can reproduce the exact same problem here, as long as there is an updated image the ttl is kept, but if the automations miss one update or they get out of sync and there isn't an update when the ttl expires it goes to the default.

I'm trying to save on the battery so I've set the maximum sleep to 1 hour. Then trying to control it, as the issue states by setting the TTL in HA.

I'd expect it to keep the same update interval as for the last image.

@waroen commented on GitHub (Apr 9, 2024): Hi, I can reproduce the exact same problem here, as long as there is an updated image the ttl is kept, but if the automations miss one update or they get out of sync and there isn't an update when the ttl expires it goes to the default. I'm trying to save on the battery so I've set the maximum sleep to 1 hour. Then trying to control it, as the issue states by setting the TTL in HA. I'd expect it to keep the same update interval as for the last image.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@baschi29 commented on GitHub (Apr 29, 2024):

I'm also able to reproduce the issue.

However after the ttl the default it falls back to seems to be 1 minute instead of the mentioned 60 minutes. I already set max sleep to 1 hour and shorten latency during config is turned off. Is there a way to change the default behavior of the tag for the meantime? Currently it consumes a lot of battery very quickly.

@baschi29 commented on GitHub (Apr 29, 2024): I'm also able to reproduce the issue. However after the ttl the default it falls back to seems to be 1 minute instead of the mentioned 60 minutes. I already set max sleep to 1 hour and shorten latency during config is turned off. Is there a way to change the default behavior of the tag for the meantime? Currently it consumes a lot of battery very quickly.

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@nlimper commented on GitHub (Apr 29, 2024):

To avoid confusion: Checking in every one minute (the default) doesn’t draw much current (if you don’t send a new image). With that, the battery is estimated 5 years life.
The checking in time is by design: with setting the TTL during upload, you tell the AP that the image is valid for at least that time. After the time runs out, the check falls back to the default, because the tag can expect a few image shortly. If, at that point, you are sure that the image is valid for a certain time again, you can push the same image with a new TTL. ( if you push the same image, the tag will not transfer the image, and will not refresh).

@nlimper commented on GitHub (Apr 29, 2024): To avoid confusion: Checking in every one minute (the default) doesn’t draw much current (if you don’t send a new image). With that, the battery is estimated 5 years life. The checking in time is by design: with setting the TTL during upload, you tell the AP that the image is valid for at least that time. After the time runs out, the check falls back to the default, because the tag can expect a few image shortly. If, at that point, you are sure that the image is valid for a certain time again, you can push the same image with a new TTL. ( if you push the same image, the tag will not transfer the image, and will not refresh).

sascha_hemi commented

2026-03-20 18:12:12 +01:00

@baschi29 commented on GitHub (Apr 29, 2024):

Alright, thanks for your detailled answer!

How does the check work if one pushed the same image? By filename/metadata or by image contents?

@baschi29 commented on GitHub (Apr 29, 2024): Alright, thanks for your detailled answer! How does the check work if one pushed the same image? By filename/metadata or by image contents?

sascha_hemi commented

2026-03-20 18:12:13 +01:00

@nlimper commented on GitHub (Apr 29, 2024):

The Md5 hash of the image. The last few images are kept in the storage of the tag. The AP tells the tag that there is a new image available with md5 xxxxxx. If the tag has the image in the cache, it displays the image without transferring the data.

@nlimper commented on GitHub (Apr 29, 2024): The Md5 hash of the image. The last few images are kept in the storage of the tag. The AP tells the tag that there is a new image available with md5 xxxxxx. If the tag has the image in the cache, it displays the image without transferring the data.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#717