Bonjour,
J’ai un truc bizarre que je ne comprends pas.
J’ai des tasmota qui me remontent les valeurs de mes compteurs.
Tout marche bien dans mqtt explorer, toutes les valeurs sont bonnes dans le log jmqttd et pourtant quand le json s’affiche dans l’équipement la valeur est une valeur qui est restée bloqué à cette nuit ?
Je sèche.
Dernière version de core et dernière version de jmqtt.
Dans le log on a bien papp à 137 qui est la valeur actuelle :
Je ne vois pas où est le problème et je suis sur que si je relance le démon jmqtt cela va se débloquer pour quelques heures.
En attendant de vous lire, je souhaite une bonne fête aux valentins et valentines
Hello bad,
Oui ça y ressemble. Je suis dispo quand tu veux. Suffit de me dire ce qu’il te faut ou ce qu’il faut que je regarde.
En attendant ayant vu qu’il y avait un pb avec les - et _ sur les templates dans un autre post, je viens à tout hazard d’enlever le_ dans mes topics mais cela n’a rien changé (sans trop de surprise)
On a fait un diag en live sur le Jeedom de rennais35000 entre midi et deux et on a pu constater 2 freeze pendant cette période.
Je suppose pour le moment qu’il s’agit d’une saturation des files d’attentes des messages en sortie (ou peut-être en entrée) du démon, car les systèmes de remonté d’énergie de rennais35000 sont très verbeux (entre ~40 et ~110 msgs par minutes avec une moyenne à ~60) et souvent constitués de gros messages json.
Le code de son démon a été instrumentalisé pour être plus verbeux lors les prochains freezes et on continuera d’investiguer ensemble à ce moment-là.
Après avoir rajouter des logs sur le temps de traitement, on a vu que le traitement d’une commande en particulier (PAPP remontée par la téléinfo touts les secondes) est très longue par rapport aux autres.
@rennais35000 utilise intenssivement cette commande dans Jeedom et elle est connecté à un paquet de scenario / commandes ce qui ralentissent considérablement le traitement des messages par le Core, de fait jMQTT met longtemps à les absorber.
Rennais35000 a alors baissé le temps entre 2 transmissions le temps de faire un peu de nettoyage et pour le moment « ça marche », jMQTT arrive a envoyer le flux de message sans être ralenti par Jeedom, mais on constate toujours un temps de traitement de ces messages >> 1 seconde :
Nous avions déjà identifié des problèmes similaires par le passé, mais le démon actuel n’est pas conçu pour faire un différence entre les messages « lents/rapides », il faudra une nouvelle évolution du démon avec des files d’attentes « inteligentes » dédiées aux messages bloquant le démon.
Des messages d’avertissement vont être mis en place :
dans le log « jMQTT », quand une commande mets plus de 1s à être traitée par le Core,
dans le log « jMQTT », quand la file d’attente du démon vers Jeedom n’arrive pas à se vider.
Rennais35000 est actuellement sur un Odroid en eMMC et regarde pour passer sur un support SSD qui devrait accélérer la lecture/écriture des données en BdD (qui semble être l’actuel goulot détranglement), voir passer sur un NUC vu la quantité d’équipements (pas que jMQTT) dont-il dispose.
Conclusion : Quand on donne un jouet à Rennais35000, il joue
J’ai configuré la remontée de Tasmota à une toute les 20 frames et ça ne plante plus, c’est largement suffisant pour gérer le délestage des équipements qui consomment avant que le Linky ne se fache.
Par contre Bad, pour le ssd ce n’est pas encore gagné car je n’ai pas l’impression que l’Odroid N2+ ait le boot sur ssd en natif. Je vais encore galérer.
Si @akenad passe par là je veux bien son aide, je pense que c’est lui qui connait le mieux les Odroid. En tout cas il tutote dessus
Bonne journée à vous tous
Ce n’est pas bien grave, tu ne vas pas retirer l’emmc de toute façon, laisse la partition de boot sur l’emmc et monte la racine du système sur le SSD une fois que le boot est fait. C’est un peu dommage d’utiliser une grosse emmc juste pour boot, mais ça devrait le faire
Tu as toujours des lenteurs ?
Tu es passé sur un SSD externe ?
J’ai intégré (en beta pour le moment) les logs qu’on avait ajouté chez toi, pour avoir des messages d’erreur dans jMQTT quand une commande mets trop de temps à être traitée.
Du coup, vu que je suis en train de faire le « ménage de printemps » dans les sujets ouvert sur le #plugin-jmqtt, on peut fermer celui-ci ?
Hello Bad,
Non ça c’est bien amélioré depuis le ménage « de printemps » dans les tables.
En // j’avais supprimé le plugin suivi-conso qui me semblait très gourmand pour le remettre sur une autre jeedom moins chargée.
J’ai également supprimé le plugin Blea qui revenait en tête des process gourmand en cpu en suivant ton tuto sur esp avec juste le bémol que je l’ai fait sous Tasmota au lieu d’omg par souci de cohérence car j’ai déjà des tasmota pour la teleinfo.
Je n’ai pas franchi le pas ssd car l’odroid n’est pas boot ssd en natif il faut que je prenne le temps de faire des modifs dans le soft de boot ou que j’attende que ça devienne un jour natif.
J’ai aussi modifié le scénario d’affichage sur le smartledmessenger qui était trop lourd. En attendant d’apprendre comment passer des messages vers l’afficheur et de le passer en mqtt, ce qui est dans ma liste des choses à faire.
Donc oui on peu fermer ce sujet, je n’ai plus eu de pb mémoire et ma charge est en ce moment :
Charge 0.11 - 0.22 - 0.3
Merci
Bien cordialement
