[en] Refactor HassLightSet using LLM TDD and new expansions

[ViViDboarder]

This should make the matching more robust and much easier to manage.

This depends on #2728 getting merged first.

[tetele]

"The mid lit" doesn't sound right

Suggested change

	- in: "[the] (half|halfway|mid) [(level|setting|brightness|bright|light|lit)]"
	- in: "([the] (half|halfway|mid) [(level|setting|brightness|light)]|(half|halfway|mid) (bright|lit)"

[tetele]

Suggested change

	- "[<numeric_value_set>] [the] brightness [of [(<all>|<the>)]] <in_area_floor> [<light>] [to] <brightness>"
	- "[<numeric_value_set>] [the] brightness [of [(<all>|<the>)]] <area_floor> [<light>] [to] <brightness>"

[tetele]

This would match "living room 50%" which, again, may not necessarily mean brightness. It could mean fan speed, it could mean many more things. It's too ambiguous

[tetele]

With optional <brightness_relative>, these are the same sentences as above (with <numeric_value_set>. Remove the optional part.

[tetele]

Ouch! "Hey Nabu... 70%" 😅 Definitely no!

[tetele]

Same thing, "70% here" is too vague.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[ViViDboarder]

🤦‍♂️ I got a little carried away it seems. I need to split these to multiple sentences to make sure some of the optional are mutually exclusive.

[ViViDboarder]

I've been trying to think of a good way to address this feedback and one of the things I'm coming to is possibly to break apart something like <brightness_value> and <brightness>. By that I mean, capturing the level vs capturing the words that indicate a brightness intent.

Because right now something like <area> [<lights>] to {brightness} could match kitchen to 80%, when I really want to match either kitchen lights to 80% or kitchen to 80% bright. I'm imagining this then being represented by two sentences <area> <lights> to <brightness_value> [<brightness>] and <area> [<lights>] to <brightness_value> <brightness>

This does mean some possible less used sentences will creep in because there won't be mutual exclusivity between {brightness_level} and <brightness> intent indicators. So it would introduce matches for kitchen to mid lit and other unlikely sentences that are technically unambiguous, but not helpful. This could be remedied by splitting both <brightness_value> and <brightness> into two each that have some distinction (not sure what I'd call them...) and then doubling the base sentences, but that all sounds like a lot more complexity to avoid a couple unuseful sentences.

I'll make the refactor and we can debate another further split after.

[ViViDboarder]

Oh! I just thought of an alternative that could avoid the vague matches like room 50%. what about required keywords? If a list of required keywords included <light> + (bright|brightness|light|lit|brighten|lighten|dark|darken|dim), then all the ambiguous sentences would be skipped.