Marc Billow
d53459d047
The TP2X_WATERPURIFIER_20K water purifier reports no oneUiVersion and its modelNum/description don't match any consumer-prefix or existing board-family token, so it fell into the unknown-device-type fallback with only common capabilities. Add a new water_purifier registry, routed via a 'WATERPURIFIER' modelNum/description fallback rule. Models dispense settings (type/temperature/capacity/pouring status), sterilize and filter status, favorite-capacity presets, and the three water/buzzer locks. Per the adding-device-support skill's "never hard-code the one dump's values" rule: dispense-capacity bounds and step come live from the device's own desiredCapacityRange/ capacityResolution fields (range_field/step_fn), not a hardcoded constant, and the hot-water-temperature control is a select over the live supportedHotTemperatures list rather than a number with invented bounds, since only a few discrete temperatures are selectable. /mode/vs/0 and /automation/waterpurifier/vs/0 are left unmodeled: the former carries an opaque wizard-workflow token with no coherent current-value contract, the latter is a static support-flags blob with no live setting to expose. Confirmed against the issue #90 diagnostics dump with zero unbound hrefs. Updates the README's supported-appliance-types table for the new device type.
28 lines
576 B
JSON
28 lines
576 B
JSON
{
|
|
"state_keys": [
|
|
"alarm_code",
|
|
"buzz_lock",
|
|
"coldwater_lock",
|
|
"dispense_capacity",
|
|
"dispense_type",
|
|
"favorite_capacity",
|
|
"favorite_capacity_enabled",
|
|
"filter_clean_remain_time",
|
|
"filter_door_status",
|
|
"filter_status",
|
|
"filter_usage",
|
|
"firmware_update",
|
|
"hot_water_temperature",
|
|
"hotwater_lock",
|
|
"pouring",
|
|
"selfcheck_error",
|
|
"selfcheck_result",
|
|
"selfcheck_status",
|
|
"sterilize_last_time",
|
|
"sterilize_period",
|
|
"sterilize_plan_time",
|
|
"sterilize_run_time",
|
|
"waterpurifier_status"
|
|
]
|
|
}
|