2 Commits

Include renames

Author	SHA1	Message	Date
adminandClaude Opus 5	0ef9565071	TEL-12: several PV inverters, and one absent member is an absent TOTAL ... 0.11.0 shipped `pv_entity` as a single string. The reference site's owner reported within minutes of it going live that they have several PV inverters and could configure one - which is ordinary for a multi-string roof, not a property of one house. `pv_entities` is the roster and the row carries the SITE total. ⚠️ THE HARD PART IS ABSENCE, NOT THE LIST. Three configured, one `unavailable`, and the sum of the other two is a SMALLER NUMBER INDISTINGUISHABLE FROM A REAL ONE. Read back by OPT-10 that says "there was less PV than there was" - the "no irradiance" conclusion the channel exists to TEST. So `pv.total()` answers `None` the moment any configured entity is absent: the topic carries HA's own `None`, the entity goes to `unknown`, the recorder records a GAP. The alternative (the partial sum beside a contributor count) was implemented and run as mutation N1b; it loses because the MQTT row is read COLD a week later by an attribution that would believe it, while the qualifying count would live in a second entity with its own history. The partial information is not thrown away - the STATUS PAGE names every entity that reported, with its watts, and every one that did not, with its reason, because that surface is read LIVE by a human who wants the diagnostic. ⚠️ AND THE MIRROR: a member honestly reporting 0 W is SUMMED. The test is `is None`, never falsiness - a roster that blanked the site on a zero would report an absence on every clear evening. THE SURFACE IS MEASURED, NOT PREFERRED. `pv_entity` could not become a list: tools/supervisor_shape_probe.py §G shows Supervisor 2026.08.0 answering an 0.11.0 install's stored string with `Invalid list for option 'pv_entity'`, and deepmerge's list strategy is `override` so a `[]` default does not rescue it - the live add-on would not start. `match(.*)?` does accept both shapes and is rejected for a different, measured reason: it validates nothing (a string, a list and the integer 417 all pass) and renders as a plain text box. So `pv_entities` joins `pv_entity` and REPLACES it when set, CFG-04's rule for `inverters:`, with a status caution saying which key won - a union would double-count the inverter the old key still names. STILL NOT A CONTROL INPUT. tools/tel11_pv_trace.py was extended rather than replaced and now grades five claims over three document sets. The control hash is UNMOVED - 846a10a5b89e… on `unset` and on `one`, on both trees - and the roster control document is byte-identical between the two trees. 2/5 is a claim TEL-11 could not make: with 0.11.0 as the baseline, "one entity behaves exactly as 0.11.0 does" is a real cross-tree identity over control AND telemetry. ⚠️ TEL-11's OWN `--compare` REFUSAL HAD TO CHANGE, and that is MUTATION.md habit 24: a discriminator defined as "the baseline lacks this feature" dies on the release that ships the feature, and dies as a false refusal. Twelve mutations, each on a fresh purged `cp -a`, no survivors. N5 is +0 B (`sum` -> `max`, the same three characters) and was run on a fresh copy with `cmp` confirming the edit on disk. The fixture is three distinct NON-ZERO contributions in two units with absence driven at EVERY position - a member contributing 0 W could go absent without moving the sum of the rest, which is habit 23 with a coinciding value in the arithmetic rather than in the plant. 31/31 in the CI image. Not deployable as merged: config.yaml stays at 0.11.0, so predeploy_check.py reports a NO-OP until PKG cuts a version. A CHANGELOG entry is wanted and deliberately not written - 11b forbids `## Unreleased` and the bump is PKG's call; DECISIONS/TEL-12-several-pv-inverters.md is the material it needs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-24 22:13:25 +02:00
glenn schrooyenandClaude Opus 5	07ba3433ed	TEL-11: PV production stops being invisible, and stays out of the control law ... OPT-10 measured that this site's pack reaches 90 % SoC on 2 days of 16 and that 20.5 kWh of surplus left the site while the pack had room - 12.6 kWh of it with the battery not charging at all - and could not say WHY, because PV production is recorded NOWHERE. Three causes need three different fixes (no irradiance: nothing to fix; a charge-power limit; the optimiser declining to charge, which is the only software defect) and guessing between them is how an optimiser gets tuned to solve a cloud problem. This card adds the channel. It does not do the attribution. AN HA ENTITY, NOT A REGISTER, AND THAT IS A PRODUCT DECISION. This add-on's RS485 bus carries the BATTERY inverter it drives; a household's PV inverter is normally a different box from a different vendor reporting into Home Assistant through its own integration. `pv_entity` takes whatever `sensor.*` the site's own PV integration provides, any brand HA can read. POSITIVE IS PRODUCTION, AND THERE IS NO `pv_invert`. The convention is derived rather than assumed: `meter_entity` is positive when IMPORTING and `batt_entity` is positive when DISCHARGING (DOCS.md, Sources), both of which are "power arriving at the house's AC bus", and production arrives there too. Those two keys carry invert flags because they are BIPOLAR and are READ BY THE CONTROL PATH - `inv.batt` feeds SAFETY-30's per-unit sign check and SAFETY-31's circulating-power sensor, so a reversed sensor hands the site a plausible number it acts on. Production is unipolar and is read by nothing: a reversed sensor announces itself as -4 kW at noon in the very history this card creates, and a flag would only let an installer hide it. No negative-value alarm either - a PV inverter's own standby draw makes a small negative reading at night ordinary, so any threshold would be a number nobody measured. ABSENCE IS NEVER ZERO, AND "DROPPED" IS NOT ABSENT. `publish()` SKIPS a None, which is right for `circulation` and exactly wrong here: a skipped row leaves Home Assistant holding the last number forever and the recorder draws a FLAT LINE through the outage, which is indistinguishable from a measurement and manufactures the "there was no surplus" conclusion this card exists to TEST. So the absence is published, with HA's own payload: `mqtt/const.py` declares `PAYLOAD_NONE = "None"` and `mqtt/sensor.py` tests it BEFORE the numeric branch, so the entity's state becomes `unknown` and the recorder stores a GAP. Read out of home-assistant/core `dev` on 2026-09-24 and quoted at the constant. `ABSENT_AS_UNKNOWN` is a one-key set and the suite asserts `circulation: None` is STILL dropped. THE UNIT IS READ OFF THE ENTITY. `mW`, `W`, `kW`, `MW`, `GW`, `TW` - HA's own `UnitOfPower`, every factor an exact power of ten. A sensor with no unit, or a unit outside that table, is REFUSED by name and the status page says which. `read_inputs()`'s `abs(raw) < 50` kW-or-W guess is safe for a quarter-hour demand forecast and is NOT safe here: 30 W of dusk is an ordinary reading and that heuristic would publish it as 30 kW. GENUINELY OPTIONAL, AND NOT A SECOND `price_now_entity`. validate.py does not mention the key - it cannot conflict with anything, because nothing else reads it. The MQTT row lives in a new `OPTIONAL_SENSORS` list whose `include` argument DEFAULTS TO EMPTY, so every caller that has never heard of `pv_entity` - test_mqtt.py's fixtures, tools/rehearse_roster.py, anything written next year - announces exactly what it announced before. Unset: no state call at all, no entity, no topic, no status row, no page row. Set and failing: a CAUTION (`ok=False, warn=True`), never a `bad` row, so a telemetry channel can never put a battery site into NOT READY. IT MUST NOT BECOME A CONTROL INPUT, AND THAT IS GRADED TWICE. `test_pv.py` part 6 drives 40 cycles of the real `cycle()` and asserts the commands are bit-identical across unset / no reading / 0 W / 8 kW, with a COMPUTED census (33 modules under app/) showing the material is mentioned in exactly three: pv.py, main.py, mqtt.py. `tools/tel11_pv_trace.py` is the cross-tree half - `safety56_behaviour_trace.py`'s pattern with a DIFFERENT control clause, because this card's claim is that nothing differs rather than that only sentences do: it REFUSES unless the two `app/` fingerprints differ and unless exactly one side reacts to the option. Measured on 41 stimulus cells: control release/1.0 unset 846a10a5b89e321086d535825925721e2f791012e8405948d4fd38d3f9d0be5f control TEL-11 unset 846a10a5b89e321086d535825925721e2f791012e8405948d4fd38d3f9d0be5f control TEL-11 set 846a10a5b89e321086d535825925721e2f791012e8405948d4fd38d3f9d0be5f telemetry release/1.0 unset a443a6ceaffe072b44bcd5f2ad946c1ed6c9e01b69e278eca631f7f4d7892164 telemetry TEL-11 unset a443a6ceaffe072b44bcd5f2ad946c1ed6c9e01b69e278eca631f7f4d7892164 telemetry TEL-11 set 4e6d1cb289a957223ad0205f732a6fec6110ce1f2032c98ad60694e67625274f UNSET is byte-identical in BOTH documents, which is stronger than "the control path is untouched": an install that does not set the option sees no change of any kind, announcement and status rows included. ⚠️ AND THE CARD'S CENTRAL MUTATION WAS A SURVIVOR ON THE FIRST BATTERY. `self.grid -= self.pv_w` in `read_inputs()` - +106 B, on disk, purged, genuinely running - came back GREEN, because the fixture drove a 6 kW export over 12 cycles, which puts the loop AGAINST ITS RAIL: a command moving `slew_w` every cycle produces the same ramp for -6000 W and for -14 000 W of apparent error. MUTATION.md habit 23 with a saturated ACTUATOR in place of a coinciding value, and it is in that file now as the habit's second instance. The fixture now drives a 600 W import the loop SETTLES on, against a responsive meter, and asks habit 23's own question as its own check: shift the METER by the same 8 kW and confirm the commands really would have moved. Evidence: 31/31 suites green in the CI image, checks.yml's exact command, purged tree, `:ro`. Ten mutations, NO survivors, each on its own `cp -a` of the tree so habit 18's revert hazard is closed by construction - table in `DECISIONS/TEL-11-pv-production.md` §7 with byte deltas and sha256s. ⚠️ THIS IS A RUNTIME CHANGE BEHIND AN UNCHANGED VERSION, AND `tools/predeploy_check.py` WILL REFUSE IT. `app/`, `config.yaml` and `translations/` are all in its `RUNTIME` tuple and `config.yaml` still reads 0.10.1, so the gate reports a NO-OP deploy until a version is cut. That is PKG's call and this card does not take it. No CHANGELOG section: `test_version_gate.py` 11b refuses a newest `## ` heading that is not config.yaml's `version:`, and opening one would mean taking that same packaging decision. The operator account is in DOCS.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-24 15:35:07 +02:00