Translation issues

[mundschenk-at]

Hi @astrandb, I've been trying to improve the German translation and noticed a conceptual issue: Currently different status values are mapped to the same technical string (e.g. both 260 for washing machines and 1795 for dishwashers map to main_wash. However the German term for that phase depends entirely on the device, so for washing machines it should be Waschen (what the Miele API/app uses) or Hauptwaschgang, whereas for dishwashers the API uses Reinigen, which is much more appropriate.

Is it possible to make the translation context dependent, i.e. for which kind of device the sensor is, or do we need to have more concrete technical status strings to enable appropriate translations?

[astrandb]

We could map 1795 to main_dishwash and make consequential changes in translation files. OK?

[mundschenk-at]

Sounds good to me. Some others that I think we should check:

• 257 and 259 from washing machines and 1794,1801 are all mapped to pre_wash. I'd have to check to API, but I don't think even the two washing machine codes designate the same phase (let alone for the dish washer).
• 533 is mapped to rinses: It is unique, but I think this is a bit unfortunately named. Not sure what it is supposed to mean in the context of dryer operations.
• 527 is missing, the German name is "Thermoschleudern" (i.e. "thermal spinning") I believe.

(The API is acting weird again, partially I got English translations when executing with de.)

[astrandb]

It will be a Mission Impossible to catch all program_ids and program_phases by watching the UI. Perhaps it could be good to make a little log facility that logs all raw and localized values for program_id and program_phase while they are passing by. We could flag the values that are not defined in the code already.

[mundschenk-at]

Yes, that sounds like a great idea. (BTW: Sometimes for whatever reasons, the API doesn't return a localized name. And even the app sometimes shows incorrect values for e.g. set drying features, which go away when you re-open the screen.)

[mundschenk-at]

I have created PR #18 for some of the issues discussed here.

[astrandb]

I just found this page on openHAB with a lot of useful info. However, my priority is to make all features such as services, settings etc work before diving into new appliance types.

[mundschenk-at]

I've read through the openHAB page and it does include a lot more programs. We have to split STATE_PROGRAM_ID according to device type as the numbers do overlap. (It's not just theoretical/hearsay, I've confirmed some of those program IDs with my devices.)

From reading the code, would we have separate MieleSensorDefinitions limited to specific types or simply make the convert function depend on the actual type? (Not sure if that's easily possible.)

[astrandb]

Things are never simple...
Perhaps we could define the STATE_PROGRAM_ID as suggested below and make the convert lambda do the lookup based on appliance type.

DISH_WASHER_PROGRAM_ID = {
  1: "program_1",
  2: "program_2",
}
WASHING_MACHINE_PROGRAM_ID = {
  1: "wash_1",
  2: "wash_2",
}

STATE_PROGRAM_ID = {
  "dish_washers": DISH_WASHER_PROGRAM_ID,
  "washing_machines": WASHING_MACHINE_PROGRAM_ID,
}

[mundschenk-at]

I think it will need to be even more complicated, because a WASHER_DRYER supports both washing machine and tumble dryer programs. We might also need more than a lambda for some sensor's convert (e.g. targetTemperature needs to take -32768 into account as an invalid/unknown value).

[mundschenk-at]

Side note: I'd rename that sensor to Program instead of Program Id, since we ware not really providing the numerical ID (if we can). We should have the raw ID as an extra state attribute, though (I don't think it warrants its own diagnostic sensor).

[astrandb]

The structure above can be extended. It is static data so the code should be managable once it is in place.

STATE_PROGRAM_ID = {
  "dish_washers": DISH_WASHER_PROGRAM_ID,
  "washing_machines": WASHING_MACHINE_PROGRAM_ID,
  "washer_dryer_machines: WASHER_DRYER_PROGRAM_ID,
  "oven": OVEN_PROGRAM_ID,
  # And so on...
}

Regarding -32768 and none: My plan is to not create the sensors for these items. As a interpret the docs these values indicate that the item is not present. If the API suddenly starts to report valid values, the sensors will appear after next restart of HA. It is possible to discover them dynamically also, but that is an exercise for a really rainy day.

Program ID -> Program is OK with me
extra_attributes are on my todo list

[mundschenk-at]

Regarding the Programs, the problem is that the washer dryer supports three modes: washing, drying, and combined washing & drying. The available programs are different for each mode and I suspect at the least the first two modes use the IDs for washing machines and tumble dryers respectively (not sure about the combined mode, I suspect its a mixture, but I'll check some programs and write down what the API reports - could we maybe implement the logging feature soon? I can try to whip something up, but you probably know better where to put it. I'd suggest enabling it for debug log level?

As for targetTemperature, the thing is, the API does report values when a program is running, just not when the machine is off.

[mundschenk-at]

[mundschenk-at]

(Not sure why it didn't update the temperature between ~17:22 01.02. and ~8:46 02.02. - the machine was definitely off during that time. It wasn't a network dropout either, because the status and program phases where updated correctly.)

[astrandb]

As you know @mundschenk-at ,I only have access to fridge and freezer. I therefore jumped into conclusions on use of target temperature.
After some reading and thinking my interpretation is (now):

• On freezers and fridges the target temperature is used as a thermostat and best representet in HA as a climate entity.
• On ovens the target_temperarture is a displayed value only. Can sometimes be set via the program data model.
• On washers (dryers? & dishwashers?) it is displayed (when device is running?) though it is not documented. Cannot be set directly as an action, but perhaps in the program data model.

[mundschenk-at]

Sounds good. I think the target temperature is only shown for washing machines/washer-dryers, not for pure tumble-dryer programs. I'm not entirely sure about dishwashers, except for some special programs there is no explicit temperature associated with them, so I assume there is not really a target temperature either, but I don't have the latest generation so things might be different for newer models.

The temperature can probably not be set via the API, unless Miele adds new functions to select programs remotely. If so, the interaction model lacks a lot of the necessary concepts at the moment, so I kinda doubt that this is coming. You set the temperature during program selection. For washing machines, it kind of is an important thing - for example, you would not want to wash your silk pyjamas with 60 °C. (Even for manual selection, the available temperatures are largely limited by the overall program.)

[mundschenk-at]

I've put the available sources together and made table of available programs by machine type (the openHAB integration, the ioBroker integration, and the Miele API examples):

The actual table is much longer. Some entries might not be totally consistent (e.g. openHAB has the Automatic program on ID 32, but my dishwasher emits 31 for Automatic), but things mostly check out for my devices. The good news is that even in drying mode, my washer-dryer uses the washing machine program IDs, so it looks like alternating on device type will be OK. I'll try to come up with a PR tomorrow.

[mundschenk-at]

I have created PR #43 for this.