Device stays Unavailable forever after Wi-Fi re-pairing — stale cached encryption key

[Dzhuneyt]

Summary

When the AC's Wi-Fi pairing is reset (holding MODE + WIFI on the unit to put it into re-pairing mode, then reconnecting it), the integration keeps encrypting requests with the stale cached key. The device silently drops those packets and the climate entity stays Unavailable indefinitely — until the user manually reloads the integration.

Reproduced on v3.6.0. Opening this before sending a patch to confirm you're open to the direction.

Symptoms

Repeats every ~60s for the affected device (other Gree ACs configured via the same integration are unaffected at the same time):

WARNING homeassistant.helpers.entity
    Update of climate.<name> is taking over 10 seconds
ERROR custom_components.gree.gree_protocol
    All 8 attempts failed for <ip>:7000. Error: TimeoutError
WARNING custom_components.gree.climate
    <name>: Failed to communicate with device <ip>:7000

Root cause

In climate.py async_update:

if not self._encryption_key:
    ...  # GetDeviceKey / GetDeviceKeyGCM
else:
    await self.SyncState()

GetDeviceKey / GetDeviceKeyGCM runs only when self._encryption_key is None — i.e. on first boot of the integration. Once a key is cached, it's never invalidated, regardless of how many consecutive SyncState calls time out.

Confirmed the device itself is healthy at the UDP and Gree-protocol layers after the re-pairing event:

• ping 0% loss, port 7000 reachable
• A fresh scan returns the device's MAC
• A fresh bind handshake succeeds and returns a new session key
• Separately: other healthy ACs on the same LAN rejected my external bind attempts (Gree allows one active controller), while the broken one accepted — consistent with its controller slot having been orphaned by the key rotation

Workaround: Settings → Devices & services → Gree → (affected device) → Reload. Fixes it in ~60s, no HA restart needed.

Proposed fix

Track consecutive update failures; after a threshold (default 3), clear the cached key so the existing async_update re-bind path auto-recovers. Preserve user-configured keys (the optional CONF_ENCRYPTION_KEY field) — silently overriding a user-supplied static key would be surprising.

~35 lines in climate.py, single-file change. Happy to open the PR if this direction works for you.

Possibly related issues

Not claiming these are the same root cause — only that the reported symptoms overlap and the mechanism (stale cached key surviving a device-side rotation) would plausibly surface from any trigger that re-associates the AC to Wi-Fi:

• AC becomes unavailable after power outage or a simple router restart #397 — AC becomes unavailable after power outage or router restart
• AC becomes unavailable in Home Assistant when internet (WAN) is down, although integration is local #394 — AC becomes unavailable in HA when internet is down
• widget shows unavailable after 2026.3.1 #420 — widget shows unavailable after 2026.3.1
• Failed to communicate with device 10.3.1.68:7000: 'NoneType' object has no attribute 'encrypt' #427 — 'NoneType' object has no attribute 'encrypt' (open)

Repro

1. Set up a Gree AC with blank encryption key (auto-bind).
2. Confirm the entity is controllable.
3. On the AC unit, hold MODE + WIFI to enter Wi-Fi re-pairing mode. Re-pair it to the same network.
4. Observe the entity stays Unavailable; log shows the 8-retry timeout loop indefinitely.
5. With the proposed patch: entity self-heals within threshold × scan_interval seconds (default 3 × 60s = 3 minutes).

[RobHofmann]

Thanks for reporting & giving the detailed write-up. AI does wonders :)