Bonjour, plus j’avance dans l’utilisation de Home assistant et plus mes scripts et automatisations deviennent complexes. Il n’est pas rare que lors d’une évolution (nouvelle version d’une intégration, changement d’un capteur, …) certaines automatisations ne fonctionnent plus. Pour s’en apercevoir c’est très difficile et c’est au hasard qu’on finit par se dire « tiens c’est curieux, ca aurait du … ». C’est souvent lors d’une démo à quelqu’un d’ailleurs.
Donc pour palier à ça, je me demande si il n’existerait pas un framework de test comme tous les frameworks des développeurs par exemple à base de mock, ingestion d’évents, … qui permettrait (sans déclencher les vrais devices) de tester les automatisations, scripts …
L’idée est bonne, mais je n’ai pas connaissance d’un tel mécanisme.
Il y a toujours moyen de s’approcher de ça avec un environnement de test mais c’est limité (à ne pas voir la totalité des appareils, ou bien à risquer de déclencher pour de vrai la sirène d’intrusion) donc pas très efficace.
Par contre, pour être tout à fait honnête et pour avoir parfois ces outils au boulot, c’est quand même ultra chronophage : à chaque modification, il faut vérifier les scénarios. A chaque nouvelle fonction, il faut en créer un de plus…
Pour ma part, avant de faire une mise à jour je lis scrupuleusement le changelog afin de voir si une notion y figurant correspond à mon installation. Comme ça je sais ‹ presque › ou ça risque de casser et je peux vérifier juste après…
+1 idem ici ! et si ce sont des installations en prod chez des clients, les mises à jour sont toutes désactivées aussi bien HA lui-même que l’os, ainsi que les add-on ! Quand ça marche il ne faut pas toucher pour le plaisir Les mises à jour se font uniquement quand le système n’est pas utilisé, que l’on a validé que la mise à jour en question ne va pas provoquer une cata quelque part, et avoir le temps une fois la mise à jour faite de retester rapidement l’ensemble de l’installation
Oui je fais ça aussi (lecture des changes logs) notamment les breaking changes. La plupart du temps ça suffit pour les maj HA.
Ca n’empêche qu’il m’est arrivé plus d’une fois (en 9 mois) d’avoir un script ou une automatisation qui ne fonctionnait plus et de s’en apercevoir longtemps après.
Bref, je sens qu’il n’y a pas de framework de tests digne de ce nom pour HA.
Ca n’empêche qu’il m’est arrivé plus d’une fois (en 9 mois) d’avoir un script ou une automatisation qui ne fonctionnait plus et de s’en apercevoir longtemps après.
Pour éviter ça, j’intègre désormais systématiquement un sensor de contrôle sur chaque automatisation ou sous-système critique (par exemple un HeartBeat sur NodeRED) pour être alerté quand il y a quelque chose qui ne fonctionne plus.
Et j’utilise NodeRED plutôt que les automatisations dont la gestion me semble justement « ingérable ».
Dernier exemple en date, je mets à jour LocalTuya en V4.1.0 (je venais de 4.0.2) et là régulièrement je perds quasiment toutes mes entités LocalTuya. Elles ne se connectent plus, j’ai des erreurs de type Timeout dans les logs alors via Smart Life ca marche bien.
D’ailleurs si quelqu’un sait comment re-installer la version précédente d’une intégration, je prends.
Je mets régulièrement à jour mon HA, de même que je le fais évoluer et il m’est arrivé de casser certains composants, alors une seule règle, le backup automatique journalier, quand ça casse, je restaure tout sauf les bases MariaDB et InfluxDB. Et au cas où le problème daterait de plusieurs jours, je garde 7 jours de backups + 3 derniers lundi, ce qui fait 10 backups en ligne avec la possibilité de remonter jusqu’à il y a un mois.
J’utilise auto_backup ici:
Et je le surveille comme ça dans configuration.yaml :
template:
- sensor:
- name: "Alerte Technique"
state: >-
{% set alerte = 'Vert' %}
{% set state = state_attr('sensor.auto_backup', 'last_failure') %}
{% if not state == None %}
{% set alerte = 'Jaune' %}
{% endif %}
...
{{ alerte }}
icon: >-
{% if is_state('sensor.alerte_technique', 'Vert') %}
mdi:alarm-light-off-outline
{% elif is_state('sensor.alerte_technique', 'Jaune') %}
mdi:alarm-light-outline
{% elif is_state('sensor.alerte_technique', 'Orange') %}
mdi:alarm-light-outline
{% elif is_state('sensor.alerte_technique', 'Rouge') %}
mdi:alarm-light-outline
{% else %}
mdi:exclamation
{% endif %}
attributes:
...
Backup: >-
{% set state = state_attr('sensor.auto_backup', 'last_failure') %}
{% if not state == None %}
{% set s = 'Erreur' %}
{% else %}
{% set s = 'OK' %}
{% endif %}
{{ s }}
intercept les requetes envoyés au device pour les envoyer sur des mocks,
vérifie que l’état des mock device est celui espéré
La difficulté elle est dans la modification du coeur pour ne pas envoyer au vrai device mais router les appels vers un mock. Je pense que ca touche le coeur.
Le reste c’est quasiment un script ou un AppDaemon
Donc à chaque mise à jour, je relance mes tests auto. Si c’est ko → rollback direct. Ca pourrait même être intégré à la procédure de mise à jour mais c’est plus cher
Et pour ton mock, il faut aussi avoir du matériel (ou une émulation) derrière (sinon tu n’as pas la notion de retour)… De quoi bien s’occuper (en plus du reste) à maintenir en condition de tests sans pour autant garantir à 100% les anomalies…
Les mises à jour se font uniquement quand le système n’est pas utilisé, que l’on a validé que la mise à jour en question ne va pas provoquer une cata quelque part, et avoir le temps une fois la mise à jour faite de retester rapidement l’ensemble de l’installation 
