bahmcloud/bahmcloud_store
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 34 Wiki Activity

Remove stale update entities after uninstall

Browse Source
This commit is contained in:
René Bachmann
2026-03-23 17:50:41 +01:00
parent 313fcf94e7
commit 599b8e0b7d
4 changed files with 35 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@@ -174,3 +174,6 @@ cython_debug/
# PyPI configuration file
.pypirc
# Local project instructions
.idea/start prompt.md

1
.idea/changes.md generated
View File

@@ -24,6 +24,7 @@
- Restored blueprint backup/restore availability in the UI and backend: the restore button is visible again for blueprint installs, blueprint backups can be listed, and blueprint content can now be restored from backup without forcing a restart.
- Fixed category-specific uninstall and restore messaging in the active panel: blueprints now reference `/config/blueprints` and explicitly state that no restart is required, while integrations keep the `/config/custom_components` restart warning.
- Updated the public documentation set (`README.md`, `README_DEVELOPER.md`, `README_FULL.md`, and `CHANGELOG.md`) for the completed blueprint backup, restore, uninstall, and restart-behavior work, and bumped the integration version to `0.7.6` for the next release.
- Fixed stale Home Assistant update entities after uninstall: BCS now removes orphaned update entities from the running platform state and entity registry when an installed repository or blueprint is uninstalled.
### Documented
- Captured the verified project identity from the repository and README files: Bahmcloud Store is a Home Assistant custom integration intended to behave like a provider-neutral store for custom integrations, similar to HACS but broader than GitHub-only workflows.

134
.idea/start prompt.md generated
View File

@@ -1,134 +0,0 @@
## Bahmcloud Store Start Prompt
You are working in the `Bahmcloud Store` repository.
Project identity:
- This is a Home Assistant custom integration named `bahmcloud_store`.
- The product goal is a provider-neutral store for Home Assistant custom integrations, similar in spirit to HACS, but not limited to GitHub.
- Current real provider implementation is strongest for GitHub, GitLab, and Gitea-compatible providers. Unknown providers currently fall through the Gitea-style code paths, so do not assume every arbitrary Git provider works without verification.
- The long-term product direction is broader than integrations only: the store should evolve into a Home Assistant content store that can manage integrations, blueprints, templates, Lovelace designs, and additional future categories from multiple git providers.
Working rules:
- All project-facing work must be done in English only, regardless of the language the user speaks in chat. This applies to code comments, documentation, changelog entries, release notes, commit messages, PR text, UI text, issue text, and any other project artifacts unless the user explicitly requests a specific exception for repository content.
- Never push, commit, tag, or create a release without explicit user approval.
- Always document every change in `.idea/changes.md` with the current date and a detailed description of what changed, why it changed, and any verification done.
- If a new release is created, update `CHANGELOG.md` with all relevant changes since the last released version.
- Never mention prompts, AI tools, KI tools, or files inside the `.idea` folder in commit messages, push descriptions, release notes, or changelog entries.
- Use plain version numbers for future git tags and release names, without a leading `v` prefix. Example: `0.7.4`, not `v0.7.4`.
- Never mention internal workflow rules or repository-internal prompt/process decisions in any public-facing project communication. This includes commit messages, push descriptions, git tags, release names, release notes, changelog entries, and similar outward-facing texts.
- Prefer changing the real active code paths, not legacy or duplicate files.
- When docs and code disagree, trust the current code first, then update docs to match verified behavior.
- Do not remove user changes or perform destructive git actions unless the user explicitly asks for them.
Repository facts to keep in mind:
- Main integration path: `custom_components/bahmcloud_store/`
- Entry point: `__init__.py`
- Main runtime/service layer: `core.py`
- HTTP API layer: `views.py`
- Provider detection and remote version/readme fetching: `providers.py`
- Repo metadata loading (`bcs.yaml`, `hacs.yaml`, `hacs.json`): `metadata.py`
- Persistent storage: `storage.py`
- Update entities: `update.py`
- Repairs restart flow: `repairs.py`
- Frontend panel actually loaded by Home Assistant: `panel/panel.js`
- Panel registration uses `/api/bahmcloud_store_static/panel.js?v=109`; if frontend assets change in a real release, bump the version query to break HA browser cache.
Current architecture summary:
- Setup is config-entry only. YAML configuration is intentionally unsupported and only logs a warning if present.
- Only one integration instance is allowed.
- The official store index URL is fixed in `const.py`:
`https://git.bahmcloud.de/bahmcloud/ha_store/raw/branch/main/store.yaml`
- The store index format currently used by the active code is a YAML mapping with:
- `refresh_seconds`
- `repos`
- each repo entry contains at least `url`, optionally `name` and `category`
- Refresh flow:
- integration initializes storage and caches
- after `homeassistant_started`, a delayed refresh runs
- periodic refresh also runs on an interval from the store index
- refresh merges official index repos, optional HACS repos, and user custom repos
- cached enrichment is applied first, installed repos are refreshed eagerly, and the rest are enriched in the background
- Optional HACS support exists behind the `hacs_enabled` setting and currently loads the official HACS integration list from `data-v2.hacs.xyz`. That path is GitHub-only metadata, not a general provider abstraction.
- Install/update flow:
- picks a ref from selected version, latest version, or default branch
- downloads a ZIP from the provider-specific archive endpoint
- extracts the repository
- finds `custom_components`
- installs every integration folder inside `custom_components/*` that contains `manifest.json`
- stores the installed ref and manifest version in HA storage
- creates backups before overwriting existing domains
- marks restart required through Repairs
- Backup/restore behavior:
- backups live under `/config/.bcs_backups/<domain>/<timestamp>/`
- restore updates stored installed-version info so the UI and update entities reflect the restored state
- retention is currently 5 backups per domain
- Installed-state reconciliation exists:
- if folders are deleted from `/config/custom_components`, stale installed entries are removed from storage
- BCS also tries to self-reconcile as installed when it was deployed externally
Public/API contract to preserve unless intentionally changed:
- `GET /api/bcs`
- `POST /api/bcs?action=refresh`
- `GET /api/bcs/settings`
- `POST /api/bcs/settings`
- `GET /api/bcs/readme?repo_id=...`
- `GET /api/bcs/versions?repo_id=...`
- `GET /api/bcs/repo?repo_id=...`
- `POST /api/bcs/install?repo_id=...&version=...`
- `POST /api/bcs/update?repo_id=...&version=...`
- `POST /api/bcs/uninstall?repo_id=...`
- `GET /api/bcs/backups?repo_id=...`
- `POST /api/bcs/restore?repo_id=...&backup_id=...`
- `POST /api/bcs/restart`
- `DELETE /api/bcs/custom_repo?id=...`
Storage model:
- Home Assistant storage key: `bcs_store`
- Stored sections:
- `custom_repos`
- `installed_repos`
- `settings`
- `hacs_cache`
- `repo_cache`
Frontend/UI facts:
- The active HA panel script is `custom_components/bahmcloud_store/panel/panel.js`.
- The richer UI is implemented there: source filtering, HACS toggle, repo detail loading, version selection, backups restore modal, restart action, and history handling.
- `panel/app.js`, `panel/index.html`, and `panel/styles.css` look like older standalone or legacy panel assets. Treat them as secondary unless you confirm they are still used for a real path.
Code-analysis findings that should influence future work:
- `store.py` represents an older store implementation with a different data model (`packages`, `source_path`, older API routes). It does not appear to be the active runtime path for the current integration flow.
- `custom_repo_view.py` duplicates logic that already exists in `views.py` and looks legacy/unreferenced.
- README files describe the project direction correctly at a high level, but some wording overstates provider generality. The actual code is provider-neutral in intent, but concretely implemented around GitHub, GitLab, and Gitea-style endpoints.
- The end-user and full READMEs contain some stale or inconsistent details compared with the current UI and code. Verify behavior in source before using README text as specification.
- There are visible encoding/mojibake issues in some documentation and older UI assets. Preserve valid UTF-8 when editing.
Planned product expansion:
1. Add support for Home Assistant blueprints and install them directly into the correct Home Assistant blueprint location from the store.
2. Add templates and Lovelace designs to the store so they can be discovered and installed from the same UI.
3. Add support for more categories beyond integrations and design the architecture so category-specific install targets and validation rules are explicit.
Implications for future architecture:
- The current install pipeline is integration-centric because it assumes repository content under `custom_components/`.
- Future category support should move toward category-aware install strategies instead of one universal install path.
- Store metadata and index entries will likely need stronger category typing, install-target definitions, and validation rules per category.
Project constraints to respect in future edits:
- Keep async I/O non-blocking in Home Assistant.
- Avoid startup-heavy network work before HA is fully started.
- Preserve repo-cache and HACS-cache behavior unless intentionally redesigning refresh logic.
- Preserve backup-before-overwrite safety for install/update/restore flows.
- Preserve update-entity behavior for installed repos.
- Keep the integration UI-admin-only and config-entry-based.
Recommended workflow for future tasks:
1. Read `README.md`, `README_DEVELOPER.md`, and relevant source files.
2. Verify whether the requested change belongs in active code or in legacy files.
3. Implement the change in the active runtime path.
4. Update documentation if behavior changed.
5. Append a detailed dated entry to `.idea/changes.md`.
6. If and only if a release is being prepared with user approval, fold release-worthy changes into `CHANGELOG.md`.
Current release baseline:
- `manifest.json` version is `0.7.5`
- Latest documented release in `CHANGELOG.md` is `0.7.5` dated `2026-03-23`

32
custom_components/bahmcloud_store/update.py
View File

@@ -1,5 +1,6 @@
from __future__ import annotations
import inspect
import logging
from dataclasses import dataclass
from typing import Any
@@ -9,6 +10,7 @@ from homeassistant.core import HomeAssistant, callback
from homeassistant.helpers.dispatcher import async_dispatcher_connect
from homeassistant.helpers.entity_platform import AddEntitiesCallback
from homeassistant.helpers.entity import EntityCategory
from homeassistant.helpers import entity_registry as er
from .const import DOMAIN
from .core import SIGNAL_UPDATED, BCSCore
@@ -127,8 +129,36 @@ class BCSRepoUpdateEntity(UpdateEntity):
def _sync_entities(core: BCSCore, existing: dict[str, BCSRepoUpdateEntity], async_add_entities: AddEntitiesCallback) -> None:
"""Ensure there is one update entity per installed repo AND keep names in sync."""
installed_map = getattr(core, "_installed_cache", {}) or {}
installed_repo_ids = {repo_id for repo_id, data in installed_map.items() if isinstance(data, dict)}
new_entities: list[BCSRepoUpdateEntity] = []
stale_repo_ids = [repo_id for repo_id in list(existing) if repo_id not in installed_repo_ids]
if stale_repo_ids:
registry = er.async_get(core.hass)
for repo_id in stale_repo_ids:
ent = existing.pop(repo_id, None)
if not ent:
continue
try:
entity_id = getattr(ent, "entity_id", None)
if not entity_id:
for entry in registry.entities.values():
if getattr(entry, "platform", None) == DOMAIN and getattr(entry, "unique_id", None) == ent.unique_id:
entity_id = entry.entity_id
break
if entity_id:
registry.async_remove(entity_id)
except Exception as exc: # pylint: disable=broad-exception-caught
_LOGGER.debug("BCS could not remove stale update entity for %s: %s", repo_id, exc)
try:
result = ent.async_remove()
if inspect.isawaitable(result):
core.hass.async_create_task(result)
except Exception as exc: # pylint: disable=broad-exception-caught
_LOGGER.debug("BCS could not detach stale update entity for %s: %s", repo_id, exc)
for repo_id, data in installed_map.items():
if not isinstance(data, dict):
continue
@@ -178,4 +208,4 @@ async def async_setup_entry(
async_add_entities: AddEntitiesCallback,
) -> None:
"""Set up BCS update entities from a config entry."""
await async_setup_platform(hass, {}, async_add_entities, None)
await async_setup_platform(hass, {}, async_add_entities, None)