Integration quality scale rules
The rules for each tier are defined down below and come with its own page with examples and more information.
🥉 Bronze
action-setup- Service actions are registered in async_setupappropriate-polling- If it's a polling integration, set an appropriate polling intervalbrands- Has branding assets available for the integrationcommon-modules- Place common patterns in common modulesconfig-flow-test-coverage- Full test coverage for the config flowconfig-flow- Integration needs to be able to be set up via the UIdependency-transparency- Dependency transparencydocs-actions- The documentation describes the provided service actions that can be useddocs-triggers- The documentation describes the provided triggers that can be useddocs-conditions- The documentation describes the provided conditions that can be useddocs-high-level-description- The documentation includes a high-level description of the integration brand, product, or servicedocs-installation-instructions- The documentation provides step-by-step installation instructions for the integration, including, if needed, prerequisitesdocs-removal-instructions- The documentation provides removal instructionsentity-event-setup- Entity events are subscribed in the correct lifecycle methodsentity-unique-id- Entities have a unique IDhas-entity-name- Entities use has_entity_name = Trueruntime-data- Use ConfigEntry.runtime_data to store runtime datatest-before-configure- Test a connection in the config flowtest-before-setup- Check during integration initialization if we are able to set it up correctlyunique-config-entry- Don't allow the same device or service to be able to be set up twice
🥈 Silver
action-exceptions- Service actions raise exceptions when encountering failuresconfig-entry-unloading- Support config entry unloadingdocs-configuration-parameters- The documentation describes all integration configuration optionsdocs-installation-parameters- The documentation describes all integration installation parametersentity-unavailable- Mark entity unavailable if appropriateintegration-owner- Has an integration ownerlog-when-unavailable- If internet/device/service is unavailable, log once when unavailable and once when back connectedparallel-updates- Number of parallel updates is specifiedreauthentication-flow- Reauthentication needs to be available via the UItest-coverage- Above 95% test coverage for all integration modules
🥇 Gold
devices- The integration creates devicesdiagnostics- Implements diagnosticsdiscovery-update-info- Integration uses discovery info to update network informationdiscovery- Devices can be discovereddocs-data-update- The documentation describes how data is updateddocs-examples- The documentation provides automation examples the user can use.docs-known-limitations- The documentation describes known limitations of the integration (not to be confused with bugs)docs-supported-devices- The documentation describes known supported / unsupported devicesdocs-supported-functions- The documentation describes the supported functionality, including entities, and platformsdocs-troubleshooting- The documentation provides troubleshooting informationdocs-use-cases- The documentation describes use cases to illustrate how this integration can be useddynamic-devices- Devices added after integration setupentity-category- Entities are assigned an appropriate EntityCategoryentity-device-class- Entities use device classes where possibleentity-disabled-by-default- Integration disables less popular (or noisy) entitiesentity-translations- Entities have translated namesexception-translations- Exception messages are translatableicon-translations- Entities implement icon translationsreconfiguration-flow- Integrations should have a reconfigure flowrepair-issues- Repair issues and repair flows are used when user intervention is neededstale-devices- Stale devices are removed
🏆 Platinum
async-dependency- Dependency is asyncinject-websession- The integration dependency supports passing in a websessionstrict-typing- Strict typing