Si le plugin est arrêté, ça le stop et le redémarre 60s plus tard, avec message télégramme à l’appui.
Ça devrait bien m’aider, car ce plugin passe son temps à ce stopper.
Pour Déconz, j’ai utilisé le heartbeat, de ce que j’en est vu, si le plugin ne communique avec aucun de ces équipements, celui ci le détecte et en cochant la case de redémarrage du démon, cela doit normalement ce faire automatiquement.
Par contre comme savoir quand il y à eu un redémarrage ?
La tu pars sur la mise en place de solution… On s’éloigne.
Je te conseille de créer d’autres posts avec des besoins précis et expliqués.
En fonction des plugins et autre partie concernée en mettant les bons tags
Je vois ce que tu veux dire car j’ai laissé le mien sans m’occuper pendant les travaux. La TIC arrêtée depuis plus d’un mois, le heartbeat n’a pas relancé le daemon. L’onduleur qui ne communique plus en USB depuis X temps. Le RFplayer qui ne peut plus commander les actionneurs mais qui reçoit encore les émetteurs.
Concernant les plugins, tous ceux qui sont reliés à un cloud vont foirer à un moment : ça s’appelle l’obsolescence connectée… Rien à faire à part pouvoir s’en passer.
Oui, il y a de l’entretien. Si on ne fait rien, ça se dégrade petit à petit. Rien que pour les piles, avec une 50aine de module, toutes les 2 semaines, il y a une pile à changer !
Pour la gestion d’une piscine ou d’un portail, il faut automate dédié où Jeedom ne fait que communiquer avec eux et les surveiller.
Il faut tout tout surveiller.
Par défaut, il n’y a pas beaucoup de choses mises en place par le core et les plugins pour détecter les anomalies.
Prenons comme exemple le Zigbee. Il faut pouvoir surveiller chaque maillon de la chaîne :
hub usb branché ou pas ?
clé Conbee connectée ou pas ?
est-ce qu’une autre clé usb peut entraîner une déconnexion de la clé Conbee ?
est-ce que le plugin tourne ?
après reconnexion de la clé usb, est-ce qu’elle reprend le bon port USB et est-ce que le plugin redémarre correctement tout seul (le heartbeat ne fonctionne pas toujours bien en fonction des plugins) ?
est-ce que le plugin remonte les anomalies d’un module qui ne répond plus ?
est-ce que lorsqu’on module déconne, le reste du réseau est fonctionnel ?
Je pense que ça ne devrait pas être à l’utilisateur de gérer ça.
Côté utilisateur, il faut mettre des alertes sur les valeurs des commandes.
mettre une alerte si une commande n’a pas changé de valeur depuis X temps (un ouvrant qui ne change pas d’état depuis une semaine, hop alerte).
mettre une alerte haute et basse sur une valeur numérique (puissance du Linky à 0 VA) et/ou en fonction du temps (pas de conso d’eau depuis 24h, ou trop de conso d’eau en 1h)
Bref, pour « blinder » Jeedom, tu sabotes volontairement ta domotique (ou mieux, tu demandes à quelqu’un d’autre de le faire) et tu regardes ce qui se passe. Il faut que Jeedom détecte et corrige un max de truc. Tu peux t’inspirer du singe de NetflixChaos Monkey — Wikipédia
Conclusion, on est content d’avoir mis en place une domotique fonctionnelle, mais en réalité, on ne fait jamais une gestion d’erreur très poussée. Au moindre grain sable, souvent, tout part en cacahuète.
Pour ma part, j’ai quelques plugins qui ne sont pas à jour, notamment rfxcom qui est encore sur la vieille version (j’ai testé la nouvelle, mais j’ai la flemme de refaire sur la prod). Mais il tourne toujours sans problème !
Aucun problème non plus avec homebridge.
Pour la gestion des erreurs, c’est une question qu’il faut se poser à la mise en place. Et oui, c’est à l’utilisateur de gérer cet aspect, car chaque jeedom est différent : ce qui semble important pour l’un ne le sera pas pour l’autre.
Mon thermomètre de la salle de bain n’envoie plus de données ? Bof pas grave, donc je peux me permettre de ne pas le monitorer.
Par contre, celui de la piscine est plus critique? Il faut alors être averti qu’il n’a plus envoyé de données depuis X minutes, ce qui permet de réagir en conséquence.
Tes problèmes viennent aussi peut-être de causes externes (brouillage sur le 433mhz par exemple, cela m’est arrivé sans que je trouve la cause, qui ne s’est d’ailleurs pas reproduite depuis des mois), des services tiers arrêtés aussi (entraînant ainsi le non fonctionnement du plugin associé)…
Oui et non. Sur une chaudière ou sur une voiture, c’est au fabricant de gérer les anomalies. L’utilisateur se contente de mettre des alertes sur sa consommation de carburant ou kilométrique. Sur une box domotique, c’est pareil, c’est à ceux qui développent le système et les plugins de vérifier tout ce qui est nécessaire au bon fonctionnement du système ou du plugin. L’utilisateur créé des alertes sur les valeurs des commandes.
Ah oui donc pour le plugin ENEDIS, il faut que le développeur s’assure que le site ENEDIS est pas en maintenance ???
Si vous ne voulez pas de souci, tournez vous vers des automates.
Sur un système ouvert comme Jeedom, l’utilisateur a tous les outils pour faire du contrôle et c’est a lui de le mettre en place.
Je dirais que oui. Lors d’une maintenance prévue, il doit y avoir une info quelque part. Ainsi le plugin annonce dans la messagerie ou le log qu’Enedis (c’est valable pour pour tous les services cloud) est en maintenance qu’il faut patienter… ça éviterait de voir débarquer des gens sur le forum disant que le plugin ne fonctionne pas. Il faudrait que plugin soit capable de déterminer si le souci vient de la connexion internet de l’utilisateur, du cloud, de l’identifiant pour se connecter au cloud, de son API. Après, si Enedis modifie son API, c’est une autre histoire. Malheureusement, là le développeur devient esclave. Ce genre de plugin devrait être sous forme d’abonnement, mais c’est un autre débat.
oui, mais pour la domotique, il n’y a jamais assez entrées/sorties.
je suis toujours à la recherche un soft d’automate pseudo temps réel avec 1024 entrées/sorties non physiques en MQTT où on peut coder un truc robuste avec un langage bien standardisé IEC 61131-3 un peu comme ce que fait CodeSYS CODESYS Development System V3 | CODESYS Store International
Ce que tu veux vis à vis de Jeedom est impossible !
Faut être réaliste.
Y a tout dans Jeedom pour mettre des choses en place.
Le hic c’est que la majorité des gens mettent des trucs vite vite, pour que ça marche.
En quelques mois c’est une usine a gaz, rien n’est tuné, rien n’est prévu en cas de pépin pour être alerté.
Ils ne prennent bien souvent pas le temps de lire la doc, ou parcourir les différents menu de Jeedom pour voir ce qu’y s’y trouvent etc.
Donc vu le cout de Jeedom et ses plugins, attendre se que tu en attends, ça signifierai une solution à un prix comment dire…
A la base, faut quand même pas oublier que c’est du DIY…
Ou bien qu’il ne correspond pas à ton besoin, tout simplement. Le fond du problème est peut-être à chercher de ce côté.
Le fait que Jeedom soit gratuit (mis à part certains plugins payants, que chacun est libre d’acheter ou pas) est une raison qui m’a fait l’adopter.
A contrario, j’ai déjà payé des produits que j’ai retourné par la suite car ils ne correspondaient pas à mon besoin.
Je parlerai plus de monitoring actif sur les choses primordial de sa solution.
Automatisme de relance de demons etc…
Bref le truc que personne fait car c lourd
Mais qd tt plante ils y viennent mais l’usine a gaz est deja trop complexe.
C’est comme les backup, ils externalisent qd ils ont tt perdu une fois…
Mais le souci c’est le spectre des technos que lon touche avec jeedom.
Linux, protocoles divers etc… tt le monde ne peut essayer de creuser ts les sujets.
Certains cherchent du vite a pas cher.
Dc ceux la continueront tjrs a raler sur la fiabilité et autres soucis car ils ne maitrisent pas
moi je dirais qu’on part sur Jeedom pour être utilisateur et que, finalement, on se retrouve, non pas développeur qui serait pompeu, mais a un niveau entre les deux
L’histoire des démons : pkoi ils ne se relancent pas seuls si le plugin est actif ? ca me choque d’être obligé de « développer » un truc pour ça. Mieux : cette semaine, mon plugin teleinfo ne récupérait plus l’injection mais seulement la conso. J’ai relancé le démon, pourtant affiché vert, et c’est repartit … bof
il y a tout pour faire dans Jeedom mais il faut le faire et ça, on ne s’y attend pas au départ. Je fouine du coté de HA et ça n’a pas l’air bcp plus réjouissant…
J’aime m’occuper de Jeedom même si le truc m’agace quelques fois, c’est cool. Par contre, s’il m’arrive maladie ou plus … ben c’est la merde
le z wave est le seul qui ne m’a jamais posé soucis, bien moins que le rfx ou le zigbee en tout cas … c’est toujours nuancé par quelqu’un ce genre d’affirmations …
Le demon est vert running et ca fonctionne plus
Le demon est stop donc rouge…
Donc en plus de heartbeat il faut aussi mettre des alertes sur la comm des modules et déclencher des actions re redémarrage auto via jeelink…
Mais je te l’accorde c’est du boulot a faire !
On revient à la gestion des erreurs et je pense qu’il y a plus de boulot à faire pour gérer les erreurs que pour faire fonctionner la domotique.