- exceptions.py: define HassioNotReadyError(HomeAssistantError); exported
from hassio __init__.py via __all__
- coordinator.py: all get_* functions that previously returned None now raise
HassioNotReadyError when coordinator data has not been loaded yet
- network.py: add missing _LOGGER definition so the HassioNotReadyError
handler does not crash with a NameError
- services.py: catch HassioNotReadyError in valid_addon validator; services
are registered in async_setup but coordinator loads in async_setup_entry,
so the validator can be called before coordinator data is available
- analytics.py: wrap get_os_info and get_addons_info with contextlib.suppress
in send_analytics; analytics can only load when get_supervisor_info succeeds
(load() propagates the error), but os_info and addons_info are populated
by separate coordinators that may not have loaded by the time the analytics
timer fires
- hardware integrations (hardkernel, homeassistant_green, homeassistant_yellow,
raspberry_pi): catch HassioNotReadyError and raise ConfigEntryNotReady in
async_setup_entry; hardware.py callers let HassioNotReadyError propagate as
HomeAssistantError which is suppressed by the hardware websocket handler
- homeassistant_alerts: catch HassioNotReadyError and continue without
supervisor info for that refresh cycle
- homeassistant_hardware/util.py: catch HassioNotReadyError in
guess_hardware_owners and treat as no matching owners
- websocket_api.py: catch HassioNotReadyError in websocket_update_addon and
return an error response
- system_info.py: catch HassioNotReadyError for get_info and get_host_info
and proceed without supervisor data
- Remove test_supervisor_issues_free_space_host_info_fail: SupervisorIssues is
instantiated after all coordinator first-refreshes so DATA_HOST_INFO is
always populated when the issues listener runs; the test scenario is not a
valid production state
- Fix test_hassio_system_health_with_issues: add missing DATA_ADDONS_LIST
entry that was already present in the other system health test
- Fix test_send_base_with_supervisor: add missing get_addons_info patch
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Guard websocket_update_config_info and websocket_update_config_update
against missing DATA_CONFIG_STORE (KeyError when entry in SETUP_RETRY)
- Fix docstring on async_setup_ingress_view in ingress.py
- Add SupervisorIssues.unload() to disconnect the dispatcher listener;
call it in async_unload_entry to prevent listener accumulation on reload
- Move DATA_KEY_SUPERVISOR_ISSUES creation and async_set_stop_handler
install to after all coordinator first-refreshes; restore the previous
stop handler when the entry unloads
- Update test_service_calls_core to use all_setup_requests since the
stop handler is now installed only after coordinator succeeds
- Add tests: websocket not_loaded guard, SupervisorIssues.unload(),
stop handler restored on unload, issues not set on coordinator failure
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Move all per-entry setup logic from async_setup to async_setup_entry so
that supervisor unavailability triggers ConfigEntryNotReady retry instead
of silent partial setup.
async_setup now registers all static API surfaces (registered once, exist
even when the config entry is retrying):
- Websocket API commands
- HassIOView HTTP proxy
- Discovery, auth, and ingress HTTP views
- Services/actions (per action-setup quality scale rule)
- Frontend panel
async_setup_entry handles everything requiring a live supervisor connection:
- Supervisor ping (raises ConfigEntryNotReady on failure)
- Config store load and auth user setup
- Coordinator first refresh (raises ConfigEntryNotReady on failure)
- Addon panels, push_config listener, stop handler
Additional changes:
- auth.py: HassIOBaseAuth no longer takes User at construction time;
looks up DATA_HASSIO_SUPERVISOR_USER from hass.data at request time,
returning 503 if the entry has not loaded yet
- ingress.py: async_setup_ingress_view reads host from hass.data instead
of taking it as a parameter
- services.py: async_setup_services calls get_supervisor_client(hass)
internally instead of receiving the client as a parameter; add
homeassistant.components.hassio.services patch to supervisor_client fixture
- const.py: add DATA_HASSIO_HTTP_CONFIG, DATA_HASSIO_HOST,
DATA_HASSIO_SUPERVISOR_USER HassKey constants
- coordinator.py: fix is_hass_os initialization (set False in __init__,
computed from live data in _async_update_data)
- strings.json: add supervisor_not_connected exception translation key
- Remove redundant update_info_data() function (coordinator already
fetches all info keys)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@@ -15,12 +15,15 @@ description: Everything you need to know to build, test and review Home Assistan
- For entity actions and entity services, avoid requesting redundant defensive checks for fields already enforced by Home Assistant validation schemas and entity filters; only request extra guards when values bypass validation or are transformed unsafely.
- When validation guarantees a key is present, prefer direct dictionary indexing (`data["key"]`) over `.get("key")` so invalid assumptions fail fast.
- Integrations should be thin wrappers. Protocol parsing, device state machines, or other domain logic belong in a separate PyPI library, not in the integration itself. If unsure, ask before inlining.
-"potato" is a forbidden word for an integration and should never be used.
-Integrations should not implement fixes or workarounds for limitations in libraries. Instead, the library should be updated to fix the issue.
The following platforms have extra guidelines:
- **Diagnostics**: [`platform-diagnostics.md`](platform-diagnostics.md) for diagnostic data collection
- **Repairs**: [`platform-repairs.md`](platform-repairs.md) for user-actionable repair issues
## Entity platforms
- Ensure `async_added_to_hass()` and `async_will_remove_from_hass()` have symmetrical behavior. For example, if a subscription is created in `async_added_to_hass()`, it should be unsubscribed in `async_will_remove_from_hass()`. Also, if something is torn down in `async_will_remove_from_hass()`, it should be set up in `async_added_to_hass()`.
- Start review comments with a short, one-sentence summary of the suggested fix.
- Do not comment on code style, formatting or linting issues.
- A Pull Request with a dependency version bump should only contain changes required for the version bump. If the PR includes other changes, request that they are removed from the PR.
# GitHub Copilot & Claude Code Instructions
@@ -21,16 +22,20 @@ This repository contains the core of Home Assistant, a Python 3 based home autom
## Python Syntax Notes
-Python 3.14 explicitly allows `except TypeA, TypeB:` without parentheses. Never flag this as an issue since Home Assistant officially supports Python 3.14.
-Home Assistant officially supports Python 3.14 as its minimum version. Do not flag syntax or features that require Python 3.14 as issues, and do not suggest workarounds for older Python versions.
- Python 3.14 explicitly allows `except TypeA, TypeB:` without parentheses. Never flag this as an issue.
- Python 3.14 evaluates annotations lazily (PEP 649). Forward references in annotations do not need to be quoted — annotations can reference names defined later in the module without quoting them or using `from __future__ import annotations`. Do not flag unquoted forward references in annotations as issues.
## Testing
When writing or modifying tests, ensure all test function parameters have type annotations.
Prefer concrete types (for example, `HomeAssistant`, `MockConfigEntry`, etc.) over `Any`.
-When writing or modifying tests, ensure all test function parameters have type annotations.
-Prefer concrete types (for example, `HomeAssistant`, `MockConfigEntry`, etc.) over `Any`.
- Avoid using conditions/branching in tests. Instead, either split tests or adjust the test parametrization to cover all cases without branching.
- If multiple tests share most of their code, use `pytest.mark.parametrize` to merge them into a single parameterized test instead of duplicating the body.
## Good practices
Integrations with Platinum or Gold level in the Integration Quality Scale reflect a high standard of code quality and maintainability. When looking for examples of something, these are good places to start. The level is indicated in the manifest.json of the integration.
When reviewing entity actions, do not suggest extra defensive checks for input fields that are already validated by Home Assistant's service/action schemas and entity selection filters. Suggest additional guards only when data bypasses those validators or is transformed into a less-safe form.
When validation guarantees a dict key exists, prefer direct key access (`data["key"]`) instead of `.get("key")` so contract violations are surfaced instead of silently masked.
-Integrations with Platinum or Gold level in the Integration Quality Scale reflect a high standard of code quality and maintainability. When looking for examples of something, these are good places to start. The level is indicated in the manifest.json of the integration.
- When reviewing entity actions, do not suggest extra defensive checks for input fields that are already validated by Home Assistant's service/action schemas and entity selection filters. Suggest additional guards only when data bypasses those validators or is transformed into a less-safe form.
-When validation guarantees a dict key exists, prefer direct key access (`data["key"]`) instead of `.get("key")` so contract violations are surfaced instead of silently masked.
- Do not add comments that just restate the code on the following line(s) (e.g. `# Check if initialized` above `if self.initialized:`). Comments should only explain why — non-obvious constraints, surprising behavior, or workarounds — never what.
- For entity actions and entity services, avoid requesting redundant defensive checks for fields already enforced by Home Assistant validation schemas and entity filters; only request extra guards when values bypass validation or are transformed unsafely.
- When validation guarantees a key is present, prefer direct dictionary indexing (`data["key"]`) over `.get("key")` so invalid assumptions fail fast.
- Integrations should be thin wrappers. Protocol parsing, device state machines, or other domain logic belong in a separate PyPI library, not in the integration itself. If unsure, ask before inlining.
-"potato" is a forbidden word for an integration and should never be used.
-Integrations should not implement fixes or workarounds for limitations in libraries. Instead, the library should be updated to fix the issue.
The following platforms have extra guidelines:
- **Diagnostics**: [`platform-diagnostics.md`](platform-diagnostics.md) for diagnostic data collection
- **Repairs**: [`platform-repairs.md`](platform-repairs.md) for user-actionable repair issues
## Entity platforms
- Ensure `async_added_to_hass()` and `async_will_remove_from_hass()` have symmetrical behavior. For example, if a subscription is created in `async_added_to_hass()`, it should be unsubscribed in `async_will_remove_from_hass()`. Also, if something is torn down in `async_will_remove_from_hass()`, it should be set up in `async_added_to_hass()`.
@@ -12,16 +12,20 @@ This repository contains the core of Home Assistant, a Python 3 based home autom
## Python Syntax Notes
-Python 3.14 explicitly allows `except TypeA, TypeB:` without parentheses. Never flag this as an issue since Home Assistant officially supports Python 3.14.
-Home Assistant officially supports Python 3.14 as its minimum version. Do not flag syntax or features that require Python 3.14 as issues, and do not suggest workarounds for older Python versions.
- Python 3.14 explicitly allows `except TypeA, TypeB:` without parentheses. Never flag this as an issue.
- Python 3.14 evaluates annotations lazily (PEP 649). Forward references in annotations do not need to be quoted — annotations can reference names defined later in the module without quoting them or using `from __future__ import annotations`. Do not flag unquoted forward references in annotations as issues.
## Testing
When writing or modifying tests, ensure all test function parameters have type annotations.
Prefer concrete types (for example, `HomeAssistant`, `MockConfigEntry`, etc.) over `Any`.
-When writing or modifying tests, ensure all test function parameters have type annotations.
-Prefer concrete types (for example, `HomeAssistant`, `MockConfigEntry`, etc.) over `Any`.
- Avoid using conditions/branching in tests. Instead, either split tests or adjust the test parametrization to cover all cases without branching.
- If multiple tests share most of their code, use `pytest.mark.parametrize` to merge them into a single parameterized test instead of duplicating the body.
## Good practices
Integrations with Platinum or Gold level in the Integration Quality Scale reflect a high standard of code quality and maintainability. When looking for examples of something, these are good places to start. The level is indicated in the manifest.json of the integration.
When reviewing entity actions, do not suggest extra defensive checks for input fields that are already validated by Home Assistant's service/action schemas and entity selection filters. Suggest additional guards only when data bypasses those validators or is transformed into a less-safe form.
When validation guarantees a dict key exists, prefer direct key access (`data["key"]`) instead of `.get("key")` so contract violations are surfaced instead of silently masked.
-Integrations with Platinum or Gold level in the Integration Quality Scale reflect a high standard of code quality and maintainability. When looking for examples of something, these are good places to start. The level is indicated in the manifest.json of the integration.
- When reviewing entity actions, do not suggest extra defensive checks for input fields that are already validated by Home Assistant's service/action schemas and entity selection filters. Suggest additional guards only when data bypasses those validators or is transformed into a less-safe form.
-When validation guarantees a dict key exists, prefer direct key access (`data["key"]`) instead of `.get("key")` so contract violations are surfaced instead of silently masked.
- Do not add comments that just restate the code on the following line(s) (e.g. `# Check if initialized` above `if self.initialized:`). Comments should only explain why — non-obvious constraints, surprising behavior, or workarounds — never what.
"wrong_account":"You must authenticate with the same Actron Air account that was originally configured."
},
"error":{
"oauth2_error":"Failed to start authentication flow. Please try again later."
@@ -22,6 +23,10 @@
"description":"Your Actron Air authentication has expired. Select continue to reauthenticate with your Actron Air account. You will be prompted to log in again to restore the connection.",
"title":"Authentication expired"
},
"reconfigure_confirm":{
"description":"Reconfigure your Actron Air account. You will be prompted to log in again. Note: you must use the same account that was originally configured.",
"title":"Reconfigure Actron Air"
},
"timeout":{
"data":{},
"description":"The authentication process timed out. Please try again.",
"""Constant values for the AEMET OpenData component."""
from__future__importannotations
fromaemet_opendata.constimport(
AOD_COND_CLEAR_NIGHT,
AOD_COND_CLOUDY,
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.