Sensors or Select boxes are shoing raw enum values looking something like BSH.Common.Program.XXX

[ekutner]

These values are used by the Home connect API and exposed by the integration for scripting and event publishing. The integration is using these values so they match the Home Connect API documentation.
Since these enum values are not very user friendly the integration relies on the Home Assistant translation capabilities to translate them into friendly names in supported languages. All the documented values have already been translated however there seem to be some undocumented values that can only be translated when users report them because until that happens there is no way to know they even exist. In the comments to this issue you can report on untranslated values to be added to the integration.
Please do NOT share screenshots, only text values of these enum values will be considered.

Important Note

The Home Assistant translation doesn't seem work for the sensor history display, so please don't report on their existence in there.

[emufan]

Dishwasher:

BSH.Common.EnumType.PowerState.Off
BSH.Common.EnumType.PowerState.On
BSH.Common.EnumType.OperationState.Inactive
most probably SH.Common.EnumType.OperationState.Active

Washing Machine

BSH.Common.EnumType.OperationState.Ready

And for
Dishcare.Dishwasher.Program.Intensiv70, Dishcare.Dishwasher.Program.Auto2, Dishcare.Dishwasher.Program.Eco50, Dishcare.Dishwasher.Program.NightWash, Dishcare.Dishwasher.Program.Kurz60, Dishcare.Dishwasher.Program.Glas40, Dishcare.Dishwasher.Program.Quick45, Dishcare.Dishwasher.Program.PreRinse, Dishcare.Dishwasher.Program.MachineCare
I don't know yet, if the diisplay of them is wanted behavior or should be used/displayed (I would prefer!) as Intensiv70, Auto2, Eco50, etc.

Same for
LaundryCare.Washer.Program.Cotton, LaundryCare.Washer.Program.EasyCare, LaundryCare.Washer.Program.Mix, LaundryCare.Washer.Program.DelicatesSilk, LaundryCare.Washer.Program.Wool, LaundryCare.Washer.Program.DarkWash, LaundryCare.Washer.Program.ShirtsBlouses, LaundryCare.Washer.Program.WaterProof, LaundryCare.Washer.Program.Curtains, LaundryCare.Washer.Program.MyTime, LaundryCare.Washer.Program.Auto30

[ekutner]

@emufan Where exactly do you see those values and and in what language? They are already translated and should appear in their friendly names in English and German. You can see the translation files here: https://github.com/ekutner/home-connect-hass/tree/master/custom_components/home_connect_alt/translations

If you are using a different language you are welcome to contribute a translation to that language.

[BeerBOFH]

Seeing the same issue here as emufan on a Washing Machine and using Home Assistant in English.

BSH.Common.EnumType.OperationState.Ready
BSH.Common.EnumType.PowerState.Off
BSH.Common.EnumType.PowerState.On
LaundryCare.Washer.Program.*

If I add "language: en-GB" to configuration.yaml the values appear correctly.

[emufan]

I see them as states in developer tools.

And I see them in all histories of the listed entities, which is not really usefull.

So, somewhere/somehow the short-translation is used, sometimes not in this cases. Language in yaml is not set to anything.

If this is a bug, you can of course split and move it to a sperated issue.

[ekutner]

@emufan As I noted. They are in the developer tools by design. These are the values documented in the Home Connect API documentation so they are also used for scripting the integration. Scripts should not depend of translated strings and these values will work regardless of your selected language.
They show up in the history because of a limitation in the HA translation implementation (at least as far as I can tell). I'm planning to open a feature request to improve this but haven't gotten to it yet.

@BeerBOFH If you see these values in the same place as @emufan then see the above explanation, otherwise specify where you do see them.

[emufan]

They are in the developer tools by design.

I think you are wrong. As this was/is not the case for other entities and after putting now de-DE in yaml, most of them disappeared as well. Afterwards not only the status is shown correctly in entity, it is shown in developer tools and history correctly as well. Not for all items but for most of them.

So this cannot be by design, but different assignments in the integration. Here I'm not the expert, if you hand over different variables for log, recorder and state or whatever is happening compared to the entities which were correct directly from the beginning and those, which are now right with de-DE and which are still not correct.

I will start from scratch and will make a table next days, if I have more time, and provide the findings. Perhaps you can then easier find the different behavior in your codings.

[ekutner]

I should have been more specific, I'm talking about "select" entities. Sensors are translated according to the configured language.

[emufan]

O.k. could be the case. I will double-check.

[emufan]

O.k. Think I got it now. But it is not only for selects, but for sensor as well, if I don't use de-DE, isn't it? See yellow markers in first column below. Is it a HA limitation there as well? Or a gap here?

green without de-DE, pink with.

BTW in other types, it is working, e.g. vacuum state. There internal state is e.g. docked, but displayed state is translated and translated state is display in history bars, etc. Same for alarm_control_panel, cover, media-player, weather, etc. entities.

On the one hand, I like to don't use de-DE because, as you said, to have language independent internal states to automate and script, but on the other hand, for the yellow marks in column one it is better in history charts, etc.

And I like the friendly name. Do you think it is an idea to have separates yaml-entires for state and name? Currently, I would like to switch it on for names, but not for states, for the given reason for automations and in hope, that the history states displaying will be improved in the future in these cases.

Secondly, yellow and orange one in third column below. Binary as non-binary coming from API and therefor only possible that way? And if yes, possible to adjust it to lowercaes in cases of such binary states, to don't have Off and off?

And thirdly: The red one in column three is finaly indeed fitting to the main topic, 😂

[ekutner]

I've updated the README file with a better explanation of how it works.

Do you think it is an idea to have separates yaml-entires for state and name?
I can't do that. When the language param is not set the friendly name relies on HA's translation mechanism. The correct fix is for HA to properly translate sensor values when they are displayed in the history too, not only when the current value is displayed.

[emufan]

O.k. Much better. 😉

I have added three missing EnumTypes per PR.

But I still get not, why it is possible for alarm_control_panel, cover, media-player, weather, etc. entities to display is "correctly" in history. Besides the select boxes, but they of course differ from the other entities.

And what is with the yellow and orange items in the third column. See questions above.

[ekutner]

I'm not sure what is your question re. the red and yellow.
However, looking at the table reminded me that setting the language param also translated the entity names, not only the sensor values. So now I think I understand what you asked for in the previous comment. I can add a parameter that will separate the state and the name translation, and makes sense to add it.

[emufan]

So now I think I understand what you asked for in the previous comment. I can add a parameter that will separate the state and the name translation, and makes sense to add it.

Yes, that was what I wanted to suggest.

I'm not sure what is your question re. the red and yellow.

First the one is Off (and in other case most probably On) and all others are off/on in lowercase. And for me it seems that these are booleans, but in these cases not created as boolean-sensors. But perhaps you drive the type from the API and than it is as it is.

[ekutner]

The type is derived automatically from the API. You can tell the type of sensor by looking at the entity ID which starts either with "binary_sensor", for boolean sensors, or with "sensor", for all other types.
When you see "Off" in a regular sensor, that's because it can have other, non-boolean, values. For example, on my washing machine the level of detergent to use can be High, Medium, Low or Off, indicating the machine should not add detergent automatically.

[mija87]

Hi,

If I add sensor_value_translation: server to the config, i get to see this: Invalid config for [home_connect_alt]: [sensor_value_translation] is an invalid option for [home_connect_alt]. Check: home_connect_alt->home_connect_alt->sensor_value_translation. (See /config/configuration.yaml, line 31).

Someone have an idea about this?

[alsFC]

Hi,

If I add sensor_value_translation: server to the config, i get to see this: Invalid config for [home_connect_alt]: [sensor_value_translation] is an invalid option for [home_connect_alt]. Check: home_connect_alt->home_connect_alt->sensor_value_translation. (See /config/configuration.yaml, line 31).

Someone have an idea about this?

same for me
sensor_value_translation: server as well as sensor_value_translation: local don't work. Rolled back to 0.4.6.

[ekutner]

@alsFC @mija87
This is not the right issue to report this problem but anyway, take a look at #32 there may be a problem when copying and pasting the parameter name, try typing it manually.

[alexdelprete]

I see two sensors (BHS.Common.*) not translated, but they are in the select.en.json and sensor.en.json translation files.
I also have Dishcare.Dishwasher.Program.Auto2 not being managed properly.

I'm using 0.5.0-b2 and I have sensor_value_translation: local and language set to en, I tried using en-GB but it makes no difference. If I use sensor_value_translation: server everything's ok.

What am I missing?

[ekutner]

@alexdelprete it's a bit confusing but the translation file is not selected by what you configure in the integration configuration but by the language you have configured for the Home Assistant. Is your HA language English?

As a side note, I noticed that the translation you are getting from the server for the Auto2 program is not just "Auto 2" but "Auto 45-65C" so would be great if you can check what are the correct translations for Auto1 and Auto3 as well.

[alexdelprete]

Is your HA language English?

IIRC, HA language is based on the user profile. I can't find a "default language" setting.

so would be great if you can check what are the correct translations for Auto1 and Auto3 as well

so I switch the program on the dishwasher and report back what's being sent by the server?

[ekutner]

I was referring to the language set in the profile.

[alexdelprete]

I was referring to the language set in the profile.

It's english.

[alexdelprete]

would be great if you can check what are the correct translations for Auto1 and Auto3 as well.

I have eight programs, tried them all starting from the first (Auto 35-45°C):

[ekutner]

I was referring to the language set in the profile.

It's english.
Then I'm not sure what can cause this because it is handled automatically by HA. There are a few things worth trying:

1. Change the HA language to German and see if these values get translated to German.
2. Verify that the translation folder exists on your hard drive and has the same permissions as the other folders. This is unlikely to be the issue but I'm just throwing any idea I have.
3. If they don't get translated then let me know what is the entity IDs of the sensor that shows the untranslated values, just to make sure the translation is in the correct section of the file.

[alexdelprete]

@ekutner I upgraded to b7 and switched to local again: the problem is solved, didn't do anything else. I guess you fixed something.

I noticed an issue with OperationState, will open a separate issue.

Thanks.

[ekutner]

Nothing in that version would have solved such a problem but as long as it's gone I'm going to close this issue

[ekutner]

@ChristophCaina It should work both ways, I actually never noticed any difference between using only the language code or language-locale.

[von-Chaps]

BOSCH OVEN
Cooking.Oven.Program.Cleaning.Ecolysis
Cooking.Oven.Program.HeatingMode.LetRest
Cooking.Oven.Program.HeatingMode.HotAirGentle
Cooking.Oven.Program.HeatingMode.GrillLargeArea

[ChristophCaina]

@ekutner : The reason for what I've noticed in my comment was pretty simple...
No translation for the entity available... Therefore, I've created PR #119 it is running locally on my system so far - and working well :)

[ekutner]

@ekutner : The reason for what I've noticed in my comment was pretty simple... No translation for the entity available... Therefore, I've created PR #119 it is running locally on my system so far - and working well :)

I saw that but I try to keep the list properly sorted, your PR adds lines which are not sorted. It's not a big deal but I didn't have time to deal with reordering the lines so I didn't merge the PR yet.

[ChristophCaina]

Oh okey.
Let me Check how to sort them better

@ekutner :
Was it just the ordering for these two lines?
"ConsumerProducts.CoffeeMaker.Program.CleaningModes.ApplianceOffRinsing": "Appliance OFF rinsing",
"ConsumerProducts.CoffeeMaker.Program.CleaningModes.ApplianceOnRinsing": "Appliance ON rinsing",

Off before On - or should I move both lines somewhere else?
I wanted to keep the "coffee-related" program translations together and then add the cleaning related programs - that's why I decided to put them after the others... :)

If you could give a short update maybe as a comment on the PR, I can do the changes you like :)

[ChristophCaina]

hi @von-Chaps,
Can you maybe provide, how these are displayed in the Homeconnect app?

• Cooking.Oven.Program.Cleaning.Ecolysis => I would use "Eco-Clean" (?)
• Cooking.Oven.Program.HeatingMode.LetRest =>
• Cooking.Oven.Program.HeatingMode.HotAirGentle =>
• Cooking.Oven.Program.HeatingMode.GrillLargeArea => I would use "Grill large area" (?)

hi @DjBac
Can you please provide, how these are displayed in the HomeConnect app?

• Cooking.Hob.Program.PowerLevelMode =>
• Cooking.Hob.EnumType.ZoneSelector.FrontRight =>
  Do we also need ZoneSelector "FrontLeft", "RearRight", "RearLeft" - or what ever else is being used?

[von-Chaps]

@ChristophCaina

• Cooking.Oven.Program.Cleaning.Ecolysis => Cleaning function
• Cooking.Oven.Program.HeatingMode.LetRest => Let rest
• Cooking.Oven.Program.HeatingMode.HotAirGentle => Gentle hot air
• Cooking.Oven.Program.HeatingMode.GrillLargeArea => Grill, large area

Ecolysis is just displayed as "Cleaning function", it makes no mention in the app of any "eco" aspect.

Many thanks.

[slippyr4]

As I understand this, you've taken the design decision to use the full string representation of the various enum types as the state value for the corresponding state entities, and rely on home assistant's translation feature to map from that home connect api defined string to something readable.

This isn't an approach I've seen other integrations use, and I do see that on the surface it's a nice solution, in practice it seems to be more trouble than it's worth.

The fact that not all parts of HA use the translation system makes a lot of stuff really hard to use. As you acknowledge in the first post, it's not supported in History, which is really unhelpful. It makes creating automations harder, because, for example if you want to do something when the appliance power is turned on, you need to specify a non friendly, overly long string "BSH.Common.EnumType.PowerState.On" instead of just "on", which is typical of all the other integrations I'm familiar with, including the "official" home connect integration.

Are you really wedded to this approach? There's a lot to like about this integration - dynamically only creating relevant entities etc - but the usability regressions compared to the "official" one make it far from clear that this is the best one to use.

[ekutner]

@slippyr4 That's a good summary and that approach is not going to change for what I believe are good reasons. You are more than welcome to use the other integration.

[xrh0905]

BSH.Common.EnumType.AmbientLightColor.Color1 Blue, I guess?

[d0np3p3]

Do we have to add the Translation to sensors.json or select..json or both?
I want to correct one and add one Translation.

[ekutner]

Both

[d0np3p3]

Okay the both diff very much in German,
Also the order diffs to English, I try to correct the German files, and add the both changes.
I will make a pull request.

[seb2020]

Hi,
I have set to use french for the language. I have see that some texte are already translated inside my HA interface but I didn't find the fr.json in the repo. How the translation is done ?

Second question : I have forked the projet to create the fr language file. Sould I translate all the json or only the missing translation ?

[ekutner]

@seb2020 Not sure how it can be translated, unless you're using sensor_value_translation: server

It will be great if you do the French translation. Make sure you start with the English file because it is the most complete. Note that the sensor translation is a superset of the select translation, so you don't have to do it twice. Ideally you should translate the whole file so it works as expected for other users.

[swejmansson]

Just installed Home Connect Alt through HACS and had issues with translation, tried to switch HA/User language to Swedish, English and British English. Restarted etc, still strange status. Read this post and some others, eventually added to yaml:
language: en-GB sensor_value_translation: server

Now working fine. There is something fishy going on. I will leave it as it is for now. Making this reply to give feedback and help others.

Running:
Home Assistant 2023.3.2
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230306.0 - latest

Home Connect Alt 0.6.0

[seb2020]

@seb2020 Not sure how it can be translated, unless you're using sensor_value_translation: server

It will be great if you do the French translation. Make sure you start with the English file because it is the most complete. Note that the sensor translation is a superset of the select translation, so you don't have to do it twice. Ideally you should translate the whole file so it works as expected for other users.

I will start with the sensor file. Is this possible to test in live my translation ? If I put the file in my HA, item will be renamed with the translation ?

[ekutner]

If you place the files in the translations folder and restart HA it should work. Note that you should also translate en.json

[seb2020]

Should I set the language: fr in the configuration of my ha for using the translation ?

[ekutner]

@seb2020 you should set the HA UI language to FR, not in the config file

[metawops]

After upgrading to 0.6.1 everything related to the translations works much better. 😊
However, with my Siemens EQ.9 coffee maker I have ONE single sensor still untranslated:

The value I currently see is ConsumerProducts.CoffeeMaker.EnumType.CoffeeMilkRatio.80Percent and the name of the entity is sensor.siemens_ti909701hc_68a40e138d03_consumerproducts_coffeemaker_option_coffeemilkratio.

Couldn't find anything with CoffeMilkRatio in the en.json translation file so I thought I might report this here.
I don't know the complete set of possible values here so I'm not able to make a new version of the file (and the German one) for a pull request. 🤷‍♂️

[metawops]

Bonus question 😉
Anyone any idea how to make a Mushroom Select card to show the translated values instead of the original API enums?
Screenshot:

But I guess that's more a question for the Mushroom cards developer, right? 😳

[EvertJob]

My dishwasher is showing some strange values:

Siemens Dishwasher - Active Program is showing Dishcare.Dishwasher.Program.Quick45

[EddyK69]

Missing translation on Siemens Washer program:
LaundryCare.Washer.Program.PowerSpeed59 (language Dutch)

[ekutner]

@EddyK69 feel free to create a PR with the translation

[EddyK69]

@EddyK69 feel free to create a PR with the translation

See PR #250

[Langtonpaul]

Hi all new to scrips and new coffee maker I have a untranslated state for coffee maker.
ConsumerProducts.CoffeeMaker.Program.Beverage.HotWater and
sensor.713050390774001643_consumerproducts_coffeemaker_option_coffeemilkratio

Can I ask when using Call a service 'Home Connect Alt: Apply setting' on can anyone tell me what the format for both the 'Setting key' and setting value wold be when my entity is.
select.713050390774001643_consumerproducts_coffeemaker_option_beanamount
and the state is ConsumerProducts.CoffeeMaker.EnumType.BeanAmount.Mild
Thanks

[ekutner]

With server translation now supporting the select entities it is finally time to close this issue.

[oywino]

Not so fast! I have updated to version 1.0.0 and believe I I have sensor value translation issues with my Inductive Siemens Cooker:

sensor.siemens_ex677lyv5e_68XXXXXXX8e_cooking_hob_option_zoneselector
Cooking.Hob.EnumType.ZoneSelector.FrontRight

sensor.siemens_ex677lyv5e_68XXXXXXXX8e_powerlevel
Cooking.Hob.EnumType.PowerLevel.Off

None of the above two sensors accept my attempt to rename them in the UI.