Skip to content

Add LG dehumidifiers DHUM_056905_WW and DHUM_231006_WW - #113

Open
tunarabuuu wants to merge 1 commit into
anszom:masterfrom
tunarabuuu:dev-dehumidifiers
Open

Add LG dehumidifiers DHUM_056905_WW and DHUM_231006_WW#113
tunarabuuu wants to merge 1 commit into
anszom:masterfrom
tunarabuuu:dev-dehumidifiers

Conversation

@tunarabuuu

Copy link
Copy Markdown
Contributor

First of the per-device-class splits from #111.

Two ThinQ2 dehumidifiers on the existing TLV path (deviceType 403), each verified against the LG cloud's own decode of the same unit while bridged:

  • DHUM_056905_WW — the base driver.
  • DHUM_231006_WW (BEKEN_BK7234) — shares the 056905 TLV map, overrides only the mode/fan enums (it uses codes 85/86 where 056905 uses 17/21) and sends fan writes as bare 0x1fa without the per-mode table.

Shared infrastructure this needs:

All labels are English. npm test passes; tsc clean.

Two ThinQ2 dehumidifiers on the existing TLV path (deviceType 403). 056905 is
the base; 231006 (BEKEN_BK7234) shares its TLV map and overrides only the mode
and fan enums, which were measured against the LG cloud's own decode of the
same unit while bridged.

TLVDevice's packet gate accepts 0xA7 in byte 6 alongside 0x87 — the
dehumidifier family frames with 0xA7 where RAC/WIN use 0x87. That change and
the HumidifierComponent discovery type both originate in BluSyn's anszom#64; this
builds on it and rebases on top if anszom#64 lands first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kkqq9320 pushed a commit to kkqq9320/rethink that referenced this pull request Aug 3, 2026
They went out as unitless raw bytes so an external power meter could settle whether any of them
tracks watts. A smart plug on the appliance's own outlet and 48 h of history settled it:

  @84  steps +5 every five-minute record and wraps at 256 - a minute counter, and it was the
       one that looked most analogue
  @87  is 0 or 59 and changes at the same instants as @86; that flag in another byte
  @89 @90  a few discrete values, moving with @86 and saying nothing beyond it

The premise went with the readings. There was never going to be an in-appliance number to
calibrate against - no tag here carries power - so the useful result of the experiment is that
the meter stays and the four proxies go. The compressor sensor is untouched: the plug validated
it, jumping to ~90 W in the same hour it goes ON and holding 100-110 W for as long as it runs.

Withdrawn, not deleted. Each key is still published carrying `platform` and nothing else, which
is what device discovery reads as "this entity is gone". Dropping the key instead only stops a
fresh install creating one and leaves the four already in a registry live forever - exactly how
the auto-dry platform change left two orphans behind on RAC_056905_WW earlier today. That
lesson came from reading upstream PR anszom#113, which documents it and gets it right.

A replay of dehum-capture-20260730.jsonl now publishes the compressor and none of the four.
@anszom

anszom commented Aug 22, 2026

Copy link
Copy Markdown
Owner

Can you rebase this to master? I've merged #64 first so there are some conflicts. Also, the comments mention Korean labels, but all labels are in English now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants