Follow up from the review of #2782.
Problem
The split _i2c / _spi multi sensor platforms (bme280_i2c, bmp280_*, bmp3xx_*, bmp581_*, ens160_*, ina2xx_*, spa06_*, ade7953_*, airthings_wave_mini; 17 in the 2026.9.0 catalog) declare their temperature / pressure / humidity blocks on a shared base schema (bme280_base.CONFIG_SCHEMA_BASE). _push_config_vars in script/sync_components.py pulls only the inherited id from an extends base, so those nested sensor ids never reach provides_id_paths. The only candidate these platforms offer a sensor reference is their hub id, which esphome rejects, and with #2782 plus esphome/device-builder-frontend#1760 that hub id is filtered out, so they offer nothing.
What I tried
Pulling nested blocks from the extends base as well:
- At every level: the sync went from about 80 seconds to more than 7 CPU minutes, because every entity block drags its inherited filters and automations into the walk.
- At the component root only: normal run time, and against esphome 2026.9.0 it changes 37 component bodies:
- the 17 split sensor platforms gain
provides: ["sensor"] with their real nested ids and lose the hub id_classes, which is the goal;
- the 8
wk2xxx_i2c / wk2xxx_spi hubs gain provides: ["uart"] through uart[].id, which looks right;
sensor.airthings_wave_plus gains five more nested sensor ids;- 11 of the 38 display platforms gain
provides: ["display"] through pages[].id.
The last one is the blocker. provides_id_paths is keyed by namespace, not class, and display::DisplayPage lives in the display namespace and is a referenced class (the page actions), so page ids would be offered in every display reference picker, a touchscreen's display: field included.
Direction
The nested leaf rule in _record_id_classes treats any class in a platform domain's namespace as an entity class. A data derived tightening would be to count a nested leaf class only when some component of that domain declares the same class at its root (sensor::Sensor is, display::DisplayPage never is). With that in place the root only inheritance above should be safe to land. No curated table is needed for either half.
Follow up from the review of #2782.
Problem
The split
_i2c/_spimulti sensor platforms (bme280_i2c,bmp280_*,bmp3xx_*,bmp581_*,ens160_*,ina2xx_*,spa06_*,ade7953_*,airthings_wave_mini; 17 in the 2026.9.0 catalog) declare theirtemperature/pressure/humidityblocks on a shared base schema (bme280_base.CONFIG_SCHEMA_BASE)._push_config_varsinscript/sync_components.pypulls only the inheritedidfrom anextendsbase, so those nested sensor ids never reachprovides_id_paths. The only candidate these platforms offer asensorreference is their hub id, which esphome rejects, and with #2782 plus esphome/device-builder-frontend#1760 that hub id is filtered out, so they offer nothing.What I tried
Pulling nested blocks from the
extendsbase as well:provides: ["sensor"]with their real nested ids and lose the hubid_classes, which is the goal;wk2xxx_i2c/wk2xxx_spihubs gainprovides: ["uart"]throughuart[].id, which looks right;sensor.airthings_wave_plusgains five more nested sensor ids;provides: ["display"]throughpages[].id.The last one is the blocker.
provides_id_pathsis keyed by namespace, not class, anddisplay::DisplayPagelives in thedisplaynamespace and is a referenced class (the page actions), so page ids would be offered in everydisplayreference picker, a touchscreen'sdisplay:field included.Direction
The nested leaf rule in
_record_id_classestreats any class in a platform domain's namespace as an entity class. A data derived tightening would be to count a nested leaf class only when some component of that domain declares the same class at its root (sensor::Sensoris,display::DisplayPagenever is). With that in place the root only inheritance above should be safe to land. No curated table is needed for either half.