Marc Billow
a7dc1db8ff
PR #316 (fork stale by several months, most of its ~2200-line diff was drift against main rather than real changes) proposed device support for the Samsung System Fresh Air Ventilator (ACA-KR-TP2-21-AN9000). Extracted what holds up, adapted to this project's conventions, and left out what doesn't: Extracted: - ventilation_mode select on CLIMATE's own href, gated via _is_ventilation_mode_device so it can only ever bind on a device whose entire supportedModes set is Purification/Ventilation/SmartVentilation -- verified against every real AC fixture in the corpus to confirm it can't false-positive on an actual air conditioner's climate card. - WINDFREE / WINDSLEEP switches on their own dedicated hrefs. - A CO2 sensor on AIR_QUALITY, matching air_monitor.SENSORS' already-bound device_class='carbon_dioxide'/unit='ppm' descriptor for the same field shape rather than guessing fresh. - HEPA_FILTER / DEVICE_ACTIVE reuse from air_purifier.py. - Removing /airlevelcheck/vs/0 from _AC_IGNORED and binding air_purifier.AIR_LEVEL_CHECK in its place: the PR's claim that this project's old "scheduler plumbing" description was wrong turned out to be independently verifiable against two of our own existing fixtures (airconditioner_cac and airconditioner_tp1x_da_ac_rac_01011 both already carry real, populated periodicSensingActivationState/autoExeState values), so this benefits existing users, not just the one new device. Left out: - Unit/device_class ('ug/m3', pm10/pm25/pm1) on the existing dust/ fine_dust/super_fine_dust sensors, sourced from an unverified third-party screenshot description. air_monitor.py already has an explicit, reasoned rejection of this exact mapping for the exact same three fields: Samsung's PM10/PM2.5 convention doesn't confirm where a third tier or a PM1 reading fits, and a wrong guess mislabels the reading forever. - A standalone common.POWER switch -- contradicts this registry's own documented design (power is deliberately the climate entity's job) and would affect every AC user, not just this device. - Promoting wind/swing to independent selects for every AC user -- a UX opinion, not a coverage necessity, and out of scope for this device's own support. - A model-name diagnostic sensor -- /information/vs/0 is already covered via the global ignore list, so this wasn't closing an actual gap. No raw diagnostics dump for this model was ever attached to PR #316, so there's no fixture for it here (fabricating one would violate this project's fixture-integrity rule) -- see tests/test_airconditioner_ventilation_windfree.py's module docstring.
57 lines
1.3 KiB
JSON
57 lines
1.3 KiB
JSON
{
|
|
"state_keys": [
|
|
"absence_clean",
|
|
"absence_power_saving_active",
|
|
"absence_power_saving_mode",
|
|
"air_filter_pm1_status",
|
|
"air_filter_pm1_usage",
|
|
"air_filter_pm1_usage_hours",
|
|
"air_filter_status",
|
|
"air_filter_usage",
|
|
"air_filter_usage_hours",
|
|
"air_purify",
|
|
"air_sensing_state",
|
|
"alarm_code",
|
|
"auto_clean",
|
|
"auto_clean_progress",
|
|
"auto_clean_running",
|
|
"clean_level",
|
|
"climate",
|
|
"current_temperature_c",
|
|
"dust",
|
|
"edge_lighting",
|
|
"edge_lighting_color",
|
|
"edge_lighting_mode",
|
|
"energy_kwh",
|
|
"energy_saved_kwh",
|
|
"fine_dust",
|
|
"firmware_update",
|
|
"humidity",
|
|
"indicator_light",
|
|
"indicator_light_mode",
|
|
"last_air_sensing_level",
|
|
"last_air_sensing_time",
|
|
"motion_detect_wind_active",
|
|
"motion_detect_wind_mode",
|
|
"mute_once",
|
|
"odor_controller_active",
|
|
"odor_controller_progress",
|
|
"periodic_air_sensing",
|
|
"periodic_sensing_skip_status",
|
|
"power_watts",
|
|
"selfcheck_error",
|
|
"selfcheck_result",
|
|
"selfcheck_status",
|
|
"sensing_interval",
|
|
"sensing_mode",
|
|
"sensing_skip_end",
|
|
"sensing_skip_start",
|
|
"sound_mode",
|
|
"sound_output",
|
|
"sound_volume",
|
|
"super_fine_dust",
|
|
"tropical_night_mode",
|
|
"uv_led"
|
|
]
|
|
}
|