pe1hvh fd3d0d2f35 fix(repeater): retry failed stats poll up to a configurable limit ...

WHAT
Repeater statistics polls now retry within the same poll instead of
recording a failure after a single session. REPEATER_POLL_MAX_ATTEMPTS
(default 5) and REPEATER_POLL_RETRY_DELAY (default 5.0) control the
budget. The login/status/logout sequence moved into a private
_attempt_session(); _poll_one() drives the loop and writes exactly one
archive record carrying the new "attempts" field and the last error.
A missing password is not retried. Version bumped to 1.24.2; the stale
__version__ = "5.0" in __init__.py was aligned with config.VERSION.

WHY
Polls fail at irregular intervals with no established root cause. This
is an explicit workaround: retrying recovers readings now, while the
attempt count makes the underlying failure rate measurable so the real
cause can be identified from data instead of guessed at.

NOTES
No API or schema break — add_measurement() gained a keyword argument
with a default, and "attempts" is an added field that older records
simply lack. A poll blocks the worker loop for its full duration, so
worst-case command latency rises from roughly 60 seconds to roughly
three minutes for a repeater that never answers. Airtime rises
proportionally: up to five login/logout round trips per failing poll.

2026-09-02 08:05:13 +02:00

..

api

fix: Multibyte path hash support

2026-04-04 22:59:44 +02:00

ble

fix(gui): dismiss the manual poll notification after three seconds The "Polling…" message raised by the Poll now button in the REPEATERS panel stayed on screen indefinitely. Root cause The notification used type='ongoing', which Quasar renders with a timeout of zero. Such a notification is meant to be dismissed programmatically by the code that raised it, but the poll runs in the worker thread and the panel never holds a handle to dismiss it. The message therefore remained visible regardless of whether the poll succeeded or failed. Every other panel in the project uses a typed notification with an explicit timeout; this one was the exception. Fix The notification is now type='info' with a 3 second timeout, matching the convention used elsewhere in the GUI. Presentation only. The poll itself was unaffected — the message was stale, not the polling.

2026-09-01 05:00:57 +02:00

core

fix(route): default reply channel to message channel, add date to timestamps

2026-08-16 08:32:24 +02:00

gui

fix(gui): dismiss the manual poll notification after three seconds The "Polling…" message raised by the Poll now button in the REPEATERS panel stayed on screen indefinitely. Root cause The notification used type='ongoing', which Quasar renders with a timeout of zero. Such a notification is meant to be dismissed programmatically by the code that raised it, but the poll runs in the worker thread and the panel never holds a handle to dismiss it. The message therefore remained visible regardless of whether the poll succeeded or failed. Every other panel in the project uses a typed notification with an explicit timeout; this one was the exception. Fix The notification is now type='info' with a 3 second timeout, matching the convention used elsewhere in the GUI. Presentation only. The poll itself was unaffected — the message was stale, not the polling.

2026-09-01 05:00:57 +02:00

services

fix(repeater): retry failed stats poll up to a configurable limit

2026-09-02 08:05:13 +02:00

static

fix: channel attribution, dedup, cache bugs + channel edit/move (v1.19.0)

2026-04-06 10:23:24 +02:00

__init__.py

fix(repeater): retry failed stats poll up to a configurable limit

2026-09-02 08:05:13 +02:00

__main__.py

fix(gui): pass repeater stores to the dashboard page handler

2026-09-01 04:14:06 +02:00

config.py

fix(repeater): retry failed stats poll up to a configurable limit

2026-09-02 08:05:13 +02:00