Inherit a base's sub-blocks in the id walk so split platforms offer their nested sensor ids

docs/API.md

@@ -285,7 +285,7 @@ The per-device automation rows follow it too: an `AvailableComponentInstance` (`
 
 `bus_constraints` ships on both the index entry and the body, present only when non-empty (72 of ~970 components). Keyed by bus id (`i2c` / `spi` / `uart`, or a typed hub such as `modbus`), it carries the requirements the component's `final_validate_device_schema` imposes on the bus it attaches to: `require_tx` / `require_rx` mark pins the component claims (ESPHome allows at most one claimant per pin per uart bus), scalars like `baud_rate` / `data_bits` / `parity` / `stop_bits` are exact-match settings, a list is a choice set (first = default), and `min_frequency` / `max_frequency` are range bounds. The frontend uses the body copy to pre-fill a dependency-added bus and the index copies to judge whether an existing bus can host a component being added without hydrating every configured component's body.
 
-`provides_id_paths` is a sibling field on the same index entry, present only when a provided interface's id is *nested* rather than the component's own top-level `id`. It maps an interface namespace to the YAML key-paths the frontend descends to collect candidate ids; `usb_uart` exposes `uart` at `{"uart": [["channels", "id"]]}`, and a component declaring one interface at several nested locations (`sprinkler` switches) lists every path. Absent for own-id providers, whose ids resolve through the section id directly. A same-domain provider may additionally list the root path `["id"]` when the component's own id is itself an entity (`sensor.pulse_counter`), so hybrid platforms keep their root entity offerable alongside the nested ones.
+`provides_id_paths` is a sibling field on the same index entry, present only when a provided interface's id is *nested* rather than the component's own top-level `id`. It maps an interface namespace to the YAML key-paths the frontend descends to collect candidate ids; `usb_uart` exposes `uart` at `{"uart": [["channels", "id"]]}`, a component declaring one interface at several nested locations (`sprinkler` switches) lists every path, and a path reaches ids a platform inherits from a shared base (`sensor.bme280_i2c`'s `temperature` / `pressure` / `humidity` live on `bme280_base`). The paths are enumerated, so a self-referential schema is listed one level deep: `lvgl` offers a widget at `widgets[]` but not one nested inside another widget's `widgets[]`. Absent for own-id providers, whose ids resolve through the section id directly. A same-domain provider may additionally list the root path `["id"]` when the component's own id is itself an entity (`sensor.pulse_counter`), so hybrid platforms keep their root entity offerable alongside the nested ones.
 
 `references_class` on a reference `ConfigEntry` names the C++ class the referenced id must inherit (`output::FloatOutput`). It is present only when some candidate of `references_component` fails it, so most references carry none. The matching declarer side ships on both the index entry and the body: `id_classes` lists the classes declared at the component's root (its own `id`, plus any generated sibling id such as a light's `output_id`), and `id_classes_by_variant` does the same per variant of a typed hub whose variants declare different classes (`modbus`: `{"role": {"client": [...], "server": [...]}}`); on such a hub `id_classes` is the default variant's, what a block with no discriminator declares; a hub whose discriminator is required (`output.template`) has no default and ships `id_classes_by_variant` alone. Both are emitted only on a declarer some reference rejects (a binary only `gpio` output for a light that needs a float output). A reference no offered declarer can satisfy is left unfiltered, since the bundle then cannot name its real candidates (`i2c` picks its id class in a function). The frontend drops a picker candidate only when its classes are known and lack the required one; an unannotated declarer always stays offered. `id_classes` describes only the component's own section `id`; a candidate reached through `provides_id_paths` (a `shelly_dimmer` light's `power` sensor) is never judged by it. An automation's `references_class` is kept only for a class the component catalog kept, so a class only automations reference never filters. A dependent that needs one non-default variant of a typed hub also gets it in `bus_constraints` (`hoermann_hcp`: `{"modbus": {"role": "server"}}`), so a dependency-added hub is created with that variant.
 

esphome_device_builder/definitions/automations/actions/sensor.template.publish.json

@@ -1 +1 @@
-{"id":"sensor.template.publish","name":"Sensor.Template → Publish","description":"You can also publish a state to a template sensor from elsewhere in your YAML file with the `sensor.template.publish` action.","docs_url":"https://esphome.io/automations/actions","domain":"sensor.template","config_entries":[{"key":"id","type":"id","label":"ID","description":"The ID of the template sensor.","required":true,"display_format":null,"references_component":"sensor","references_class":"sensor::Sensor","help_link":"https://esphome.io/components/sensor/template#in-some-trigger"},{"key":"state","type":"float","label":"State","description":"The state to publish.","required":true,"display_format":null,"templatable":true,"help_link":"https://esphome.io/components/sensor/template#in-some-trigger"}],"is_control_flow":false,"has_else_branch":false,"has_condition_gate":false,"accepts_action_list":[],"scalar_shorthand_key":null}
+{"id":"sensor.template.publish","name":"Sensor.Template → Publish","description":"You can also publish a state to a template sensor from elsewhere in your YAML file with the `sensor.template.publish` action.","docs_url":"https://esphome.io/automations/actions","domain":"sensor.template","config_entries":[{"key":"id","type":"id","label":"ID","description":"The ID of the template sensor.","required":true,"display_format":null,"references_component":"sensor","help_link":"https://esphome.io/components/sensor/template#in-some-trigger"},{"key":"state","type":"float","label":"State","description":"The state to publish.","required":true,"display_format":null,"templatable":true,"help_link":"https://esphome.io/components/sensor/template#in-some-trigger"}],"is_control_flow":false,"has_else_branch":false,"has_condition_gate":false,"accepts_action_list":[],"scalar_shorthand_key":null}

esphome_device_builder/definitions/automations/conditions/sensor.in_range.json

@@ -1 +1 @@
-{"id":"sensor.in_range","name":"Sensor → In Range","description":"This condition passes if the state of the given sensor is inside a range.","docs_url":"https://esphome.io/automations/actions","domain":"sensor","config_entries":[{"key":"id","type":"id","label":"ID","required":true,"display_format":null,"references_component":"sensor","references_class":"sensor::Sensor"},{"key":"above","type":"float","label":"Above","description":"**Required — set at least one of:** `above`, `below`.\n\nThe minimum for the condition.","display_format":null,"help_link":"https://esphome.io/components/sensor#in-a-trigger"},{"key":"below","type":"float","label":"Below","description":"**Required — set at least one of:** `above`, `below`.\n\nThe maximum for the condition.","display_format":null,"help_link":"https://esphome.io/components/sensor#in-a-trigger"}],"accepts_condition_list":false,"scalar_shorthand_key":null,"required_groups":[{"kind":"at_least_one","keys":["above","below"]}]}
+{"id":"sensor.in_range","name":"Sensor → In Range","description":"This condition passes if the state of the given sensor is inside a range.","docs_url":"https://esphome.io/automations/actions","domain":"sensor","config_entries":[{"key":"id","type":"id","label":"ID","required":true,"display_format":null,"references_component":"sensor"},{"key":"above","type":"float","label":"Above","description":"**Required — set at least one of:** `above`, `below`.\n\nThe minimum for the condition.","display_format":null,"help_link":"https://esphome.io/components/sensor#in-a-trigger"},{"key":"below","type":"float","label":"Below","description":"**Required — set at least one of:** `above`, `below`.\n\nThe maximum for the condition.","display_format":null,"help_link":"https://esphome.io/components/sensor#in-a-trigger"}],"accepts_condition_list":false,"scalar_shorthand_key":null,"required_groups":[{"kind":"at_least_one","keys":["above","below"]}]}