Found on a real 1312-GA house: a room with floor heating, a convector and an AC unit became
ONE climate (convector setpoint, AC controller mode, AC fan speed as the valve). Room 1.09
matched 2.09 and a central "09." GA, "Kids room 1" took "Kids room 2 temperature", and valves
came from light brightness and blind position statuses. The zone was the room alone: device
words were stripped as qualifiers, "А/С" vanishes in the tokenizer, the floor digit of "1.09"
is dropped.
Now a climate is assembled per room AND device type (floor, wall, radiator/convector, fan
coil, AC; RU/EN/DE words, removed from the zone as whole words):
- room code "N.NN" only at the start of a name, and it must match on both sides;
- standalone numbers of the anchor must be in a device member; a shared room sensor's
numbers must be among the anchor's; digits in dotted codes and values do not count;
- an untyped GA is shared room data: any role if the room has one device, otherwise only
the current temperature, which several devices may reuse; with a room code the room's
untyped sensor qualifies even without the device's extra words;
- a word that sets another device of the room apart keeps its GAs away;
- control roles must be unambiguous: more than one candidate -> review climate_ambiguous;
- two mode GAs that cannot be told apart -> review climate_duplicate_anchor, not dropped;
- only 20.102 / 20.105 anchor; valve needs a valve word; AC never gets a valve;
- stable address order, so results never depend on parse order.
Two gates. Own audit on seven real projects, every changed entity inspected: no control GA
used by two climates, no address lost; house 16 -> 33 climates (one per device), manual
review 33 -> 12; flat 7 -> 9; HDL 3 -> 5; demo 6 -> 13; villa 23 -> 21 with the 3 it cannot
disambiguate sent to review instead of guessed. LLM council (three models + devil's
advocate, sanitised packet): accept with hardening; its P0s (same-type devices, silent
first pick) and P1s (mid-name codes, dotted digits, non-102/105 anchors, generic valve
words) are all in this commit, with tests E and F covering its failure catalogue.
Out of scope, recorded: identically named rooms of different flats without room codes, and
lexical identity in general -> device-channel identity ("lever 0").
Also works around a mypy 2.3.1 parse error on a comment right after a compound if.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a real 1312-GA house (43 of 159 "switch without status" had a Read+Transmit
object on the command GA), measured on all seven corpus projects.
detect_missing_status already counted these as satisfied through pairing.self_reporting();
the generator did not and put them on the review list without a state_address. It now
uses the same function: no separate status found and the command GA has an R+T object
-> state_address = the command GA. Same for the on/off sibling of a dimmable light and
for brightness_state_address on a self-reporting brightness GA. Write-only objects still
go to review.
Corpus: no entity count changed, no address lost; review items 598 -> 555 on the house,
-36, -40, -12, -1, -32 on the others. Test C in test_real_house_fixes.py covers R+T,
write-only and a non-lighting switch.
Not verified on a live Home Assistant: state_address equal to address is accepted by the
KNX schema and xknx reads from it, but no running instance was used here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a real 1312-GA house, measured on all seven corpus projects.
B. Lighting on/off (1.001, lighting category) is emitted as a Home Assistant light with
address + state_address, not a switch. The HA KNX light platform documents exactly
that ("Simple light"). suggest.py already proposed light for these; the two engines
disagreed. Without status it is reported as light_without_status.
D. A 5.001 lighting GA with no on/off GA in its zone produced a light with only
brightness_address. Home Assistant requires address on a KNX light, so that YAML was
invalid. 51 of them across six projects, mostly motion-detector parameters on 5.001.
They now go to review as light_without_switch, and the brightness status is no longer
consumed for an entity that does not exist, so it surfaces as not_mapped.
Corpus, before -> after: lights without address 51 -> 0 everywhere; no address lost from
YAML or review on any project; switch -> light moves of 220 (house), 205, 62, 43, 17, 10,
13. test_pipeline B1 fixture gains its on/off GAs (it encoded an invalid light) plus a
test for the review route. CHANGELOG also records fix A from 481bab0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a real 1312-GA house, confirmed across all seven corpus projects.
- A quantity word in the name of a 1-bit, date/time or text GA names what the flag,
threshold trigger or timestamp is about ("on by motion detector by illuminance",
"CO2 threshold 1", "meter value recorded, date"), not the value. 12 of 12 hits on
1-bit GAs in the corpus were false positives; mains 1, 10, 11, 16, 19 are skipped.
- Legitimate alternatives are accepted, checked against xknx 3.20: power 9.024 kW and
14.080 VA; energy 13.010 to 13.016 and 14.031 J, plus power DPTs under Russian
"электроэнергия" names that are routinely used for power readings.
- Power factor gets its own rule (14.057) ahead of power, so "Фактор мощности" is no
longer expected to be 14.056.
Real findings still fire: a bare DPT 9 named "lux threshold", a 5.x named "temperature
control", a 5.001 named "power", 9.002 named "temperature". New test file
test_real_house_fixes.py, wired into CI.
Corpus: subdpt_suspect 17 -> 2 on the house, 7 -> 2 and 1 -> 0 on two others; no other
metric moved. Baseline re-recorded in this commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recorded on its own, before any product change, so later diffs show only what a fix
moved. Numbers only; the local map with the real path stays gitignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
detect_missing_status already folds in detect_role_completeness, and the guard
called both, so every missing_value_status finding was recorded twice. The
product tools (server, report, handover) only call the aggregate and were never
affected. Found while auditing a TapPlan export with the same call pattern.
Baseline re-recorded in this commit. Exactly 12 metrics moved, all of them that
one code and the warning total it feeds, halved on each of the six projects;
nothing else changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Public CI only runs synthetic fixtures, but every regression we have actually
shipped showed up on real projects, which are confidential and cannot reach a
GitHub runner. corpus_check.py runs a local corpus through the full pipeline
(parse, checks, HA YAML, entity suggestions) and diffs the counts against a
recorded baseline.
Only numbers are committed: counts, severity and code histograms, and a short
digest per source file. The project map with real paths lives in
tools/corpus_map.json, which is gitignored; corpus_map.example.json shows the
shape. Verified both directions: a deliberate change to the diagnostics filter
made the guard exit 1 and name the two metrics that moved, a clean tree exits 0,
and a machine without a map exits 2 without doing anything.
Wired into CONTRIBUTING and into the release checklist before the build step.
