Intro

Dans mon infrastructure domotique, j’ai plusieurs conteneurs LXC qui tournent en continu (Node-RED, ESPHome/VSCode, Frigate…). Je voulais un moyen simple de savoir, depuis mon tableau de bord Home Assistant, si un service critique était bien actif, sans avoir à me connecter en SSH à chaque fois. Voici comment j’ai mis ça en place à base de cron, mosquitto_pub et Node-RED.

Le principe

Chaque LXC surveillé exécute un petit script bash toutes les minutes (ou toutes les 5 minutes selon les cas), qui :

• vérifie l’état du service concerné (systemctl is-active)
• relève sa version installée et compare avec la dernière version disponible (registre npm par exemple)
• calcule l’utilisation CPU et RAM du conteneur
• publie le tout en MQTT, avec retenue (-r), sous un topic dédié

Le script (exemple pour Node-RED)

#!/bin/bash
set -u
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

MQTT_HOST="192.168.0.37"
MQTT_USER="remy"
MQTT_PASS="********"
BASE="monitor/nodered_lxc"

pub() {
  mosquitto_pub -h "$MQTT_HOST" -u "$MQTT_USER" -P "$MQTT_PASS" -r -t "$1" -m "$2"
}

# ... détection du service, version, CPU, RAM ...

pub "$BASE/status"   "$RUNNING"
pub "$BASE/version"  "$CURRENT"
pub "$BASE/latest"   "$LATEST"
pub "$BASE/cpu_pct"  "$CPU_PCT"
pub "$BASE/mem_pct"  "$MEM_PCT"

Il est déclenché par une tâche cron root dans le conteneur :

*/1 * * * * /usr/local/bin/nodered_version_mqtt.sh >/dev/null 2>&1

Flux des informations

Le cron déclenche le script qui publie sur le broker MQTT de Home Assistant ; Node-RED relaie ensuite ces topics vers le broker central, d’où ils sont lus par les capteurs du dashboard.

Le pont Node-RED

J’ai un broker MQTT dédié à Home Assistant (192.168.0.37) et un broker central (192.168.0.204) qui agrège plusieurs sources. Un flow Node-RED (« Bridge MQTT Prefix ») écoute monitor/# sur le broker HA et republie tel quel vers le broker central, ce qui me permet de centraliser toutes mes métriques d’infrastructure à un seul endroit.

Côté Home Assistant

Des capteurs MQTT lisent simplement ces topics :

mqtt:
  sensor:
    - name: "Node-RED LXC Version"
      unique_id: nodered_lxc_version
      state_topic: "monitor/nodered_lxc/version"
      icon: mdi:package-variant

    - name: "Node-RED LXC Version la plus récente"
      unique_id: nodered_lxc_latest
      state_topic: "monitor/nodered_lxc/latest"
      icon: mdi:cloud-download

    - name: "Node-RED LXC CPU"
      unique_id: nodered_lxc_cpu_pct
      state_topic: "monitor/nodered_lxc/cpu_pct"
      unit_of_measurement: "%"
      state_class: measurement
      device_class: power_factor
      icon: mdi:cpu-64-bit

    - name: "Node-RED LXC Mémoire"
      unique_id: nodered_lxc_mem_pct
      state_topic: "monitor/nodered_lxc/mem_pct"
      unit_of_measurement: "%"
      state_class: measurement
      icon: mdi:memory

  binary_sensor:
    - name: "Node-RED LXC En cours d'exécution"
      unique_id: nodered_lxc_running
      state_topic: "monitor/nodered_lxc/status"
      payload_on: "running"
      payload_off: "stopped"
      device_class: running
      
template:
  - binary_sensor:
      - name: "Node-RED LXC Mise à jour disponible"
        unique_id: nodered_lxc_update
        device_class: update
        state: >
          {% set cur = states('sensor.node_red_lxc_version') %}
          {% set lat = states('sensor.node_red_lxc_version_la_plus_recente') %}
          {{ cur not in ['unknown','unavailable','none',''] and
             lat not in ['unknown','unavailable','none',''] and
             cur != lat }}      

Résultat : un petit tableau de bord qui me montre en un coup d’œil la santé de chaque LXC surveillé.

Le binary_sensor indique si une une mise à jour est à réaliser.

Piège rencontré : les messages retained et les scripts orphelins

Un de mes LXC (à l’origine dédié à ESPHome) a depuis été reconverti en serveur VSCode. Le script esphome_version_mqtt.sh continuait pourtant de tourner dessus, cherchant un service esphome qui n’existait plus — d’où un statut « stopped » fantôme affiché en permanence dans mon dashboard.

À retenir : quand on republie avec l’option -r (retained), le broker garde le dernier message même si plus personne ne le republie. Penser à purger ces topics explicitement après suppression d’un script :

for t in version latest cpu_pct mem_pct status; do
  mosquitto_pub -h 192.168.0.37 -u remy -P "********" -t "monitor/esphome_lxc/$t" -r -n
done

(Le flag -n publie un message vide, ce qui supprime le retained côté broker.)

Article rédigé avec l’assistance de Claude AI (Anthropic) à partir de mes données et retours d’expérience.