Bonjour,
Ce matin, j’ai eu la surprise (quoique…) d’avoir mon système Jeedom, embarqué sur un RPi4B avec un disque SSD, figé et qui ne répondait plus. 
Je pense que c’est lié au disque SSD que je l’ai installé il y a quelques mois, car ce n’est pas la première fois et depuis cela se produit régulièrement, à peu près 1x par mois.
La méthode la plus efficace pour résoudre ce petit souci est plutôt simple : un arrêt/marche. Alors oui, c’est abrupt, mais terriblement efficace et tellement simple… 
D’autant plus que même un RESET ne fonctionne pas toujours dans ce cas. Et Debian, comme tous les systèmes Linux, supporte plutôt bien des A/M sauvages (même si ce n’est pas recommandé et à ne pas reproduire trop souvent en raison essentiellement du risque de corruption des données en BDD, etc…).
Mais ce n’est efficace que s’il y a quelqu’un physiquement à la maison pour débrancher la prise ! Et on perd bien sûr un peu d’historique au passage mais bon, ce n’est pas le point le plus critique.
Du coup je me suis dit que ce serait pas mal d’avoir un système indépendant (et de concept simple) d’auto-surveillance de l’état d’un système domotique pour agir le cas échéant, et éviter de se retrouver dans la situation où la maison va perdre une partie de ses automatismes, plus ou moins sensibles et pendant plus ou moins longtemps, sans que l’on puisse faire quelque chose.
J’ai lu quelques sujets où certains envisageaient de faire tourner un second Jeedom en parallèle, prêt à reprendre le lead en cas de pépin sur le système principal. Le gros avantage reste que ça fonctionnerait quel que soit l’origine du problème : logiciel (bug/plantage/…) ou matériel (panne).
Mais si c’est dans le domaine du réalisable (à voir), ça me semble quand même un peu compliqué à mettre en place.
Pour faire plus simple, et se prémunir d’un problème uniquement d’origine logicielle, j’ai pensé concevoir un système de surveillance en partant sur ces principes :
- un module ESP32 envoie un ping récurent vers le RPi4 supportant Jeedom, toutes les 30 secondes par exemple (pour ne pas trop saturer le RPi avec ces requêtes purement techniques),
- s’il n’y a pas de réponse au ping à un moment donné (mais après deux ou trois récurrences pour éviter les faux-positifs), l’ESP va actionner un relais ou une prise connectée (je ferai avec les moyens du bord…) via un des ses GPIO pour effectuer un arrêt/marche physique du RPi4 branché dessus, et donc le relancer.
Du coup je me suis lancé dans une petite XP ce matin en codant un petit bout de programme tout simple avec un ESP32, et ma foi cela semble très bien fonctionner.
Mais avant de passer à l’étape finale pour intégrer proprement tout ça, je voulais savoir si certains d’entre vous utilisait déjà ce type de dispositif, et si je ne passe pas à côté de certains aspects auxquels je n’aurai pas pensé, ou d’autres éléments à prendre en compte, ou même si le principe de pinger en permanence le RPi est une bonne méthode.
Qu’en pensez-vous ?
Si ce petit projet intéresse quelques personnes, je suis bien sur disposé à rédiger un petit tuto à ce sujet une fois que ce sera du concret…
Merci pour vos retours !
Ce serait dommage, alors que je suis sur le point de passer en prod sur un RPi5 prêt à l’emploi avec son SSD NMVe intégré, sur lequel j’ai installé Jeedom qui n’attends que cela. La seule chose qui me retient encore, c’est la compatibilité incertaine de certains plugins qui me sont indispensables avec DB12 (et deux ou trois petits trucs…).
)