Mes Tips Home Assistant

Bienvenue dans ma collection de tips et automatisations pour Home Assistant.

Ces guides documentent les solutions que j'ai trouvées après avoir galéré sur des cas concrets : intégrations capricieuses, comportements inattendus, patterns fiables à réutiliser. L'objectif est de garder une trace des approches qui fonctionnent — et pourquoi elles fonctionnent.

---

Automatisation Apple TV

Note : L'intégration Apple TV dans Home Assistant peut être capricieuse, notamment pour l'allumage. Les séquences ci-dessous ont été affinées pour être les plus fiables possible, même si quelques ratés subsistent à l'allumage.

Allumage

Un rechargement de l'entrée de config est nécessaire avant d'envoyer la commande turn_on, sinon l'entité peut être dans un état non réactif. Un délai de 8 secondes laisse le temps à l'intégration de se réinitialiser.

sequence:
  - action: homeassistant.reload_config_entry
    metadata: {}
    data: {}
    target:
      entity_id: remote.apple_tv_du_salon
  - delay:
      hours: 0
      minutes: 0
      seconds: 8
      milliseconds: 0
  - action: media_player.turn_on
    continue_on_error: true
    metadata: {}
    data: {}
    target:
      entity_id: media_player.apple_tv_du_salon
continue_on_error: true

Pourquoi ce pattern ?

• reload_config_entry force la reconnexion de l'intégration Apple TV, ce qui évite les états "fantômes" où l'entité est présente mais ne répond plus.
• Le délai de 8 secondes est nécessaire pour que l'intégration soit pleinement opérationnelle avant d'envoyer la commande.
• continue_on_error: true sur le turn_on et au niveau de la séquence évite de bloquer l'automatisation parente si l'Apple TV met du temps à répondre.

Extinction

Un test d'état est ajouté en amont pour éviter une erreur si l'Apple TV est déjà éteinte, en veille ou indisponible.

if:
  - condition: not
    conditions:
      - condition: state
        entity_id: media_player.apple_tv_du_salon
        state:
          - "off"
          - standby
          - unavailable
then:
  - action: remote.send_command
    target:
      entity_id: remote.apple_tv_du_salon
    data:
      command: suspend
    continue_on_error: true
  - action: media_player.turn_off
    target:
      entity_id: media_player.apple_tv_du_salon
    data: {}

Pourquoi ce pattern ?

• La condition not sur les états off, standby et unavailable protège contre les erreurs d'exécution quand l'Apple TV est déjà inactive.
• La commande suspend via remote.send_command envoie le signal de mise en veille au niveau IR/protocole Apple TV, ce qui est plus fiable que turn_off seul.
• Le media_player.turn_off en complément s'assure que HA met bien à jour l'état de l'entité côté intégration.
• continue_on_error: true sur le suspend évite un blocage si la télécommande virtuelle ne répond pas.

---

Points d'attention lors de la création de blueprints

Deux limitations importantes rencontrées lors du développement de blueprints.

Les triggers ne peuvent pas utiliser les variables de la section variables:

Les variables déclarées dans variables: ne sont pas encore évaluées au moment où les triggers sont définis. Il faut donc utiliser directement les !input dans les triggers, ou des entités statiques.

# ❌ Ne fonctionne pas
variables:
  ma_entite: !input entity_input

trigger:
  - platform: state
    entity_id: "{{ ma_entite }}"  # variables: pas encore disponible ici

# ✅ Correct
trigger:
  - platform: state
    entity_id: !input entity_input  # utiliser !input directement

L'accès aux inputs dans les templates Jinja2

Dans les templates Jinja2 des actions, les !input doivent être capturés au préalable dans la section variables: pour être accessibles. Un accès direct à !input dans un template imbriqué peut échouer selon le contexte d'évaluation.

# ❌ Peut échouer selon le contexte
actions:
  - condition: template
    value_template: "{{ !input entity_input == 'on' }}"

# ✅ Correct : capturer d'abord dans variables:
variables:
  mon_input: !input entity_input

actions:
  - condition: template
    value_template: "{{ mon_input == 'on' }}"