Bonjour,
Merci à tous pour vos idées et cette discussion intéressante.
En effet, la résilience de Linux et de Jeedom permet normalement de pouvoir s’affranchir sans trop de souci d’un système de surveillance quelconque, et une simple prise connectée commandée via une appli peut largement faire l’affaire, c’est vrai…
Néanmoins j’ai un peu travaillé sur le sujet (j’aime bien automatiser ce genre de chose), et je suis arrivé à concevoir un système de récupération automatique de Jeedom, permettant de pallier à plusieurs types d’avaries possibles situées sur les niveaux applicatif et/ou réseau.
1.- Quoi : perte du réseau local en raison d’une avarie électrique restreinte à la box jeedom, et/ou du routeur ou de la box qui gère le réseau, ou parce que Jeedom ou le routeur/box est planté.
Qui : box Jeedom, routeur, box internet.
Comment : détection de cette perte de réseau local si pas de réponse de la box Jeedom à des ping IP.
2.- Quoi : perte du brocker MQTT activé sur Jeedom (ce qui suppose bien entendu qu’un brocker MQTT soit activé, comme Mosquito par exemple qui est installé par défaut avec MQTT Manager ou autre). C’est important car si l’ensemble des équipements du réseau Zigbee est connecté via z2m, cela implique la perte complète du réseau Zigbee.
Qui : brocker MQTT
Comment : détection par la perte de la connexion MQTT (plus de ‹ handshake ›).
3.- Quoi : plus de réponses de Jeedom à une sollicitation MQTT (idem, cela suppose donc l’installation et l’activation préalable d’un brocker MQTT).
Qui : Jeedom, qui est donc peut-être planté, gelé, ou fortement ralenti / dégradé.
Comment : détection par une absence de réponses ‹ Pong › à une sollicitation par message MQTT ‹ Ping › vers Jeedom.
Le principe est que si après cinq tentatives de reconnexion après la détection de l’un de ces trois cas de figure, l’ESP32 n’a toujours pas de retour, celui-ci va initier un arrêt/marche de la box Jeedom via un relais connecté à l’un de ces GPIO, en générant un créneau monostable de 500ms.
Et si ca ne fonctionne toujours pas après deux cycles d’arrêt / marche, on s’arrête là (dans ce cas, si un A/M ne résoud toujours pas le problème, il est inutile d’insister lourdement…).
Et ca donne ça dans mes simulations :
1.- Cas où la box Jeedom est stoppée/HS (et donc plus de réponses aux pings) :
Après quelques minutes, l’ESP provoque l’arrêt / marche.
2.- Cas où le brocker (Mosquito) est stoppé ou planté :
Après le time-out, l’ESP provoque l’arrêt / marche.
3.- Jeedom ne réponds plus en MQTT sur le topic dédié (normalement « pong » sur le topic Rx)
Après un time-out un peu plus long cette fois, un peu plus de 5’ (le temps de dépiler les msg MQTT), l’ESP provoque l’arrêt / marche.
Le code de l’ESP32 est écrit C++ (avec l’IDE Arduino ou VSC), ce qui est plus simple et plus souple que de passer par ESPEasy par exemple (je trouve…).
Les délais prévus dans le code laissent le temps au système soit de se ‹ rattraper aux dernières branches › avant l’exécution de la sentence, soit de redémarrer proprement une fois celle-ci exécutée, sans saturer non plus la box Jeedom avec des interrogations permanentes.
Reste à voir maintenant ce que ça donnerait une fois en place en situation réelle, et ça, c’est l’étape suivante… 
).