@Loic @Mips…
Ma proposition d’évolution du plugin par ici : Comment connaitre les états des plugins actifs?
Bonjour,
Faudrait detailler ou mettre un contexte car la aucun idée de ce dont on parle.
HISTORIQUE
Sur eWeJee et un autre plugin (WifilighV2 je crois), de temps en temps le(s) démon(s) de communication (Yen a 2 dans la beta eWeJee) tombai(en)t sans prévenir et la relance automatique n’a également pas tj fonctionnée.
PROBLEME
Je trouve très gênant d’avoir des services de communication ou autre (plugins) qui tombent sans le savoir et donc des fonctions de domo inactive sans le savoir.
ESSAIS
J’ai cherché des infos du coté de la page Santé mais non exploitable sans code PHP à priori. Idem avec jeelink qui ne donne que l’état associé à l’activation de plugin lui-même (ce que j’appelle le démon principal). Idem du coté Hearbeat qui est très limité d’après mes essais Heartbeat
OBJECTIF
Mon objectif était de déclencher un scénario lorsque le(s) démon(s) « secondaire(s) tombai(en)t » (de communication & Co) n’étaient plus actifs. On m’a proposé des commande bash afin de détecter des APIs qui ne répondent plus ou autre… Trop nébuleux et spécifique à mon gout, je préfère le code car il procure une meilleure maitrise.
SOLUTION
Au final, j’ai transformé et obtenu le code en lien, par ici, qui vérifie l’état des dépendances ainsi que l’état des démon secondaires pour les plugins en activité. Dans un premier temps, je déclenche un scénario tout les matins qui me donne la situation via telegram (Si pas de message c’est que télégram est down également) 
Dans un second temps je vais faire tourner ce code tous les 10mn et générer un message (qui m’est transmit en télégram aussi) si au moins un des status est NOK.
EVOLUTION JEEDOM
Ne pourrait-on pas mettre ces données de surveillance qq part => Panneau santé par exemple et à disposition sous forme d’une commande (état) ?
Un truc du genre :
#[Sante][ttlesplugin][Etatdépendance]#
#[Sante][ttlesplugin][EtatDémons]#
#[Sante][nomd'uneplugin][Etatdépendance]#
#[Sante][nomd'uneplugin][Etatdépendance]#
Avec la possibilité en option de générer un message via un scénario déclenché par le changement d’un de ces états.
Ce doit être plus clair, enfin j’espère 
Donc on parle de demons de plugins.
Et cas particulier certains plugins ont 2 démons.
Le deuxième n’étant pas pris en compte !
Dc y a pas d’histoire de démon secondaire ou autre.
Sans formule alambiquée ce sera plus simple pour que le dev comprenne non ?!
Mon message est-il compréhensible ? Si oui alors le reste n’est qu’affaire de gout, n’est-ce pas ?
Faute d’expérience en Linux/PHP/Jeedom, je n’ai pas le vocabulaire exact et le structure exact. Il faut bien « démarrer » un jour. Je connais assez bien les tâches/thread Event/Semaphore…COM/DCOM/Marshalling sous Windows (y’avait pas de Linux ya 20 ans). Alors Deamon and Co, je fais ce que je peux. Je te promets je vais regarder
Pour finir, si ma prose ne te plait pas, je ne peux rien faire pour toi… Une histoire de génération certainement. Et pour les leçons de morale j’ai passé l’âge
Je terminerais par cette expression que j’aime bien : Ce que l’on conçoit bien s’énonce clairement, et les mots pour le dire arrivent aisément.
ps : Tu as une vision des « devs » que je ne partage pas mais on ne peut pas tj être d’accord.
Hello @anon39781406
A vrai dire, le second démon est mal géré de mon côté et je n’avais pas trop d’idée comment faire ça, mais le plugin Zigbee m’a éclairé sur le sujet, donc ce sera sur la prochaine bêta, qui mettra le démon principal en nok si le secondaire est NOK.
C’est plus logique de cette façon, le monitoring sera donc efficace.
1 « J'aime »
Si je contribue à l’amélioration de ton code, j’en suis flatté (en espérant que tu comprennes le sens de ce mot, en tant que développeur ;-))
ps : es-tu autorisé à parle de démon principal et secondaire…
Les deux sont principaux, le problème est de gérer les deux car certains vont vouloir couper le cloud et rester en full LAN, d’autres l’inverse et d’autres les deux.
Donc je dois inclure le choix des utilisateurs et le prendre en compte dans le deamon info
Dans ce cas, ne faut-il pas gérer ces choix par des checkbox de conf (ce que je souhaite utiliser) puis ensuite montrer et lancer le(s) demon en fonction des checkbox ?
Comme le heatbeat, gérer 2 infos dans la même variable est toujours ambiguë (en l’occurrence si vide ou 0 ne fonctionne pas si <> alors prend la valeur pour vérifier le temps entre 2 communication le tou avec un cycle de 5mn…). As-tu compris ?
Non 
Je vais gérer ça autrement.
Je vais partir sur un démon qui va gérer les démon cloud et LAN
Donc 3 démon en gros…
L’utilisateur pour choisir quel démon utiliser.
En fonction du choix utilisateur le démon surveillera l’état du ou des démon voulu.
Et passe en nok s’il y a un problème.
De cette façon la gestion automatique relancera le démon adéquat.
Ça fait usine à gaz mais c’est je pense le meilleur moyen d’avoir quelque chose de fiable …
Et bien voila, tu viens d’inventer le daemon tertiaire 
Ca me semble cohérent vu de ma fenêtre. Sonne-moi alors si tu cherches un Bête-testeur…
ps : De mon conté j’ai un scénario cyclique (5mn) qui détecte un problème de dépendance ou de démon. Il m’envoie un message et se met en « silence » pendant une heure (réarmement d’une variable globale avec DANS que je n’avait pas encore utilisé) même si l’erreur perdure puis revient à la charge si je n’ai pas corrigé. Prochaine étape un plugin maison qui sait…
Bonjour,
Jeedom fournis tout ce qu’il faut au plugin pour la gestion d’un ou X demon. Si il n’y a pas de relance alors il y a un soucis coté plugin dans la gestion des démons. C’est pas au core de s’adapter a chaque plugin pour des cas comme ca mais au plugin de se présenter correctement au core.
Loic,
Ok mais là n’est pas la question de base.
Je parle d’avoir une meilleure vue sur le fonctionnement/diag des plugins :
J’ai le cas ce matin d’un démon planté (@Foulek57 voir message direct) en terme de com mais qui continue à fonctionner. Le code de diag en référence ne l’a pas détecté mais on est sur du bug en beta.
ps @Foulek57 le Heartbeat n’a rien vu car c’est de la com avec des faux positif! J’en conclue qu’il sert seulement à détecter qu’un équipement ne communique plus avec son plugin de sa propre initiative. 9a me semble finalement assez restrictif…
Mais c’est un soucis dans le plugin la. Le core propose deja tout il suffit juste que le plugin s’en serve correctement.
Le core demande toute les 5min au plugin si les demons sont ok si nok alors il les relancent
Ensuite ya une 2eme verification qui est le heartbeat et qui la ne se base pas sur l’info du plugin mais directement sur la date de derniere reception d’information pour tous les équipements du plugin et si nok alors il relance le demon.
C’est largement suffisant pour couvrir tous les cas possible et IL N’Y AURA AUCUNE EVOLUTION LA DESSUS.
Pas de problème. Je propose, tu disposes…
Si le plugin utilise correctement les fonctions du core tous ce que tu proposes est deja la il n’y a rien a ajouter.
Et je te garanti que ca marche bien le plugin zigbee peux avoir 2 demons et dès qu’il y a un soucis avec un des 2 le core le redemarre de lui meme sans soucis.
En effet je vais m’inspirer du plugin Zigbee justement.
@anon39781406 laisse moi le temps de faire les corrections c’est déjà sur papier, reste a le coder proprement et tu pourras faire les tests sur la bêta.
Je te tiens au courant.
1 « J'aime »
Mon humble participation sera un grand honneur mon seigneur…
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.