# Passive V4 data capture - user inventory and raw acquisition

Status 2026-10-02: source implementation, CLI/mocked tests and staged user installation.
Not part of the live manager, not a control or training release.

## Lihrenmoos user-reported inventory (not applied to running configuration)

- GoodWe 1/2: each 50 kW AC, each 156 kWh reported physical battery capacity.
- SolarEdge: 10 kW AC, 10 kWh reported physical battery capacity.
- EV allocation: 30 kW / 160 kWh total, understood as 10 kW EV per inverter.
- PV roof: approximately 20 kWp east and 20 kWp west. Tilt/individual strings unknown.
- Nominal battery sum: 322 kWh. 162 kWh nominal difference to EV allocation is NOT a
  verified usable SDL capacity. AC ratings are not verified battery charge/discharge ratings.
- Exact types, firmware, common AC meter boundary and device watchdog remain unverified.
- Current saved manager topology still reports 161.44 kWh / 39 kW. Gateway currently
  lists 130/130/8 kWh and 57/57/5 kW. These may use a different usable/nominal basis.
  Do not rebase virtual SOC or change current controls based on these notes alone.

## Why collect before boundary approval

Record the actual original numerical channels now, with source metadata and timestamps.
The algebraic base-load candidate is useful for diagnosis, but NEVER a certified base-load
training sample until the physical AC/DC boundary and historical recipe are verified.
No dependence on hardware-watchdog approval for passive recording.

21 channels: PCC power, legacy displayed PCC power, PV for three inverters, three physical
battery powers, EV/SDL virtual powers and SOCs, three physical SOCs, dynamic EV limits,
T1/T2 import counters, EV/SDL requested setpoints (READ ONLY).
A cyclic script reads values already present in Symcon every 30 seconds. It does not issue
additional Modbus polls. Original VariableUpdated/VariableChanged are retained; these are
Symcon timestamps, not independent device-measurement timestamps. Two-pass reads detect
concurrent changes; missing/non-numeric/re-used channels remain explicit quality failures.

## Storage and interpretation

Daily append-only raw-YYYYMMDD.jsonl in the separate capture stage data directory, UTC
capture times plus original source timestamps, immutable mapping/inventory snapshots by
SHA256. Raw errors and quality_hold are recorded too; nothing is invented as zero.
The raw observations are a source for later documented 5-minute aggregation, not themselves
aligned 5-minute means. No interpolation, training publication or future SDL assumption.

A 512 MiB journal quota, 64 MiB daily limit, 256 KiB record cap and 100 MiB free-space
reserve bound recording. Limits fail visibly without deleting old data. File permissions
0640; no upload credentials, request bodies, complete instance configurations or secrets.
A separate status variable and STATUS.json show latest capture and failures. Process restart
retains files; an incomplete final JSONL row is preserved for manual review, not extended.

## Install / stop

Staged user entry point: /srv/agent/netplan-v4-data-capture-stage/install.php
Execute in the Symcon PHP editor (not a Linux shell):

    require '/srv/agent/netplan-v4-data-capture-stage/install.php';

Installer checks exact source hashes and numeric source identities before creating a NEW
root category ENELIX_V4_PASSIVE_CAPTURE, a status string, collector script and stop script.
IPS_SetScriptTimer enables only this new script at 30 seconds. Repeating installation is
idempotent. Unrelated/edited scripts or object identity collisions are not overwritten.

Stop using the newly created script 'Nur diese Messaufnahme stoppen'; it disables only
this collection timer, retains collected files, and does not stop the manager or battery.
No module reload, existing archive change, existing timer/poller change, service restart,
forecast selection, battery reservation or actuator command is included.

Current tests: 36 core/file tests + 19 mocked native lifecycle tests with PHP CLI on the
test host. First real capture and future timer execution require the user activation.
These tests do not certify hardware mappings or a Symcon-kernel run.