daikin_madoka: 5s cooldown between control() and the next poll

[pridmen]

After a SET_OPERATION_MODE / SET_SETTING_STATUS / SET_SETPOINT the BRC1H takes a few hundred milliseconds (sometimes much longer for SET_OPERATION_MODE, which the existing code already pauses 600ms after) to settle internally before its GET_* responses match what we just wrote. When PollingComponent's next tick fires within that window the readback can return the previous state and overwrite climate::mode / target_temperature in ESPHome, leading to visible "set cool → flip back to fan_only briefly → flip to cool again" jitter in HA UI.

Stamp millis() on every control() and short-circuit update() for the next 5 seconds. After 5s the stamp clears and normal polling resumes.

No behaviour change in steady state — affects only the first 1–2 polls after a control command.

Test plan

• Set mode rapidly (cool → heat → fan_only) from HA, observe no transient flicker in climate.*.mode after each set.
• Idle behaviour identical to upstream (update() continues to poll on schedule once cooldown expires).

[github-actions]

To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file:

external_components:
  - source: github://Petapton/esphome@pull/11/head
    components: [daikin_madoka]
    refresh: 1h

---

(Added by the PR bot)

[Petapton]

Hi, is there any log documenting this behavior?

[pridmen]

The behavior is a race between control() writing a new value and PollingComponent::update() reading it back before the BRC1H has settled internally, so it's timing-dependent. In steady state (default 60 s interval) it almost never triggers, which is why it's easy to miss. To make it show up reliably you have to widen the window:

How to reproduce / catch it

1. Set update_interval: 5s (or lower) on the climate platform so a poll lands inside the settle window.
2. logger: at DEBUG/VERBOSE on daikin_madoka.
3. From HA, change mode rapidly: cool → heat → fan_only, ~2 s apart.
4. Watch climate.<dev>.mode (HA history) and the [D][daikin_madoka] readback lines.

Without the cooldown, the just-set mode flips back to the previously-read value for one poll cycle and then flips to the new value on the following poll (visible cool → fan_only → cool jitter). The BRC1H takes a few hundred ms — longer after SET_OPERATION_MODE, which is exactly why the existing code already pauses 600 ms there — before its GET_* readback matches what was just written.

Stamping millis() on control() and short-circuiting update() for 5 s only affects the first 1–2 polls after a command; steady-state polling is unchanged. I can capture a verbose [D][daikin_madoka] trace of the jitter, but to do that I have to revert the cooldown on a live unit and drive it into the window, so give me a bit.