J’utilise actuellement d’un coté, le plugin-shelly pour interroger mes shelly EM.
Celui-ci me renvoie toutes les minutes les valeurs (si je me souviens bien, j’ai ajouté la fonction « cron() » pour l’avoir à la minutes)
→ C’est bien pour ne pas trop surcharger le système en appels de scénarios mais encore trop lent.
D’un autre coté, je passe par plugin-jmqtt pour avoir les valeurs en temps réel:
→ C’est mieux pour plugin-suiviconso
A l’inverse, ces valeurs sont remontées quasiment toutes les secondes.
Du coup, impossible à exploiter par scénarios car ils sont appelés à trop nombreuses reprises.
J’avais lu un post (mais impossible à retrouver), un moyen de « limiter » virtuellement la quantité de messages reçus, afin de ne pas trop lancer de scénarios simultanément.
Idéalement, j’aimerais une exécution toutes les N secondes afin de ne pas surcharger le système mais garder un temps de réponse acceptable pour un affichage sur des awtrix.
Si quelqu’un à souvenir de ce post, ou à une idée pour répondre à mon besoin, je lui en serai reconnaissant.
Donc j’imagine que les valeurs sont historisées si tu t’en sers pour le suivi conso ?
Dans ce cas pourquoi ne pas mettre ton scénario qui exploite ces données sur un cron et d’exploiter l’historique plutot que la dernière valeur ?
Sinon je ne vois pas comment limiter le nombre de messages reçus mais je n’utilise pas jmqtt.
Cependant une « bidouille » pourrait être de n’autoriser qu’une seule exécution simultanée du scénario (ce qui est normalement le cas par défaut) et de mettre par exemple un sleep 30 à la fin du scénario. Si de nouvelles mesures arrivent entre temps, jeedom ne relancera pas le scénario car l’exécution précédente n’est pas terminée.
Je n’ai jamais testé les scripts côté Shelly mais peut-être qu’il y a moyen de remonter une information sur un topic différent et avec une période différente.
Un scénario est une possibilité, mais j’éviterais de mettre un sleep qui va le mettre en attente tout le temps. Selon ce qu’on souhaite, on peut aussi juste le déclencher de manière programmée toutes les x minutes et aller chercher la valeur. On peut aussi utiliser un bloc « SI » avec une condition sur collectDate au tout début, ça devrait fonctionner même si ça ne réduit pas le nombre de lancement de scénarion (peut-être qu’il est possible de mettre collectDate dans le déclencheur mais je ne suis pas certain).
Enfin, en termes de bidouille, une option est de passer par un virtuel et d’utiliser ce dernier comme déclencheur de scénario. En faisant cela, il me semble que le scénario ne se déclenche que sur changement de valeur.
C’est dans les paramètres avancés de la commande. Tu peux définir la fréquence max de valeurs à prendre en compte.
Ca ne sert à rien de gérer ceci dans le Shelly. Le mqtt est capable de gérer des milliers de messages par minute, c’est jeedom le facteur limitant. Il faut traiter là !
Effectivement, ce n’est pas le MQTT le facteur limitant. Mais traiter le sujet au niveau du Shelly permet justement d’éviter à Jeedom de le traiter.
Pour l’option dans la configuration de la commande, si on parle de « Limiter à une valeur toutes les » cela n’agit que sur l’historisation. Même avec l’option activée, la valeur est mise à jour et il y a déclenchement d’un scénario qui l’utiliserait.
