Le besoin de départ tenait dans un bouton : éteindre le bureau depuis Home Assistant. Il fallait demander l’arrêt de l’ordinateur, puis couper les prises concernées une fois la séquence suffisamment avancée.
Une temporisation pouvait donner une première solution. Elle imposait toutefois d’attendre une durée fixée à l’avance, sans beaucoup d’informations sur ce qui se passait réellement. J’ai voulu aller plus loin et construire un enchaînement réutilisable dans Node-RED.
Le premier essai SSH fonctionnait. Je pouvais envoyer une commande à l’ordinateur. Il restait à organiser la suite.
Retrouver des blocs et découvrir les messages
L’interface de Node-RED m’était visuellement familière : des blocs reliés entre eux, chacun chargé d’un traitement. Mon expérience des langages graphiques d’automatisme m’a aidé à lire cette représentation.
J’ai cependant dû prendre le temps de comprendre le modèle des messages. Une information entre dans un nœud, peut être transformée, puis orientée vers une autre branche. Le contenu transmis et le moment où il arrive déterminent ce qui se produit ensuite.
Les sous-flux ont demandé le même apprentissage. Un bloc de déclenchement placé au mauvais endroit ne fournissait pas le point d’entrée que j’imaginais. Il fallait distinguer le composant réutilisable et ce qui allait l’appeler, puis définir les informations qu’ils échangeaient.
Ces détails sont devenus plus clairs avec un usage concret sous les yeux. Je pouvais suivre la commande depuis le bouton et observer où la séquence cessait de faire ce que j’attendais.
Suivre les conséquences de la commande
L’arrêt de l’ordinateur met plusieurs événements en jeu. La commande doit être acceptée, le système doit engager son extinction, puis la prise pourra être coupée selon les conditions prévues.
J’ai associé la commande SSH à une surveillance par ping. Après la demande d’arrêt, le flux effectue plusieurs observations successives avant de poursuivre vers les prises, avec une attente supplémentaire. Une correction du test portant sur le code de retour a permis de remettre l’enchaînement dans le bon ordre.
Le bouton Home Assistant, la commande, la surveillance et la coupure ont alors fonctionné ensemble pour mon usage. La séquence donnait davantage d’informations que la seule attente d’un délai fixe.
L’indicateur conserve une limite importante : une absence de réponse réseau peut avoir plusieurs causes. Je ne peux pas en déduire, à elle seule, que tout arrêt s’est terminé proprement. Cet exemple m’a justement obligé à distinguer ce que j’observe de ce que j’en conclus. Le même soin s’applique aux retours d’état de nombreux équipements.
Construire un composant que je peux reprendre
Une fois le premier PC commandé, j’ai rendu le sous-flux plus générique. Le nom de la machine, son adresse, les paramètres SSH et les prises associées sont devenus des propriétés de l’instance. L’action demandée est transmise par le message.
Cette organisation évite de recopier toute la logique pour un autre ordinateur. Elle rend également les corrections plus faciles à suivre : le comportement commun reste regroupé, tandis que les informations propres à chaque cible sont identifiables.
Il a fallu examiner les fonctions moins visibles, notamment la remise à zéro de la surveillance et le traitement des résultats. Ce sont elles qui déterminent si le composant peut être relancé proprement et compris plusieurs mois après sa création.
J’y retrouve un intérêt que j’ai aussi pour la documentation : conserver les raisons et la structure d’un fonctionnement afin de pouvoir le reprendre sans tout redécouvrir.
Donner à chaque outil un rôle qui reste lisible
Node-RED a ensuite participé au projet de répartition des tâches du foyer. Les premières règles y ont été développées, avant que l’architecture évolue avec Grocy et une intégration dédiée dans Home Assistant.
Dans cette version, Node-RED déclenche le cycle ; le moteur de répartition est porté par l’intégration. Cette évolution me paraît cohérente avec le travail réalisé sur les données, les réalisations et leur conservation. Le rôle de chaque composant s’est précisé à mesure que le projet grandissait.
Vers un réveil par le réseau
La prochaine évolution que je souhaite tester est le Wake-on-LAN : réveiller les PC compatibles par un message envoyé sur le réseau, sans faire dépendre leur démarrage d’une prise connectée. Je pourrais alors réserver les prises aux équipements qui ont réellement besoin d’une coupure secteur.
Cela suppose que la machine reste alimentée et que le matériel comme le système autorisent ce réveil. Un PC dont la prise est coupée ne reçoit plus ce message. La commande d’arrêt propre via SSH garderait donc son rôle, avec une vérification du comportement réel après l’arrêt ou la veille.
Ce serait une évolution du sous-flux existant : conserver le bouton et les réglages réutilisables, puis adapter la séquence à ce que la machine sait déjà faire. Le réveil par le réseau reste à valider sur les PC concernés.