A few days ago I wrote that I was not updating to Home Assistant 2026.10 on release day, and listed what I would check first. Since then, other people have done the uncomfortable part for me. In the German-language simon42 community forum, a thread opened on 7 October collects what broke after the update. I read it end to end, and I think it is more useful than any changelog, so here is what I took from it.
A caveat first: this is a forum thread, not a bug tracker. Reports are anecdotal, mostly about 2026.10.0, and the thread title already points at 2026.10.1, which the official changelog lists as released on 10 October. Some of what follows may already be fixed. I am reading it as a map of where to look, not as a verdict on the release.
The pattern: custom integrations break first
The loudest reports are not about Home Assistant itself. One user reported that the EcoFlow Cloud custom integration (version 1.7.1) would not start and rolled back to the previous version; another was already running the EcoFlow IoT integration in parallel, where things kept working, and planned to switch. A third reported that a custom Ecovacs integration refused to load because it could not find cryptography==48.0.1, even after installing the package by hand. That user went back to 2026.9, and the thread links a core issue for it. The workaround that reportedly worked for someone else was to remove the integration, delete its folder under custom_integrations, restart and set it up again.
None of this is surprising, and none of it is Home Assistant’s fault in a simple sense. Custom integrations pin dependencies, core bumps dependencies, and the two collide on update day. But it is a good reminder of what the real risk is on my own box: not core, but the handful of things I installed from outside it. Every custom component is a small bet that its maintainer ships a fix within days of a release.
The one that hits automations: input_select conditions
The report I would take most seriously is an automation error: “Cannot use ‘for’ with a list of states”. One user hit it with a state condition on an input_select helper and made it go away by swapping the condition for the dedicated “dropdown option selected” condition instead. I cannot reproduce that, so I will not claim to know the exact trigger. But the lesson is cheap to act on: before an update, search your automations for state conditions that compare helpers against lists, and know where they are.
The editor change people are grumbling about
The other cluster of complaints is about the new automatic trigger IDs. Several users said custom, human-readable trigger IDs can no longer be set in the visual editor and now require YAML, and a frontend issue was opened on 8 October saying custom IDs are not displayed in the new trigger picker. One user fixed a display glitch simply by clearing the browser cache, which is the most boring and most common fix in this hobby, and worth trying before you file anything.
I understand the design instinct: automatic IDs save typing for people who never name theirs. But I name mine, because “trigger 3” in a trace tells me nothing at 2 a.m. If your automations lean on named IDs in choose blocks, this is a place to look closely rather than assume.
Not everything is a regression
To keep this fair: the thread also has good news. One user ran the repairs dialog and fixed 23 entities whose area did not match their device. Another said KNX runs normally on 2026.10.0, while a different user reported KNX trouble, so the same integration produced both a success story and a complaint, which usually points at setup differences rather than a clean bug. And one reported Proxmox install that hung at “Still waiting for Home Assistant Core to start” had no resolution in the thread, with the poster suspecting their reverse proxy. A hanging system is the scary kind of report, but one unresolved case is a data point, not a trend.
The historygraph looking “broken” to one user turned out, per another poster, to be the new frontend layout rather than a bug. I mention it because the 2026.10 release rebuilt the map card and touched card layouts, and some of the “my dashboard is wrong” energy is really “my dashboard is different”.
What I am changing in my routine
Reading the thread, three habits earn their keep. First, I take a backup and copy it off the machine before any minor update, not just before the scary ones. Second, I write down which custom integrations I run and check each one’s issue tracker on release day, because that is where the thread says the pain concentrates. Third, I wait for the first patch release. Most of the reports I read were against .0, and a few days of other people’s bug reports is a cheaper test environment than my own living room lights.
The thread’s authors suggest the same basics: read the backward-incompatible changes and keep an external backup. It is dull advice, and it is the advice that works. Thanks to everyone in that thread for documenting their breakage so publicly; this is the part of the open-source smart-home world I would not trade for any cloud dashboard.
Leave a Reply