Files

T

perseus177 9ee0329467 feat(airconditioner): reset the legacy filter counter locally

FilterCleanAlarm_Clear, through the same single-token options merge as every
other setting on /mode/vs/0. Measured on an ARTIK051_KRAC_18K: 2.04 Changed and
FilterTime_95 (9 h 30 min) -> FilterTime_0, still zero on a fresh DTLS session
and on every poll after; none of the other 17 tokens moved and the alarm
entries stayed Deleted.

The counter has had no reset until now, and the descriptor said so: two earlier
rounds against live hardware failed, and the conclusion drawn from them was
that the reset had to be cloud-only. That conclusion was wrong, and the way it
was reached is the interesting part -- it came from diffing every resource the
appliance reports before and after pressing reset in Samsung's app, which
showed only the counter zeroing and the alarm clearing. A trigger token cannot
show up in such a diff, because a trigger is never stored. The appliance's own
app sends this token and skips the write when the counter is already zero.

Both failures stay in the comment, because they say what this is not: writing
FilterTime_0 (the value is not writable -- 5595 -> 5595 after 69 s, 1925 ->
1925 after 65 s, two units, opposite power states), and POSTing the cloud
capability's command name to /actions/vs/0 (real name, wrong transport).

Gated on the FilterTime_ token, so it appears only where there is a counter to
reset; newer boards report filter usage through their own resource and would
need a different mechanism.

2026-08-05 01:46:29 +00:00

5.2 KiB

Raw Blame History

AC filter-time counter reset: solved

registry/capabilities/airconditioner.py's filter_time sensor (FilterTime_<N> option token, tenths of an hour) has a reset entity now (filter_time_reset, issue-tracked as PR #289): a single-token options write of FilterCleanAlarm_Clear to /mode/vs/0, the same merge every other setting on that href uses. Measured on an ARTIK051_KRAC_18K: FilterTime_95 (9h30m) → FilterTime_0, still zero on a fresh DTLS session and every poll after; none of the other 17 tokens moved and the /alarms/vs/0 entries stayed Deleted.

The rest of this file is kept as-is: the failed attempts below are still the best record of what doesn't work on this generation, and the reasoning that follows them explains why the reset looked cloud-only for as long as it did — a genuine trap worth knowing about before the next reset-adjacent mystery on this board family.

What the reset actually is

A command, not a value write. Samsung's cloud models it as capability custom.dustFilter, command resetDustFilter, no arguments (implemented in several SmartThings HA forks; not in the core integration) — that command name is real, but see below for why POSTing it directly went nowhere.

Tried, all against a live unit, all failed (before the token above was found)

FilterTime_0 via the single-token options merge that works for every other setting on this href — accepted with no error, then discarded. Tried on two units in opposite power states to rule out the obvious confound: 5595 → back to 5595 after 69s (powered off, alarm active), 1925 → back to 1925 after 65s (actively cooling).
A full options[] read-modify-write with FilterTime_0 substituted, instead of the single-token merge — zero fields changed anywhere.
A write to /consumable/vs/0, the board's own filter resource (items[{name: FilterProgress, state: N}]) — discarded. /oic/res declares that resource oic.if.s (read-only), which fits.
/actions/vs/0 (x.com.samsung.da.actions, oic.if.a) is the obvious local command channel but publishes no schema: GET returns {} on baseline and on oic.if.a, and five POSTs probing the shape (empty map, empty string, empty array, invalid value, items shape) all returned 4.00 with an empty body — no echo of accepted field names, unlike the laundry firmware's "Control fail, <...>". Guessed action names were deliberately not enumerated against a live appliance: an unknown vocabulary on a channel called "actions" can hold a factory reset next to the one we want.
/hass/state/vs/0 and /hass/command/vs/0 (advertised in /oic/res, and /opt/data/hass.db exists in /file/list) → 4.04 on every interface, so unimplemented scaffolding on this firmware.
/file/transfer/vs/0 serves only /mnt/usage.db; selecting another path returns 4.05/4.00, so the firmware can't be pulled that way to read the action vocabulary out of it.
/rm/micomdata/vs/0 (channel toward the MICOM board the physical panel talks to) stays empty even after successfully enabling remote management.

What the failures are not

Not a transport, permission, or cert problem: a control write of rmState on /rm/state/vs/0 was accepted (2.04 Changed, value held, restored afterwards), and FilterAlarmTime_ is written through the very same options merge and kept. Writes work; this one value just isn't driven that way.

The token, and why the dead ends below missed it

FilterCleanAlarm_Clear is not derived from anything in this file's earlier attempts — how it was originally identified isn't recorded here. What is recorded is why the standard technique (diff the appliance's reported state before/after triggering the action in Samsung's app) couldn't have found it on its own: the token is a trigger, never stored and never echoed back in x.com.samsung.da.options, so a before/after diff of stored state shows only the effects (counter zeroing, alarm clearing) and never the token that caused them.

Dead ends tried before the token was known (kept for the next unrelated mystery)

The /actions/vs/0 action vocabulary from an independent source (a firmware image, or a capture of what the cloud sends the device).
The IR path — the physical remote has a filter reset (Options → Filter Reset → SET), and IRremoteESP8266 decodes this AC family, though issue #1277's dump doesn't include that button.

Evidence for the counter's direction and scale

Confirmed counting up (running time since last reset, not remaining time): token 1710 matched the Samsung app's "171 hours 0 minutes" for the same filter (pins the tenths-of-an-hour scale); seen rising while the unit ran (171.0 → 171.5); and across two units on one site the /alarms/vs/0 filter alarm tracks the counter in the right direction — live (FilterAlarm, Created) at FilterTime_5595, still the FilterAlarm_OFF/Deleted placeholder at FilterTime_1915, matching the app's own 500-hour threshold behavior. FilterAlarmTime_ in the same options blob is that threshold (500 on every unit on record).

The entity key stays filter_time rather than filter_time_elapsed: renaming it would change every existing unit's entity_id/unique_id for a wording improvement only.

5.2 KiB Raw Blame History