Ecobee setpoint occasionally never confirms — no error logged, no fan/setpoint collision, no consistent pattern

Configuration
1

I have a Home Assistant automation that periodically adjusts my Ecobee’s setpoint via climate.set_temperature, based on real sensor conditions. Most commands confirm in under a second. Occasionally — roughly once every 1-3 days, no consistent time of day — a command never gets acknowledged. The thermostat’s reported target temperature simply never updates to match what was requested, even after waiting 30+ minutes.

What I’ve ruled out so far:

  • Not a fan-mode collision — I built a guard to prevent any set_fan_mode-type call from firing while a setpoint change is still pending (there’s a known separate GitHub issue about this). The guard engaged correctly during my most recent failure, confirmed no collision occurred, and the setpoint still failed to confirm.
  • Nothing logged locally — I have system_log capturing anything mentioning “ecobee” in real time. Zero entries during the failure window. No warning, no error, nothing on HA’s side suggesting anything went wrong.
  • Physical hardware state: hvac_action shows the compressor/fan responding normally around the same time, so something is happening at the thermostat — it’s specifically the setpoint confirmation that never lands.

Running the native Ecobee integration (cloud polling), recently updated Core 8.1 → 8.3.

Has anyone else seen a pattern like this — a setpoint write that silently never confirms, with nothing logged on the HA side at all? Trying to figure out if this is a known cloud-side quirk or something specific to my setup before filing a GitHub issue.

2

Based on the “Thermostat - Concepts” section of the integration documentation, perhaps you have some sort of conflicting interaction with the Ecobee’s comfort settings or presets? There are a bunch of moving parts there…

For what it’s worth, I use climate.set_temperature via the the Homekit integration and haven’t experienced the issue you describe.

3

That’s a really useful angle, thank you. I actually have a somewhat unusual comfort-settings config that might be relevant: I collapsed my program down to a single “Home” comfort setting running 24/7 (deleted Away and Sleep), with Hold Action set to “Until I change it.” Given holds are described as relative to the currently active climate in the program, a single-climate setup with no scheduled transitions is a real edge case I hadn’t fully ruled out — I just haven’t found a clean way to test it, since ecobee.set_climate_hold only supports a named preset’s fixed temperature, not the arbitrary values I need to send.

Interesting that HomeKit’s been reliable for you — I looked at switching to it for this specific use case, but it appears to round to whole-degree precision, and I need 0.5° granularity for what I’m doing, so it wasn’t viable for me. Good data point that the issue might be specific to the native cloud integration’s write path though.