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 will be needed - pip install --upgrade pytoyoda against PyPI will be enough.

Read this first

You will run terminal commands inside your Home Assistant container. Set aside 10 minutes, follow each step exactly. There's a rollback section at the bottom if anything goes sideways.

This guide does not modify ha_toyota itself - only the underlying pytoyoda Python library. Stock ha_toyota 2.3.0 from HACS is what you should already have.

Step 0 - figure out which Home Assistant install you have

Install type	How to recognise it	What you'll do
Home Assistant OS (HAOS)	Settings -> System -> About shows "Operating system: Home Assistant OS X.Y"	SSH into the host, then `docker exec` into the container
HA Container / Supervised	You run HA via `docker compose` or `docker run` directly	`docker exec` straight from your Docker host
HA Core in a venv	You manage the Python venv yourself	Activate the venv and run `pip` directly. Skip the `docker exec` parts.

For HAOS, install the Advanced SSH & Web Terminal add-on by frenck, set Protection Mode: off, restart the add-on, and SSH in. The official "Terminal & SSH" core add-on has no docker command and won't work.

You're in the right shell when docker --version returns a version number.

Step 1 - get a ROOT shell inside the Home Assistant container

docker exec -u 0 -it homeassistant bash

The -u 0 is required. Without it, pip install may write to a per-user directory that HA's Python doesn't read from.

You should now see a # prompt.

Step 2 - install the pytoyoda fork from git

pip install --upgrade --no-deps --force-reinstall \
  "git+https://github.com/nledenyi/pytoyoda.git@feat/per-endpoint-optional"

--no-deps is required - without it pip will try to "upgrade" your other HA dependencies and may break unrelated integrations.

--force-reinstall is required because the fork reports the same version number (5.1.0) as upstream PyPI; without it pip skips the install.

Verify the install

Two checks. Both must pass.

Check 1 - confirm it's the fork, not PyPI's 5.1.0.

PyPI ships its own pytoyoda 5.1.0; the fork branch reports the same version number. Pip records where it actually pulled the code from in direct_url.json, so we read that:

python3 -c "
import importlib.metadata, json
dist = importlib.metadata.distribution('pytoyoda')
print('Version :', dist.version)
url_json = dist.read_text('direct_url.json')
if url_json:
    info = json.loads(url_json)
    print('Source  :', info.get('url'))
    print('Branch  :', info.get('vcs_info', {}).get('requested_revision'))
    print('Commit  :', info.get('vcs_info', {}).get('commit_id', '')[:8])
else:
    print('Source  : PyPI (NOT the fork - install did not take)')
"

Expected:

Version : 5.1.0.post1.dev0+57ed082
Source  : https://github.com/nledenyi/pytoyoda.git
Branch  : feat/per-endpoint-optional
Commit  : 57ed0822

The version string is computed from git describe at install time: 5.1.0.post1.dev0 means "1 commit past the v5.1.0 tag, dev build". That's a PEP 440 post-release of 5.1.0, which still satisfies ha_toyota's pytoyoda>=5.1.0,<6.0 requirement, so HA won't try to re-pull 5.1.0 from PyPI on the next restart.

If Source: PyPI appears, re-run Step 2 with --force-reinstall.

If Version starts with 5.0.0.post... instead of 5.1.0.post..., that means git describe didn't see the v5.1.0 tag (fork-side gotcha fixed on 2026-04-29). The 5.0.0.post... version doesn't satisfy ha_toyota's >=5.1.0 pin, and HA will try to reinstall from PyPI on the next restart - undoing this fix. Re-run Step 2 with --force-reinstall to pick up the now-published tag.

Check 2 - sanity check that the resilience field is wired up.

python3 -c "from pytoyoda.models.vehicle import EndpointDefinition; \
  import dataclasses; \
  fields = [f.name for f in dataclasses.fields(EndpointDefinition)]; \
  print('has optional field:', 'optional' in fields)"

Expected: has optional field: True.

Step 3 - restart HA

Exit the container shell:

exit

Then restart HA Core. From your host shell:

ha core restart

Wait 1-3 minutes for HA to come back up.

Step 4 - verify it worked

Open Home Assistant -> Settings -> Devices & Services, find "Toyota EU community integration". You should see:

The integration set up successfully (no "Failed to set up" banner).
Your vehicle's entities (location, fuel, doors, locks, etc.) populating with values.
A climate entity may or may not appear - that depends on capability flags, separate from this fix.

To confirm the climate-settings 500 was caught (not propagated), check the HA log:

Settings -> System -> Logs -> Load Full Logs, filter for pytoyoda. You should see an entry like:

WARNING ... Optional endpoint 'climate_settings' failed: ToyotaApiError: 500 ...

That warning is the desired outcome - the failure was recorded but didn't abort the update cycle.

Rollback

If anything goes wrong, revert pytoyoda to the PyPI release:

docker exec -u 0 -it homeassistant bash
pip install --upgrade --no-deps --force-reinstall "pytoyoda==5.1.0"
exit
ha core restart

What to report back

If you can post the following on issue #291, that's the most useful:

Did the integration set up successfully? (yes/no)
Did your vehicle's non-climate entities populate? (yes/no)
The HA log line for the climate_settings warning (if any).
Whether you re-ran the probe gist and climate-settings came back as anything other than 500 (very rare but useful to know if it ever clears on its own).

Thanks for testing!

nledenyi/Toyota EU - test pytoyoda fork (climate-settings 500 resilience).md

Select an option

No results found