Washer: Missing translations / Texts for Cycle selection

[elninio2000]

Appliance model

DA_WM_TP1_21_COMMON

What's missing or wrong

The dropdown for choosing the cycles contains some technical keys without a translation of what they are used for.

For my washer, following entries had only the technical name:

08 -> only rinse and spin
74 -> drum clean
06 _> xxl laundry
A0 -> quick wash 15"

And furthermore i can select the "download" cycle but there is no way to select which program to download. The smart things app allows me here to download special programs liks sports or jeans.

In case there is a possibility to offer the download programs i can provide a full list of all programs including the temperature, rinse count and spin level.

Diagnostics file

No response

[mbillow]

Thank you for the cycle names, I’ll get these added. Can you please try running one of the download options? Then provide a diagnostic dump (wait at least 30s after starting the cycle) here? I’d love to figure out how the download feature works.

[elninio2000]

Hi Marc,

thank you for your response and for adding the translations.

I attached two dumps, the (1) is jeans download program and (2) is sports download program

[elninio2000]

config_entry-localthings-01KZGQYRCQQKMRNTYW4ZFAHY9V (2).json
config_entry-localthings-01KZGQYRCQQKMRNTYW4ZFAHY9V (1).json

[mbillow]

Thanks for the two dumps — diffed them and found something useful.

What differs between the Jeans and Sports dumps

Every field in /course/vs/0's x.com.samsung.da.options is identical between the two except:

AvailableDelayTime_33  (sports)  vs  AvailableDelayTime_74  (jeans)
OneTimeCloudCourse_0021550449284D134AA04C0035F004F005F0AC00  (sports)
OneTimeCloudCourse_001F6B0449284D134AA04C0035F004F005F0AC00  (jeans)

Byte-aligning the two OneTimeCloudCourse hex blobs (20 bytes each), only bytes 1–2 differ:

sports: 00 21 55 | 04 49 28 4D 13 4A A0 4C 00 35 F0 04 F0 05 F0 AC 00
jeans:  00 1F 6B | 04 49 28 4D 13 4A A0 4C 00 35 F0 04 F0 05 F0 AC 00

That looks like a 2-byte cloud-assigned program ID (Sports = 2155, Jeans = 1F6B), not locally-decodable wash parameters — /washer/vs/0 reports the same temp/spin/rinse (30°/800/3) in both dumps, so the actual per-program settings aren't visible anywhere else in the OCF surface.

Also: CloudCourse_0021550449284D134AA04C0035F004F005F0AC00 is unchanged in both dumps and matches the sports OneTimeCloudCourse exactly. So CloudCourse looks like the persisted/"saved" downloaded course (sports, downloaded earlier), while OneTimeCloudCourse is whichever program is selected for that one run (jeans, without overwriting the saved default).

This is the same shape as the MostUsed_* situation already noted in washer.py — a per-course byte that changes but doesn't decode to anything confirmed locally. Without the cloud, there's no way to know which IDs exist for your model or map an ID to a name generically, so before writing any code I'd like to test whether this field is even locally writable/effective.

Could you try a write test?

With the washer idle and "Download" already selected as the course (Course_87) — please don't press Start until after checking the result:

1. Swap the value. In HA, Developer Tools → Actions, call localthings.write_resource:

action: localthings.write_resource
data:
  device_id: <the washer's device_id>
  writes:
    - href: /course/vs/0
      payload:
        x.com.samsung.da.options: ["OneTimeCloudCourse_001F6B0449284D134AA04C0035F004F005F0AC00"]
  verify_after: 5

(use the Sports value for the reverse direction). verify_after re-reads the resource 5s later so the response tells you whether the write held or got reverted by the board.

2. Check for effect, two ways:

• App/panel: open the SmartThings app (or the washer's own display) and see whether the program name/settings shown now says the other program.
• Purely in HA: the two original dumps already differ in remainingTime (Sports = 00:33:00, Jeans = 01:14:00) and AvailableDelayTime (33 vs 74) — each program's own estimated duration. After the write, call localthings.read_resource on /operational/state/vs/0 and /course/vs/0 (or just watch the remaining-time sensor if you have one) and see if those values flip to match whichever program's token was just written.

3. Let us know what happened — held & reflected everywhere, held but ignored by the machine, or reverted outright are all useful outcomes. If it works, that's good evidence the first two bytes are a swappable program ID, and with a couple more confirmed ID/name pairs we could look at real "download program" support. If it's ignored or reverted, that tells us this needs a cloud round-trip and isn't a good fit for local-only control.

Thanks again for digging into this — the cycle name list you offered earlier would also help a lot for the other part of this issue (the missing course translations).

---

Generated by Claude Code

[mbillow]

The four cycle-name translations you listed are up in #344 (06/08/a0 were genuinely missing; 74 turned out to already be translated). Leaving this issue open for the download-course part — still want to try the write test from my comment above before building anything on the OneTimeCloudCourse/CloudCourse fields.

---

Generated by Claude Code

[elninio2000]

Thank you, that worked fine!

In case I execute your localthings.write_resource the maschine switched into jeans mode and the timer and onetimecloudcourse had expected values. This only works, if I already selected "download" first. If something else was selected, the api seemed to accept the write_resource (no error), but the maschine doesn't switch automatically to download.

I'd recommend to always select the download mode automatically in your api (than, the behavior would match the smartthings app, which switches automatically). But however, it's your decision of course.

I can provide a list of onetimecloudcourse id's for all download modes, my maschine has. I'll responde here once the list is finished.