[GH-ISSUE #85] Displays getting stuck on "Waiting for data" after associating #588

New Issue

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

sascha_hemi commented

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

Originally created by @Ennar1991 on GitHub (Jul 17, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/85

Describe the bug
The displays seem to get stuck af the "Waiting for data" screen after associating with an access point and failing to receive the initial data (AP lost, restarted, temporarily out of range, overpowered by other 2.4 GHz transmissions). Placing the display right next to the access point does not help once it got stuck. Only a reboot by manually powering it off and on again resolves the issue. This is hard or annoying to do in signs used in installations or built into other components.

To Reproduce
Steps to reproduce the behavior:

Power off a display
Power the display back on
Wait until the display has booted and starts drawing the "Waiting for data" screen
Power off the AP for a few seconds while the display is waiting for data
Power the AP back on
The display is stuck in "Waiting for data". This happens with 1.56" and 2.9" displays. There seems to be a missing timeout or misconfigured reset timeout.

Expected behavior
The display will realize that no data could be received and will try to check in later (5-10 min)

Screenshots

Two displays were rebooted manually after moving the card away from the AP, while three others were allowed to reconnect on their own. The displays were left next to the AP over night (12 hours).

Originally created by @Ennar1991 on GitHub (Jul 17, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/85 **Describe the bug** The displays seem to get stuck af the "Waiting for data" screen after associating with an access point and failing to receive the initial data (AP lost, restarted, temporarily out of range, overpowered by other 2.4 GHz transmissions). Placing the display right next to the access point does not help once it got stuck. Only a reboot by manually powering it off and on again resolves the issue. This is hard or annoying to do in signs used in installations or built into other components. **To Reproduce** Steps to reproduce the behavior: 1. Power off a display 2. Power the display back on 3. Wait until the display has booted and starts drawing the "Waiting for data" screen 4. Power off the AP for a few seconds while the display is waiting for data 5. Power the AP back on 6. The display is stuck in "Waiting for data". This happens with 1.56" and 2.9" displays. There seems to be a missing timeout or misconfigured reset timeout. **Expected behavior** The display will realize that no data could be received and will try to check in later (5-10 min) **Screenshots** ![grafik](https://github.com/jjwbruijn/OpenEPaperLink/assets/76875847/6212c991-163e-4c3e-86b2-36cf822327e0) Two displays were rebooted manually after moving the card away from the AP, while three others were allowed to reconnect on their own. The displays were left next to the AP over night (12 hours).

sascha_hemi added the bug label 2026-03-20 18:10:45 +01:00

sascha_hemi closed this issue

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

sascha_hemi commented

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

@jjwbruijn commented on GitHub (Jul 17, 2023):

Hey! First of all: thank you for your badge-holder-design!

I understand this problem happened with 2/5 tags?

So a bit of background on what happens:

Tags try to get information from the AP. The the tag will do up to DATA_REQ_MAX_ATTEMPTS attempts to get information
The tag keeps track of an 'attempts' value per attempts, that determines the next sleep duration. If a tag can't reach its AP, it will give up after (currently) 14 attempts; it will add this value into its powermanagement algorithm. This algorithm uses a rolling average of all check-ins; it will average to INTERVAL_AT_MAX_ATTEMPTS attempts of 10 minutes, with a POWER_SAVING_SMOOTHING-sized smoothing window. If the average is INTERVAL_AT_MAX_ATTEMPTS, the tag will switch to 'no AP detected' mode, where it will display a 'no ap' symbol in the top right corner.
The tag will enter 'disassociated' mode, where it will periodically scan for AP's on a few different channels

This behaviour has been pretty well tested; it's been pretty solid as far as I can tell. If you're interested, take a look at powermgt.c and powermgt.h, where you can find how that works. Even if there is a bug somewhere that could leave it in some sort of unplanned loop, the watchdog should reset the tag.

So what happens with your tags? I don't know, but I can hazard a guess!

I think you're batteries may be on their last legs; with the AP gone, the 14 attempts the tag does to get data from the AP (that fail) may be a little too much and it may sag the voltage enough to 'hang' the SoC. This, in turn, might cause the battery to drain even further...

Bottomline: I don't know! This is fairly well-tested; I'll take another look at the code, maybe I can somehow reproduce the issue.

@jjwbruijn commented on GitHub (Jul 17, 2023): Hey! First of all: thank you for your badge-holder-design! I understand this problem happened with 2/5 tags? So a bit of background on what happens: - Tags try to get information from the AP. The the tag will do up to DATA_REQ_MAX_ATTEMPTS attempts to get information - The tag keeps track of an 'attempts' value per attempts, that determines the next sleep duration. If a tag can't reach its AP, it will give up after (currently) 14 attempts; it will add this value into its powermanagement algorithm. This algorithm uses a rolling average of all check-ins; it will average to INTERVAL_AT_MAX_ATTEMPTS attempts of 10 minutes, with a POWER_SAVING_SMOOTHING-sized smoothing window. If the average is INTERVAL_AT_MAX_ATTEMPTS, the tag will switch to 'no AP detected' mode, where it will display a 'no ap' symbol in the top right corner. - The tag will enter 'disassociated' mode, where it will periodically scan for AP's on a few different channels This behaviour has been pretty well tested; it's been pretty solid as far as I can tell. If you're interested, take a look at powermgt.c and powermgt.h, where you can find how that works. Even if there is a bug somewhere that could leave it in some sort of unplanned loop, the watchdog should reset the tag. So what happens with your tags? I don't know, but I can hazard a guess! I think you're batteries may be on their last legs; with the AP gone, the 14 attempts the tag does to get data from the AP (that fail) may be a little too much and it may sag the voltage enough to 'hang' the SoC. This, in turn, might cause the battery to drain even further... Bottomline: I don't know! This is fairly well-tested; I'll take another look at the code, maybe I can somehow reproduce the issue.

sascha_hemi commented

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

@Ennar1991 commented on GitHub (Jul 17, 2023):

Batteries might be a bit low, they're used tags. Thank you for the quick response. I might donate the badge design to this repo if I find out how to.

@Ennar1991 commented on GitHub (Jul 17, 2023): Batteries might be a bit low, they're used tags. Thank you for the quick response. I might donate the badge design to this repo if I find out how to.

sascha_hemi commented

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

@slimline33 commented on GitHub (Jul 20, 2023):

I had the same problem. The latest firmware must be installed on the AP with the appropriate firmware. This must be renamed to AP_force_flash.bin. Upload this to the littleFS partition and reboot. After that it worked for me.

@slimline33 commented on GitHub (Jul 20, 2023): I had the same problem. The latest firmware must be installed on the AP with the appropriate firmware. This must be renamed to AP_force_flash.bin. Upload this to the littleFS partition and reboot. After that it worked for me.

sascha_hemi commented

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

@kopierschnitte commented on GitHub (Jul 24, 2023):

@slimline33 Could you explain a little bit more? I'm also getting these kind of problems after using the AP for around 2 days (started directly with FW1.6).

@kopierschnitte commented on GitHub (Jul 24, 2023): @slimline33 Could you explain a little bit more? I'm also getting these kind of problems after using the AP for around 2 days (started directly with FW1.6).

sascha_hemi commented

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

@slimline33 commented on GitHub (Jul 24, 2023):

The access point display (SoluM tag) must be on the same firmware level as the tags. This is independent of the Access Point firmware (for the esp32).

To do this, you take the firmware based on your display from the access point -> SoluM Segmented (OpenEPaper AP Mini) then of course needs the Segmented firmware. The NanoAP then needs the display firmware from the 1.54" SoluM display.

You can download the appropriate AP display firmware here: https://github.com/jjwbruijn/OpenEPaperLink/tree/master/binaries

Then rename the file "AP_force_flash.bin" and load it into the first directory (http://192.168.X.X/edit). The display firmware is then updated from the access point with a reboot!

I have only been familiar with SoluM displays and openepaperlink.de for 3 weeks.

I hope this is correct :D maybe @jjwbruijn can confirm this

@slimline33 commented on GitHub (Jul 24, 2023): The access point display (SoluM tag) must be on the same firmware level as the tags. This is independent of the Access Point firmware (for the esp32). To do this, you take the firmware based on your display from the access point -> SoluM Segmented (OpenEPaper AP Mini) then of course needs the Segmented firmware. The NanoAP then needs the display firmware from the 1.54" SoluM display. You can download the appropriate AP display firmware here: https://github.com/jjwbruijn/OpenEPaperLink/tree/master/binaries Then rename the file "AP_force_flash.bin" and load it into the first directory (http://192.168.X.X/edit). The display firmware is then updated from the access point with a reboot! I have only been familiar with SoluM displays and openepaperlink.de for 3 weeks. I hope this is correct :D maybe @jjwbruijn can confirm this

sascha_hemi commented

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

@atc1441 commented on GitHub (Jul 24, 2023):

100% Correct

@atc1441 commented on GitHub (Jul 24, 2023): 100% Correct

sascha_hemi commented

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

@kopierschnitte commented on GitHub (Jul 24, 2023):

Great explanation. Thx!
But how can I determine the FW level of the tags because I still cannot reach existing or bind new tags.

@kopierschnitte commented on GitHub (Jul 24, 2023): Great explanation. Thx! But how can I determine the FW level of the tags because I still cannot reach existing or bind new tags.

sascha_hemi commented

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

@slimline33 commented on GitHub (Jul 24, 2023):

That is secondary for now. First, the latest firmware must be installed on the AP display! Downward compatible is the newer firmware in any case.

Once you can then connect, you can update the displays via the AP.

@slimline33 commented on GitHub (Jul 24, 2023): That is secondary for now. First, the latest firmware must be installed on the AP display! Downward compatible is the newer firmware in any case. Once you can then connect, you can update the displays via the AP.

sascha_hemi commented

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

@nlimper commented on GitHub (Jul 27, 2023):

Most important in this, is that the AP has at least firmware version 0017 (that is the latest, at the moment). You can check this firmware version either by looking at Serial at startup of the AP, or in the web interface, button 'AP config', in the table under 'active access points', column 'AP ver'.

@nlimper commented on GitHub (Jul 27, 2023): Most important in this, is that the AP has at least firmware version 0017 (that is the latest, at the moment). You can check this firmware version either by looking at Serial at startup of the AP, or in the web interface, button 'AP config', in the table under 'active access points', column 'AP ver'.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#588