Home Assistant 2026.11: custom integrations that fail with "cannot import name", and which ones are fixed

Is this you?

1. Go to Settings > System > Logs. Open the menu of the log card and choose Show raw logs, then search for cannot import name. The normal log view usually does not find it: there the error often shows only as Error setting up entry … for …, and you have to open that entry to see the traceback.

2. Look for ImportError: cannot import name '…' from 'homeassistant.…'. Just above the traceback there is usually Error setting up entry … for …. The folder after custom_components/ in the same traceback is the integration that has the problem.

3. Find that integration in the table. If it is not there, the steps below still apply: tell its author the name and where it now comes from (the list for authors).

Some integrations fail in a different way. An integration set up in configuration.yaml (a platform: entry) loses only that platform. An integration that starts its platforms in the background can show as loaded with no entities; the only log trace is then Task exception was never retrieved, followed by the same ImportError.

What to do

Before you update to 2026.11.0: check the table for each custom integration you use. Update the fixed ones in HACS first. If HACS does not offer the version the table names, open the integration in HACS and choose Update information in its ⋮ menu: that makes HACS check GitHub for new releases. HACS's own list of versions can be days behind; on 31 October it had last changed on 29 October. A few fixed releases need 2026.11 itself, and HACS will not install them on 2026.10; their row says so, so update those right after you update Home Assistant. If one shows Not fixed, wait. Home Assistant's own documentation says you can stay on the previous version until a fix is released. If you update anyway, turn on the backup option in the update dialog (Automatic backup before update or Create manual backup before update), so you can go back.

In Docker there is no update dialog. Make a backup first in Settings > System > Backups. To stay on 2026.10, pin the image to ghcr.io/home-assistant/home-assistant:2026.10.4, or homeassistant/home-assistant:2026.10.4 from Docker Hub (in Compose, on the image: line). The stable tag moves to 2026.11.0 on release day, so a container set to stable gets 2026.11 at its next pull.

If you have already updated and an integration fails:

• Its row says Fixed: install the integration's update and restart. In 2026.11, HACS becomes part of Home Assistant as the Marketplace, and your HACS integrations move into it when Home Assistant first starts after the update. Their updates show under Settings > Updates. If installing the update asks you to accept the Marketplace's notice, open Settings > Marketplace and accept it first: until then it cannot install updates. After the update, a repair offers to restart Home Assistant for you. The Marketplace checks its catalog for new versions every 6 hours, and that catalog can itself be days behind, so a recent fix may not show yet.
• Its row says Not fixed, or "not yet in a release": go back to 2026.10. Restore the backup you made before the update, in Settings > System > Backups. On Home Assistant OS, restoring the Home Assistant settings from that backup also brings back the version you ran then. Home Assistant's documentation says to go back by restoring a backup: installing the earlier version alone does not undo changes the newer version made to your data. In Docker, change the image to 2026.10.4 (in Compose, the image: line, then docker compose up -d) first, then restore the backup. If you have no backup, the file edit below or waiting for the author are what is left.
• Tell the author, if their issue tracker has no report of it yet. The ImportError line is enough; if the name is in the list for authors, add the line that replaces the import.

If you are comfortable editing a Python file, you can make the author's fix yourself until the update ships. Open the file named in the traceback. It is in /config/custom_components/<folder>/ or a subfolder of it; the File editor app shows the same folder as /homeassistant/custom_components/<folder>/. Take the name out of the old import and import it from where the list for authors says. For example, this line from the tascam-bdmp4k integration:

from homeassistant.components.sensor import SensorEntity, StateType

becomes these two lines:

from homeassistant.components.sensor import SensorEntity
from homeassistant.helpers.typing import StateType

If the import lists its names in brackets over several lines, delete only the removed name and its comma from the list, and add the new from … import … line below the closing bracket. Then restart Home Assistant.

The same import can be in more than one file of the integration. After the restart, check the log again, and repeat for each file it names; Studio Code Server can also search the whole folder for the name. HACS, or the Marketplace in 2026.11, replaces these files when you next update the integration, which is what you want once the author's fix is out. This does not work for async_track_state_change, DATA_ZONE_STORAGE_COLLECTION or async_get_unprefixed_name: those need a code change by the author.

Fix status by integration

These are the custom integrations we found that import or call something Home Assistant 2026.11 removes: 61 from the HACS default list, and 2 outside it whose users have reported the error on GitHub. Fixed means the integration's latest GitHub release, which is what HACS and the Marketplace install, no longer has the import. We read every row again on 31 October; a release after that date is not shown.

Two names that the 2026.11 development code removed, ATTR_LAST_TRIGGERED in script and EventExtraStoredData in event, were put back before the beta (#189196 and #189209, merged 28 October). That is why five rows say no update is needed.

Errors from two other 2026.11 changes, to last_states and to DeviceInfo, have a different cause: see our note on those.

For integration authors: where each name comes from now

In 2026.11, Home Assistant moved each entity platform's classes into its own entity.py module and gave the platform packages an explicit __all__ (for example #186863 for sensor and #186835 for climate). Names that a package only imported for its own use are no longer bound in it, so importing them from there fails. Import each name from the module that defines it:

Two changes need more than a new import:

• async_track_state_change in homeassistant.helpers.event is removed (#184756). It was deprecated in April 2024. Its replacement, async_track_state_change_event, passes your callback one Event instead of (entity_id, old_state, new_state), so the callback needs a small rewrite. If you import it but never call it, delete the import.
• verify_client_id in homeassistant.components.auth.indieauth now requires the keyword arguments request_scheme and request_netloc (#186543). 2026.10 does not accept them.

If your name is not in the table: between 2026.10.4 and the 2026.11.0b2 beta, 1,752 names stopped being importable from the top level of 219 built-in integration packages, by our reading of the source. Apart from the names in the table above, no integration in the HACS default list imports one of them on its default branch, as we read it on 31 October. Of the 1,752, 253 are in homeassistant.const in both versions, and 448 are defined in a homeassistant.helpers module, homeassistant.core, homeassistant.exceptions or homeassistant.config_entries. Import those from there; that works on 2026.10 as well. 352 are now in a submodule of the same package, such as its new entity.py, which may not exist in 2026.10. For those, keep the old import as a fallback:

try:
    from homeassistant.components.event.entity import EventExtraStoredData
except ImportError:  # Home Assistant 2026.10 and earlier
    from homeassistant.components.event import EventExtraStoredData

The other 699 are defined somewhere else: in the Python standard library, in a third-party package, in another Home Assistant module, or nowhere any more. Import them from where they are defined.

How we checked

• The list. On 18 October we read every Home Assistant import in 3,219 of the 3,241 repositories in the HACS default integration list, and checked which names the 2026.11 development code no longer provides. Every hit was read by hand. The details, and a script that tries each import on your installed Home Assistant, are in our longer note.
• The beta. On 31 October we checked those imports again against the source of 2026.10.4 and of the 2026.11.0b2 beta. The removed names are the same as in the development code, apart from the two that were put back.
• The current list. The HACS default list has grown to 4,292 integrations since 18 October. On 31 October we read the default branch of each one with the method in the next point. That found one more integration that imports a removed name (flare) and none of the others; two repositories could not be downloaded. A few more matches turned out to be in files the integration never loads, behind a check for the new function, or only in a type annotation, and are not listed.
• The status column. On 31 October we downloaded each listed integration's latest GitHub release and its default branch, and read every Python file outside its tests for an import of any name that the beta no longer provides where 2026.10.4 did, or a call to verify_client_id with one argument. We also read the lowest Home Assistant version each release asks for in its hacs.json, which HACS checks before it installs. An import does not count if it only runs for type checking, behind a Home Assistant version check, or inside a try that catches the error. We compared the result with a plain text search for each line we cited on 18 October, and read the file by hand wherever the two disagreed.
• What we ran. On the 2026.11.0b2 beta (31 October), each removed import raised ImportError, apart from the two names put back, and each replacement in the table above imported. Five of these integrations (flightradar24, home-connect-hass, climate_group_helper, petlibro and NissanConnect) failed to set up with their own import and loaded with the one-line fix, using Home Assistant's real loader; on 2026.10.4 they loaded both ways. We also loaded the latest release of every integration the table marks as fixed or working, apart from flare, on the beta the same way: none raised an import error. And we ran the latest release of every integration marked Not fixed, apart from ha-webauthn-mfa: each failed with the import its row names, except Modbus_Devices, which fails only when that code runs, and Hass-Custom-Alarm, which fails earlier (see its row). On the 2026.11 development code (18 and 24 October), the same checks, without PRECISION_WHOLE, EVENT_THEMES_UPDATED and SERVICE_TRIGGER, gave the same results.
• Limits. Outside the HACS default list, we only cover integrations whose users reported the error. Names reached in unusual ways, such as importlib or getattr, are missed. For ha-webauthn-mfa, Modbus_Devices and flare, the effect in the table is what the code predicts, not something we ran. 2026.11.0 can still differ from the beta; we check it again on release day and update this page.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. We reported this change to several of the authors in the table and opened pull requests on some; the two still open are marked. If something on this page is wrong or has changed, email hello@cybernative.ai. We correct the page and list each correction here with its date.