rename: climate entity to Remote Pre-Conditioning

[scottaki]

Rename the climate entity to "Remote Pre-Conditioning"

Summary

The climate entity is a remote pre-conditioning controller — it only
reflects remote pre-heat/pre-cool cycles. Its old display name "Climate"
implied it showed the live cabin HVAC state, which it cannot: a car driven
with the heater running shows off, because the Geely cloud simply does not
report manual in-cabin HVAC operation.

This PR renames the entity's display name to Remote Pre-Conditioning and
documents the scope in the module docstring and README.

Why

hvac_mode turns ON solely from preClimateActive / defrost
(custom_components/geely_connect/climate.py). Both fields are set by the
Geely cloud only while a remote pre-climate cycle is running — the flag
goes false the moment the cycle ends or the car starts. Manual in-cabin
HVAC (driver presses heat/AC while driving) is not reported anywhere in the
API payload; the phone app has the same blind spot (its AC indicator reads
the same preClimateActive field).

Verified live on an APAC-market Geely EX5 (2026-08): during a 10-minute
drive with the cabin heater clearly running (interior temp 12.3 → 18.1 °C),
the climate entity stayed off at every poll because preClimateActive
remained false. Remote pre-warm fired from HA correctly showed heat_cool
until the cycle ended. The complete climateStatus payload contains no
field for manual HVAC state.

Changes

• custom_components/geely_connect/climate.py
  • _attr_name: "Climate" → "Remote Pre-Conditioning"
  • Module docstring: added a "Scope" note explaining the entity reflects
    remote pre-conditioning only and why
• README.md
  • Features table row for Climate clarified:
    "Remote pre-heat/pre-cool: on/off, set temperature (15.5–28.5 °C),
    Rapid Warming, Rapid Cooling. Only reflects remote pre-climate cycles —
    the cloud does not report manual cabin HVAC"

Non-breaking

Display name only. _attr_unique_id and the resulting entity_id
(climate.my_geely_ex5_climate) are unchanged, so existing installations
keep their entity, dashboards, and any entity-registry customizations
(which override this default name anyway).

Test plan

• After reload, the climate entity's friendly name reads
  "Geely EX5 (… ) Remote Pre-Conditioning" (device name + entity name)
• Existing installs with a custom registry name are unaffected
• Remote pre-warm still shows heat_cool while a cycle runs, off at
  all other times

Note for maintainers

"Remote Pre-Conditioning" is the tested choice from an affected user; if a
shorter label is preferred, "Remote Climate" also reads accurately. The
important part is dropping the implication of live cabin state.

[YossiKon]

Thank you @scottaki — this is a model PR: a real-world observation, a verified root cause, a minimal diff, and an honest test plan. Merged. 🎉

I reviewed it in depth before merging, and everything you claimed checked out:

• The factual claim is accurate. On main, hvac_mode derives solely from preClimateActive / defrost (plus the short optimistic window after a command), and the module's own docs already record that airBlowerActive can't be used. The entity structurally cannot reflect manual cabin HVAC, so the old name really was over-promising. Your 10-minute drive experiment matches the code exactly.
• Existing installs are safe, as you said: unique_id is untouched, the registry keeps climate.<device>_climate, and registry name overrides win anyway.
• Naming style fits — every entity in this repo uses _attr_has_entity_name with Title-Case names, so "Remote Pre-Conditioning" slots right in (it's now the longest name in the fleet, which feels appropriate for what it does 🙂).

One subtlety the review surfaced that your test plan couldn't have seen without a fresh install: with has_entity_name, HA generates the object_id of a newly registered entity from the entity name — so brand-new installs would get climate.<device>_remote_pre_conditioning, while the ~30 references shipped in this repo's dashboards, cards and automations (and the README's "replace my_geely_ex5" adaptation procedure) all assume the _climate suffix. Old installs keep the old id, new installs get a new one, and no single version of the shipped YAML can match both.

Rather than send it back to you for that — the rename itself is exactly right — I merged as-is and completed it in a follow-up commit (f03eeb5) that pins the suggested object_id so new installs also get climate.<device>_climate, and updates the shipped dashboard tiles that still labeled the entity "Climate" so your rename actually reaches users of the stock dashboards.

Thanks again for taking the time to verify this against a real car and for writing it up so carefully — reports like this are exactly what makes the entity model trustworthy.

(This review was performed with the help of Claude Code.)