Simplify status interface

README.md

@@ -20,8 +20,9 @@ Scheduled collection remains anchored to `:00`, `:05`, `:10`, … boundaries.
 
 Observations are saved durably to **Parquet** before upload. Separate workers handle
 delivery and optional history recovery; an internet outage does not block recording.
-Acknowledged observations are deleted **30 days after acknowledgement**. Pending
-observations never expire, even if their measurement dates are much older.
+Acknowledged observations are retained for **30 full local calendar days after
+acknowledgement**. Cleanup removes whole observation days. A pending or recently
+acknowledged record keeps its whole local day, even when its measurements are much older.
 
 ## Installation
 
@@ -110,10 +111,17 @@ acknowledgements mark only the accepted records; remaining records retry with
 exponential backoff. Delivery is **at least once**: the website deduplicates stable
 UUIDs when a response is lost, so retries and replays do not double-count energy.
 
-`collector.retention_days` defaults to 30. Automatic cleanup runs at service startup
-and hourly, deleting records acknowledged more than that many days ago. Old pending
-records remain. Replay clears acknowledgement and therefore prevents expiry until
-another successful transfer. The main website retains its own imported history.
+`collector.retention_days` defaults to 30. All retention cutoffs are midnight in
+`collector.timezone`. For example, on November 2 with 30 days retained, the cutoff
+is October 3 at 00:00 local time, regardless of the execution time. The entire
+October 3 day is kept and eligible for history recovery.
+
+Automatic cleanup runs at service startup and hourly. It removes an older local
+observation day only when every record in that day was acknowledged before the
+cutoff. Pending or recently acknowledged records protect the entire day, including
+its rows in adjacent UTC Parquet partitions. Replay clears acknowledgement and
+therefore prevents expiry until another successful transfer. The main website
+retains its own imported history.
 
 ```bash
 .venv/bin/python -m solar_relay --config config.toml prune
@@ -179,9 +187,9 @@ SOLARWEB_PASSWORD=your-account-password
 ```
 
 While live collection runs, the separate recovery worker checks at startup and hourly
-by default. It checks every five-minute energy interval back to
-`collector.retention_days` (30 days by default), including entirely empty days and
-dates before the first local observation. A two-hour delay allows the inverter to
+by default. It checks every five-minute energy interval from midnight at the start
+of the date `collector.retention_days` ago (30 days by default), including empty
+days and dates before the first local observation. A two-hour delay allows the inverter to
 upload its recent history. Only local dates containing gaps are fetched, and existing
 live or recovered energy is preserved. When all eligible intervals are present, no
 Solar.web requests are made. Unavailable chart days remain missing for retry and do
@@ -189,7 +197,7 @@ not prevent other dates from being recovered. Login and network failures stop th
 attempt and retry on the next scheduled check.
 
 Set `collector.timezone` to the installation's Solar.web timezone; local chart dates
-include 23/25-hour DST days. The old `history.lookback_days` setting is accepted but
+include whole 23/25-hour DST days. The old `history.lookback_days` setting is accepted but
 ignored; `collector.retention_days` controls the automatic recovery window.
 
 Recovery pairs the `FromGen` Production series from the consumption view with the
@@ -220,8 +228,8 @@ Recovery requires the account credentials even if API keys remain set.
   --from 2026-10-29 --until 2026-10-31
 ```
 
-Manual recovery with explicit date bounds accepts at most 30 days per invocation and
-can query dates older than the automatic retention window. Unbounded recovery checks
+Manual recovery with explicit date bounds accepts at most 30 local calendar days
+per invocation and can query dates older than the automatic retention window. Unbounded recovery checks
 the whole retention window, even when longer than 30 days. Only aligned five-minute
 chart samples in W are accepted;
 longer aggregates and unexpected units are rejected.
@@ -327,9 +335,13 @@ extraction/last success, upload backlog, retained observations, and daily five-m
 completeness with a selectable interval grid and gap ranges. Dates use the configured
 timezone. DST days have 276 or 300 intervals; ordinary days have 288.
 
-Complete means at least one fresh, successful extraction for energy, meter and boiler
-in that five-minute slot. It does not mean continuously observed power or switch state.
-The unfinished current slot is excluded from missing counts. Historical recovery
+The five-minute interval card appears above daily coverage. Status shows Energy and
+Boiler; meter counters remain archived but do not affect status, completeness, or
+interval details. Complete means valid energy and boiler data in the same five-minute
+slot. It does not mean continuously observed power or switch state.
+The current slot shows its saved extraction immediately, including partial or failed
+results. Until a record arrives, it is pending and excluded from missing counts.
+Future slots remain upcoming. Historical recovery
 contributes energy only. After retention cleanup, pruned records no longer contribute
 to this local page; the website keeps the transferred history. Refresh is every 15 seconds.