mirror of https://github.com/home-assistant/supervisor.git synced 2026-02-14 23:19:37 +00:00

Go to file

Stefan Agner b214d18f28 Cache Core config on startup and validate on Supervisor restart

Cache the Home Assistant Core configuration (components list) when Core
reaches RUNNING state in _block_till_run(), and clear it on stop or
before restart. This avoids repeated API/WebSocket calls to fetch the
config on every use.

The cached config is used in two places:
- Update verification: checks frontend component is loaded after update
  using cached config instead of a separate API call, with fallback to
  error state if cache is unavailable.
- Hardware events: checks USB component availability using cached config
  instead of a WebSocket round-trip on every device event.

Additionally, adds ensure_started() to HomeAssistantCore which validates
API readiness and populates cached state when Core is already running.
This is called on Supervisor restart to close a gap where Supervisor
had no health validation of Core and hardware events were silently
dropped because the config cache was never populated.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-02-13 17:31:01 +01:00

.devcontainer

Update Python to 3.13 (#5564 )

2025-01-21 11:57:30 +01:00

.github

Fix getting Supervisor IP address in testing (#6564 )

2026-02-13 08:12:19 +01:00

.vscode

Migrate to Ruff for lint and format (#4852 )

2024-02-05 11:37:39 -05:00

rootfs/etc

Avoid empty newlines in Supervisor logs (#4698 )

2023-11-13 20:12:17 +01:00

script

Add mypy to ci and precommit (#5969 )

2025-06-24 11:48:03 +02:00

supervisor

Cache Core config on startup and validate on Supervisor restart

2026-02-13 17:31:01 +01:00

tests

Cache Core config on startup and validate on Supervisor restart

2026-02-13 17:31:01 +01:00

wheels

Use unpublished local wheels during PR builds (#6374 )

2025-12-02 14:08:07 +01:00

.dockerignore

Use unpublished local wheels during PR builds (#6374 )

2025-12-02 14:08:07 +01:00

.gitignore

Use unpublished local wheels during PR builds (#6374 )

2025-12-02 14:08:07 +01:00

.hadolint.yaml

Revert "Revert "Update base images to 3.11-alpine3.18 (#4639 )" (#4646 )" (#4657 )

2023-11-02 11:29:15 +01:00

.pre-commit-config.yaml

Bump ruff from 0.14.2 to 0.14.3 (#6280 )

2025-10-31 11:42:39 -04:00

.vcnignore

Sign code folder (#2725 )

2021-03-16 15:47:40 +01:00

AGENTS.md

Add AGENTS.md symlink (#6237 )

2025-10-08 10:44:49 +02:00

build.yaml

Remove cosign from container (#6442 )

2025-12-20 08:56:36 -05:00

CLAUDE.md

Add GitHub Copilot/Claude instruction (#5986 )

2025-07-04 07:05:05 +02:00

codecov.yaml

Remove annotations (#2007 )

2020-09-03 16:36:09 +02:00

Dockerfile

Remove cosign from container (#6442 )

2025-12-20 08:56:36 -05:00

LICENSE

Update LICENSE

2020-07-29 14:45:37 +02:00

MANIFEST.in

Add Audio layer / PulseAudio (#1523 )

2020-02-25 18:37:06 +01:00

pyproject.toml

Reformat pyproject.toml using taplo (#6550 )

2026-02-11 09:56:00 +01:00

README.md

Add OHF logo to README (#5316 )

2024-09-30 18:42:08 +02:00

requirements_tests.txt

Bump ruff from 0.15.0 to 0.15.1 (#6565 )

2026-02-13 08:59:59 +01:00

requirements.txt

Bump cryptography from 46.0.4 to 46.0.5 (#6551 )

2026-02-11 00:18:13 -05:00

setup.py

Use version which is treated CalVer by AwesomeVersion (#5572 )

2025-01-24 09:59:50 +01:00

tox.ini

Migrate to Ruff for lint and format (#4852 )

2024-02-05 11:37:39 -05:00

README.md

Home Assistant Supervisor

First private cloud solution for home automation

Home Assistant (former Hass.io) is a container-based system for managing your Home Assistant Core installation and related applications. The system is controlled via Home Assistant which communicates with the Supervisor. The Supervisor provides an API to manage the installation. This includes changing network settings or installing and updating software.

Installation

Installation instructions can be found at https://home-assistant.io/getting-started.

Development

For small changes and bugfixes you can just follow this, but for significant changes open a RFC first. Development instructions can be found here.

Release

Releases are done in 3 stages (channels) with this structure:

Pull requests are merged to the main branch.
A new build is pushed to the dev stage.
Releases are published.
A new build is pushed to the beta stage.
The stable.json file is updated.
The build that was pushed to beta will now be pushed to stable.