Name a blueprint update after the blueprint - #1561
Conversation
These hung off a single device called "Blueprints", and the updates page reads a row by the device it belongs to. So somebody with twenty blueprints saw twenty rows saying "Blueprints", with nothing to say which was which. Frenck spotted it on a screenshot in #1548. The device is gone rather than split. One device per blueprint would have read correctly and filled the device list with twenty entries that are not devices; a blueprint is a file, with no firmware and nothing to connect to. Without a device the entity's own name stands on its own, which is the blueprint's name. Two things follow from it. The entity ID loses its prefix: `update.<name>` where it used to be `update.blueprints_<name>`. Anybody who already has these keeps the old ID, because the registry pins that to the unique ID and the unique ID has not moved. So installations differ depending on when they started, which is not tidy, and renaming them for everybody would break automations that reference one. And the old device is now empty, so it gets removed on the first round. A device that is not a device and holds nothing is only something to wonder about later. Five entity IDs in the tests moved with it. Both changes are mutation tested: putting the device back fails forty tests, skipping the cleanup fails one.
frenck
added
documentation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughBlueprint update entities no longer attach to a shared device. Startup removes the legacy “Blueprints” device. Entity IDs, names, documentation, and tests now reflect the standalone entity model. ChangesBlueprint update entities
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change removes the misleading shared device and gives blueprint update entities names that identify their blueprint while preserving existing registrations during migration. No actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant BlueprintUpdate
participant EntityRegistry
participant DeviceRegistry
BlueprintUpdate->>DeviceRegistry: Find legacy device
BlueprintUpdate->>EntityRegistry: Detach registered entities
BlueprintUpdate->>DeviceRegistry: Remove legacy device
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🟡 Changes recommended
Legacy device removal currently deletes existing entity-registry entries, breaking preserved IDs and customizations.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Names blueprint update entities after their blueprints by removing the shared device association.
Changes:
- Removes the shared “Blueprints” device.
- Adds legacy-device cleanup and migration tests.
- Updates entity IDs and documentation.
File summaries
| File | Description |
|---|---|
custom_components/spook/ectoplasms/blueprint/update.py |
Removes device association and cleans up the legacy device. |
tests/ectoplasms/blueprint/test_update.py |
Updates IDs and adds naming/device tests. |
documentation/integrations/blueprint.md |
Documents device-less entities and new default IDs. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 2
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Review pointed out that removing a device takes the entity registrations on it with it, which is true: Home Assistant deletes every entity entry that belongs to the same config entry as the device. Both are ours here, so it reached for that. What it does not do is cost anything. The registration goes into the registry's deleted list and comes straight back out when the same unique ID turns up again, which is later in the same setup, with the entity ID, the name, the icon, the area, the aliases, the labels and whether it was hidden all still on it. Verified rather than assumed, because the claim was that a user's own naming would be lost. The churn is the reason to avoid it anyway. A dozen repairs re-inspect on any entity registry change, and an entity going and coming back for no reason gives all of them nothing to find. So the entity is taken off the device first, and the device is then removed holding nothing. The lookup moved with it. Finding a device by its identifiers alone is deprecated, because identifiers are no longer unique across config entries, and it warns with a request to open a bug report. The replacement wants to know whose device it is, so the whole thing now runs from where the config entry already was: once, at setup, rather than on every round. Three mutations, each one failing the test on its own: keeping the entity on the device, leaving the device behind, and looking it up under the wrong entry. The test seeds a registration the way the released version left it, and asserts nothing is dropped at all. It also hands its config entry to the setup instead of making up a second one, without which Home Assistant never compares the two as equal, never reaches the removal, and the test passes while proving nothing.
|
There was a problem hiding this comment.
🟡 Changes recommended
Legacy registrations for blueprints removed while offline can remain orphaned after migration.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 1
- Review effort level: Balanced
Description
The blueprint update entities hung off a single device called "Blueprints", and the updates page reads a row by the device it belongs to. So somebody with twenty blueprints saw twenty rows saying "Blueprints", with nothing to say which one each row was about.
Measured before and after, on the same blueprint:
The device is gone rather than split up. One device per blueprint would have read correctly and filled the device list with twenty entries that are not devices: a blueprint is a file, with no firmware and nothing to connect to. Without a device the entity's own name stands on its own, and that name is the blueprint's.
Motivation and Context
Spotted on a screenshot in #1548, where the rows were indistinguishable.
Two consequences worth stating plainly, because neither is free.
The entity ID loses its prefix on a fresh install.
update.<name>where it used to beupdate.blueprints_<name>. Anybody who already has these keeps the old ID, because the entity is taken off the device before the device is removed, so the registration is never dropped. Two installations therefore differ depending on when they first ran this, which is not tidy. Bringing them into line is a decision of its own and not this PR: it would rename an entity somebody may reference.The old device is now empty, so it is removed at setup. A device that is not a device and holds nothing is only something to wonder about later.
Removing a device is not free, which review was right to raise. Home Assistant deletes the registration of every entity on a device when the device goes, and both belong to Spook here, so it reached for exactly that. It also hands the whole registration back the moment the same unique ID turns up again, which is later in the same setup, with the entity ID, name, icon, area, aliases, labels and hidden state all still on it. So nothing was being lost, but a dozen repairs re-inspect on any entity registry change and an entity that goes and comes back gives every one of them nothing to find. Taking the entity off the device first avoids the round trip entirely.
One deprecation went with it. Looking a device up by its identifiers alone is deprecated, since identifiers are no longer unique across config entries, and it warns with a request to open a bug report against Spook. The replacement wants to know whose device it is, so the cleanup now runs from
async_start, where the config entry already was, once at setup rather than on every round.How has this been tested?
Three new tests: the name and title are the blueprint's, no device is created at all, and a device left over from an earlier version gets cleared away without taking anything with it.
That last one seeds the registration the way v5.3.0 left it, renamed and with an icon set by hand, and asserts that no entity is dropped at all. It hands its own config entry to the setup rather than making up a second one: under two entries Home Assistant never compares the two as equal, never reaches the removal, and the test would pass while proving nothing. It did exactly that on the first attempt.
Five entity IDs in the existing tests moved with the change, which is the same rename users will see on a fresh install.
Every part is mutation tested:
The forty is the existing suite noticing the entity IDs shift back, which is a fair way to find out the device is what drives them.
Full suite is 1537 passing. Ruff, pylint and prettier clean.
One documentation line was quietly broken before this and is fixed here: the default entity ID line read
\_Default ...rather than italics, because the old ID contained an underscore that prettier had to escape. With the prefix gone the escape goes too.Screenshots (if appropriate):
None from me. The change shows up on Settings > Updates, where each row now names its blueprint.
Types of changes
Checklist