nledenyi

Viessmann Vitodens 100-W B1HG - Local OpenTherm control via ESP32/ESPHome (bypassing Viessmann cloud paywall)

Status: Implemented and running. Document reflects the working configuration as of April 2026, including Viessmann-specific quirks discovered during deployment.

Viessmann Vitodens 100-W B1HG - Local Control via OpenTherm

1. Background & Root Cause Analysis

The Problem: Viessmann Cloud API Paywall

nledenyi

Toyota EU: /v1/global/remote/status is a cache endpoint, and that changes everything

Sharing a root-cause finding from an investigation on 2026-04-24. Not a fix PR yet. Posting because this appears to unify at least 10 open issues across pytoyoda/pytoyoda and pytoyoda/ha_toyota, including the predecessor DurgNomis-drol repos.

TL;DR

GET /v1/global/remote/status is a cache read. The cache is populated when the car's cellular modem transmits. That only happens during active trips (assumed auto-report from the car, to be validated), or when someone issues POST /v1/global/remote/refresh-status to command the car to wake up and transmit, for example whenever a user opens the Toyota Android app and the app requests a fresh read. pytoyoda only implements the GET side; the official Toyota app uses both.

So the unification: it is not that different endpoints have different problems. It is that /v1/global/remote/status is a single flaky endpoint that happens to be the ONLY source of door/loc

nledenyi

pytoyoda diagnostic probe (v2)

A read-only diagnostic for accounts hitting climate / status issues with the Toyota HA integration. Dumps feature flags, account-state gating signals, and a sanitized view of what your vehicle returns from each climate endpoint.

The output is sanitised - VINs are truncated to the last 6 chars, GPS is redacted, strings are capped. It's safe to paste verbatim as a comment on this gist.

nledenyi

Toyota EU integration - test pytoyoda fork (climate-settings 500 resilience)

A work-in-progress pytoyoda fork that survives the persistent HTTP 500 returned by /v1/global/remote/climate-settings on some accounts. The fix catches the failure, logs it, and lets the rest of the vehicle update cycle succeed - so the integration sets up and runs even when that one endpoint is broken on the Toyota gateway.

Companion to ha_toyota issue #291. Once the upstream PR merges and a new pytoyoda is released, none of this

nledenyi

Toyota EU integration - test ha_toyota fork (refresh-status 500 resilience)

A work-in-progress fork of the Toyota EU community integration that fixes the smart status-refresh strategy on vehicles whose gateway returns persistent HTTP 500 on POST /v1/global/remote/refresh-status. Targets ha_toyota#293 (the gateway-rejects-the-wake-POST bucket of #291).

What changes vs stock ha_toyota 2.3.0:

• The wake POST is wrapped in try/except. A 5xx exception now correctly advances the auto-disable counter and lets the rest of the cycle's bookkeeping run (instead of propagating past it and freezing entities at last-good).
• A bare GET fallback fires when the POST fails, so /status entities still refresh this cycle even before auto-disable kicks in.
• The "Refresh vehicle status" service / button now bypasses both auto-disable AND user-disable. If the gateway recovers (or you want a fully manual schedule), pre