j’ai quelques appareils qui utilisent le protocole MQTT pour envoyer leurs infos à Jeedom. En particulier, j’ai openDTU qui gère ma production solaire, de la téléinfo via Tasmota, et un compteur Shelley. Tout ce petit monde est un peu bavard, et depuis quelques jours je me retrouve confronté à un problème de saturation de la file d’attente.
Dans les logs de jMQQTd, j’ai des lignes du genre:
Sending 40 messages (49541 left in queue)
J’ai temporairement résolu le problème en configurant openDTU pour qu’il n’envoi des données que toutes les 60s au lieu des 10s précédentes. jMQTTd a maintenant le temps de traiter la file, elle reste à 0.
Mais je ne comprends pas pourquoi ce problème est apparu soudainement. Ma config fonctionnait depuis des mois. La matériel (raspberry PI 4) n’a pas changé.
Auriez-vous des pistes de recherche ? J’aimerai au moins redescendre la communication des mes appareils à 30s.
Est-il possible de « purger » la file d’attente ?
Non, il n’est pas possible de purger la file d’attente, car tous les messages MQTT doivent être reçu séquencelement pour que le tout ait du sens.
jMQTT est conçu pour traiter plusieurs milliers de messages par seconde, la seule chose qui le ralenti est Jeedom lui-même et les évènements qu’il doit traiter lors de la réception de chaque message.
As-tu d’autres alertes dans les logs ?
Tu devrais voir des messages de niveau WARNING indiquant que certains messages sont traités lentement par Jeedom, peux-tu poster ces logs et regarder pourquoi ils sont aussi long à ingérer stp ?
Bonjour,
Je n’ai pas de warnings dans les logs.
Voici le log jMQTTd sur quelques minutes. On voit lignes 73 et 261 que le nombre de messages en attente à augmenté.
J’ai trouvé qu’en redémarrant le daemon, la file se vide (puis commence à se remplir…).
Bonjour,
désolé pour l’absence de réponses mais entre les vacances puis le boulot, j’ai laissé tombé pour le moment. Le défaut semble toutefois directement lié à la chaleur extérieure. Maintenant que le PI est à 30°C, tout fonctionne, les défauts se produisaient à partir de 42°C dans l’armoire informatique… J’en déduis que le PI réduit sa puissance pour ne pas surchauffer, ce qui entraîne un traitement moins rapide des données.
J’ai tout de même travaillé à réduire la charge sur le broker mqtt. Pour certains appareils, je vais chercher les infos via leurs API plutôt que de laisser l’appareil spammer en MQTT.
Je reviendrai vers vous si le défaut se reproduit
Le problème n’est pas le « spam » en MQTT, mais les actions que tu réalises dans Jeedom lorsque tu reçois un message sur ce topic.
Chaque fois qu’il y a des problèmes de charge de ce type, c’est lié aux scénarios/virtuels qui sont très consommateurs et pourraient être optimisés.
Exemple récent : calcul d’un total de conso (Heure, J, M, A) avec un scénario déclanché lors de la réception d’un nouvel index du compteur (toutes les 30 secs…)
Optimisation simple : il suffit de lancer un scénario toutes les heures pour faire le delta depuis le dernier index, et éventuellement on mets à jour les autres indexes (toutes les heures pour avoir une valeur intermédiaire, ou juste au bon moment du jour/mois/an).
Résultat : charge divisée par 8, plus de messages dans la file de jMQTT, température du système réduite de 4°C.
non non, je maintiens que certains appareils spamment… J’utilise openDTU pour monitorer mes panneaux solaires. J’ai besoin de 3 infos par panneau (joignable, actif, puissance produite). Ayant 4 panneaux, ça fait 12 infos, plus la production totale. Le système envoie une cinquantaine d’infos par panneau (rendement, voltage DC, voltage AC, température, etc…) plus des infos système (IP, qualité du wifi, etc…). Environ 230 données par envoi, 95% d’inutiles pour la plupart des utilisateurs.
A qui ça sert d’envoyer à chaque fois la prod de la veille. Elle ne change qu’une fois par jour ! La version du firmware, elle ne changera jamais, pourquoi l’envoyer plus d’une fois par jour ?
Selon moi, dès qu’un appareil envoi plus de données que nécessaire, c’est du spam.
J’ai proposé à l’auteur de diviser en 3 groupes (production, infos interne et infos système) pour pouvoir choisir ce qu’on veux envoyer mais il refuse mes modifs.
Maintenant que je vais chercher mes 13 infos via l’API, plus aucune charge sur le broker, la file d’attente dans Jeedom qui ne gonfle plus et ma maison réagit immédiatement aux variations de production.
Je continu d’utiliser MQTT pour mes capteurs et mes prises connectées et votre plugin est génial pour la gestion sous Jeedom, mais certain concepteurs d’appareil devraient comprendre qu’il faut pouvoir ajuster la verbosité. A minima, n’envoyer que les nouvelles données.
Si tu ne crées pas de commande dans jMQTT sur ces topics inutiles, alors Jeedom ne devrait même pas voir ces messages, donc il ne devrait y avoir aucun ralentissement.
J’aimerai bien que tu testes, si ça ne te dérange pas.
Et ce n’est pas Mosquitto (le « vrai » Broker) qui sera chatouillé par quelques centaines de messages par seconde.
Par contre, je comprends ton point de vu et que le passage par l’API te convienne mieux.
On pourra donc clore le sujet une fois le test fait.