kkqq9320
412fff9b99
/airlevelcheck/vs/0 has been covered as "periodic air-quality sensing scheduler plumbing" since the registry gained a coverage stub for it. Two AVT-WW-TP1-23-AXX500 dumps (issues #84 and #190) show it is not plumbing: it drives the feature the SmartThings app calls AI Purify, where the unit wakes on a timer, samples the air, and optionally acts on the result. Every field is named, none are opaque, and two of them are already user-set on the reported units. The select's three on-states are the app's own options rather than an invented grouping -- it offers exactly "Sensing only" (sample, take no action), "Auto clean" (purify while the air reads bad, stop once it improves) and "Get notified" (raise a SmartThings notification). Labels were transcribed from the Korean app and rendered in English; the auto-stop half of "Auto clean" is the app's own description and is not otherwise visible in the dump, which reports only the selected autoExeState. The remaining entity names follow their raw fields rather than inventing a concept -- the skip window is "sensing skip", after periodicSensingSkipStatus/Time. Three of this registry's four board families report the resource with the same field names -- TP1X_DA-AC-AIR (#130), A-VTWW-TP2 (#151) and AVT-WW-TP1 (#84, #190). Only ARTIK051_TVTL (#56) has no such href, and its golden is unchanged. Bound unconditionally rather than behind a match_fn; the one field that genuinely varies (periodicSensingInterval, absent on the #130 board) is gated per-entity, so that board gets eight entities instead of nine rather than a broken one. range_hood.AIR_LEVEL_CHECK already models this same href, and its read-only keys are reused verbatim here so both families share one catalog entry. It is deliberately not imported: the hood exposes periodic_air_sensing as a read-only BinarySensorDesc and this board needs a writable SwitchDesc on that key, so reusing the hood's capability would migrate every hood user's entity to a different platform. Every write was exercised on AVT-WW-TP1-23-AXX500 hardware. This board hands out 2.04 for writes it silently discards (see HEPA_FILTER's filter-reset note), so an echo proves nothing -- each was judged by whether the value survived a reconnect, which forces a new DTLS session, fresh discovery and a fresh observe of the href, leaving no cached state to read back: * sensing_mode's combined two-field PUT lands both fields, both ways: sensing_only -> auto_purify raises autoExeState with activation still On, and back again lowers it. * The sensing-skip switch holds Off -> On and back. * The half-preserving time writes hold: from 13:00-23:00, writing start=07:30 then end=22:00 left the device on '07302200' -- each write kept the half it wasn't given. * periodic_air_sensing and sensing_interval: writing 60 s drove an observed ~60 s sensing cycle. * The read side of the skip window is separately cross-confirmed on two units: #84's sits at the inert '00000000', #190's carries a real '03002300' (03:00-23:00), which is what pins the HHMMHHMM split. * The other two families get the writes on field-shape grounds -- the same basis on which they already share MODE, HEPA_FILTER and the air-quality sensors. range_hood._timestamp moves to common.epoch_to_utc so both callers share it, matching how filter_usage_percent was shared. No behaviour change. Every existing entity is untouched: the three golden updates are purely additive, no renames, no unit or device_class changes.
27 lines
526 B
JSON
27 lines
526 B
JSON
{
|
|
"state_keys": [
|
|
"air_sensing_state",
|
|
"alarm_code",
|
|
"clean_level",
|
|
"device_active",
|
|
"dust",
|
|
"energy_kwh",
|
|
"fine_dust",
|
|
"firmware_update",
|
|
"hepa_filter_status",
|
|
"hepa_filter_usage",
|
|
"last_air_sensing_level",
|
|
"last_air_sensing_time",
|
|
"odor",
|
|
"periodic_air_sensing",
|
|
"periodic_sensing_skip_status",
|
|
"power_switch",
|
|
"sensing_interval",
|
|
"sensing_mode",
|
|
"sensing_skip_end",
|
|
"sensing_skip_start",
|
|
"super_fine_dust",
|
|
"wind_strength_fan"
|
|
]
|
|
}
|