Repository navigation
async_setup_entry fails with KeyError: 'entities' on Home Assistant Core 2026.9.0 (works fine on 2026.8.3) #225
Description
Environment
MyHOME integration version: 0.9.3 (installed via HACS)
Home Assistant Core (issue occurs): 2026.9.0
Home Assistant Core (confirmed working): 2026.8.3
Installation type: Home Assistant OS 18.2 (Home Assistant Green)
Python version: 3.14.6
Config style: YAML-based (myhome.yaml), two gateway config entries (two separate MYHOMEServer1 units)
Description
After Home Assistant Core auto-updated to 2026.9.0, both of my myhome gateway config entries started failing to set up with the traceback below. This happened with zero changes to myhome.yaml or to the custom_components/myhome files.
Downgrading Home Assistant Core back to 2026.8.3 (via a full backup restore, same myhome.yaml, same custom_components/myhome files) resolves the issue immediately and completely. This is 100% reproducible: the same config that crashes on 2026.9.0 works flawlessly on 2026.8.3.
Steps to reproduce
Set up the MyHOME integration (0.9.3) with a YAML-based config (light, cover, climate platforms) on any Home Assistant OS installation.
Update Home Assistant Core to 2026.9.0.
Restart Home Assistant (a full restart, not just a config entry reload).
Observe that the gateway config entry fails to set up.
Traceback
Codice
Adding diagnostic logging showed that this affects every single device across every platform (light, cover, climate, and the auto-generated button platform) on both gateways — not one specific device or platform.
What I've ruled out
Before opening this, I spent a long time isolating the cause and can rule out the following with reasonable confidence:
myhome.yaml content: I ran validate.py's config_schema from the 0.9.3 release against my real, complete configuration file in an isolated Python environment, using the exact voluptuous==0.15.2 pinned by Home Assistant Core's requirements.txt. Validation succeeds with zero errors, and every device correctly ends up with an entities key in the resulting structure. I could not reproduce the KeyError outside of the live Home Assistant instance.
File integrity: init.py and validate.py on the live instance are byte-for-byte identical (verified via md5sum) to the official 0.9.3 release on GitHub.
Disk space / HACS version / recent config edits: none of these were factors — disk had 19.5GB free, HACS showed no pending update (still 0.9.3), and the config file had not been touched.
Suspected cause
I believe this is connected to the Home Assistant Core 2026.9.0 device registry changes (child devices architecture, home-assistant/core#178666, architecture proposal #1414), building on the 2026.8 "single config entry per device" change.
custom_components/myhome/init.py (async_setup_entry) iterates device_registry.devices.values() and checks entry.entry_id in device_entry.config_entries directly:
Python
Another HACS integration (JurajNyiri/HomeAssistant-Tapo-Control#1418) reports that this exact pattern broke on Home Assistant Core 2026.9.0 due to home-assistant/core#179578 ("no longer supports iteration over device registry keys").
More concretely, the changelog for homematicip_local v2.10.0 documents the precise mechanism:
"devices were no longer removed from the device registry when their last entity disappeared. The removal path tested device_id in device_registry.devices, and on HA 2026.9 devices iterates device entries instead of being a mapping, so the membership test silently never matched. It now asks the registry directly."
This confirms device_registry.devices no longer behaves as a plain mapping on 2026.9.0 — which is exactly what myhome's pruning code in async_setup_entry relies on (device_registry.devices.values(), and entry.entry_id in device_entry.config_entries). I still haven't traced the exact mechanism connecting this to the entities KeyError specifically (that dict is built independently by validate.py), but given how directly this matches the code pattern in init.py, I'd treat it as the most likely root cause rather than just a lead.
Workaround
Downgrading Home Assistant Core to 2026.8.3 (via a full backup restore) resolves the issue completely, with no other changes needed.
For anyone hitting this before a real fix lands: I temporarily patched async_setup_entry to skip devices missing the entities key (logging a diagnostic error instead of raising) and to skip the registry-pruning step entirely whenever incomplete data is detected, to avoid the pruning logic wiping out entity registry entries (which happened to me on first attempt — lost some manually-set entity IDs before I added that safeguard). Happy to share the patch if useful, though it's a workaround, not a fix.
Additional context
This integration hasn't had a commit since March 2024 (release 0.9.3), which predates all of the 2026 Home Assistant device registry architecture changes referenced above. It may need updates to stay compatible as Home Assistant continues evolving these APIs (single-config-entry-per-device in 2026.8, child devices in 2026.9, and more deprecations already announced for 2027.8).
Happy to provide more diagnostics (full logs, config structure, etc.) if helpful.
Activity
feu77 commentedon Sep 4, 2026
Can confirm this on my setup too — MyHOME 0.9.3, HA core updated from 2026.8.2 → 2026.9.0 today, same KeyError: 'entities' on startup, affecting basically all climate and button entities (126 errors in my logs).
Found two additional, related KeyErrors that aren't yet mentioned here, same root pattern (direct dict indexing without a fallback):
light.py (async_setup_entry): _configured_lights[_light][CONF_ICON] → KeyError: 'icon'
switch.py (async_setup_entry): same pattern for CONF_ICON → KeyError: 'icon'
cover.py / switch.py (async_setup_entry): _configured_covers[_cover][CONF_ENTITY_NAME] → KeyError: 'entity_name'
Interesting: validate.py's MyHomeDeviceSchema.call already backfills these exact keys with None when missing (if CONF_ICON not in data[device]: data[device][CONF_ICON] = None, same for CONF_ENTITY_NAME), so the intent was clearly to make these optional. That defaulting doesn't seem to reach the entities that fail, though — consistent with your theory that device_registry.devices iteration behavior changed in 2026.9.0 and something upstream of the schema call is short-circuiting before the rekeying step runs for a subset of devices.
Workaround: reverting the HA core image to 2026.8.2 resolves everything immediately, all 205 entities load cleanly (vs. 123 partially loaded on 2026.9.0). No .storage/recorder DB compatibility issues going backward one version, for anyone else considering this as a stopgap.
Given the last commit here is from March 2024, is this repo still maintained? Happy to help test a fix if someone puts one together — this affects basically all entities (lights, switches, covers, climate, buttons) for anyone running MyHOME.
ricvec commentedon Sep 4, 2026
Same issue here :(
phil54113 commentedon Sep 4, 2026
same issue, only way to get it working , From the command line: : ha core update --version 2026.8.3
domsai47 commentedon Sep 4, 2026
Same issue here :(
Downgrading to 2026.8.3 and work fine
m13v commentedon Sep 4, 2026
the skip-and-log-diagnostic workaround trades a loud KeyError that keeps the config entry in a retry/error state for a quiet async_setup_entry that returns True with some devices silently absent. once it returns True, HA marks the entry loaded and there's no failed-setup retry to bring the skipped ones back, so 'half my lights are gone' reads identical to 'working.' and the entities KeyError is downstream anyway. the actual 2026.9 change is
entry.entry_id in device_entry.config_entriesnever matching once devices stops being a plain mapping, so skipping on incomplete data buries the one signal pointing at the real cause instead of surfacing it.GreenGrassBlueOcean commentedon Sep 8, 2026
Thank you for reporting this issue.
This issue has been resolved in the modernized v2 architecture developed under the new OpenWebNet-HA community organization:
v2-phase1-architecture) and merged core commits.If you would like to test, please download or switch to the
v2-phase1-architecturebranch in HACS. If you encounter any remaining issues on this build, please feel free to report them in PR #232.m13v commentedon Sep 8, 2026
the canonical entity registry migration is the piece to watch on that v2 branch. the OP already lost manually-set entity_ids once to the pruning path, and a canonical migration is exactly the step that re-derives ids from scratch. worth confirming it preserves existing registry entries instead of reassigning them, otherwise the switch trades a loud KeyError for silently renamed entities.