- Home
- Skills
- Home Assistant
- Core
- Integrations
integrations_skill
- Python
85k
GitHub Stars
3
Bundled Files
3 weeks ago
Catalog Refreshed
2 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill home-assistant/core --skill integrations- platform-diagnostics.md628 B
- platform-repairs.md1.9 KB
- SKILL.md26.7 KB
Overview
This skill provides a practical, implementation-first reference for building, testing, and reviewing Home Assistant integrations. It condenses required project layout, config flow patterns, coordinator usage, manifest and quality-scale expectations, and runtime best practices into actionable checks. Use it as your primary guide when authoring or auditing an integration.
How this skill works
The skill inspects integration structure, manifest contents, quality_scale.yaml status, and common module patterns (coordinator, entity, config_flow). It validates expected entry points (async_setup_entry / async_unload_entry), config flow behavior, discovery and reauth flows, and recommended async patterns such as websession injection. It also highlights where to store runtime data and how to register services and platforms correctly.
When to use it
- Creating a new Home Assistant integration from scratch
- Reviewing or auditing an existing integration for quality-scale compliance
- Implementing config flows, reauthentication, discovery, or device management
- Refactoring synchronous code into asyncio-friendly patterns
- Writing or validating integration tests and platform files
Best practices
- Follow the standard integration layout and include manifest.json, strings.json, and quality_scale.yaml
- Use DataUpdateCoordinator for polling, pass config_entry into the coordinator, and raise UpdateFailed on API issues
- Always implement UI config_flow (set config_flow: true), validate inputs, set unique IDs and prevent duplicates
- Store connection-critical info in ConfigEntry.data; use ConfigEntry.options for non-critical settings
- Register services in async_setup and validate entry existence/state before acting
- Avoid exposing polling intervals to users; determine update_interval programmatically and set sensible minimums
Example use cases
- Add a new sensor platform with coordinator-based polling and entity base class
- Audit an integration to move from Bronze to Silver by adding entity unavailability and parallel updates
- Implement reauthentication and reconfigure flows for a cloud account-based integration
- Migrate HTTP clients to async websession injection for Platinum-level async behavior
- Create zeroconf/ssdp/ble discovery handlers and update dynamic IPs on discovery
FAQ
Check manifest.json for quality_scale key and the integration's quality_scale.yaml. Bronze rules always apply; higher-tier rules apply only if the integration targets that tier or higher.
Where should non-persistent runtime objects be stored?
Store non-persistent runtime data on the config entry (entry.runtime_data) so it’s available across setup/unload and not persisted to disk.