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 #435] AP loses connection with tags #812

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

Originally created by @tomseii on GitHub (Jan 30, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/435

Originally assigned to: @nlimper on GitHub.

Describe the bug
It can work great for a few hours up to a day, but then suddenly the AP loses connection with the tags and the tags timeout. On the same time new tags pop up in the AP, but with the same mac as the ones that timeout.

The only fix i have found so far, that works sometimes, is to pull the batteries from all the tags, short, and put in the batteries again. AP will then find the original tags and the "new" ones just sit there. I have started to delete them because they will fill up the AP.

To Reproduce
I haven't been able to reproduce the bug, it seems random.

Originally created by @tomseii on GitHub (Jan 30, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/435 Originally assigned to: @nlimper on GitHub. **Describe the bug** It can work great for a few hours up to a day, but then suddenly the AP loses connection with the tags and the tags timeout. On the same time new tags pop up in the AP, but with the same mac as the ones that timeout. The only fix i have found so far, that works sometimes, is to pull the batteries from all the tags, short, and put in the batteries again. AP will then find the original tags and the "new" ones just sit there. I have started to delete them because they will fill up the AP. **To Reproduce** I haven't been able to reproduce the bug, it seems random.
sascha_hemi added the bug label 2026-03-20 18:13:12 +01:00
sascha_hemi commented 2026-03-20 18:13:13 +01:00
Author
Owner
Copy Link

@maxbie commented on GitHub (Feb 8, 2025):

I had a similar or the same problem since the last update. ~ Once a day the status changes to “failed” and the connection to the tags is lost. The AP TFT shows CMD Mode. – But according to logs dev's told me that it's a hardware issue. Since I'm using a different AP, everything works.

<!-- gh-comment-id:2645960438 --> @maxbie commented on GitHub (Feb 8, 2025): I had a similar or the same problem since the last update. ~ Once a day the status changes to “failed” and the connection to the tags is lost. The AP TFT shows CMD Mode. – But according to logs dev's told me that it's a hardware issue. Since I'm using a different AP, everything works.
sascha_hemi commented 2026-03-20 18:13:13 +01:00
Author
Owner
Copy Link

@nlimper commented on GitHub (Mar 24, 2025):

@maxbie that doesn't match at all with the issue that the topic starter reports..

@tomseii hm, I haven't seen that one. Next time when it happens, could you please make a screenshot of the web interface (including the tags cards and status bar at the bottom of the window), and make a backup of the database? (config tab -> download tagDB). (note: watch out, if you use the calendar content, the tagDB contains a very private key which should not become public).
You can also send me the tagDB in private if you like.

<!-- gh-comment-id:2749183908 --> @nlimper commented on GitHub (Mar 24, 2025): @maxbie that doesn't match at all with the issue that the topic starter reports.. @tomseii hm, I haven't seen that one. Next time when it happens, could you please make a screenshot of the web interface (including the tags cards and status bar at the bottom of the window), and make a backup of the database? (config tab -> download tagDB). (note: watch out, if you use the calendar content, the tagDB contains a very private key which should not become public). You can also send me the tagDB in private if you like.
sascha_hemi commented 2026-03-20 18:13:14 +01:00
Author
Owner
Copy Link

@linesquarecube commented on GitHub (Apr 23, 2025):

I'm facing the same issue as @tomseii. After a while, the AP is not updating tags and the "expected checkin" starts counting till infinity. Rebooting the AP is not resolving the issue and I also get new tags with already known MACs.
@nlimper: As requested, here is a screenshot of the web interface and the content of the tagDB

Not sure if worth mentioning, but when I force the tag to refresh via a button on the tag in this situation, it says that it cannot find an AP by showing a small sign in the right upper corner or a sad panda if there is no content.

Another thing I recognized is that the time in the logs is shifted for several hours compared to the real time even if I set it to "Central European Time"

Thanks for any help :)

Image

[[
  {
    "mac": "00000B7CA706BC95",
    "hash": "00000000000000000000000000000000",
    "lastseen": 1745437080,
    "nextupdate": 1745445600,
    "nextcheckin": 1745437140,
    "pending": 1,
    "alias": "",
    "contentMode": 1,
    "LQI": 124,
    "RSSI": -62,
    "temperature": 26,
    "batteryMv": 3056,
    "hwType": 54,
    "wakeupReason": 0,
    "capabilities": 225,
    "modecfgjson": "{}",
    "isexternal": false,
    "apip": "0.0.0.0",
    "rotate": 0,
    "lut": 0,
    "invert": 0,
    "updatecount": 38,
    "updatelast": 1745437078,
    "ch": 11,
    "ver": 41
  }
],[
  {
    "mac": "0000CCDC1B90A994",
    "hash": "00000000000000000000000000000000",
    "lastseen": 1745437134,
    "nextupdate": 3216153600,
    "nextcheckin": 1745437194,
    "pending": 0,
    "alias": "",
    "contentMode": 21,
    "LQI": 0,
    "RSSI": -72,
    "temperature": 0,
    "batteryMv": 0,
    "hwType": 224,
    "wakeupReason": 0,
    "capabilities": 0,
    "modecfgjson": "null",
    "isexternal": false,
    "apip": "0.0.0.0",
    "rotate": 0,
    "lut": 0,
    "invert": 0,
    "updatecount": 0,
    "updatelast": 0,
    "ch": 0,
    "ver": 0
  }
],[
  {
    "mac": "0000007CA706BC95",
    "hash": "00000000000000000000000000000000",
    "lastseen": 1745436562,
    "nextupdate": 0,
    "nextcheckin": 1745436622,
    "pending": 0,
    "alias": "",
    "contentMode": 0,
    "LQI": 0,
    "RSSI": 0,
    "temperature": 0,
    "batteryMv": 0,
    "hwType": 0,
    "wakeupReason": 0,
    "capabilities": 0,
    "modecfgjson": "",
    "isexternal": false,
    "apip": "0.0.0.0",
    "rotate": 0,
    "lut": 0,
    "invert": 0,
    "updatecount": 0,
    "updatelast": 0,
    "ch": 0,
    "ver": 0
  }
],[
  {
    "mac": "0000000000000000",
    "hash": "00000000000000000000000000000000",
    "lastseen": 1745436866,
    "nextupdate": 0,
    "nextcheckin": 1745436926,
    "pending": 0,
    "alias": "",
    "contentMode": 0,
    "LQI": 0,
    "RSSI": 0,
    "temperature": 0,
    "batteryMv": 0,
    "hwType": 0,
    "wakeupReason": 0,
    "capabilities": 0,
    "modecfgjson": "",
    "isexternal": false,
    "apip": "0.0.0.0",
    "rotate": 0,
    "lut": 0,
    "invert": 0,
    "updatecount": 0,
    "updatelast": 0,
    "ch": 0,
    "ver": 0
  }
]]
<!-- gh-comment-id:2825374536 --> @linesquarecube commented on GitHub (Apr 23, 2025): I'm facing the same issue as @tomseii. After a while, the AP is not updating tags and the "expected checkin" starts counting till infinity. Rebooting the AP is not resolving the issue and I also get new tags with already known MACs. @nlimper: As requested, here is a screenshot of the web interface and the content of the tagDB Not sure if worth mentioning, but when I force the tag to refresh via a button on the tag in this situation, it says that it cannot find an AP by showing a small sign in the right upper corner or a sad panda if there is no content. Another thing I recognized is that the time in the logs is shifted for several hours compared to the real time even if I set it to "Central European Time" Thanks for any help :) ![Image](https://github.com/user-attachments/assets/4eeff0be-8836-47b7-9bf9-b06ce8c7cf1f) ~~~ [[ { "mac": "00000B7CA706BC95", "hash": "00000000000000000000000000000000", "lastseen": 1745437080, "nextupdate": 1745445600, "nextcheckin": 1745437140, "pending": 1, "alias": "", "contentMode": 1, "LQI": 124, "RSSI": -62, "temperature": 26, "batteryMv": 3056, "hwType": 54, "wakeupReason": 0, "capabilities": 225, "modecfgjson": "{}", "isexternal": false, "apip": "0.0.0.0", "rotate": 0, "lut": 0, "invert": 0, "updatecount": 38, "updatelast": 1745437078, "ch": 11, "ver": 41 } ],[ { "mac": "0000CCDC1B90A994", "hash": "00000000000000000000000000000000", "lastseen": 1745437134, "nextupdate": 3216153600, "nextcheckin": 1745437194, "pending": 0, "alias": "", "contentMode": 21, "LQI": 0, "RSSI": -72, "temperature": 0, "batteryMv": 0, "hwType": 224, "wakeupReason": 0, "capabilities": 0, "modecfgjson": "null", "isexternal": false, "apip": "0.0.0.0", "rotate": 0, "lut": 0, "invert": 0, "updatecount": 0, "updatelast": 0, "ch": 0, "ver": 0 } ],[ { "mac": "0000007CA706BC95", "hash": "00000000000000000000000000000000", "lastseen": 1745436562, "nextupdate": 0, "nextcheckin": 1745436622, "pending": 0, "alias": "", "contentMode": 0, "LQI": 0, "RSSI": 0, "temperature": 0, "batteryMv": 0, "hwType": 0, "wakeupReason": 0, "capabilities": 0, "modecfgjson": "", "isexternal": false, "apip": "0.0.0.0", "rotate": 0, "lut": 0, "invert": 0, "updatecount": 0, "updatelast": 0, "ch": 0, "ver": 0 } ],[ { "mac": "0000000000000000", "hash": "00000000000000000000000000000000", "lastseen": 1745436866, "nextupdate": 0, "nextcheckin": 1745436926, "pending": 0, "alias": "", "contentMode": 0, "LQI": 0, "RSSI": 0, "temperature": 0, "batteryMv": 0, "hwType": 0, "wakeupReason": 0, "capabilities": 0, "modecfgjson": "", "isexternal": false, "apip": "0.0.0.0", "rotate": 0, "lut": 0, "invert": 0, "updatecount": 0, "updatelast": 0, "ch": 0, "ver": 0 } ]] ~~~
sascha_hemi commented 2026-03-20 18:13:14 +01:00
Author
Owner
Copy Link

@lrnflk commented on GitHub (Sep 5, 2025):

Could this be due to the AP not being able to access the (hardcoded) NTP servers.?

I just had a similar issue after making some changes in my local network where I noticed that the firewall logs were being filled up with NTP requests from the AP to blocked external addresses, as my AP is on an isolated IoT network. After adding a rule allowing the AP to access the external NTP servers it all started working again right away.

<!-- gh-comment-id:3258823508 --> @lrnflk commented on GitHub (Sep 5, 2025): Could this be due to the AP not being able to access the [(hardcoded) NTP servers.](https://github.com/OpenEPaperLink/OpenEPaperLink/issues/167)? I just had a similar issue after making some changes in my local network where I noticed that the firewall logs were being filled up with NTP requests from the AP to blocked external addresses, as my AP is on an isolated IoT network. After adding a rule allowing the AP to access the external NTP servers it all started working again right away.
sascha_hemi commented 2026-03-20 18:13:14 +01:00
Author
Owner
Copy Link

@linesquarecube commented on GitHub (Sep 5, 2025):

Maybe the missing connection to the NTP server was also part of the problem in my setup. However, unlike for @lrnflk, I discovered that the real issue was a faulty ESP board with a very poor Wi-Fi range. After switching to another board, I haven’t had any issues for several months now.

<!-- gh-comment-id:3259523768 --> @linesquarecube commented on GitHub (Sep 5, 2025): Maybe the missing connection to the NTP server was also part of the problem in my setup. However, unlike for @lrnflk, I discovered that the real issue was a faulty ESP board with a very poor Wi-Fi range. After switching to another board, I haven’t had any issues for several months now.
sascha_hemi commented 2026-03-20 18:13:14 +01:00
Author
Owner
Copy Link

@tomseii commented on GitHub (Sep 19, 2025):

My AP broke down completely, ended up buying new boards and made a new AP. Worked great a few hours. AP lost connection with the tags. Removed them and tried to connect them again, "No AP can't be found". Even tried on a different network, nothing works. My guess i am doing something wrong when i build the APs, but i'm giving up now so.. Thanks for the help anyway :)

<!-- gh-comment-id:3313402607 --> @tomseii commented on GitHub (Sep 19, 2025): My AP broke down completely, ended up buying new boards and made a new AP. Worked great a few hours. AP lost connection with the tags. Removed them and tried to connect them again, "No AP can't be found". Even tried on a different network, nothing works. My guess i am doing something wrong when i build the APs, but i'm giving up now so.. Thanks for the help anyway :)
sascha_hemi commented 2026-03-20 18:13:15 +01:00
Author
Owner
Copy Link

@maxbie commented on GitHub (Sep 19, 2025):

@tomseii I’m not sure if this is still helpful, but a colleague mentioned to me that there’s a mismatch in the Spaghetti AP manual. At one point, you shouldn’t rely on the photos but rather on the table. But I don't know any more details.

<!-- gh-comment-id:3313442716 --> @maxbie commented on GitHub (Sep 19, 2025): @tomseii I’m not sure if this is still helpful, but a colleague mentioned to me that there’s a mismatch in the Spaghetti AP manual. At one point, you shouldn’t rely on the photos but rather on the table. But I don't know any more details.
sascha_hemi commented 2026-03-20 18:13:15 +01:00
Author
Owner
Copy Link

@Markusenz commented on GitHub (Sep 20, 2025):

Same here:
From time to time tags get inaccessible and they reappear as new entry with different prefix in the MAC address.
From then on the newly appeared version is updated correctly and the „old“ entry remains inaccessible. See screenshot below.
Did not yet find out when exactly that happens or how to reproduce. Happened with only one AP active and also in a two AP environment. AP firmware and Tags are on latest SW version.

Image

<!-- gh-comment-id:3315073779 --> @Markusenz commented on GitHub (Sep 20, 2025): Same here: From time to time tags get inaccessible and they reappear as new entry with different prefix in the MAC address. From then on the newly appeared version is updated correctly and the „old“ entry remains inaccessible. See screenshot below. Did not yet find out when exactly that happens or how to reproduce. Happened with only one AP active and also in a two AP environment. AP firmware and Tags are on latest SW version. ![Image](https://github.com/user-attachments/assets/17cd4a88-9fd6-40b3-ae69-944684e4c027)
sascha_hemi commented 2026-03-20 18:13:15 +01:00
Author
Owner
Copy Link

@atc1441 commented on GitHub (Sep 20, 2025):

Heym the one with 1337 Mac is received via BLE and the same other one via 802.15.4 Would turn of BLE in the AP if you got no BLE Display to use

<!-- gh-comment-id:3315075384 --> @atc1441 commented on GitHub (Sep 20, 2025): Heym the one with 1337 Mac is received via BLE and the same other one via 802.15.4 Would turn of BLE in the AP if you got no BLE Display to use
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#812
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?