Multi Zigate: decorreler les zigate et faire en sorte que meme si on perd une zigate le plugin continu sur les autres zigates.

[KiwiHC16]

Pensez à la cagnotte: http://kiwihc16.free.fr/index.html#cagnotte

[Tartanpion27]

Cette fonction serait en effet intéressante. J'ai 2 zigate WiFi dont une a son accès WiFi plus ou moins stable. Du coup, celle qui a un bon accès WiFi se retrouve à attendre que l'autre se reconnecte pour que le plugin soit fonctionnel.

[tcharp38]

@KiwiHC16 Apres une rapide reflexion je vois un souci à debattre. Aujourd'hui si un des demons tombe, le status renvoyé à Jeedom (par déamon_status) est NOK. Ce dernier va dans la plupart des cas redemander le lancement des demons via deamon_start() n'est ce pas ? Du coup si on veut décorreler, il faut accepter que le status renvoyé à Jeedom soit OK alors qu'un lien est HS. D'accord avec ca ?

On pourrait definir que

• si 1 seule zigate et lien HS => retour NOK
• si plusieurs zigatse et 1 seule HS => retour OK
• si plusieurs zigates et plusieurs HS => retour NOK

Ca te semble acceptable et assez carré ? Autrement dit on accepte qu'un seul lien soit cassé mais pas +.

[edgd1er]

et pourquoi ne pas faire un start_daemon intelligent ?

• un ou plusieurs deamon(s) d'une des zigate tombe(nt) => jeedom retour HS
• start_daemon demandé mais jeedom ne démarre que les daemon manquant(s) ? soit en stockant les pid soit en filtrant un pgrep

le stop resterait un stop forcé de tout les daemons. Qu'en pensez vous ?

[KiwiHC16]

Oui mon idée est le start_daemon intelligent. Il garde ce qui fonctionne et essaye de redemarrer ce qui ne fonctionne pas.

• Si on demande un arret on arrete tous les daemons
• Si on demande un demarrage on démarre tout
• Si un bout plante on indique erreur, et on essaye de demarrer que cui est planté et on indique dans le message de plantage ce qui est planté.

Maintenant je ne sais pas si c est facile a implémenter du fait du core de jeedom qui en cas de redemarrage doit faire un stop suivi d un start, mais je ne suis pas sure.

[Tartanpion27]

Ou bien en 2 étapes car le mode intelligent risque d'être plus long à implémenter. 1) un mode dégradé qui permet de démarrer la zigate non HS, comme indiqué par @tcharp38 2) le mode intelligent indiqué par @KiwiHC16.

[tcharp38]

Meme si mode intelligent (d'ailleurs j'ai un truc comme ca dans le pipe, non finalisé) il faut clarifier ce qu'on attend. Donc la il manque juste le comportement souhaité si on relance et ca replante par ex car on ne doit pas relancer le démon non stop. Il y a forcement un pb.

Le cas a definir je crois est "un bout plante". En dehors de bien sur remonter l' erreur on peut tenter de relancer 1 ou 2 fois tout en remontant toujours status OK comme ca Jeedom ne touche rien. Apres je ne vois toujours pas l'interet de remonter PAS OK à Jeedom car il ne fera pas mieux que relancer le tout à nouveau n'est ce pas ? Bref le comportement quand juste "un canal" plante (une zigate sur plusieurs) vaut le coup d etre reflechis

[edgd1er]

L'idée que le status réel des daemons ne remonte pas dans jeedom me gene, du coup le dashboard est un fake :) jeedom dit ok alors que l’état réel est inconnu et il faut regarder les logs pour savoir que qq chose cloche. L'interface n'est plus fiable, en terme d'experience ce n'est pas terrible

Jeedom relance automatiquement seulement si la gestion automatique est activée, il pourrait y avoir un mécanisme pour changer ce comportement au bout de trois relances par exemples. D'ailleurs, le bouton restart est caché lorsque la gestion automatique est activée.

si vous garder la remontée d'un status bidon, alors il faut prévoir un alerting par messages qui ne bombarde pas l'interface ( daemon_info), pour remonter l'état réel, en cas de pb.

si personne n'est sur le sujet, je peux travailler sur ce restart/start intelligent, en reprenant les "specs" de kiwi

• Si on demande un arrêt on arrête tous les daemons
• Si on demande un démarrage on démarre tout
• Si un bout plante on indique erreur, et on essaye de démarrer que qui est planté et on indique dans le message de plantage ce qui est planté.

l'idée est de dire que si au moins un process tourne, alors on relance les manquants, sinon c'est qu'un stop a été demandé et on ne fait rien.

si un (re)start a été fait il y a moins de 45 secondes et que des process manquent, alors status ko et messages.

daemon_info sera capable de connaître l'état des process en cours et attendu et demandera un restart_intelligent.

Qu'en pensez vous ?

[tcharp38]

Ok, je comprends ton point de vue côte retour Jeedom. Je te laisse faire mais si possible faudra decrire le comportement + en detail, en commentaire ou doc dev, surtout pour "un bout plante".

Attention à Jeedom qui ne parle pas trop bien Anglais :) il attend deamon_info() et non pas daemon_info(). Idem pour start et stop.

En ce qui me concerne je te laisse gerer ce sujet.

[KiwiHC16]

@edgd1er je te mets sur ce sujet pour éviter que les autres traveillent sur le sujet en même temps.

[KiwiHC16]

Les process que l on a:

• Abeille (Cron Jeedom) (x1) - Obligatoire
• AbeilleCmd (Process) (x1) - Obligatoire
• AbeilleParser (Process) (x1) - Obligatoire
• AbeilleSerialRead (Process) ( x NbZigate) - Optionnel
• Socat (Process) (Option Wifi) ( x NbZigate) - Optionnel

Comment monitorer les process ? Est ce que l on garde ce qui existe ou on essaye d ajouter quelque chose de plus complexe comme un heartbeat ?

Pour chaque Zigate, on a un "Status" pour l activer ou desactiver. Est ce que l on doit avoir un "Erreur Status" par Zigate qu on affiche par Zigate avec creation d une alarme.

[edgd1er]

bon, je commence a avoir qq chose de correcte:

@tcharp38 , @KiwiHC16 pourriez vous tester ma branche smart_start svp avec votre matériel si possible ?

2 possibles pb:

• je n'ai pas prioriser le démarrage du socat dans les daemons. cela arrive au fil de l'eau, j'ai tenté un tri inverse dans le tableau associatif mais pas sur du résultats ( d'ou une autre idée d'évolution, mettre des tests au moins sur les fonctions critiques: decodage des msg hexa, arret, relance des daemons, join-leave , ...)
• j'ai considéré que les daemons étaient isolés et ne dépendaient pas les uns des autres. si A tombe, je relance A, je n'ai pas besoin d'arreté B et C, puis relancer les 3.

possiblement un troisieme, interrogate n'est pas surveillé.

la méthode de validation:

• le plugin est arreté => les daemons ne sont pas redemarrés. etat normal
• le plugin est lancé => les daemons sont démarrés. etat normal
• un kill d'un demon est fait sur un shell. état anormal car le nombre attendu de daemons est différents de celui en execution. relance du daemon manquant
• retour a un état normal.

je n'ai pas de zigate wifi ni de pizigate, ni de troisieme zigate dispo. donc mes tests se sont limités au max a 2 zigates défines, 1 active.

Un exemple de log, ci dessous: isMissingDaemons:362: False = etat normal a 19h21, kill du daemon => etat anormal [2020-11-19 21:15:09][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,0,3 detection du process manquant et relance [2020-11-19 21:15:09][DEBUG] : Tools:restartMissingDaemons: missing daemons:, serialRead1 retour a l'etat normal [2020-11-19 21:15:10][DEBUG] : AbeilleTools::isMissingDaemons:362: False

[2020-11-19 21:15:06][DEBUG] : AbeilleTools::isMissingDaemons:362: False, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,1896 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/php/AbeilleSerialRead.php Abeille1 /dev/ttyUSB0 debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug
[2020-11-19 21:15:06][DEBUG] : AbeilleTools::isMissingDaemons:362: False, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,1896 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/php/AbeilleSerialRead.php Abeille1 /dev/ttyUSB0 debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug

==> /home/user/Documents/Linux/docker/DOCKER_CONFIG/jeedom/webdata/pluglog/AbeilleParser.log <==
[2020-11-19 21:15:08][debug] Abeille1, Type=8011/APS data ACK, Status=A7, DestAddr=1F81, DestEP=01, ClustId=0000

==> /home/user/Documents/Linux/docker/DOCKER_CONFIG/jeedom/webdata/pluglog/AbeilleSerialRead1.log <==
[2020-11-19 21:15:08][debug] Reçu: "801100080FA71F81010000AE00"

==> /home/user/Documents/Linux/docker/DOCKER_CONFIG/jeedom/webdata/pluglog/Abeille <==
[2020-11-19 21:15:09][INFO] : deamon_info(): Le plugin est démarré. la cron tourne
[2020-11-19 21:15:09][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,0,3
[2020-11-19 21:15:09][DEBUG] : AbeilleTools::isMissingDaemons:362: True, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug
[2020-11-19 21:15:09][WARNING] : Abeille: il manque au moins un processus pour gérer la zigate
[2020-11-19 21:15:09][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,0,3
[2020-11-19 21:15:09][DEBUG] : Tools:restartMissingDaemons: lastLaunch: 2020-11-19 21:10:10,running:Array (     [cmd] => 1     [parser] => 1     [serialRead1] => 0 ) 
[2020-11-19 21:15:09][DEBUG] : Tools:restartMissingDaemons: restarting serialRead1: /usr/bin/nohup /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/php/AbeilleSerialRead.php Abeille1 /dev/ttyUSB0 debug >>/var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../../../log/AbeilleSerialRead.php1.log 2>&1
[2020-11-19 21:15:09][INFO] : Tools:restartMissingDaemons: restarting AbeilleserialRead1
[2020-11-19 21:15:09][DEBUG] : Tools:restartMissingDaemons: missing daemons:, serialRead1
[2020-11-19 21:15:09][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,0,3
[2020-11-19 21:15:09][DEBUG] : AbeilleTools::isMissingDaemons:362: True, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug
[2020-11-19 21:15:09][WARNING] : Abeille: il manque au moins un processus pour gérer la zigate
[2020-11-19 21:15:09][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,0,3
[2020-11-19 21:15:09][DEBUG] : AbeilleTools::isMissingDaemons:362: True, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug
[2020-11-19 21:15:09][WARNING] : Abeille: il manque au moins un processus pour gérer la zigate
[2020-11-19 21:15:10][INFO] : deamon_info(): Le plugin est démarré. la cron tourne
[2020-11-19 21:15:10][DEBUG] : Tools:getRunningDaemons: nbExpected: 3, found: 1,1,1,3
[2020-11-19 21:15:10][DEBUG] : AbeilleTools::isMissingDaemons:362: False, params: ok,,4,2,USB,/dev/ttyUSB0,192.168.0.1,Y,USB,/dev/monitZigate2,192.168.0.1,N, running: 1891 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleParser.php debug,2710 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/class/AbeilleCmd.php debug,3430 /usr/bin/php /var/www/html/plugins/Abeille/resources/AbeilleDeamon/lib/../../../core/php/AbeilleSerialRead.php Abeille1 /dev/ttyUSB0 debug

[KiwiHC16]

Pas vu de soucis sur mon systeme de dev sans pour autant avoir fait des tests spécifiques. Je vois un message Jeedom quand il y a un soucis meme si le daemon est toujours en vert. Le probleme est que si le systeme est en mode dégradé nous ne le savons pas sauf qi nous regardons les messages, ce que je fais rarement. Peux être ce que nous pourrions faire c est envoyer un statut sur une commande de la ruche pour partager l etat. Et cela permet a l utilisateur de mettre en place un scenario pour envoyer un message, un sms, faire un appel,.. en cas de detection de degradation vers l utilisateur qui peut ainsi reagir dans la minute.

[tcharp38]

A clarifier mais ca semble une bonne idée.

[edgd1er]

oui, vous avez tt les deux raisons, ou moment du dev, je n'ai pas trouvé de solution satisfaisante qui ne bombarde pas l'interface de message. Mais effectivement, c'est un point a améliorer,mais je ne vois pas comment faire.

[KiwiHC16]

Il faut ajouter dans le modèle ruche une commande info. Ensuite dans le code il faut envoyer le message sur cette commande.

Je vais faire un exemple que vous pourrez utiliser.

Mais si on veut l utiliser pour une entrée de scénario utilisateur il faut peut qu on fasse un « énumération » , une liste des messages que l utilsateur peut recevoir.

[KiwiHC16]

Dans master, manip pour tester:

• supprimer la ruche
• redemarrer le daemon, la ruche doit être régénérée
• dans shell: cd /var/www/html/plugins/Abeille/core/php php AbeilleTest.php 200
• Et vous devez voir le message "Le message" dans la commande "SystemMessage" de la ruche

Vous pouvez mettre dans le code ou vous le souhaitez:

Abeille::publishMosquitto(queueKeyAbeilleToAbeille, priorityInterrogation, "Abeille1/Ruche/SystemMessage", "Le message");

[KiwiHC16]

A voir si tous les messages vont vers une unique Ruche ou si cela va sur une ruche specifique. On a le choix.

[edgd1er]

@KiwiHC16 , j'essaie d'utiliser la commande donnée et j'ai ce message

[2020-11-29 02:31:41][DEBUG] : message(topic='Abeille2/Ruche/SystemMessage', payload='daemon manquant')
[2020-11-29 02:31:41][DEBUG] :   L'objet 'Abeille2/Ruche' existe mais pas la cmde 'SystemMessage' => message ignoré

j'ai supprimé les ruches et redamarré les démons. Je ne maîtrise pas du tout la remontée d'information vers jeedom. je vais creuser un peu plus.... Si cela marche, il devrait avoir distinction par ruche.

j'ai remplacé en ligne 18 dans AbeilleTest.php $message = new object(); par $message = new MsgAbeille(); J'ai toujours le message indiquant que la ruche1 ne connait pas cette commande. il doit manquer qq chose à la création de la ruche.

[edgd1er]

@KiwiHC16 , My mistake, la synchro entre mon conteneur de dev et le dossier git ne fonctionnait plus. Tout est Ok, je corrige le nom du daemon hs.

Je prévois d'afficher une liste des daemons hs par ruche et rien si tout est ok. il faudra juste voir si une maj de l'interface a chaque tour ne va pas surcharger jeedom.

Es tu ok avec ça ?

[KiwiHC16]

"il faudra juste voir si une maj de l'interface a chaque tour ne va pas surcharger jeedom." Je ne comprends pas ce point. Que veux tu dire ?

[KiwiHC16]

Gestion des processus gros bazar... #1521

Je clos celui ci et on continue dans #1521.