Bonsoir à tous,
J’ai un esp8266 avec Tasmota qui interroge mon compteur électrique via le port P1 et publie les infos sur jmqtt. Le compteur publie 2 grosses chaines de caractères 1x par seconde.
JMQTT recois bien toutes les données, mais peine à suivre la cadence et visiblement repli son buffer. Donc après une journée, Jmqtt publie les infos avec plus de 45 minutes de retard!
Quelqu’un saurait-il comment faire que tasmota publie à un intervalle autre que 1s?
Ou comment vider periodiquement le buffer de jmqtt?
Bonjour,
Il y a plusieurs sujets ici la dessus.
Le problème n’est pas jMQTT mais jeedom derriere. Vérifiez les traitements que vous avez ajouté sur les données. (Scénarios, historisation, etc mais regardez les sujets ils en parlent mieux que moi)
Si vous n’avez pas le choix peut être découper le telegram dans l’équipement plutôt que dans jeedom…
Ou alors il y a homewizard qui fait un petit équipement pour le P1 belge qui fait ça bien avec mon plugin gratuit et vous pouvez descendre à la seconde.
1 « J'aime »
Merci pour ta réponse rapide. Oui,je n’ai pas trouvé comment traiter l’info dans tasmota. J’ai aussi essayé espeasy, mais sans succès. Je vais voir avec le bidule pour les belges.
Mais attention, en fonction des traitements que vous ferez sur les données, ça peut aussi saturer ou charger votre jeedom… il faut que vos actions liées soient limitees
1 « J'aime »
si tu as déjà l’esp avec l’adaptateur p1 (je ne sais pas exactement ce que tu as comme matos), tu peux aussi utiliser plugin-smartmeterp1
voir ici pour flasher: Compteur intelligent belge. Comment récupérer les données avec Jeedom? – DomoHab
1 « J'aime »
Si vous utilisez tasmota, vous avez toutes les infos dans la doc.
Voir les paramètres noraw,full,changed, skip et limit
Notamment les paramètres changed pour n’envoyez que les valeurs modifiées et skip qui permet de t’envoyer qu’une trame sur x
Norbert
J’avais le même genre de problème, retard à l’allumage sur la réception des messages MQTT, parfois jusqu’à 10mn sur les infos envoyées par un Shelly 3EM.
Totalement disparus depuis le passage d’un rpi3b vers rpi5 (sous debian 12), aujourd’hui tout est pratiquement instantané.
J’avais le même problème avec un RPI4 que j’avais résolu en passant sur un RPI5 mais depuis quelques jours j’ai de nouveau le problème.
Le retard provient du plugin JMQTT car j’ai créé deux équipements sur le même topic: un dans JMQTT et un dans MQTT-Manager pour un Relais Shelly.
Quand je bascule le relais l’état remonte immédiatement via l’équipement MQTT-Manager et pas via l’équipement JMQTT. Pourtant ce dernier équipement fonctionnait très bien il y a une semaine.
Même problème, même remarque. Relisez ce qui est écrit.
1 « J'aime »
Merci de votre réponse mais il doit y avoir un vrai problème avec le plugin JMQTT.
J’ai doublonné tous mes objets MQTT dans MQTT-Manager en utilisant les mêmes topics MQTT et ceux là fonctionnent très bien.
Les informations remontent très bien dans les objets MQTT-Manager et pas dans les mêmes objets JMQTT.
Coté performance Jeedom tourne sur RPI5 alors pas de souci de ce coté là
Vous avez lu mes messages précédents ??
Regardez aussi les autres sujets sur jMQTT il est bien expliqué que celui ci attends une réponse de jeedom avant d’envoyer le message suivant, donc si jeedom a un temps de traitement important il sera plus lent que un autre plugin qui envoi tout à la chaîne sans se soucier de cela…
En réduisant le temps de traitement sur une commande (comme inexpliqué plus haut) vous aurez de meilleurs résultats ! Les autres plugins ne sont qu’une illusion de rapidité…
Merci j’ai bien mieux compris le problème avec votre dernière réponse et le post sur la Saturation apparente du broker avec Shelly