ViCare: blocking call to putrequest causes full event loop freeze / Supervisor watchdog restart loop after 2026.9.0 #181371

The problem

The problem

After manually updating Home Assistant Core to 2026.9.0, our ViCare-based
heat pump setup (Viessmann Vitocal, accessed via the official vicare
integration) started causing repeated full Home Assistant Core freezes,
approximately every 68–71 minutes, forcing the Supervisor watchdog to
kill and restart Home Assistant Core.

Home Assistant's own blocking-call detector logs the following on
almost every polling attempt (via homeassistant.update_entity):

Caught blocking call to putrequest with args
(<HTTPSConnection(host='api.viessmann-climatesolutions.com', port=443)>,
'GET', '/iot/v2/features/installations/.../gateways/.../devices/0/features/')
inside the event loop by integration 'vicare' at
homeassistant/components/vicare/api.py, line 26:
return super().request(method, url, **kwargs).
(offender: urllib3/connection.py, line 406: return super().putrequest())

For plain sensor entities, this is caught and only aborts the calling
automation (logged as an ERROR, automation fails, but Core keeps running).

For climate and fan platform entities specifically, the same
blocking call appears to actually freeze the event loop long enough
that Supervisor's watchdog stops receiving API responses and force-
restarts Home Assistant Core entirely — this happened like clockwork
roughly every 70 minutes, all night and into the next day, for about
24 hours straight.

Timeline / reproduction

• Manually updated Core to 2026.9.0 on 2026-09-04 at approx. 14:15 local time.
• First forced Core restart (via Supervisor watchdog) occurred at 14:18:38,
  and continued every ~68–71 minutes without interruption (with one
  short-interval exception caused by a manual power cycle during
  unrelated troubleshooting) until the ViCare integration was fully
  disabled.
• Removing the climate and fan entities from our homeassistant.update_entity
  polling automations reduced but did not eliminate the crash loop
  (still crashed again ~70 minutes later, triggered via a plain sensor
  entity's cache refresh instead).
• As a controlled test, we fully disabled the ViCare config entry
  (Settings > Devices & Services > Viessmann ViCare > Disable) at 11:07.
  The Supervisor watchdog restart loop stopped immediately and has not
  recurred for 90+ consecutive minutes since (longer than any single
  crash-free interval observed since the 2026.9.0 update), while every
  comparable interval before disabling contained at least one forced
  restart.
• Re-enabling is expected to reproduce the issue (not yet tested, to
  avoid further instability).

Suspected cause

This is a related but distinct occurrence of the same underlying issue
as #125443 ("Blocking call in event loop in ViCare integration",
closed Dec 2024). That issue was fixed narrowly for the getSerial()
call during entity setup (see PR #125495), fixing the specific call
site at vicare/entity.py line 39.

However, the same root cause — PyViCare's fetch_all_features() making
a synchronous, blocking HTTP request whenever its internal cache is
stale — is not limited to entity setup. Any entity's property access
(climate, fan, or plain sensors) can trigger this same blocking call
during normal runtime operation, not just at startup.

This appears to have become newly reproducible/more severe after
2026.9.0 (first in 2026.9.0b1), which includes:
"Fix ViCare setup by passing the accessor to fetch_all_features" (#180315)

This change may have altered how/when the cache refresh is triggered,
resurfacing the same class of bug through a different code path than
the one fixed in #125495.

For plain sensor entities, Home Assistant's blocking-call detector
cleanly raises and aborts only the calling automation/update — Core
keeps running. For climate and fan entities specifically, the same
blocking call appears to actually freeze the event loop long enough
to trip the Supervisor watchdog, causing a full Core restart roughly
every 68-71 minutes in our case.

What version of Home Assistant Core has the issue?

core-2026.9.0

What was the last working version of Home Assistant Core?

core-2026.8.x (exact last-known-good version not pinned down, but stable
for weeks prior to the 2026.9.0 update)

What type of installation are you running?

Home Assistant OS (Home Assistant Green)

Integration causing the issue

vicare

Link to integration documentation on our website

https://www.home-assistant.io/integrations/vicare/

Diagnostics information

(attach Supervisor log excerpt showing the watchdog restart cycle, and
Core log excerpt showing the "Caught blocking call to putrequest" error,
both available on request)

Example YAML snippet

action: homeassistant.update_entity
target:
entity_id:
- climate.viessmann_warmepumpe_heizung
- fan.viessmann_warmepumpe_beluftung

Anything in the logs that might be useful for us?

See blocking-call traceback above; full logs available on request.

Additional information

Fully disabling the ViCare config entry immediately and reliably stopped
the crash loop in a controlled test — happy to provide the raw Supervisor
and Core logs for both the "enabled" (crashing) and "disabled" (stable)
periods if useful for debugging.

What version of Home Assistant Core has the issue?

core-2026.9.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

vicare

Link to integration documentation on our website

https://www.home-assistant.io/integrations/vicare/

Diagnostics information

No response

Example YAML snippet

action: homeassistant.update_entity
target:
  entity_id:
    - climate.viessmann_warmepumpe_heizung
    - fan.viessmann_warmepumpe_beluftung

Anything in the logs that might be useful for us?

2026-09-05 08:42:00.669 ERROR (MainThread) [homeassistant.components.automation.vicare_polling_tag] ViCare Polling - Tag: Error executing script. Unexpected error for call_service at pos 1: Caught blocking call to putrequest with args (<HTTPSConnection(host='api.viessmann-climatesolutions.com', port=443)>, 'GET', '/iot/v2/features/installations/1254390/gateways/7637415007098214/devices/0/features/') inside the event loop by integration 'vicare' at homeassistant/components/vicare/api.py, line 26: return super().request(method, url, **kwargs). (offender: /usr/local/lib/python3.14/site-packages/urllib3/connection.py, line 406: return super().putrequest())

2026-09-05 09:42:55.886 WARNING (MainThread) [supervisor.misc.tasks] Watchdog missed an Home Assistant Core API response.
2026-09-05 09:45:26.874 ERROR (MainThread) [supervisor.misc.tasks] Watchdog missed 2 Home Assistant Core API responses in a row. Restarting Home Assistant Core!

Additional information

Fully disabling the ViCare config entry immediately and reliably stopped the crash loop in a controlled test: the previous ~68-71 minute Supervisor watchdog restart cycle ran uninterrupted for over 24 hours (every single interval containing at least one forced restart), and stopped completely for 90+ consecutive minutes once ViCare was disabled at 11:07. Happy to provide the raw Supervisor and Core logs for both the "enabled" (crashing) and "disabled" (stable) periods if useful for debugging.