Il n’a pourtant pas l’air méga chargé :
Je te MP pour diag en direct
Bonsoir @Bad,
Je viens d’effectuer quelques tests pour sauvegarder mes équipements et ma configuration JMQTT,
Tout est OK et semble très bien fonctionner,
[2023-04-16 22:56:55]INFO : ###########################################################
[2023-04-16 22:56:55]INFO : Starting jMQTT backup...
[2023-04-16 22:56:55]INFO : Writing PID file... [ OK ]
[2023-04-16 22:56:55]INFO : Cleaning up... [ OK ]
[2023-04-16 22:56:55]INFO : Preparing to backup... [ OK ]
[2023-04-16 22:56:55]INFO : Generating index file... [ OK ]
[2023-04-16 22:56:55]INFO : Generating Data file... [ OK ]
[2023-04-16 22:56:55]INFO : Generating History file... [ OK ]
[2023-04-16 22:57:08]INFO : Backing up jMQTT folder... [ OK ]
[2023-04-16 22:57:08]INFO : Backing up jMQTT log files... [ OK ]
[2023-04-16 22:57:08]INFO : Mosquitto folder in /etc is missing [ SKIPPED ]
[2023-04-16 22:57:08]INFO : Generating Metadata file... [ OK ]
[2023-04-16 22:57:08]INFO : Creating archive jMQTT_20230416_225708.tgz... [ OK ]
[2023-04-16 22:57:11]INFO : Cleaning up... [ OK ]
[2023-04-16 22:57:11]INFO : Removing PID file... [ OK ]
[2023-04-16 22:57:11]INFO : End of jMQTT backup.
[2023-04-16 22:57:11]INFO : ###########################################################
Concernant la partie Sauvegardes disponibles, j’ai une proposition d’amélioration. Serait-il possible de pouvoir créer l’option d’envoyer automatiquement la sauvegarde vers un autre disque dur ? Avoir également le choix de la rétention et de la fréquence de la sauvegarde,
Par exemple, avec le core de Jeedom on peut envoyer notre backup vers un disque dur sur notre réseau local,
Au plaisir,
Bonne soirée,
Hello,
Alors en fait toute la config de jMQTT est déjà sauvegardée nativement par le Core et présente dans les backup du Core (sauf Mosquitto).
Pour être honnête, j’utilisais jusque là un vieux bout de code pour restaurer tous mes équipements dans un état stable avant de pouvoir faire les captures d’écran de la doc ou les tests de montée de version avant de libérer une version.
Je me disais que ça pourrait servir à d’autres qui souhaitent restaurer jMQTT en l’état et en gardant les id et les liaisons, sans toucher aux autres plugins, mais ça n’a pas vocation à évoluer pour faire des backups externalisées, vu que tout est déjà dans la backup de Jeedom.
Sachant aussi qu’il reste des bugs dans ce code : la sauvegarde d’un historique très important (>100Mo) peut échouer par manque de RAM (corrigé dans ma version locale) et la restauration ne restaure pas bien les la version du plugin dans la page de mise à jour, les caches des équipements et 3-4 subtilités…
Bad
1 « J'aime »
@Bad
deja merci pour le temps investi sur le dev du plugin.
j’ai également le problème remonté par @JC38
j’ai également le plugin MQTT2 (officiel jeedom) qui pointe sur le même serveur mosquito (distant) que JMQTT (je viens de le désactive en lisant les postes précédents car je ne m’en sert pas encore)
J’ai également passer le log en debug
La derniere foi que j’ai eu l’erreur j’etais juste au pc et j’ai pu voir que le demon de JMQTT était arrêté
Hello,
Suite à mon analyse d’hier soir sur le Jeedom de @JC38, j’ai identifié que le cron plugin est effectivement saturé et qu’il y mets souvent plus d’une minute à s’exécuter.
J’ai remonté les timeouts à 300s au lieu de 135s sur sa machine, et nous allons chercher à identifier le plugin qui « prend son temps » sur ce cron.
Pour info, la machine n’est pas surchargée et le démon se coupe suite à un mécanisme (ré)introduit dans la dernière version pour éviter les démons fantômes. Il n’y aurait pas de problème (au contraire) si plus d’équipement publiaient et récupéraient des infos en MQTT (évitant ainsi le timeout).
Bad
1 « J'aime »
merci @Bad pour ta réponse rapide
j’ai aussi vu un cron plugin chez moi a 128s…
voici ma liste de plugin histoire de pouvoir faire peu etre un lien entre mes plugin et ceux de @JC38
comme dit plus haut MQTT2 et ZwaveJS sont desactivé depuis ce matin
par contre les 128s on été detectés apres cette désactivation
Oui, je ne pense pas que ce soit lié à un plugin avec un démon, ni un cron dédié et probablement pas un plugin officiel, vu qu’il est bien connu de l’équipe qu’il faut éviter de faire tourner des tâches longues dans ce cron.
Chez JC38, j’ai rajouté des debug dans le core ( class plugin, fonction cron() ) pour voir qui bouffe tout le temps, mais il n’y avait pas d’affichage et il était trop tard hier soir pour reboot.
Mais tu peux essayer de chercher le fautif « à l’ancienne » en désactivant un plugin à la fois et en regardant le résultat sur le temps d’exécution du cron.
Bad
Lo,
Je comprends ton point de vu,
Effectivement lors d’une sauvegarde du core, après restauration tous les équipements ajoutés au plugin reviennent dans son intégralités, Merci pour ton retour et l’intérêt porté à mes questions,
Bonne fin de journée,
Au plaisir,
1 « J'aime »
petite info complémentaire le problème arrive a chaque foi que le cron est exécuter je pense en meme temps que le cron 5 min ,pas sur de cette information mais je viens de tester en effaçant l’erreur a chaque foi quelle apparaît et j’ai eu l’erreur a 18:25:04, 18:30:04 , 18:35:04 , 18:40:04
j’ai passer en debut de soire le timeout de 135 a 300 s depuis plus de soucis mais c’est un sparadrap sur une jambe de bois
Alors oui et non, il faut trouver le plugin qui monopolise ton cron5, mais dans l’absolu 300s c’est acceptable pour tuer un démon fantôme, donc ça peut être la nouvelle norme.
sauf que j’ai qd meme eu 9 fois le problèmes depuis hier soir
ce que je comprend pas c’est que le seul plugin que j’ai mis a jour c’est jmqtt donc en fait c’est le seul qui fait la verif?
Oui, le démon et Jeedom doivent communiquer toutes les Xs sinon le démon meurt.
Comme évoqué plus haut :
Bad
tu peux essayer de chercher le fautif en désactivant un plugin à la fois et en regardant le résultat sur le temps d’exécution du cron.
on est d’accord que l’on ignore les plugins officiels dans un premier temps et que l’on priorise les plugins qui on un cron ? si on ignore les officiel je n’en est que 2 …
ou en sont tes investigations sur le jeedom de @JC38 ?
Hello,
Pour le moment, aussi bien lui que moi, sommes en déplacement 
Donc c’est en pause jusqu’à ce weekend.
Commence en effet par ces 2 là et élargie si ça persiste.
EDIT : petite piste sur le plugin BLEA :
Bad
Petit update, j’ai pu constater de 17h30 à 18h40 sur le Jeedom de @JC38 , les « anomalies » suivantes :
Dans le cron plugin 15 minutes, il y a eu systématiquement des temps de traitement élevés pour :
- monitorsensor ~120s
- conso ~20s
- geotrav ~8s
Dans le cron plugin 1 minute, il est arrivé N fois des temps de traitement élevés pour :
- 5x alexaamazonmusic ~75s
- 4x reolink ~40s
- 4x alexaapi ~30s
Pour trouver ces temps, j’ai rajouté les lignes log::add('cron', 'info', ' ----> '... dans les fonctions cron() et cron15() dans core/class/plugin.class.php, exemple avec cron() :
try {
log::add('cron', 'info', ' ----> '.substr(microtime(), 2, 6).'µs CRON01 du plugin : '.$plugin_id);
$plugin_id::cron();
} catch (Exception $e) {
log::add($plugin_id, 'error', __('Erreur sur la fonction cron du plugin :', __FILE__) . ' ' . $e->getMessage());
} catch (Error $e) {
log::add($plugin_id, 'error', __('Erreur sur la fonction cron du plugin :', __FILE__) . ' ' . $e->getMessage());
}
}
}
log::add('cron', 'info', ' ----> '.substr(microtime(), 2, 6).'µs Fin des CRON01');
Bad
1 « J'aime »
Hello
je reviens de déplacement également pendant ce dernier j’avais désactive blea mais cela n’a rien changé sauf peut etre le nombre d’occurrence /heure du problème
je vais implémenter ton bout de code et poster les resultats
Vu ensemble avec @Yogui par message privé, un script bloquait le cron 1 minute chez lui.
Après transformation en scénario et adaptation du script, le cron se déroule comme il faut et le plugin jMQTT fonctionne sans problème.
Je vais néanmoins rehausser le timer de jMQTT dans la prochaine stable à 5mins.
@JC38, c’est bon pour toi aussi ? On peut fermer le sujet ?
Bonjour Bad,
Je n’ai plus de pb avec jMQTT, il est stable. On peut donc clore le sujet. 
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.