Je suis arrivé sur votre post puisque je suis actuellement entrain de basculer mes Shelly sur JMQTT.
J’en ai moins que Julien74 mais quand même un peu plus de 70.
La bonne nouvelle me concernant c’est que je voulais savoir jusque combien de d’entrée on pouvait avoir sur le plugin JMQTT et j’ai eu ma réponse dans ce fil de discussion.
Je me rend compte qu’au fur et à mesure que je les intègre, ma charge Jeedom augmente pas mal.
Pouvant même parfois monter jusque 4 mais cela reste assez rare.
Au fil de ma lecture, j’ai vu ton post :
Or je suis dans le même cas, la plupart de mes Shelly déjà intégré sont dans l’onglet « Shellies »
Par contre je suis novice, comme j’ai pu le préciser dans un autre post, cela ne fait que deux semaines que j’ai découvert le plugin JMQTT, pour avoir un suivis de mon onduleur et de mes batteries.
Comment faire pour que mes modules Shelly ne soient pas d’office mis dans l’objet « Shellies » ?
Pour info mon broker est en externe sur mon Nas Synology.
J’ai cherché mais il n’y a rien dans la config des modules en eux-mêmes et rien sur le broker non plus.
Je ne pense pas qu’en terme de charge cela change grand chose que le plugin jMQTT update les infos de x objets ou que ces commandes soient dans 1 seul objet.
Moi j’ai fait du nettoyage car j’avais un mix des 2… Donc autant que cela soit propre, et j’ai fait le choix d’avoir des objets indépendants, chaque objet jMQTT représentant 1 shelly.
Si tu regarde la photo que j’ai fait sous MQTT explorer, je suis dans le même cas que toi.
Les derniers Shelly que j’ai acheté qui sont des Plus-Plug-s sont indépendant alors que les EM et Plug-S sont regroupé.
Et je n’ai pas trouvé comment les rendre indépendant.
Questions idiote mais je découvre encore, si je retire les commandes non utilisées directement dans le module JMQTT est ce que ça aide à soulager la communication ?
j’ai utilisé des templates par défaut qui ont ajouté énormément de commande que finalement je n’utilise pas.
Je penses à la température en Farenheit, la commande reboot, tout ce qui concerne le firmware ou les info Wifi comme sur l’image dessous.
Je ne penses pas qu’il soit possible de configurer le module pour choisir ce qu’il envoi ?
Je ne me suis pas encore plongé dans la doc MQTT de Shelly.
De ce que je (pense) avoir compris:
Ce n’est pas vraiment les champs infos dans les objets Shelly qui bouffe le CPU / créé de la latence.
Bon, de mon coté j’ai nettoyé tout ce que j’ai pu quand meme, pour que ce soit propre. Les temperatures internes des modules j’en ai rien à cirer je ne les utilise pas, donc autant les virer.
Ce qui mange vraiment des ressources, c’est lorsque le jMQTT met à jour un champ info, et que ce champ info est utilisé ailleurs dans jeedom, que ce soit un virtuel, un scenario etc… A chaque fois que la valeur change par une trame jMQTT, Jeedom est averti (par un event), et doit bosser pour faire prendre en compte le changement.
C’est pour cela que pour ma part, les valeurs par jMQTT sont donc en « cul de sac ». plus aucun virtuel ne reprend directement ces valeurs.
J’ai donc « juste » mon scenario en PHP qui tourne en tache de fond, va lire ces valeurs et les traite pour fabriquer des données agrégées toutes les 10s / 20s / 30s (lire mon code). Ainsi mes virtuels ne sont mis à jour que très peu et cela créé bien moins d’event dans Jeedom.
