Discover scalar composite features in Home Assistant

[MaxRink]

Summary

• Discover safe scalar composite features in Home Assistant instead of hiding all composite children.
• Preserve and inherit Home Assistant config/diagnostic metadata from composite exposes to scalar child entities.
• Disable write-only composite settings and advanced Wi-Fi composite settings by default so they do not clutter HA device pages.
• Mark seasonal watering adjustment children and the scalar irrigation remove index as disabled config controls.
• Preserve and inherit Home Assistant metadata on scalar child discovery payloads.
• Continue skipping secrets and non-scalar composite children.

Review feedback addressed

• The use case is devices where scalar diagnostic/configuration values are currently nested inside a composite expose and are safe to publish as individual HA entities.
• This does not try to split atomic composite controls that must be written as a single object; those should stay composite or be represented differently in the converter.
• Category inheritance keeps converter-level grouping intent intact for HA even when scalar children are discovered independently.
• The SONOFF valve converter PR now moves independent controls, including plan removal, to scalar exposes where possible; this PR remains the generic fallback for safe scalar children still nested in composites.

Home Assistant limitation

MQTT discovery can set entity_category and enabled_by_default, but it cannot create arbitrary custom sections on a device page or attach sibling entities to a valve more-info dialog. Grouped irrigation/manual-control UI still needs a dashboard/card or future Home Assistant support.

Scope note

• Device-option plumbing for overrideHaDiscoveryPayload was moved to the smaller dedicated PR Pass device options to HA discovery overrides #32379 so this PR stays focused on scalar composite discovery.

Validation

• npm exec --yes pnpm@10.18.3 -- exec vitest run test/extensions/homeassistant.test.ts --config ./test/vitest.config.mts
• npm exec --yes pnpm@10.18.3 -- run check
• npm exec --yes pnpm@10.18.3 -- run build

Live validation on my Home Assistant instance

• Deployed the built Home Assistant discovery override together with the current ZHC SONOFF valve override to the Zigbee2MQTT add-on.
• Verified retained discovery for homeassistant/number/0xa4c1381456c7ffff/irrigation_plan_remove_plan_index/config contains entity_category: config, enabled_by_default: false, and commands zigbee2mqtt/Bewässerungsventil/set/irrigation_plan_remove_plan_index.
• Verified the live SONOFF valve exposes scalar irrigation controls through zigbee2mqtt/bridge/devices and no longer exposes the old irrigation_plan_remove composite publicly.

Combined live validation on my Home Assistant instance - 2026-06-23:

• Stacked this PR with the valve and readback PRs and ran node --run check, node --run build, and node --run test locally: 23 files, 792 tests passed.
• the Home Assistant entity registry shows scalar manual/config entities such as number.bewasserungsventil_manual_irrigation_duration, select.bewasserungsventil_manual_irrigation_mode, select.bewasserungsventil_manual_irrigation_amount_unit, and number.bewasserungsventil_manual_fail_safe.
• Native HA/MQTT discovery still cannot group these into custom device-page sections or attach them to the valve more-info dialog; the practical workaround remains a dedicated dashboard section.

[MaxRink]

Superseded by the current live validation notes in the PR description.

[Koenkk]

I think this is similar to #32362 (comment), maybe we should change the device expose instead? I think we over-used composite a bit. It should only be used for cases were e.g. 2 properties always need to be set together, and I don't think HA supports that (e.g. image a config for a window cover where both left and right calibration position have to be set together, in 1 message send to the device).

[MaxRink]

Agreed on the distinction. This PR is scoped to safe scalar composite children only; atomic composite controls that need one object payload should stay composite or be represented differently in the converter.

The water-valve work also has a converter-side split where possible, so this generic path is for the remaining cases where scalar config/diagnostic values are still nested inside a composite.