fix(climate): keep optimistic state until DKN cloud catches up #4

2026-05-27T12:51:18Z

thatguygriff commented

2026-05-27 12:51:18 +00:00

Summary

Fixes a bug where Home Assistant's climate UI flips back to the previous setting moments after a successful change (target temperature, HVAC mode, fan, swing). The unit itself and the DKN mobile app reflect the change correctly — only HA reverts.

Root cause

The DKN cloud's REST endpoint (/api/v1/installations/dknUsa) lags behind the unit's actual state for 5–60s after a write. The previous optimistic-overlay TTL of 2.5s expired before the cloud caught up, so the next coordinator publish (REST poll or socket device-data push) brought in stale values and the UI re-rendered with them.

Fix

Two coordinated changes:

Extend the overlay TTL to 30s (OPTIMISTIC_TTL_SEC in const.py) as a safety bound for cloud-propagation lag.
Make the overlay self-clearing. _optimistic_set now records the underlying device key + expected device value. A new _reconcile_optimistic runs on every coordinator publish (REST poll + socket push) and clears any overlay whose device key now reports the expected value — i.e. the moment the cloud confirms the write. The TTL caps how long a silently-failed write can hold a wrong value.

Also removes the unused _wait_for_device_value helper.

Test plan

From HA, change target temperature on a real device — UI shows new value immediately, does not revert within 60s, unit and DKN app reflect the change.
Repeat for HVAC mode (heat/cool/auto/off), fan mode, swing mode, power on/off.
With debug logging on custom_components.dkncloudna, confirm overlay entries in hass.data[DOMAIN][entry_id]["optimistic"][mac] disappear once the next coordinator publish carries matching device data — not after the 30s TTL.
Silently-failed write fallback: send a setpoint the unit rejects (or transiently disconnect); confirm the UI falls back to the cloud-reported value within 30s.

## Summary Fixes a bug where Home Assistant's climate UI flips back to the previous setting moments after a successful change (target temperature, HVAC mode, fan, swing). The unit itself and the DKN mobile app reflect the change correctly — only HA reverts. ## Root cause The DKN cloud's REST endpoint (`/api/v1/installations/dknUsa`) lags behind the unit's actual state for 5–60s after a write. The previous optimistic-overlay TTL of 2.5s expired before the cloud caught up, so the next coordinator publish (REST poll or socket `device-data` push) brought in stale values and the UI re-rendered with them. ## Fix Two coordinated changes: 1. **Extend the overlay TTL to 30s** (`OPTIMISTIC_TTL_SEC` in `const.py`) as a safety bound for cloud-propagation lag. 2. **Make the overlay self-clearing.** `_optimistic_set` now records the underlying device key + expected device value. A new `_reconcile_optimistic` runs on every coordinator publish (REST poll + socket push) and clears any overlay whose device key now reports the expected value — i.e. the moment the cloud confirms the write. The TTL caps how long a silently-failed write can hold a wrong value. Also removes the unused `_wait_for_device_value` helper. ## Test plan - [ ] From HA, change target temperature on a real device — UI shows new value immediately, does not revert within 60s, unit and DKN app reflect the change. - [ ] Repeat for HVAC mode (heat/cool/auto/off), fan mode, swing mode, power on/off. - [ ] With debug logging on `custom_components.dkncloudna`, confirm overlay entries in `hass.data[DOMAIN][entry_id]["optimistic"][mac]` disappear once the next coordinator publish carries matching device data — not after the 30s TTL. - [ ] Silently-failed write fallback: send a setpoint the unit rejects (or transiently disconnect); confirm the UI falls back to the cloud-reported value within 30s.

thatguygriff added 1 commit 2026-05-27 12:51:18 +00:00

fix(climate): keep optimistic state until DKN cloud catches up

Validate / Hassfest validation (pull_request) Has been skipped

Details

Validate / HACS validation (pull_request) Has been skipped

Details

494c6df2c3

The DKN cloud REST endpoint lags behind the unit for several seconds
after a write, even though the unit itself and the DKN app reflect
the change immediately. The previous 2.5s optimistic-overlay TTL
expired well before the cloud caught up, so the next coordinator
publish (REST poll or socket device-data push) carried stale values
and the HA UI reverted to the previous setting.

Extend the overlay TTL to 30s as a safety bound, and track the
underlying device key + expected device value alongside each overlay.
On every coordinator publish, clear overlays whose device key now
reports the expected value (cloud has confirmed). The TTL still
caps how long a silently-failed write can hold a wrong value.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

thatguygriff merged commit 2770eda23b into main

2026-05-27 12:53:09 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GitHub/homeassistant-dkncloudna#4