Centralisation de l'arrêt et du redémarrage de raspberry pi sans WOL

Hello,

Petite problématique de la semaine, HA sur pi5 ondulé avec remontée d’info via nut, comment stopper proprement une série de pi ondulés (sur un autre onduleur sans remontée d’infos ) et surtout comment les redémarrer sans WOL (tous les pi sont alimentés via un HAT POE) le tout sur un vieil enterasys 48ports POE, j’ai un peu galéré après avoir tenté un accès ssh non fiable à priori, mais je pense avoir trouvé la soluce.
connexion du pi5 via un câble série/usb sur le port com du switch, j’ai aussi tenté snmp mais ça me semble plus complexe ( et je ne maîtrise pas )

Mise en place d’un système d’extinction propre via mqtt

1

script python pour éteindre une ou plusieurs machine
#!/usr/bin/env python3
import paho.mqtt.client as mqtt
import subprocess
import sys

# Configuration MQTT - ADAPTEZ À VOTRE CONFIG
MQTT_BROKER = "xxx"  # IP de votre Pi5 Home Assistant
MQTT_PORT = 1883
MQTT_USER = "xxx"  # Si vous avez un user/pass MQTT
MQTT_PASS = "xxx"   # Supprimez les lignes user/pass si pas d'auth
MQTT_TOPIC = "homeassistant/halt/+"

def on_connect(client, userdata, flags, rc):
    print(f"Connecté MQTT : {rc}")
    if rc == 0:
        print(f"Souscription au topic: {MQTT_TOPIC}")
        client.subscribe(MQTT_TOPIC)
        print("Souscription effectuée")
    else:
        print(f"Erreur de connexion: {rc}")

def on_subscribe(client, userdata, mid, granted_qos):
    print(f"Souscription confirmée: {mid}, QoS: {granted_qos}")

def on_message(client, userdata, msg):
    topic = msg.topic
    message = msg.payload.decode()
    
    print(f"=== MESSAGE REÇU ===")
    print(f"Topic: {topic}")
    print(f"Payload: {message}")
    print(f"==================")
    
    hostname = subprocess.check_output(['hostname']).decode().strip()
    print(f"Mon hostname: {hostname}")
    
    if topic == f"homeassistant/halt/{hostname}" or topic == "homeassistant/halt/all":
        print(f"✅ Condition OK pour {hostname}")
        if message == "halt":
            print("🔥 Ordre d'extinction reçu, mise en halt...")
            subprocess.run(['sudo', 'halt'])  # HALT RÉEL ACTIVÉ !
            # print("HALT serait exécuté maintenant !")  # Commenté
        else:
            print(f"❌ Message non reconnu: {message}")
    else:
        print(f"❌ Topic non reconnu pour {hostname}")

client = mqtt.Client()
if MQTT_USER and MQTT_PASS and MQTT_USER != "votre_user_mqtt":
    client.username_pw_set(MQTT_USER, MQTT_PASS)
    print("Authentification MQTT activée")
else:
    print("Pas d'authentification MQTT")

client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message

try:
    print(f"Connexion à {MQTT_BROKER}:{MQTT_PORT}")
    client.connect(MQTT_BROKER, MQTT_PORT, 60)
    print("En attente de messages...")
    client.loop_forever()
except Exception as e:
    print(f"Erreur MQTT: {e}")

il a fallu ensuite
trouver les commandes d’allumage et d’extinction des ports
Extinction > set port inlinepower ge.1.20 admin off
Allumage > set port inlinepower ge.1.20 admin auto

On poursuit avec un petit réglage de terminal et SSH

on installe un pyserial dans un environnement virtuel et on test que ça fonctionne

python3 -m venv venv

source venv/bin/activate

pip install pyserial

echo "import serial; print('OK:',serial.__version__)" > test.py

python test.py

on cherche le bon port pour le câble…

dmesg | grep tty

ici [ 2.242847] usb 3-2.6: pl2303 converter now attached to ttyUSB0c

et avec un petit script python tjs en cours d’écriture, on se connecte au switch, environnement virtuel lancé, srcript pyton lancé en manuel pour le moment

et testé sur un port pour vérifier que ça fonctionne

python3 /config/scripts/test_serial.py on puis python3 /config/scripts/test_serial.py off

et enfin en interface graphique

c’est testé, ça fonctionne j’uploaderai les videos sur youtube

j’en suis là pour ce soir, en l’état je peux éteindre n’importe quel pi proprement potentiellement, éteindre le port poe ensuite, puis le rallumer et le pi redémarre normalement.
Reste à gérer en fonction des remontées d’onduleur, mais ça sera vraiment facile à côté

je vais faire tremper mon cerveau dans les glaçons :wink:

cdt

2 « J'aime »

Re,

POE off https://www.youtube.com/shorts/ezmkQAMYB38

POE on https://www.youtube.com/shorts/J0DBYSaZj-4

cdt

Hello…

Alors par défaut le PI démarre au retour du courant … Donc quasi 50% réglé.
Pour le reste, un client nut par pi (via le lan)… Et tu utilises le signal pour qu’il s’éteigne …ou qu’il annule l’extinction au retour du courant.
J’avais donné un exemple sur proxmox + nut mais le principe est le même

Hello,

faudra que je regarde à trouver ça, si tu retrouves le lien ça m’intéresse, :wink:

cdt

1 « J'aime »

Re,

Bon je garde sous le coude, ça me semble tout aussi « compliqué » à mettre en place, et j’y vois un soucis auquel j’ai pensé en dormant, impossible de gérer l’arrêt des cams tant qu’à faire (si c’est possible) pour évite de corrompre les cartes SD dans celles-ci ( bien que je n’ai jamais eu de soucis à ce niveau). De toute façon je veux avoir une gestion des ports POE :slight_smile:

Mais merci quand même, si j’ai à y revenir :wink:

cdt

Coté cam j’ai pas connaissance de trucs qui peuvent s’arrêter. Mais bon ça ne me semble pas effectivement être le truc le plus critique.

Et coté POE pour les PI, tu es en dehors du système/OS, donc ça sera impossible de faire autrement que couper brutalement. Tu vas forcément devoir, par un moyen ou un autre envoyer une info comme quoi le courant VA couper… Dans ton cas, toute la gestion des VM qui est dans l’exemple ne sert à rien, donc niveau config, c’est light normalement

Re,

Oui, et c’est pour ça que j’ai commencé par chercher un moyen de faire un halt sur les pis concernés ( le script en haut du 1er message ) là je lance la commande mais je peux halt le pi proprement.

Ensuite l’idée c’est onduleur à 30% HA envoie l’info halt aux pi concernés, attends, envoie l’info de coupure des ports POE des pi concernés.

si le secteur revient, et onduleur à 40% HA redémarre les ports POE, les pi redémarrent sinon ça reste sur off et à 20% HA s’éteint.

globalement c’est un script python par pi, et une automation + 1 script python dur HA

enfin c’est l’idée :smiley: mais je n’en suis pas encore là
cdt

Le souci du script c’est que ça t’oblige à avoir une session shell/ssh par PI … à traiter les codes retours etc… Faisable mais à mon avis bien plus compliqué que de configurer le client nut (globalement il fait un shutdown ou l’annule). Chose à faire sur chaque PI évidement mais comme tu dois de toute façon mettre l’env python sur tous les PI aussi c’est pas pire.
Et l’autre avantage c’est que c’est indépendant d’HA : moins de couche = plus de fiabilité

Re,

De toute façon toutes les idées sont bonnes à prendre, j’ai détaillé ce que j’avais fait surtout pour pouvoir y revenir et surtout parce que c’était frais dans mon esprit

cdt

Re,

Bon après les 872p de doc du switch j’ai creusé un peu pour les 361p de l’api http de reolink pour les cams.

j’arrive bien à faire un reboot

par contre il prend bien la commande de shutdown mais n’éteint pas la cam… dommage

cdt