Remove legacy code for format conversion

README.md

@@ -100,14 +100,9 @@ Live and recovered records share the same Parquet table and watt columns:
 `production_ac_w`, `consumption_w`, `grid_w`, `grid_import_w`, and `grid_export_w`.
 Recovered chart values are stored directly in those fields; `production_w` (PV DC),
 lifetime counters, and boiler state remain unknown. `record_kind` and the original
-chart data distinguish recovered values from live snapshots. The older
-`history_interval.energy_wh` metadata is retained for compatibility. Existing archives
-are normalized on `run` startup, preserving IDs, recording times and upload acknowledgements.
-To normalize an archive before exporting without starting collection:
-
-```bash
-.venv/bin/python -m solar_relay --config config.toml normalize-history
-```
+chart data distinguish recovered values from live snapshots. Both sources use the
+same validation and completeness checks. The relay stores power directly; energy
+totals are calculated by the receiving application.
 
 These common power readings match the sibling `solar` application's existing
 model: its `stats` table stores timestamped watts for Production and Consumption,
@@ -177,7 +172,7 @@ for the local API's archive limitations.
 Optional recovery signs in to Solar.web with a real Fronius account and reads its
 private daily charts after the inverter uploads its backlog, using the same login
 flow and chart series as the sibling `solar` website. No cloud calls occur while
-disabled. A public guest link and Query API subscription/keys are not needed.
+disabled. A public guest link is not needed.
 
 Create a dedicated Solar.web / Fronius account and grant it permission to view this
 installation's metrics. Keep public sharing disabled. The account can have guest
@@ -218,16 +213,14 @@ 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 whole 23/25-hour DST days. The old `history.lookback_days` setting is accepted but
-ignored; `collector.retention_days` controls the automatic recovery window.
+include whole 23/25-hour DST days. `collector.retention_days` controls the automatic
+recovery window.
 
 Recovery pairs the `FromGen` Production series from the consumption view with the
 `ToConsumer` Consumption series from the production view, regardless of the display
 language. Paired power values are stored directly in the common watt readings.
-Grid import/export are their nonnegative differences. As in `solar`, multiplying
-each five-minute power value by `5/60` yields estimated Wh. The compatibility
-`history_interval` field retains those estimates and the conversion method;
-the original chart watts remain available without converting Wh back to W.
+Grid import/export are their nonnegative differences. The relay keeps the original
+chart watts without converting them to interval energy.
 Null or unpaired readings stay missing and are tried again later.
 
 Login uses HTTPS and in-memory cookies. Credentials are submitted only to the Fronius
@@ -238,12 +231,6 @@ disk. An expired session is renewed once. Rejected credentials,
 MFA, CAPTCHA, consent, or a changed sign-in form stop that attempt with a redacted
 error. Complete any required interactive account setup in a browser.
 
-When migrating from Query API recovery, replace `access_key_id_env` and
-`access_key_value_env` with `username` and `password` in `[history]`, or use the
-environment fallback above. Obsolete configuration keys are accepted and ignored
-for migration. Restart the service after updating its configuration or environment.
-Recovery requires the account credentials even if API keys remain set.
-
 ```bash
 .venv/bin/python -m solar_relay --config config.toml recover \
   --from 2026-10-29 --until 2026-10-31
@@ -254,8 +241,8 @@ per invocation and can query dates older than the automatic retention window. Un
 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.
-Recovery stores stable UUIDs and common power readings, retaining `history_interval`
-as provenance and compatibility metadata. A future solar-side importer can put both
+Recovery stores stable UUIDs and common power readings with their chart provenance.
+A future solar-side importer can put both
 live and recovered production/consumption in the existing `stats` watt table and
 use its normal five-minute Wh conversion exactly once.