Bonjour,
Je tourne sur Debian 12 avec HA Supervised et Node Red installé à coté (donc ce n’est pas un add-on)
Je cherche à lancer Node Red seulement après que HA ait fini de s’initialiser totalement (ses 16 containers). Surtout après un reboot.
En effet le container InfluxDB doit être « UP » ainsi que HA car ils sont utilisés dans mes flows NR.
Actuellement ils démarrent chacun de leur coté en parallèle et de ce fait NR présente des erreurs car HA et InfluxDB ne sont pas encore prêt lorsque lui est déjà Up.
Ma config:
Home Assistant 2023.9.1 / Supervisor 2023.08.3 / Node Red 3.0.2 / Debian 12 / Docker version 24.0.6
Avez-vous des idées sur la bonne méthode pour lancer NR en toute fin d’initialisation ?
Salut,
Ordonner les containers ‹ hors HA › c’est assez facile avec docker-compose depends_on:est là pour ça.
Par contre, faire ça avec HA supervised (attendre HA puis lancer NR), pas certain que ce soit possible
Et accessoirement il faudrait aussi gérer l’arrêt de HA… Sinon ça sert à rien NR reste allumé et à la même erreur que quand HA démarre
Bonjour @Pulpy-Luke , quelle rapidité dans ta réponse, merci.
Alors en effet ce n’est pas un ordonnancement des containers qui m’intéresse mais bien le fait d’attendre que HA signal, voir lance lui même NR via un shell linux, un webhook, un autre moyen.
Je ne suis pas suffisamment connaisseur de HA pour évoquer toutes les possibilités.
Peut être une entité qui se met à « true » lorsque tout et fini d’initialiser et ensuite une automatisation qui lancerait NR ?
Ça cogite, mais je ne veux pas me lancer dans un truc impossible ou pas assez réfléchi, d’où l’idée de voir avec la communauté HA ce quelle en pense.
OK.
Ce que tu décris là, c’est plus ou moins le fonctionnent d’un addon … Mais tu as délibérément fait un container à part. Pourquoi ?
Non NR n’est pas dans un container, il est installé via npm (bare bone). C’est une gros logiciel qui gère des onduleurs et des batteries.
Je ne l’utilise pas sous docker car j’ai des accès aux ports séries et il y avait pas mal de déboires il y a 2-3 ans avec la remontées de données dans les containers. Donc j’étais parti « full install » plus simple à gérer.
En fait je suis en train de faire un nouvel interface à mon logiciel, cette fois depuis HA qui est d’une puissance sans égal pour faire une foule de tâches que je n’ai plus besoin d’écrire dans NR.
Tu peux toujours lancer une action de type command_line dans HA (systemctl start xxxxxx)
Par contre, ça me semble une architecture bien compliquée. Perso si la gestion des onduleurs est critique, je m’assurerai que c’est le moins risqué possible pour que ça démarre.
Et comme dit plus haut, tu as aussi un souci avec l’arrêt/relance de HA…
mon soft est un complément a des situations ou les logiciels propriétaires sont bien « léger ». Ils ont de plus une grosse tendance à passer par la Chine pour fonctionner.
Il ne doit pas être critique en effet. C’est juste un plus pour gérer son installation solaire mais il n’est pas essentiel. Les onduleurs sont censés se débrouiller tout seul.
Et oui en effet, il faut aussi gérer l’arrêt, bien que ce ne soit pas trop gênant si ce n’est pas fait.
En fait je tente de synchroniser les 2 outils, ça évite simplement des messages d’erreurs internes tant que NR n’arrive pas à joindre HA. Mais le moteur lui continue de tourner dans NR, HA étant une interface.
Une interface qui a un gros potentiel d’où mon souhait de l’utiliser
… Oups, j’oubliais, oui le command_line me semble approprié, reste à savoir à quel moment le lancer
Edit1: je vois qu’il existe une commande nommée Shell command qui pourrait semble-t-il faire l’affaire. Mais à nouveau quel est le trigger qui va déclencher ce service au bon moment ?
Est-ce que HA dit quelque part dans une entité lorsqu’il a fini de se lancer complètement ?
Attendre que HA indique la fin du démarrage :
Faire la liste de tous les addons, et vérifir qu’ils sont lancés en te basant sur ça
puis lancer ton script.
A mon sens, ça produit les même erreurs au démarrage et à l’arrêt, si NR sait s’y reconnecter et si c’est juste pour filtrer les logs, ça me semble lourd.
Top, merci pour les pointeurs sur les infos.
Je vais potasser tout ceci.
Tu as raison pour la gestion de l’arrêt. En effet actuellement tout fonctionne mais je trouvais dommage d’avoir des messages d’erreurs (cachés) pendant un certain laps de temps. C’est plus par souci de qualité que je pensais à synchroniser les 2 logiciels.
J’apprécie tes remarques qui sont pertinentes et le mini « brainstorming » entamé.