Fix T0xE1 dishwasher programs falling back to ECO

[phntom]

T0xE1 dishwasher programs fall back to ECO

Summary

• Fix program selection for the default, 76006481, 7600649Q, and
  7600V1E7 T0xE1 profiles.
• Keep the existing Home Assistant select option keys and translations, while
  sending the codec-native mode values expected by the appliance.
• Limit this PR to one device-mapping file; it does not modify shared entity
  classes, cloud adaptation, command building, or services.

Root cause

The downloaded E1 Lua encoder accepts mode values such as auto, intensive,
normal, eco, glass, and rapid. The mappings instead sent values such as
auto_wash, strong_wash, and glass_wash. The encoder does not recognize
those values and silently falls back to ECO (0x04), so selecting most programs
starts an ECO cycle.

For example, the public select option remains glass_wash, preserving existing
translations and automations, but its payload changes from:

{"work_status":"work","mode":"glass_wash"}

to:

{"work_status":"work","mode":"glass"}

The same correction is applied to all affected explicit profiles. Options that
the codec cannot encode are removed instead of allowing them to start ECO.

Relationship to #226

Following the maintainer feedback, this PR has been split down to the minimal,
independent program-selection bugfix. It neither competes with nor depends on
the cloud-config auto-adaptation proposed in #226.

The native delayed-start/raw-command work previously included here has been
removed from this PR and preserved separately. I will coordinate that proposal
with @NOisi-x and the general design in #226 before asking for it to be merged.

Validation

• Hardware frame captures on WQP8-W7634C-W (sn8 7600020L) confirmed distinct
  mode bytes and correct durations for all 13 exposed programs: soak, rapid,
  1hour, 90min, glass, self-clean, auto, normal, hygiene, intensive, eco, fruit,
  and quiet.
• A focused Home Assistant mapping check verified all four profiles and
  confirmed every emitted mode is accepted by the downloaded E1 Lua encoder.
• Python compilation and git diff --check pass.

[sususweet]

@phntom Thanks for this PR – fixing the program selection and adding native delayed start for T0xE1 dishwashers is very valuable, and the hardware verification you've done is impressive! 🚀

Before we can merge this, I need to bring your attention to PR #226, which also targets T0xE1 devices with a broader auto‑adaptation approach. Both PRs modify overlapping parts of the codebase (especially T0xE1.py, select entities, and command building), so there's a risk of conflicts and duplication.

Could you please take a look at #226 and coordinate with @noisi‑x? Ideally, you two can discuss the best way to combine or reconcile your changes – perhaps merging the delayed‑start service from your PR into the auto‑adaptation framework, or aligning the program‑selection fixes with the cloud‑config logic in #226.

Once you've reached an agreement on a unified approach, feel free to update this PR or close it in favor of a combined solution. I'm happy to review and merge the final result.

Let me know if you need any help facilitating the discussion. Thanks again for your contribution! 🙏

[phntom]

Thanks, @sususweet. I reviewed #226 and applied a scope split to this PR:

• rebased onto the latest master and reduced it from 4 commits / 5 files to 1 commit / 1 mapping file;
• retained only the hardware-verified codec-mode bugfix;
• removed the delayed-start, raw-command service, countdown entities, and translation changes;
• kept all shared entity/platform code untouched.

Both HACS and hassfest pass on the rewritten PR.

@NOisi-x: the remaining fix is independent of cloud auto-adaptation—it only corrects invalid static payload values that the current Lua codec otherwise converts to ECO. I preserved the delayed-start work separately and will coordinate that proposal with the general design in #226 before asking for it to be merged.

[NOisi-x]

@phntom Sorry for the late reply, and thank you very much for your work. I would like to ask a favor. Are you logged in using an MSmartHome account? Could you please help confirm whether there is a consistent or similar API endpoint to getAppModelConfig under MSmartHome? Its function is to return the front-end rendering specifications for the APP according to the SN8 encoding. I would like to know if its return data is consistent with that of Meidimeiju. Thank you very much!

[phntom]

Yes, I use an MSmartHome account. I tested /cfhrs/common/v1/api with msg=getAppModelConfig for T0xE1 SN8 7600020L, using the authenticated MSmartHome regional and global API routes. Both returned HTTP 200 with an empty body, including when I added the standard MSmartHome general request fields. Therefore, the Meiju endpoint is not directly compatible. This does not rule out a different MSmartHome endpoint; I can compare results if you provide the expected Meiju response schema.

[NOisi-x]

@phntom Thank you for your efforts！

I also tested the Meiju (mp-prod.smartmidea.net) /cfhrs/common/v1/api endpoint with the same msg=getAppModelConfig payload against a working Meiju account. The endpoint correctly returns the expected structured response and authentication succeeds — however, the per-model config for 7600020L is an empty string. So I think this SN8 is only for MSmarthome.

I verified the api call with SN8 760Y0026, which returned a full ~7KB config containing 9 washing modes with per-mode conditions, step sequences, and capability flags — proving the endpoint and auth flow are correct. The followings are my findings.

SN8 7600020L (per-model config)

{"retCode":"0","desc":"success","result":{"config":""}}

SN8 DIFFTYPE (global diff config for 0xE1)

Returns a ~7KB response with 6 top-level keys, including a diffType section:

key	count	example SN8s
withoutLockOnStart	76	76006485, 760RX10P, 7600JV20, ...
keepOffOnPowerOff	4	000000X4, 000000Y1, ...
deviceUploadFaltDataOnPower	3	000000K2, 000000K1, ...
doorOff	1	00003906
diffBrand	16	7600001Z, 760Y0016, ...
devOffKeep	70+	0000D25A, 760P40T1, ...

Request Format

POST https://mp-prod.smartmidea.net/mas/v5/app/proxy?alias=/cfhrs/common/v1/api

Headers

content-type: application/json; charset=utf-8
secretVersion: 1
accesstoken: <Meiju access token from /mj/user/login>
random: <unix timestamp as string>
sign: HMAC-SHA256(iot_key + json_body + random, hmac_key)

Body

{
  "msg": "getAppModelConfig",
  "params": {
    "protype": "e1",
    "sn8": "<SN8>"
  },
  "reqId": "<hex16>",
  "stamp": "<YYYYMMDDHHmmss>"
}

Working Device Config Example: 760Y0026 (T0xE1 dishwasher)

For comparison, this is what a non-empty config looks like. SN8 760Y0026 returns a ~7KB
config with one top-level key version_0:

Response (outer envelope)

{
  "retCode": "0",
  "desc": "success",
  "result": {
    "config": "<escaped JSON string — see below for decoded contents>"
  }
}

Decoded config structure (inside result.config, after JSON.parse)

{
  "version_0": {
    "setting": {
      "keepTimeType": 0,
      "keepStartNow": 1,
      "keepSetTime": 1
    },
    "text": {
      "keep": {
        "name": "烘干储存",
        "desc": "可设置抑菌储存时间"
      }
    },
    "more": {
      "ota": 1,
      "strainer": 1,
      "waterEl": { "el": 1, "water": 1 },
      "salt": { "enable": 1 },
      "bright": { "enable": 1 },
      "lock": 1
    },
    "modeList": { ... }
  }
}

Response Schema (on success)

{
  "retCode": "0",
  "desc": "success",
  "result": {
    "config": "<JSON string or object>"
  }
}

Note: the config field may be a JSON string (needs JSON.parse / json.loads) or a nested object, depending on the device.

If you're willing to keep exploring this API under the MSmartHome account, I'd be very happy to compare notes if you dig up anything else!