Hello @jerryzz,
Merci pour ta question, en effet, l’explication n’est pas très simple à comprendre.
Il est crucial que les messages MQTT soient reçus et traités dans l’ordre, sinon ils n’ont plus de sens : « OFF, puis ON, puis toute suite OFF », n’est pas du tout équivalent à « OFF, puis OFF, puis toute suite ON ». Donc jMQTT doit traiter les messages dans l’ordre exact d’arrivée.
Ce message de WARNING indique que le traitement des évènements associés avec cette commande à pris beaucoup de temps. Le « temps de traitement » correspond au temps mis par le Core de Jeedom pour rendre la main à jMQTT.
La « limite acceptable » de temps de traitement d’une commande par jMQTT est définie statiquement à 300ms et le « chrono » marche comme ça (hors démon) :
- réception d’un nouveau message MQTT,
- (début du « temps de traitement »),
- identification des commandes pour lesquelles une valeur peut être modifiée,
- découpage du message si jsonPath utilisé dans les commandes,
- event pour mise à jour de la valeur des commandes identifiées,
- (fin du « temps de traitement »),
- attente de nouveaux messages.
Le temps de traitement est important, si les évènements qui en découlent (maj de virtuels en cascade, lancement de scenarios, etc) sont nombreux et/ou prennent trop de temps au Core.
Dans des cas extrêmes, si le temps de traitement est toujours très important, le phénomène peut ralentir la réception des messages et créer un étalement dans le temps des messages, donc une perte de réactivité des retours d’états et de l’execution des commandes.
Du coup, si ce temps de traitement est systématiquement trop important, il faut que tu cherches pourquoi et que tu allèges le temps de traitement des commandes qui en découlent.
Tu n’as pas non plus un très grand nombre d’équipements ou de commandes jMQTT, mais je vois que tu fais référence aux modules Shelly qui sont connus pour envoyez très souvent des données en MQTT.
Regarde quels autres commandes et scenario utilisent les commandes #[MQTT][shellies][shelly-em1:emeter:0:power]# et #[MQTT][shellies][shelly-em1:emeter:1:power]#, s’il y a trop de choses déclenchées lors de l’évènement de changement de valeur, ça peut être ta cause.
TL;DR : Perso, je commencerais par chercher tous les scénarios mis à jour à la volée par ces 2 commandes et j’essayerais de retirer les déclencheurs pour les transformer en scénarios programmés (par ex toutes les 1 ou 5 minutes selon ce que tu veux faire des infos.
Je vois aussi que tu es sur un PI3 B, avec >2 de charge, il est peut-être aussi à sa limite.
Bad