Si tu modifies le fichier de ton coté, dans ton fork (attention nouveau mot 
), dès que tu auras commit le PR sera à jour.
Fork is ok for me guy. I’m an old man but not totally newbie
Mes derniers Kg de C++ ont 20 ans mais c’est un peu comme le vélo. A cette époque, j’étais « le roi » de Ms Source Safe. Les concepts sont les mêmes avec beaucoup plus d’options et à une échelle mondiale (je trouve tj cela extraordinaire)…
Et comme dit Léonard c’est en sciant que Léonard devient scie 
Merci de ton aide
1 « J'aime »
En tout cas ça marche :
Petites remarques au passage (pour la V4.2 sait-on jamais):
1 - Une check On/OFF (avec popup indiquant un cycle de 5mn) + une valeur de timer de surveillance de com aurait évité les ambiguïtés
2 - Cela a-t-il une utilité pour des plugin comme Mobile ou Virtuel et encore moins JeeXplorer
3 - Pour moi le terme Watchdog serait plus approprié (PLC experience)!
Quelqu’un utilise cette fonction ?
Pour finir, mon idée étant de vérifier que le daemon ne tombe pas, cette option est encore plus « intéressante » => Je vais l’activé partout ou ça cause et faire des réglages
Finalement je laisse le fil ouvert
Non aucun intérêt sur les plug-in n’ayant pas d’équipements ou avec des équipements qui ne se mettent pas à jour.
Vous parlez de la « gestion automatique »?
C’est cette option qui relance le démon s’il est tombé.
REX (J’en profite pour me faire un mémo):
Comme je l’ai dit, 1er test, il y a génération d’une erreur si positionnement Heartbeat sur un plugin non communiquant Ex : Mobile
Hier, j’ai mis des Heratbeat partout ou ya de la com (à priori):
**PLUGIN - Heartbeat Xmn - Relance Démon (** si pas d'option dispo)**
ALEXA-API - 60mn - no
AMBILIGHT - 60mn - ** => Pas utilisé et pas certain qu’il y ai des échanges!
ENEDIS - 70mn - ** => Pas très en forme ces dernières heures, Pas significatif
eWeJee - 3mn - Yes
Freebox - 10mn - no
Freebox Re - 10mn - no
Google Sma - 30mn - no
IFTTT - 60mn - **
Jeedom Link - 5mn - **
Monitoring - 10mn - **
Network - 20mn - **
SmartLife/Tu - 2mn - **
OpenVPN - 30mn - **
Vigil. méteo - 30mn - **
Weather - 30mn - **
wifilightV2 - 3mn - Yes
Zigbee - 3mn - Yes
Pas un seul message en 15-20h de fonctionnement. Je me suis dit c’est parfait, tout va bien.
@Foulek57
J’ai quand même essayer d’aller plus loin sur eWeJee en arrêtant volontairement les démons + RAZ des logs:
Dans le log eWeJee:
[2021-01-24 18:21:04][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:22:05][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:23:04][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:24:04][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:25:06][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:25:56][DEBUG] : Demon LAN nok, server =
[2021-01-24 18:26:04][DEBUG] : Demon LAN nok, server =
eWeJee_lan et eWeJee_node => Vide
1h après rien de chez rien! Est-ce normal ?
Puis j’ai coché le daemon :
1h après rien de chez rien non plus! Est-ce normal ?
Test avec WifilightV2 a 3mn sans redémarrage daemon et Gestion automatique à OFF :
Rien ne se passe non plus.
Redémarrage daemon sur ON
Rien ne se passe non plus.
Au final, le heartbeat vérifie la communication seulement si le démon est lancé ou s’il ne fonctionne pas quelque soit l’état du démon?
Il fonctionne sur les plugins qui ne communique pas par essence (ex mobile) dans tous les cas il n’y a pas d’intérêt ici!
@Mips Tu, pas vous stp. Je suis assez vieux comme ça
La gestion auto ne fonctionne pas parfois… Je cherche un moyen « générique » d’être alerté que le (les) demon d’un plugin sont arrêté… rien de plus. Par ailleurs, le statut de(s) démon est toujours connu de Jeedom:
Si l’état n’est pas accessible directement de Jeedom, faut il passer par un script (je ne connais pas très bien le PHP mais 7 ans de c++ m’aide)?
Salut,
ce post peut t’aider :
ps -eo ppid,stat,cmd | grep -e '^ 1 ' | awk '/zigbeed/ {print substr($2,1,1)}'
La gestion automatique du démon va toujours redémarrer le démon s’il est NOK (et si la config et les dépendances sont OK).
Et le heartbeat permet de le redémarrer s’il n’y a plus de communications.
Donc je ne vois pas de raison de coder cela à la main, ce n’est pas nécessaire tout est déjà présent dans le core.
Ca je voudrais un exemple: soit le démon est démarrer, soit il ne l’est pas et il le sera; il n’y a pas de « parfois ca ne fonctionne pas »
1 « J'aime »
C’est possible faudrait regarder dans le code du core.
Ça par contre ça met jamais arrivé.
Dans les erreurs tu doit avoir un message comme quoi le démon ne c’est pas relancé après 3 essaie (je sais plus le message exact)
Pour le LAN : sudo lsof -i TCP:6006
Pour le cloud : ps -eo pid,command | grep newserver | grep -v grep | awk '{print $1}'
Le heartbeat vérifie si au moins une commande d’au moins un équipement a été mise à jours les X dernières minutes, indépendamment de si un démon existe ou pas ou si un démon est démarré ou pas.
1 « J'aime »
C’est du spécifique… mais merci
C’est fait exprès tout fonctionne plutôt bien depuis quelques jours. Dans tous les cas, j’ai maintenant tous les éléments pour investiguer ma perte de MCO!
A vrai dire ça fait qq temps que je n’ai pas eu. Je reviendrais par là le cas échéant
Un grand merci, Je regarde ce soir.
Idée : Une solution mise à disposition des états de « l’objet » santé serait encore plus simple, non ?
Reste à voir ce qui se cache derrière réellement les OK/erreurs / demon secondaires, échange de données, erreurs… La doc n’est pas très loquace (je peut faire un PR si j’ai les billes, pour les autres…)
je comprends pas cette notion de demon secondaire…
Le plugin eWeJee as un second démon pour la gestion des perifs en LAN.
Exactement, j’irai plus loin.
L’activation du plugin tourne sous un demon (une tache)
Ici il y a en plus le Wan et le LAN que j’ai appelé « secondaire » faute de mieux.
C’est le cas de Zigbee ou d’autres plugins ayant des services de communication
Me trompe-je?
Méa culpa, j’ai pas encore la culture (lu assez) Jeedom certainement…
Ben non pour moi le plugin est activé ou pas.
En général on l’active après installation.
Ensuite certains plugins ont un démon, zwave etc…
Et ce n’est pas un démon secondaire. C’est le démon du plugin point barre.
Oui effectivement Zigbee a la possibilité d’activer un second démon, je vais voir pour le faire fonctionner de la même façon.
EU REX KA
Je suis parti de celui-ci : [TUTO] Une autre stratégie pour la surveillance des démons - Plugins / Monitoring - Communauté Jeedom
Je préfère le code que l’exécution de bash/shell, ce qui m’a emmené ici : [TUTO] Recevoir une notification Telegram regroupant les états des démons - Utilisation du core de Jeedom / Scénarios - Communauté Jeedom
J’ai repris ceci juste pour les icônes:
J’ai surtout recup ceci : [TUTO] Recevoir une notification Telegram regroupant les états des démons - #40 par Thibaut_T
Soit un scénario qui se lance tout les jours à 7h :
Ceci:
// On efface la variable message
$message='Dependances : ';
// on ajoute une ligne dans le log
$scenario->setLog('Début Monitoring des Dependance');
$tags = $scenario->getTags();
$valeurOK=$tags['#IconOK#'];
$valeurNOK=$tags['#IconKO#'];
// pour chaque plugin activé de votre jeedom
foreach (plugin::listPlugin(true) as $plugin)
{
if ($plugin->getHasDependency())
{
$dependency_info = $plugin->dependancy_info();
if ($dependency_info['state'] == 'ok')
{
$valEtat = $valeurOK.' ';
}
elseif ($dependency_info['state'] == 'in_progress')
{
$valEtat = 'In prog';
}
else
{
$valEtat = $valeurNOK.' ';
}
$message .='|'.$valEtat.$plugin->getName().' ('.$plugin->getId().')';
}
}
$message=str_replace("|","\n",$message);
// on selectionne la commande telegram correspondante au destinataire du message
$cmd=cmd::byString('#[Telegram][Telegram][Eric - xxxx]#');
// on envoie le contenu de la variable message via telegram
$cmd->execCmd($options=array('title'=>'Jeedom', 'message'=> "$message"), $cache=0);
// on log la fin de la verification des démons
$scenario->setLog('Fin monitoring des Dependances');
et ceci
// On efface la variable message
$message='Deamon :';
// on ajoute une ligne dans le log
$scenario->setLog('Début Monitoring des Demons');
$tags = $scenario->getTags();
$valeurOK=$tags['#IconOK#'];
$valeurNOK=$tags['#IconKO#'];
$valEtat='toto';
foreach (plugin::listPlugin(true) as $plugin)
{
if ($plugin->getHasOwnDeamon())// && config::byKey('deamonAutoMode', $plugin->getId(), 1) == 1)
{
$deamon_info = $plugin->deamon_info();
if ($deamon_info['state'] == 'ok')
{
$valEtat = $valeurOK;
}
else
{
$valEtat = $valeurNOK;
}
$message .='|'.$valEtat.$plugin->getName().' ('.$plugin->getId().')';
}
}
$message=str_replace("|","\n",$message);
// on selectionne la commande telegram correspondante au destinataire du message
$cmd=cmd::byString('#[Telegram][Telegram][Eric - xxx]#');
// on envoie le contenu de la variable message via telegram
$cmd->execCmd($options=array('title'=>'Jeedom', 'message'=> "$message"), $cache=0);
// on log la fin de la verification des démons
$scenario->setLog('Fin monitoring des démons');
Ce qui me donne un Daemon NOK pour le plugin zigbee si je stop le daemon ainsi:
Résultat :
@Foulek57 pour eWeJee l’arrêt du premier daemon CLOUD est détecté mais pas le second (LAN) :
as-tu une fonction pour recup le second, comparable à celle-ci ?
$plugin->getHasOwnDeamon()
@Mips STP :
PHP Core : Y a-t-il un endroit (Doc, .h) où recup la liste et signification des methods (functions) ?
La doc Jeedom pour les dev me parait très light à priori…j’ai du raté qq chose ?