Add support for LG dehumidifier DHUM_056905_WW#64
Conversation
MQTT discovery and TLV control for the 056905 clip platform (0xA7/0x87). Supported features: - Power and operating modes: smart, jet, silent, spot, laundry - Current and target humidity (30–70%) - Fan speed (low/high) via select - Ionizer, UVnano, and bucket light switches (not available on official integration) - Off timer: off or 1–8 minutes Includes capability-packet handling, unit tests from panel captures, and bridge registration.
anszom
left a comment
anszom
left a comment
There was a problem hiding this comment.
Thanks for the PR! See a couple of comments below
| }, | ||
| write_callback: (val) => { | ||
| if (val !== 2 && val !== 6) return false | ||
| this.sendFanSpeedTlvs(val) |
There was a problem hiding this comment.
I think this could be handled by the write_attach option.
There was a problem hiding this comment.
write_attach supports one TLV per tag; fan speed needs repeated 0x2d7/0x2d8/0x2d9 per mode. Was tricky to get this to work. Could add a new primitive to FieldDefinition in tlv_device.ts for this use-case, but tried to avoid any interface changes.
There was a problem hiding this comment.
Ok, I think I get it now, some 'T' values need to be sent out multiple times to achieve the desired result...
| /** Entering these modes resets fan speed to low (high remains user-selectable). */ | ||
| const SILENT_MODES = new Set([2, 19]) | ||
|
|
||
| const HA_MODES = ['Smart', 'Jet', 'Silent', 'Spot', 'Laundry'] as const |
There was a problem hiding this comment.
Consider to (partial) match HA modes:
https://developers.home-assistant.io/docs/core/entity/humidifier/#modes
e.g.:
Smart -> Auto
Jet -> Boost
Silent -> Sleep / Eco
There was a problem hiding this comment.
Better if options in HASS match options on device control? Generic names can make for confusing UI.
| const tlvs = [{ t: 0x1fa, v: fan }, ...modes.flatMap(([m, f]) => modeFan(m, f))] | ||
| for (const { t, v } of tlvs) this.raw_clip_state[t] = v | ||
| return tlvs | ||
| } |
There was a problem hiding this comment.
It is quite difficult to understand what is happening here.
From what I can decipher, it's something like
modeFan(17, fan),
modeFan(18, fan),
modeFan(20, fan),
modeFan(21, 6), // always 6 - why?
modeFan(22, fan)
since it's quite obvious that 2d7 2d8 and 2d9 don't represent any gobally understood state, does it make sense to store them in raw_clip_state ?
Please rewrite this function so that the meaning would be evident. Also, since this feature is one of more complex parts of this implementation, please add an unit test to cover this.
3 participants
MQTT discovery and TLV control for the 056905 clip platform (0xA7/0x87).
Supported features:
Includes capability-packet handling, unit tests from panel captures, and bridge registration.
Note: I can only be certain of compatibility with this exact model of dehumidifier: MD19GQGE0 (other models in this family have slightly different capabilities and controls exposed).