Add raw_value to HomeConnect select

[boergegrunicke]

Proposed change

This adds the raw_value to the program select, which is basically the raw value that was received from the API. This is relevant, because the API reports back some programs that are not selectable from the user (rinsing, self-clean, favorites). But these programs might be still relevant for automations. (The user might want to trigger something when a favorite program starts, but posibly not while the device is self-cleaning itself).
Having this as an attribute in the select, does not break anything for existing users, does not bother "normal" users, but enables users that are interested in it, to read the data and enhance automations.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes # NONE
• This PR is related to issue: NONE
• Link to documentation pull request: NONE
• Link to developer documentation pull request: NONE
• Link to frontend pull request: NONE

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @DavidMStraub, @Diegorro98, @MartinHjelmare, mind taking a look at this pull request as it has been labeled with an integration (home_connect) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of home_connect can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign home_connect Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[Copilot]

Pull request overview

This PR adds a raw_value attribute to the HomeConnect program select entity that exposes the raw API program value. This enables users to detect programs that aren't user-selectable (like rinsing, self-clean, or favorites) for automation purposes, while maintaining backward compatibility with existing functionality.

Key Changes

• Modified update_native_value() to store the raw API program value in extra_state_attributes
• Added error handling for invalid program keys using try-except around ProgramKey conversion
• Updated test to verify raw_value attribute is present in entity state

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
homeassistant/components/home_connect/select.py	Added raw_value to extra state attributes and wrapped ProgramKey conversion in try-except to handle non-selectable programs
tests/components/home_connect/test_select.py	Enhanced test to verify raw_value attribute is correctly set in entity state

[Diegorro98]

We already explored exactly the same feature a while ago at #131874, but after some discussion we decided to discard it.

The programs can be easily added to aiohomeconnect, then they will appear in the entities state so the user can check the value in the automations.

See for example #157174

The drawback (or the advantage) of this way to work is that the users need to report the program keys or even contribute them directly.

[boergegrunicke]

@Diegorro98 Yes, I get this. But when the programs are added to the programs in aiohomeconnect they would appear in the select, and the user could select them. In case of programs like "rinse on startup" (coffee maker) this does not make any sense, because this cannot be set by the user. There are also a bunch of programs that are not available by the API (e.g. maximum efficiency on my dishwasher), so even they would make sense to include, the API would return an error when someone tries to set it using the API.
There is a big discrepancy between programs that ca be set using the API and programs that are reported by the API but cannot be enabled using the API. This change ins only about the programs that might be reported via the API but are not allowed to be set using the API. Back then I suggested (128310) making this possible using an extra sensor for all programs that are reported back from the API, that would still be the better way in my opinion, but the solution in #131874 was fine for me as well. But with the current solution, I do not see a way to have a program that can be reported back from the API but not selected from the users side.

[MartinHjelmare]

Marking as draft until the discussion is settled.

[Diegorro98]

Maybe the solution is not about adding an attribute, maybe we should allow those programs to be present on the entity and improve the error handling to ensure that the user understands that the error is not related to Home Assistant, is because the API doesn't allow using that program. Also we could add the information to the documentation to be clear that some programs are not selectable so that unnecessary issues aren't created,

[boergegrunicke]

In my opinion the select has the intention to present the user options to select from. And adding options there (and there will be a bunch of them), that will knowingly cause an error when they are selected, does not sound right to me.
I could rather imagine to maintian both separtly, user-selectable and non-user-selectable programs, but this would again mean to have an additional sensor, that is only inteded to show the state of the reported program value.

But in any case, another reason to keep the raw value in there: Due to the fully qualified dot notation, that the API is using (e.g. ConsumerProducts.CoffeeMaker.Program.Beverage.Ristretto), it is possible to do easy filtering by a pattern matching, to filter for example only on "Beverage" programs. This might not be relevant for basic user, but for advanced users this would make it much easier to select an entire category of programs, so I think this would be very helpful to have it at least in an attribute.

[Diegorro98]

Apart from my opinion, I don't know if either adding programs that might not work which can be selected or adding an extra attribute with the original key, which maybe for basic users that would like to do an automation based on their favorite program selection is difficult or not very intuitive, meet the Home Assistant quality standards.

[boergegrunicke]

So this means, in result: We are hiding some information that is delivered by the API, but as it could be not intuitive for some users, we do not allow anybody to receive this info at all?
I welcome you to add better suggestions, but currently there is one big chunk of information missing (all programs that cannot be triggered by the user but will only be reported back from the API), and I try to bring suggestions on how to add this piece.

[Diegorro98]

I think you are misunderstanding me, I was just exposing the options that we have.
I'm with you about the fact that it would be helpful to have this attribute for programs that have not been added yet to aiohomeconnect and Home Assistant.

Now that I have more time than yesterday, let me do a bullet-point list about this:

• Adding new programs to aiohomeconnect although they don't work (API responds with an "Program not supported" error).
  • Adding programs it is something we already do, and I personally think that it is a good idea to continue doing it.
  • Programs not working for an user shouldn't be an excuse to avoid adding those programs as maybe there are other users whose appliances allow using those programs.
    • See Dishwasher missing program #155236, where an user requested a program that was missing, and once added the user wasn't able to use it.
      • Although it did not work for the user, it might work for other users that have different models of dishwashers.
  • Suggestion: The documentation can be improved to report that this can happen with some programs, so that users that face this issue can find this resource and be aware that there's nothing wrong with their appliances
  • Suggestion: The error handling can be improved so that in case we get SDK.Error.UnsupportedProgram we can help the user to understand that there's nothing wrong with Home Assistant or the appliance.
• Add an extra attribute called raw_value, which will contain the raw value of the program that the API sends.
  • The user will always be able to check all the programs in its automations. Issues or contributions are not needed to be able to create to get non-added programs based automations working.
    • This discourages the addition of programs to aiohomeconnect and Home Assistant.
  • The user needs to set the program once or download diagnostic file in order to know the program key
  • It might not be intuitive for beginner users.
  • Basic users can also use it in automations as the entity trigger does have the attribute selector. (I'm mentioning this just to retract my self what I said before that could be difficult for basic users)

Based on these points, I wouldn't add this extra attribute. But I invite anyone (and specially to @boergegrunicke) to contribute to this bullet-point list in order to have it as complete as possible to make a decision.

Also, @MartinHjelmare, what's your opinion about this topic?

[MartinHjelmare]

I don't think adding an attribute would be acceptable. We don't need to know the main state of the select entity to understand the attribute value.

A separate sensor that is disabled by default could be acceptable.