Discover scalar composite features in Home Assistant

[MaxRink]

Design outcome

This remains draft intentionally.

Reviewer feedback pointed out that broad scalar-composite discovery is the wrong default when a converter can expose independent values directly. The SONOFF valve work moved the affected irrigation/manual-watering values to scalar exposes in zigbee-herdsman-converters, which is the preferred fix for that device and avoids Home Assistant discovery guessing intent from composite children.

Current scope if this is revived

• only expose scalar composite children for a concrete device/use case that cannot be represented cleanly in the converter
• do not split composite values that are atomic and must be written as one object
• keep converter-provided metadata as the source of truth instead of adding Home Assistant-specific inference

Review note

Koenkk suggested changing the device expose instead, because composite should only be used when multiple values must be written together. This PR is therefore kept separate from the converter-side fix and intentionally does not try to generalize beyond the remaining safe cases.

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.

Status

Kept as draft, not ready for merge. The practical path is to continue fixing over-used composites in zigbee-herdsman-converters first, then revisit this only if a clear generic gap remains.

[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.