Home Assistant Update Broke Something? How to Fix It (2026)

It is a Tuesday afternoon. You updated Home Assistant Core last night, or maybe the auto-update did, and now something has stopped working. The heating won't respond to the schedule. Half your Hue lights show as "unavailable". The solar charge automation fires every morning but the battery sits at 12%. The dashboard loads, but the logbook is empty. You have a job to get back to and you are 40 minutes into a tab-explosion of GitHub issues, none of which match exactly.

This guide is written for you. It is a triage flowchart for the breakages that actually happen on UK Home Assistant setups after a Core update — not a generic "have you tried turning it off and on again" listicle. Each section names the specific failure, explains what is happening underneath, and tells you what to do. Most of these we have lived through ourselves while running customer hubs at habbb. None of the fixes need a developer.

TL;DR — the three checks worth doing first

Before you open any logs, run these three checks. They eliminate 60% of the cases where "the update broke things" turns out to be "something else happened around the same time".

• Is Home Assistant Core actually running? Not the Supervisor — Core. Settings → System → Hardware should show the host responsive, but Settings → System → Logs is what tells you if Core itself crashed during startup. A blank or stale logbook means Core restarted recently and may still be coming up.
• Has the integration's auth quietly expired? Settings → Devices & services. Look for any integration with an orange "reconfigure" or "reauthenticate" button. Tado, Nest, Ring and Hue (cloud-routed) all have access tokens that expire on their own schedule, and a Core update is often just the moment you happen to notice.
• Does Settings → System → Logs show errors in the last hour? If yes, the top-most repeating error is almost always the actual breakage. Copy the integration name out of it — that is the section of this guide you want.

If those three don't tell you anything, work down the table below.

Identify the breakage

Tado integration suddenly slow

This is the most common Tado breakage of the last twelve months and it is not actually caused by a Home Assistant update — it is caused by tado° itself. They are a UK-popular brand which is why we get this question more than any other.

In early 2025 tado° announced API rate limits on their cloud (existing customers had a 19 February 2025 in-app deadline to choose a subscription tier, with the limits ramping in fully through 2025). The free tier — which is what most people are on if they bought a starter kit and never subscribed to anything — gets 100 requests per day. Their paid Auto-Assist or AI Assist tiers get 20,000 requests per day. The tado integration in Home Assistant polls the cloud regularly to read room temperatures, set-points and device states, so 100 requests per day runs out fast — typically before lunchtime. After that the integration looks like it has gone to sleep. You change a set-point in the HA UI and tado° doesn't respond for half an hour because the next poll is queued.

There are three honest options:

1. Subscribe to Auto-Assist. £2.99/month or £30/year per home (for Tado V3+; if you've got Tado X, the equivalent is AI Assist at £3.99/month or £29.99/year). Either lifts the limit to 20,000 req/day, which is comfortable headroom for any HA installation. This is the path most of our customers end up taking because it just makes the problem disappear.
2. Reduce poll frequency in HA and accept the gap. You can change the integration's update interval, but realistically anything that keeps you under 100 calls/day means a 15–20 minute lag on temperature readings. Heating works fine; live tweaking from your phone does not.
3. Move to local-only. tado° X (the Matter-over-Thread generation) can be controlled locally without touching the cloud. The older V3 / V3+ kit cannot. If you have V3+, this option isn't open to you without replacing hardware.

To check whether you are being rate-limited right now: Settings → System → Logs, search "tado". You'll see lines like Rate limit exceeded or 429 Too Many Requests. That is unambiguous — it is not your update, it is the cap.

Hue lights unavailable after a Core update

Philips have been moving the Hue ecosystem from the v1 API to the v2 API across 2024–2025 and pushing bridge firmware that drops v1 support on certain bulb categories. Most of the time the built-in Home Assistant hue integration handles this transparently. Occasionally, after a Core update, you see one or more bulbs flip to "unavailable" and stay there.

The diagnostic order:

1. Check the bridge directly. Open the official Hue app on your phone. Are the bulbs reachable there? If they are not, this is not a Home Assistant problem at all — your bridge has lost them and you need to re-pair from the Hue app first.
2. If the bulbs work in the Hue app but not in HA: Settings → Devices & services → Hue → three-dot menu → Reload. Nine times out of ten this is enough.
3. If reload doesn't fix it: remove and re-add the Hue integration. You will not lose your scenes — those live on the bridge, not in HA.
4. If you're using the HACS community Hue integration rather than the built-in one, update it. The community fork lagged the v2 API rollout for a few months in 2025 and that is the most common trigger for this exact symptom.

Don't factory-reset the bulbs unless you have already exhausted the above. A factory reset means re-pairing every bulb individually with the dimmer switch, which is genuinely tedious if you have more than a dozen.

Solar automation fired but the inverter didn't move

This one is specific but worth its own section because it is the most expensive failure mode on the list — if the automation that pulls cheap overnight power into your battery silently fails, you wake up to 12% state of charge and a £4 day instead of a 60p day.

The symptom: your morning automation fires (you can see it in the logbook), the MQTT message is published (you can see it in the MQTT add-on logs), but the inverter or battery doesn't change state. Reads still work — the inverter's current SoC, voltage and power figures all update correctly in HA. Only writes are silently dropped.

The cause, if you are running an MQTT bridge add-on like lxp-bridge for a Lux Power inverter or any similar middleware: the add-on has lost its subscription to the MQTT command topic. It still publishes telemetry outbound (which is why reads keep working) but it is no longer listening for the inbound commands HA sends. This sometimes happens after a Home Assistant Core restart, depending on the order in which Core, the MQTT broker and the bridge come back up.

The immediate fix:

• Settings → Add-ons → lxp-bridge (or your equivalent) → Restart. Not "restart Home Assistant" — restart the add-on specifically. The subscription gets re-established on connect.

The permanent fix is a small automation that restarts the bridge add-on whenever Home Assistant itself starts up:

alias: lxp-bridge restart on HA start
trigger:
  - platform: homeassistant
    event: start
action:
  - service: hassio.addon_restart
    data:
      addon: a0d7b954_lxp-bridge   # check your slug in the add-on URL
mode: single

If your bridge supports it, also enable publish_holdings_on_connect: true in its config so that the inverter's full state republishes after every reconnect. The two together close the loop.

For ongoing assurance, a "roundtrip probe" — a small automation that writes a no-op value to the inverter and reads it back once an hour, alerting if the read doesn't match — is what we run on every habbb hub that has solar.

Automations not firing — the initial trap

Here is a Home Assistant gotcha that has eaten more afternoons than it should have. If you have an input_text, input_number or input_boolean helper with an initial: value set, that value resets to the initial on every Home Assistant restart. By design — not a bug. The HA team have declined to change it.

The reason this looks like "the update broke something": you set the helper from an automation (say, "store the time the last washing-machine cycle finished"), the automation depends on reading that value back later, and immediately after a Core update the value is whatever the YAML says rather than whatever you last stored.

The fix is one line. Open the helper's YAML (or the UI editor for that helper) and delete the initial: line entirely. Don't set it to empty, delete it. Helpers without an initial: use Home Assistant's standard restore-state mechanism, which writes to disk every 15 minutes and immediately before any restart.

If the helper was created via the UI, you may need to find it under /config/.storage/input_text (or input_number, input_boolean) and remove the initial key from the JSON, then restart Core once more. After that the value will persist across restarts forever.

Logbook or history gone

You opened the logbook to find out when an automation last ran and it returned nothing — or only the last few days. The automations didn't stop firing. The data is gone.

Home Assistant's recorder integration has a default retention of 10 days. Anything older than that is purged during the nightly maintenance run. After a Core update, the maintenance run sometimes ticks over for the first time in a while and clears out a chunk of history that you had got used to seeing.

To extend retention, add this to your configuration.yaml:

recorder:
  purge_keep_days: 60
  # optionally, limit which entities are recorded to keep the DB small
  # exclude:
  #   domains:
  #     - sun
  #     - automation

60 days is comfortable for most homes; 365 if you want a year of energy data. The trade-off is database size. The default SQLite database lives at /config/home_assistant_v2.db and grows roughly proportional to the number of frequently-changing entities times retention days. If you have a lot of high-frequency sensors (power meters, especially), consider excluding their per-second history and relying on the long-term statistics table instead, which keeps hourly aggregates indefinitely regardless of purge_keep_days.

After changing retention you'll need to wait for the next purge cycle, or run the recorder.purge service manually with repack: true, before you see the database actually shrink — bumping purge_keep_days doesn't bring back data that was already deleted.

YAML editor 500 errors on every automation

Symptom: you click on any automation in Settings → Automations & scenes and the panel shows "Response error: 500". You can run the automations, you can see them, but you cannot edit them in the UI.

If you store credentials in secrets.yaml and reference them with !secret from automations.yaml, this is the cause. Home Assistant's UI editor cannot serialise !secret references back to YAML when you save, and it errors out 500 on the load step rather than the save step, which is why even opening an automation breaks. It doesn't matter whether the specific automation you opened uses !secret — the presence of any !secret anywhere in automations.yaml poisons the editor for all of them.

The fix:

• For non-sensitive references (entity names, integer thresholds), inline the literal value directly into automations.yaml.
• For genuinely sensitive values (API keys, webhook tokens), move the automation to a script defined in YAML, or use a template that reads the secret from a file outside automations.yaml. The UI editor isn't asked to parse those.

After removing the last !secret from automations.yaml, reload automations (Developer tools → YAML → Reload Automations) and the UI editor will work again.

Won't boot at all after a Core update

This is rare but it is the scariest one. The dashboard returns ERR_CONNECTION_REFUSED, the companion app shows offline, and you don't know whether the box is even alive.

First check the box itself. If it is a Pi, the green activity LED should be flickering — not solid, not dark, flickering. If it is dark, it is a power or SD/SSD problem and not a Home Assistant problem; reseat the power cable and the storage. If it is solid green, the kernel is up but something is wrong above it.

Assuming the hardware is alive, your recovery path is SSH. If you have the official Advanced SSH & Web Terminal add-on installed, you cannot use it right now because Core isn't serving the dashboard. What you can use, if you set it up in advance, is the host-level dropbear SSH that HA OS exposes when you drop an authorized_keys file onto the boot partition. (This is what habbb uses to reach customer hubs — every habbb-shipped Pi 5 has dropbear listening on port 22222 from day one, which is why we can fix things you can't.)

If you didn't set that up: power off the Pi, take the SSD or SD card out, mount it on a laptop, drop your public key into the hassos-boot partition under CONFIG/authorized_keys, put it back, boot. SSH to root@<pi-ip>:22222. Once in, you can:

ha core update --version 2026.4.4   # roll back to a known-good version
ha core restart

The version you want is whatever you were on before the bad update. If you don't remember, ha core info will show what is currently installed and ls /mnt/data/supervisor/backup/ will list any automatic backups Supervisor took before the update.

General rollback advice

Home Assistant Supervisor takes an automatic partial backup of Core before every update. Most people don't know this and most people don't use it. From the dashboard (if it's responsive): Settings → System → Backups. The most recent automatic one is named after the version it was taken before — e.g. Core 2026.4.4. Restore that backup and you're back where you were 24 hours ago.

From the command line:

ha backups list
ha backups restore <slug> --homeassistant

The --homeassistant flag restores Core only, not the whole system, which is faster and safer.

If you want to pin Core to a specific version going forward (e.g. you know 2026.5.x has a regression you don't want), use ha core update --version 2026.4.4 and then don't click "Update" in the UI until you've checked the release notes for the next one. There is no "lock" mechanism in Supervisor — staying on a pinned version is a discipline thing.

Or, pay someone else to deal with this

Most of the breakages above take 20–60 minutes to triage and fix once you've seen them before. The first time, they take an afternoon. The Tado one in particular has caught out enough people that "tado integration broken home assistant" is one of the highest-volume search terms in the UK Home Assistant world.

If you'd rather not be the person who diagnoses these on a Tuesday afternoon, that's what habbb does. We test every Home Assistant Core update on a bench unit before deploying it to customer hubs. We watch the integrations you have installed for the kind of cloud-side breakages that aren't actually triggered by a HA update at all (Tado, Hue, Nest). We fix things quietly when they break and you find out from the changelog email rather than from the heating not coming on.

It is £40/month for an existing Home Assistant setup you already own (we connect to your hardware, no new box), or £150 hardware plus £30/month if you start fresh with us. No contract, cancel any time. The boundary worth knowing: we keep what you have working — adding a brand-new integration or a brand-new automation from scratch is quoted separately. Same as a boiler service contract.

If your current Pi or Yellow is already up and you'd rather we just adopted it, start here. If you'd rather start from scratch with hardware we ship, check fit here.

FAQs

Should I just turn off auto-updates?

No, but qualify that. Leaving auto-updates on means you get security fixes promptly. Turning them off means you control the timing but you also have to remember to update, which most people don't. The middle path — and what we do for habbb customers — is to subscribe to the Home Assistant release notes RSS, wait 7–10 days after a release for any "this version eats your database" reports to surface in the forums, then update during a window when you're around to fix it. If that sounds like work, that is what habbb is.

Does habbb update on a schedule?

Not a calendar schedule. We update when a release has been out long enough to have flushed out the obvious regressions, which is typically 1–3 weeks after release. We test it on a bench unit running the same hardware as the customer fleet before pushing. If a release has a known regression that affects an integration you depend on, we hold you back until the patch release.

What if my custom integration breaks?

We triage it. If it's a popular HACS integration with an active maintainer, the fix is usually a wait-for-the-update problem and we report back. If it's a niche one that has been abandoned, we tell you honestly that it has been abandoned and discuss your options — replace the underlying device, switch to a different integration, or pay for a one-off custom fix. The subscription covers triage and existing working setups; bespoke development is quoted separately.

How often does Tado break specifically?

In the last two years, twice meaningfully. The 2025 rate-limit announcement was the bigger one. The other was a token-refresh bug on one specific Core release that needed a reauthenticate-from-UI step. Tado is reliable as a brand but its cloud is a third-party service we don't control, and that is the risk you take with any cloud-routed integration.

Do you support every integration I've installed?

Yes for the standard set — Hue, Tado, Hive, Nest, Ring, Sonos, TP-Link, Shelly, Aqara, IKEA, Octopus Energy, ESPHome, MQTT, all the common Zigbee networks. If you have something genuinely esoteric (a custom-built integration for a specific solar inverter, say), we'll have a conversation about it. We are not in the business of saying "we don't support that" without checking — but we are also honest if something is past our depth and would need bespoke work.

Z2M vs ZHA — does either break less often after updates?

Honestly, ZHA is more conservative. It ships with Home Assistant and follows its release cadence, so a Core update is unlikely to break ZHA itself — only the radio adapter underneath. Zigbee2MQTT moves faster, gets new device support sooner, and occasionally breaks in ways ZHA doesn't because it has a wider device matrix to worry about. Both are fine production choices. If you have an existing Z2M setup that works, don't switch; if you're starting fresh and stability-first, ZHA is the easier ride.