[codex] Add climate action and status telemetry

[joeblack2k]

Summary

This draft PR combines three small status/telemetry fixes for the ESPHome LG controller:

• Fixes Feature Request - Set "Action" Attribute #94 by publishing ESPHome/Home Assistant climate action from the live LG status frame.
• Fixes Error code reported as decimal rather than int #132 by configuring the raw LG error-code sensor with integer-style display precision.
• Adds optional passive AE.80/CE.80 telemetry sensors for humidity, fan operation time, indoor unit operation time, and precise room temperature.

This supersedes #171. It ports the climate-action work onto a clean branch from JanM321/main and also addresses the #171 review comment about the preheat flag.

Root Cause / Fix Log

#94 Climate action

The component previously restored and published HVAC mode, but did not advertise or update CLIMATE_SUPPORTS_ACTION, so Home Assistant could only show the configured mode instead of the live action.

This PR now:

• Adds CLIMATE_SUPPORTS_ACTION to the climate traits.
• Updates this->action for off, idle, cooling, drying, heating, fan, and defrosting.
• Uses the live mode plus outdoor-unit state.
• Treats preheat as idle for the indoor unit, which matters on multi-split systems where the outdoor unit can run for another indoor unit.
• Uses the heat/cool status temperature flags (0x40 cooling, 0x80 heating) when the mode is heat_cool.
• Keeps action in sync even while status changes/sends are pending, so HA does not lag behind the most recent bus status.

Mapping:

• mode == off -> off
• defrost bit set -> defrosting
• mode == fan_only -> fan
• outdoor unit off or preheat bit set -> idle
• cool + outdoor active -> cooling
• dry + outdoor active -> drying
• heat + outdoor active -> heating
• heat_cool + status flags -> cooling / heating, otherwise idle

#132 Error code formatting

The LG error byte was already published raw, but the sensor schema did not specify integer-style precision. This PR keeps publishing the same raw LG byte and adds accuracy_decimals: 0 without assigning a device class or state class that Home Assistant might misinterpret.

AE.80 / CE.80 telemetry

The protocol notes document additional type-6 subtype-0x80 telemetry frames. This PR passively parses those frames and exposes optional sensors:

• humidity: byte 2, %, humidity device class, measurement, 0 decimals.
• fan_operation_time: bytes 3-4, h, duration device class, total_increasing, 0 decimals.
• indoor_unit_operation_time: bytes 6-7, h, duration device class, total_increasing, 0 decimals.
• precise_room_temperature: bytes 10-11 as integer + one decimal digit, °C, temperature device class, measurement, 1 decimal.

Frames are ignored for Slave sender messages and accepted only when subtype byte 1 is 0x80. The precise room temperature is kept as a separate sensor and does not overwrite current_temperature.

Validation

Repository validation:

• git diff --check passed.
• uvx esphome config template.yaml passed using a temporary /tmp copy with a valid base64 API key substituted for the upstream placeholder my_key.
• uvx esphome compile template.yaml passed using the same temporary copy.

Live Bioscoop LG Airco validation:

• uvx esphome config bioscoop-lg-airco.yaml passed.
• Live config retained WiFi SSID Legacy, static IP 192.168.2.166, ESPHome API encryption, and passive/continuous BLE tracking with Bluetooth proxy inactive for Bermuda use.
• Live config compiled successfully from a temporary space-free /tmp build directory.
• OTA flash to 192.168.2.166 succeeded.
• ESPHome logs after OTA showed build 2026-06-01 07:29:03 +0200, WiFi connected to Legacy, BLE tracker running, API reconnect successful.
• Home Assistant climate state confirmed hvac_action is now present. During live cooling test before the preheat refinement HA reported hvac_action: cooling; after the final preheat-aware flash the current unit state was off with hvac_action: off.
• New AE.80 sensors were registered in Home Assistant with the expected metadata, but remained unknown during the short live log window because this unit did not emit a CE.80/AE.80 frame in that sample.
• ESPHome log showed Error Code >> 0 with the generated code setting error_code->set_accuracy_decimals(0). HA's backend state API still stores the value as a numeric string (0.0), which appears to be HA/ESPHome sensor state representation rather than a firmware precision issue.

Known Limitation

The AE.80/CE.80 sensors are passive. They only publish values when the LG bus actually emits a matching type-6 subtype-0x80 frame.