Home Assistant Best Practices

Core principle: Use native Home Assistant constructs wherever possible. Templates bypass validation, fail silently at runtime, and make debugging opaque.

Decision Workflow

Follow this sequence when creating any automation:

0. Gate: modifying existing config?

If your change affects entity IDs or cross-component references — renaming entities, replacing template sensors with helpers, converting device triggers, or restructuring automations — read [safe-refactoring](references/safe-refactoring.md) first. That reference covers impact analysis, device-sibling discovery, and post-change verification. Complete its workflow before proceeding.

Steps 1-5 below apply to new config or pattern evaluation.

1. Check for a purpose-specific, then generic native, trigger/condition

Since 2026.7 the default building blocks are purpose-specific triggers/conditions — <domain>.<name> keys (motion detected, battery low, door opened) with area/floor/label targets. Check for one that matches the intent first, then a generic native trigger/condition, and only then a template. See [automation-patterns #purpose-specific-triggers--conditions-default-since-20267](references/automation-patterns.md#purpose-specific-triggers--conditions-default-since-20267).

Common substitutions:

• List of individual sensor entities in a trigger → one purpose-specific trigger with an area/floor/label target:
• {{ states('x') | float > 25 }} → numeric_state condition with above: 25
• {{ isstate('x', 'on') and isstate('y', 'on') }} → condition: and with state conditions
• {{ now().hour >= 9 }} → condition: time with after: "09:00:00"
• waittemplate: "{{ isstate(...) }}" → waitfortrigger with state trigger (caveat: different behavior when state is already true — see [safe-refactoring #trigger-restructuring](references/safe-refactoring.md#trigger-restructuring))

2. Check for built-in helper or Template Helper

Before creating a template sensor, check [helper-selection](references/helper-selection.md).

Common substitutions:

• Sum/average multiple sensors → min_max integration
• Binary any-on/all-on logic → group helper
• Rate of change → derivative integration
• Cross threshold detection → threshold integration
• Consumption tracking → utility_meter helper

If no built-in helper fits, use a Template Helper — not YAML. Create it via the HA config flow (programmatically or in the UI: Settings → Devices & Services → Helpers → Create Helper → Template). A flow-created helper is UI-editable; a template: YAML entry needs a template.reload and is not.

Write template: YAML when the user asks for it, when neither path is available, or when the config needs a key the flow has no field for — trigger-based templates and attributes: are the common ones. Then use managed YAML editing ([yaml-only-integrations](references/yaml-only-integrations.md)), not a hand-edit.

3. Select correct automation mode

Default single mode is often wrong. See [automation-patterns #automation-modes](references/automation-patterns.md#automation-modes).

4. Use entityid over deviceid

device_id breaks when devices are re-added. See [device-control](references/device-control.md).

Exception: Zigbee2MQTT autodiscovered device triggers are acceptable.

5. For buttons and remotes

• **Any integration exposing an event.* entity:** Use event.received targeting that entity — a normal entity, so it can be renamed and survives a re-add when the integration keeps a stable unique ID
• ZHA: No event entities — use an event trigger with device_ieee (persistent)
• Z2M: Event entities are experimental and off by default — use a device trigger (autodiscovered) or mqtt trigger

See [device-control #buttonremote-patterns](references/device-control.md#buttonremote-patterns).

Critical Anti-Patterns

Reference Files

Read these when you need detailed information: