Watchdog installation domotique

Bonjour,

Dans cette section, parler de tout et de rien … :slight_smile:

Je dois réaliser une installation domotique pour surveiller à distance une résidence secondaire, entre autre, assurer le mode hors gel et contrôler que tout va bien.

Cette résidence secondaire se trouve à 5h30 de route, donc, pas envie d’être obligé de faire un aller-retour, juste pour redémarrer en cas de problème.

Côté jeedom, un mini PC, N3700 + SSD128G et 8G ram , sous debian12 sans interface graphique avec un jeedom en 4.4, des scénarios simples: lecture de capteurs SNZB02, commande clims via infrarouge (avec le vieux plugin broadlink) et commande de radiateurs électriques si nécessaire. Sur le PC, il y a aussi frigate avec 1 ou 2 caméras IP max. Frigate n’écrit rien sur le SSD mais sur un synology, d’ailleurs tout à été configuré pour ne (pratiquement) rien écrire sur le SSD. (un maximum en ram disk)

Me vient alors l’idée de créer un watchdog, qui, en cas de défaut prolongé, redémarrerait le ou les équipements en défaut, et j pense à un hardware reset, c’est à dire une coupure d’alimentation pendant une minute.

Mon installation se composera du matériel suivant:

  • le mini PC N3700
  • un synology pour VPN et comme serveur de fichier pour frigate
  • un routeur asus RT-AX58
  • une box je ne sais pas encore quel fournisseur internet
  • une clé 4G TP‑Link MR200 + carte sim free en backup

Pour alimenter tout ce petit monde, je vois deux options:

Option1: Un UPS, connecté en USB au synology, et jeedom qui regarde le statu de l’UPS à l’aide du plugin NUT (déjà fait sur autre install, voir ci après), tous le matériel est alimenté par ses walls plugs respectifs.

Option2: Une alimentation 12V type industriel, avec petite batterie de backup et qui alimente tout ce beau monde directement en 12V

Pour la partie watchdog, je pense à un développement FW + HW à base d’un ESP32 avec ethernet câblé. Le jeedom doit lui parler régulièrement pour dire que tout va bien, si il ne le fait pas, au bout d’une heure par exemple (je peux me permettre une panne d’une heure), alors un watchdog HW coupe brutalement l’alimentation de tout le bazard pendant une minute.

Je peux éventuellement avoir des watchdog séparés pour redémarrer séparément des équipements, surtout si c’est une alimentation en 12V et pas via les wall plugs.

Je ne pense pas que redémarrer un synology soit nécessaire, ca ne se plante jamais ce truc …

Bref, suis-je dans un délire complet ?

D’autres solutions existent elle ?

Est-ce fou de vouloir fiabiliser une installation jeedom, qui n’a pas vocation d’être 100% fiable ?

Qu’en pensez-vous, je suis prêt à tout lire, tous les retours sont bon à prendre :slight_smile:

Bonjour,

Je vais prêcher pour ma paroisse, bien qu’il y ait d’autres solutions… :wink:
Voir ici mon module JWS qui assure ce type de monitoring.

A adapter au besoin…

1 « J'aime »

Chez moi j’ai une prise connecté en wifi commandée par ewelink qui peut donc être coupée et rétablie à distance si c’est jeedom qui plante mais j’ai une box atlas, une prise commandée en zigbee par jeedom pour éteindre et rallumer la box si c’est elle qui est plantée, jeedom observe en permanence la connexion internet par le plugin network et fait un reboot de la box si pas de réseau pendant 5 minutes. Pour les équipements que je souhaite contrôler je surveille en permanence s’ils remontent bien les infos par un virtuel qui récupére le lastCommunication puis fait un time_diff avec l’heure actuelle, c’est gerable aussi par scénario.

Je pense que le plus gênant c’est la perte de communication avec jeedom, que ce soit à cause de la box ou de jeedom lui-même. Une fois ces 2 cas traités le reste se fait directement depuis jeedom sans trop de problème.

1 « J'aime »

Je vois que je ne suis pas le seul à avoir pensé à sécuriser une installation domotique et je m’en réjouis.

Bravo, c’est une superbe réalisation, ce me parle et en plus c’est très bien documenté !

Je vois qu’il y a eu pas mal d’évolution, preuve que le sujet à bien été bien suivit.

L’expérience que j’ai de mon côté avec mon installation actuelle à mon habitation principale , c’est qu’à ce jour jeedom est très stable si on y chipote pas et qu’on le laisse vivre sa vie tranquillement, ce qui me pose parfois des soucis c’est mon “vieux” routeur RT AC68U que je dois redémarrer de temps à autre. Un routeur plus récents type RT-AX58U semble réputé plus fiable mais j’aimerais avoir une surveillance du routeur et de l’accès externe.

Ha oui, il y a le DNS OVH de jeedom qui nous a souvent causé des soucis ces derniers temps, mais avec le ddns du synology j’ai aussi une solution de backup. J’ai aussi installé sur le synology open VPN, donc en cas de plantage, même si ce n’est pas automatique, je pourrais toujours me connecter via le VPN sur le périphérique de surveillance et essayer de redémarrer un truc à distance.

Quoi qu’il en soit, c’est une très belle base, même si j’aurais peut être envie de l’adapter ou le compléter.

Mais c’est à réfléchir car le mieux est parfois l’ennemi du bien :slight_smile:

Encore merci pour les infos et bravo pour cette réalisation.

Ca c’est effectivement une solution assez simple. A la maison j’ai aussi mis une prise wifi sur l’alimentation du PC Jeedom mais je n’avais pas pensé à mettre une prise zigbee pour redémarrer la box / le routeur. C’est peut être finalement une solution suffisamment fiable, et dans mon cas pour éviter des déclenchements intempestifs, je peux même allonger le délai car je peux perdre la connexion pendant quelques heures ce n’est pas un gros problème.

De rien, si cela peut au moins servir d’inspiration…

En ce qui concerne le routeur, j’ai un Asus RT-AX58U justement. Je traite les problèmes éventuels de connexion réseau (plantage du Wifi ou des ports Ethernet du routeur, ou de la box (Freebox Ultra)) de cette façon :

A partir de Jeedom, je teste la connectivité Internet avec un ping des serveurs DNS de Google (8.8.8.8) via la connexion Wifi.
→ Si celle-ci est OK, tout va bien, RAS. Je relance le scénario toutes les 15’.
Si cette connexion est KO, alors on teste de la même façon la connectivité Internet mais via la connexion Ethernet cette fois.
→ Si celle-ci est OK (le DNS Google réponds), j’effectue un RESET uniquement de la partie Wifi du routeur.
Sinon, il n’y a donc plus aucun accès réseau (LAN et WAN) et j’effectue un RESET complet du routeur, et ce jusqu’à deux fois consécutivement.

Enfin, s’il y a toujours échec des ping en Wifi et en Ethernet après deux tentatives de réinitialisation du routeur, je tente en dernier recours de réinitialiser la Freebox (là aussi au maximum deux fois). Le scénario est relancé après 5 minutes pour vérifier le retour (ou non) de la connexion Internet.
S’il n’y a pas de retour de la connexion, il y a donc un autre problème matériel (routeur HS, box HS, panne d’Internet plus ou moins généralisé) qui demandera soit d’attendre, soit une intervention physique.
J’utilise le plugin freebox (qui me permet de la redémarrer si besoin) et pour le routeur, j’utilise via le plugin SSH les commandes service restart_wireless pour redémarrer le Wifi, ou reboot pour le redémarrer complétement…

Et ça marche plutôt pas mal, tous les problèmes sont ainsi résolus automatiquement…

1 « J'aime »

Merci pour toutes ces infos très intéressantes

C’est surtout, pour mon cas, que j’ai eu à subir ces 2 types de panne (jeedom planté et une autre fois la box plantée) et quand tu n’es pas chez toi tu croises les doigts pour qu’il ne se passe rien en attendant que tu rentres…

1 « J'aime »

Mauvaise idée, la 4.4 pose des problèmes de nos jours…
Et sous debian12 mieux vaut partir sur >4.5 donc 4.6.

Sinon je n’ai jamais eu fortement ce besoin mais

  • soit un jump host qui ne fait rien d’autre peut aider en cas de problème
  • soit un kvm/ip (mais bien sécuriser)

Évidemment l’hypothèse de base c’est qu’il y a toujours du réseau

1 « J'aime »

Pour tester l’accès externe, je suis en train d’expérimenter un service gratuit (à confirmer …) sur https://healthchecks.io Ca à l’air pas mal fait, le jeedom doit pinger le service, et le service peut envoyer une notification par email mais aussi à jeedom via Webhook. A voir, pour le moment je suis en pleine expérimentation.

Oups, je me suis trompé, je suis bien en 4.6.1, mais merci de m’avoir prévenu.

Je viens de me faire un watchdog avec un Shelly Plus 1 et un plugin que je n’ai pas encore publié.

Le principe:

  • Le shelly a un contact sec que j’utilise pour couper l’alimentation de mon raspberry (On pourrai aussi couper une alim 240V).
  • Le plugin charge un programme javascript dans le shelly avec quelques paramètres dont la valeur est définie via la config de l’équipement dans le plugin.
  • Le programme charger dans le Shely initialise et compteur a une valeur initiale (900 par exemple) puis décrémente ce compteur de 1 chaque seconde.
  • Si le compteur atteint la valeur 0, le contact est ouvert quelques seconde puis refermer.
  • Le plugin envoi régulièrement une commande au shelly pour réinitialiser le compteur à sa valeur initiale.
  • Un interrupteur est branché sur le port SW du Shelly. Lorsque cet interrupteur est fermé (position maintenance), le javascript ne décrémente plus le compteur et une infos est envoyée au plugin pour que l’on sache que le watchdog est désactivé.

S’il y a des intéressés, je peux publier le plugin mais je vais d’abord faire un test avec un Shelly 1 Gen4

EDIT
la commande peut être envoyée via un cron du plugin ou via un scénario schdulé régulièrement. Chez moi, j’ai un scénario qui envoie une commande vers un module zigbee et vérifie que la commande a effectivement été exécutée.

5 « J'aime »

Bonjour,

Oui, je vois le principe.
C’est donc complémentaire à ce que je propose puisque ce service n’offre que l’envoi d’une notification (sans autre action) dans le cas ultime où toutes les actions effectuées (redémarrages via JWS ou via un scénario de surveillance par Jeedom) auraient échouées.
En effet, dans ce cas précis l’accès à Internet est donc impossible, et donc aucune notification pour prévenir ne peut être envoyée (sauf s’il y a une autre alternative d’accès via un réseau mobile par exemple).

En soi, ça ne résout pas vraiment le problème en fait (mais au moins, on est au courant…).

Bonjour,

Effectivement, après essai, si tout va bien, le service n’envoie rien et pas moyen de l’interroger. Donc ce n’est utile que pour l’envoi d’un email, et l’utilité de l’email est quand même très limitée car la connexion internet n’est nécessaire que pour pouvoir se connecter à jeedom, et dans ce cas, quand on essayera de se connecter, on se rendra bien compte du problème. Pour être honnête, je me suis un peu planté, je n’aurais même pas du perdre mon temps à tester le service :wink:

C’est effectivement jeedom qui doit tester la connexion internet et générer le redémarrage de la box et ou du routeur pour tenter de récupérer la connexion.

Il va falloir que je dorme là dessus, côté hardware, j’aimerais bien sécuriser les alimentations, la multiplication de ces petits wall plugs bon marchés ne m’inspire pas confiance: si une alim tombe en panne, inutile d’essayer de redémarrer l’équipement. Je préfèrerais une alimentation générale en 12V (j’espère que tout est bien en 12V), redondée, avec une commande et une protection pour chaque sortie: pas question de faire tout tomber si un équipement présente un défaut sur son alimentation. J’espère juste ne pas tomber dans l’excès avec mes délires d’électronicien, car c’est parfois les solutions les plus simples les plus fiables :wink:

1 « J'aime »

Bonjour. C’est une très bonne solution de watchdog, et on pourrait imaginer un shelly pour redémarrer Jeedom et un autre pour redémarrer la partie connexion internet (avec des timings différents).

Je ne connais pas bien les shelly, une fois le programme chargé, il reste en mémoire non volatile ?

Oui, je pense que ce plugin pourrait intéresser pas mal de monde :slight_smile:

OK, Je vais publier le plugin. Mais il faut d’abord:

  • Que je prépare une doc
  • Que j’adapte et test le plugin avec un Shelly 1 Gen4 ( j’en ai reçu un aujourd’hui ).

Si tout va bien, je publie une Beta la semaine prochaine.

1 « J'aime »

Merci, et no stress, on patientera :slight_smile:

Hello,

Voici déjà un début de doc pour la préparation du Shelly

1 « J'aime »

Bonjour,
Au vu de la doc, j’ai une question pour ma part (je m’en doutais un peu vu les photos, mais le schémas de câblage me le confirme…) :
Comment se passe la négociation entre la box Jeedom et l’alimentation du coup, vu que les ports CC1 et CC2 ne sont visiblement pas câblés ?

En effet, sauf erreur de ma part, par défaut avec ce protocole USB-C, en cas d’absence de négociation l’alimentation n’est sensée délivrer qu’un maximum de 1A, ce qui est largement insuffisant pour n’importe quelle box Jeedom.

Bonne question,
Dans mon cas, le problème ne se pose pas car je suis alimenter via une alim 5V (réglée a un peu plus que 5V).

Je pense prochainement remplacer cette alim par une alim officielle Raspberry (oas pour des problèmes électrique mais pratique). A ma connaissance, cette alim officiel n’a pas de négociation de puissance. Il ne devrai pas y avoir de soucis.

Par contre, je ne sais pas ce qui se passera avec un chargeur USB standard. Au pire, il faudra couper le 220V qui alimente le chargeur.

A mon avis, il n’y aura pas de soucis avec un PI4 car il ne négocie pas sont alimentation.

C’est un peu différent avec le PI5 qui tente de voir si l’alim peu fournir 5A. Si l’alim répond « non » ou si la négociation n’est pas possible, le Pi5 limite la puissance qu’il peut fournie sur ses port USB et se limite à une conso de 3A

Perso, je n’ai pas de PI5 mais deux PI4. Je vais bientôt pouvoir faire un test avec l’alim Officielle