v0.4.4.3

0.4.4.3 - 2026-05-21

✨ Features

• New "Other (Advanced)" Device Type: A new generic bucket has been added to the Device Type dropdown for appliances that do not match any of the supported types (Washing Machine, Dryer, Washer-Dryer Combo, Dishwasher, Air Fryer, Bread Maker, Pump). Unlike the supported types, Other (Advanced) ships intentionally generic defaults that are not tuned for any specific appliance class: there is no curated phase catalog, no device-type-specific runtime branching, no per-class fallbacks for active-timeout, off-delay, DTW band ratio, or completion threshold. The contract is explicit: WashData provides the state machine, profile-matching pipeline, and entity layer; the user provides the tuning. This is the right pick for users who want to experiment with appliances WashData does not have first-class support for (instant pots, kettles, blenders, etc.) and accept that defaults will not work out of the box. It is also the runtime fallback when a hard-removed deprecated device type orphans an existing entry (see Deprecations below).

⚠️ Deprecations

• Four Device Types Deprecated: Electric Vehicle, Heat Pump, Coffee Machine, and Oven are now marked as deprecated and scheduled for removal in a future release (planned: 0.4.6). All four fail at least one of WashData's three appliance fit tests (user-selected discrete program, reproducible power signature, clean return to OFF), so profile matching and time-remaining estimation produce noise rather than signal: EV cycles vary by state-of-charge and load-management rather than a fixed program, heat pump cycles are weather/thermostat driven, coffee machines fragment into seconds-long user-driven bursts, and ovens hold an oscillating thermostat signature with no deterministic end. Refining defaults and phase catalogs for these classes is unlikely to recover meaningful matching quality. No behavior change for existing setups in this release: the integration continues to work for entries already configured with these types, all stored options and learned profiles are preserved, and the runtime state machine is unchanged. The new-entry device-type dropdown filters these out (so they cannot be picked for fresh installs), the options flow shows existing entries' current type with a (deprecated) suffix so it is still selectable until the user migrates, and the Settings options-flow step displays a yellow warning at the top of the form when the entry is on a deprecated type explaining the situation and listing both the supported alternatives (Washing Machine, Dryer, Washer-Dryer Combo, Dishwasher, Air Fryer, Bread Maker, Pump) and the new Other (Advanced) bucket as a generic landing that preserves all hand-tuned settings. The deprecation warning has been internationalized: a {deprecation_warning} placeholder was added to all locale translation files so the warning (injected by the options flow) appears at the top of the Settings form description for all users regardless of language. Once a user switches to any non-deprecated type the warning disappears and the suffix is dropped. After two release cycles, the deprecated constants will be removed from the dropdown entirely and any entry still on a removed type will fall back to Other (Advanced) at runtime (so the integration does not silently pretend the orphaned entry behaves like a washing machine), with stored options preserved exactly as the user set them.

🐛 Bug Fixes

• Advanced Settings Save Blocked by "Entity None is neither a valid entity ID nor a valid UUID" (#245): After upgrading to 0.4.4.2, submitting the Advanced Settings form (with or without the Apply Suggested Values checkbox) failed with three validation errors against external_triggers_section's external_end_trigger, door_sensor_entity, and switch_entity fields, and none of the changes were persisted. When the Advanced Settings form was reorganised into collapsible sections, these three EntitySelector fields were declared with default=None for unset entities; voluptuous renders the form with None filled in, and on submit the EntitySelector validator rejects None because it is neither a valid entity ID nor a UUID. Fix: switched all three fields to the description={"suggested_value": ...} pattern already used for energy_price_entity elsewhere in the options flow, so the field renders as empty when unset and the validator only sees real entity IDs on submit. Users on 0.4.4.2 who never configured an external end trigger, door sensor, or pause switch can now save Advanced Settings (including suggested-value applications) without clearing the form first.