Migrate records to solar web format

README.md

@@ -96,6 +96,25 @@ atomically replaces the daily file, and fsyncs the directory. File permissions a
 uploader, status request or CLI replay from overwriting another operation. HTTP
 requests happen outside the archive lock.
 
+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
+```
+
+These common power readings match the sibling `solar` application's existing
+model: its `stats` table stores timestamped watts for Production and Consumption,
+then applies `5/60` only when calculating Wh totals. `production_ac_w` maps to
+Production and `consumption_w` maps to Consumption. The solar-side relay importer
+is separate work; this relay change prepares both record sources for ingestion.
+
 The upload request is a JSON object with `schema_version: 1` and a `samples` array,
 authenticated with `upload.token` from private `config.toml`, or the environment
 variable named by `upload.token_env` when that setting is empty. The website must
@@ -108,8 +127,10 @@ commit its data before responding:
 Only explicitly acknowledged IDs receive an `uploaded_at` timestamp. A plain HTTP
 200, malformed response, timeout or unknown ID never clears the queue. Partial
 acknowledgements mark only the accepted records; remaining records retry with
-exponential backoff. Delivery is **at least once**: the website deduplicates stable
+exponential backoff. Delivery is **at least once**: a receiver must deduplicate stable
 UUIDs when a response is lost, so retries and replays do not double-count energy.
+The sibling solar app does not yet provide an HTTP receiver; leave uploads
+disabled until a compatible receiver is available.
 
 `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
@@ -202,11 +223,11 @@ ignored; `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. As in `solar`, each five-minute W value is treated as constant over that
-interval and divided by 12 to obtain Wh. Self-consumption is the smaller of production
-and consumption; purchase/export are their nonnegative differences. These are chart
-estimates, rather than the former Query API's measured Wh channels. The original
-paired power values and conversion method are retained in each recovered record.
+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.
 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
@@ -233,9 +254,10 @@ 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 `history_interval` records, which the main website
-uses directly without integrating them as live power. Install the corresponding
-`solar` receiver update before enabling cloud recovery.
+Recovery stores stable UUIDs and common power readings, retaining `history_interval`
+as provenance and compatibility metadata. 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.
 
 **Boiler switch history and cumulative meter readings are not recovered.** Historical
 energy intervals leave those sources unknown, and the status page shows partial