Add ThinQ2 device handler for CST_570004_WW (LG ceiling-cassette AC)

[3735943886]

Summary

Adds MQTT translation for CST_570004_WW, an LG ceiling-cassette indoor unit
(deviceType 401), typically installed as several IDUs on one multi-split ODU.
Previously these only worked in bridge mode.

It speaks the same DualCool AC TLV protocol as RAC_056905_WW, so per the
preferred direction in #73 this extends RAC rather than duplicating it, and
drives features from the device's real capability frame wherever possible —
not hardcoded per-model tables. It does not modify tlv_device.ts, and
CST_570004_WW is a new modelId, so no existing device is affected.

Why a plain CST_570004_WW: RAC_056905_WW alias doesn't work

I tried the alias first (as suggested in #73). It fails because CST diverges from
RAC in ways proven by the capability dump below:

1. 0xA7 framing — CST sends its async/query TLV frames with UART header
   byte6 = 0xA7 instead of 0x87, so tlv_device drops every frame. Handled in
   CST's own processData (same approach as POT_056905_WW), not in the shared base.
2. Feature bitmap moved — CST omits RAC's 0x2CC entirely.
3. Mode table differs — CST's auto is wire value 3, not RAC's 6; RAC
   decodes wire 3 as undefined (blank mode) and writes auto as the unsupported 6.
4. Filter data lives elsewhere — RAC reads filter usage from a basic-filter priv-command
   that returns an unpopulated counter on CST (used=0, life=720); the real usage is in value
   tags 0x356 (rated life 2400 h) / 0x355 (remaining).
5. Fan scale differs, and RAC would expose a bogus jet switch + a heat mode this
   cooling-only unit doesn't have.

Capability-driven decoding (read, don't hardcode)

Rather than synthesize, the handler reads what CST actually advertises. Aligned caps
dump (RAC's test frame vs a live CST frame):

tag	RAC	CST	meaning
0x2C1	0x57 = {0,1,2,4,6}	0x0F = {0,1,2,3}	supported modes (bit N = wire mode N): CST = cool/dry/fan_only/auto, auto=3
0x2C2	0x17C = {2,3,4,5,6,8}	0x1D5 = {0,2,4,6,7,8}	supported fan speeds (bit N = wire speed N)
0x2CB	—	0x1006 = {1,2,12}	feature bitmap (CST's relocated 0x2CC): bit1 energy-save, bit2 auto-dry
0x2CC	0x6	—	RAC's feature bitmap; absent on CST
0x2CD	0xF	0x1FE037	RAC reads jet/swing here; on CST this holds unrelated data (13 bits set)
0x2D3	0x7	0x401011	timers — bit0 sleep + bit4 start/stop read correctly, no change
0x2E1/0x2E2	—	32 / 60	temp range 16–30 °C (raw/2)

Concretely:

• Energy saving is read from 0x2CB (mapped into RAC's 0x2CC slot, masking bit2
  since CST exposes auto-dry as a duration select), replacing an earlier presence heuristic.
• Temperature range is read from 0x2E1/0x2E2, fulfilling RAC's existing
  TODO: some devices report these temp ranges via tags 0x2e1 - 0x2ec, falling back
  to RAC's 18–30 when absent.
• HVAC modes use CST's wire table (auto=3), confirmed by both 0x2C1 bit3 and a
  live 0x1F9=3 capture.
• Filter usage is read from value tags 0x356 (rated life 2400 h) / 0x355 (remaining),
  exposed as a remaining-% and a used-time (h) sensor. RAC's basic-filter priv-command counter
  is unpopulated on CST (used=0, life=720), and this model's app exposes no filter reset or
  last-reset date, so RAC's priv-command filter entities (including the reset button) are dropped.
• Jet is suppressed and swing is taken from the real on/off value tags 0x205/0x206,
  because CST's 0x2CD is not RAC's jet/swing bitmap. This one genuinely can't be read
  cleanly — documented rather than guessed.

Extra entities CST exposes

Humidity (0x336, raw/10 = %RH), always-on Power (0x2B3), auto-dry duration select
(0x20E) + remaining sensor (0x225, minutes), display brightness (0x21F), comfort
energy saving (0x23F), and a wind-mode / comfort-airflow select
(0x290/0x291/0x3D6/0x3D7, mutually exclusive one-hot flags).

Testing

• tests/cloud/devices/CST_570004_WW.test.ts drives real captured packets
  (caps / values / filter reply) through the handler and asserts: 0xA7 normalization,
  caps-derived temp range and energy-save, auto wire value 3 (read + write), jet/heat
  suppression, CST fan scale, and the extra components. npm run test → 302/302;
  prettier --check and npm run build clean.
• Physical verification on 4 live IDUs (LG multi-split): per-unit humidity matches the
  app; filter remaining/used match the app across all 4 units (2400 h rated); auto mode set
  from HA actually engages auto on the unit; power reads 0 W idle and rises while cooling.

Known limitations (not guessed)

• 0x2C2's fan bitmap is understood but has an unresolved off-by-one at CST's lowest speed,
  so the fan list is the hand-verified {1,2,4,6,7,8} rather than auto-derived.
• Energy in kWh is cloud-computed (reads 0 locally); derive in HA via a Riemann integral of
  the Power (W) sensor.

🤖 Generated with Claude Code

[anszom]

Thanks for the PR.

The decision to base this implementation from RAC sounds good, but I think a better course of action would be to split out an AC_common base class - instead of translating the packets to match RAC's expectations. This way the common logic could stay the same, but the differences would be more clear. Can you do that?

This change could also be useful for #89

[3735943886]

The decision to base this implementation from RAC sounds good, but I think a better course of action would be to split out an AC_common base class - instead of translating the packets to match RAC's expectations. This way the common logic could stay the same, but the differences would be more clear. Can you do that?

Sounds good, I'll do that.

[3735943886]

Closing this — I'll open a new PR refactored onto a shared ac_common base class.

[anszom]

Note that you don't need to close & open a new PR. Each push (or force-push) to a branch updates an existing PR. You can reopen this one when you're ready as well.

Also, I recommend rebasing to follow the base branch instead of merging, this makes the commit history cleaner