JMQTT avec 3 Shelly 3EM --> saturation?

Bonjour à tous,

J’utilise JMQTT pour remonter les infos de 3 modules Shelly 3EM. J’ai des remontées de 9 pinces amperemétriques au total. Tout tournées plutôt bien jusqu’il y a quelques jours, seules 7 pinces étaient raccordées. Je viens de raccorder les 2 dernière et j’ai des plantages réguliers (gros décalage des valeurs entre l’appli Shelly et les remontées dans Jeedom).
Parfois je perds complètement la connexion avec mes Shelly et je suis obligé de les rebooter pour que les infos s’actualisent sous Jeedom.

Pour info je suis en Jeedom 4.3.17 sur une VM et JMQTT dernière mise à jour

Ci-dessous le LOG du broker:

[2023-04-17 00:56:03]WARNING : Attention, Payload '750.5' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/2/total' traité en 427ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:2:total]#
[2023-04-17 00:56:18]WARNING : Attention, Payload '954.59' reçu sur le Topic 'shellies/shellyem3-244CAB43632F/emeter/1/power' traité en 307ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 2][emeter:1:power]#
[2023-04-17 00:56:18]WARNING : Attention, Payload '1401.74' reçu sur le Topic 'shellies/shellyem3-244CAB43632F/emeter/2/power' traité en 496ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 2][emeter:2:power]#
[2023-04-17 00:56:21]WARNING : Attention, Payload '963.25' reçu sur le Topic 'shellies/shellyem3-C8C9A3704FB5/emeter/1/power' traité en 514ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 1][emeter:1:power]#
[2023-04-17 00:56:32]WARNING : Attention, Payload '1393.38' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/power' traité en 752ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:power]#
[2023-04-17 00:56:48]WARNING : Attention, Payload '953.22' reçu sur le Topic 'shellies/shellyem3-244CAB43632F/emeter/1/power' traité en 409ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 2][emeter:1:power]#
[2023-04-17 00:57:02]WARNING : Attention, Payload '1389.73' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/power' traité en 637ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:power]#
[2023-04-17 00:57:03]WARNING : Attention, Payload '4763747.1' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/total' traité en 1493ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:total]#
[2023-04-17 00:57:04]WARNING : Attention, Payload '242.15' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/2/voltage' traité en 373ms (très long), vérifiez les commandes affiliées : Aucune
[2023-04-17 00:57:20]WARNING : Attention, Payload '963.92' reçu sur le Topic 'shellies/shellyem3-C8C9A3704FB5/emeter/1/power' traité en 322ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 1][emeter:1:power]#
[2023-04-17 00:57:32]WARNING : Attention, Payload '1386.49' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/power' traité en 570ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:power]#
[2023-04-17 00:57:58]WARNING : Attention, Payload '516.50' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/power' traité en 851ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:power]#
[2023-04-17 00:58:00]WARNING : Attention, Payload '455.42' reçu sur le Topic 'shellies/shellyem3-244CAB435603/emeter/1/power' traité en 572ms (très long), vérifiez les commandes affiliées : #[Sous-Sol][Shelly 3EM 3][emeter:1:power]#

J’ai des WARNING toutes les secondes.

J’ai comme l’impression que les infos arrive trop fréquemment et que je n’ai pas assez de ressource pour traiter l’afflux de données. Qu’en pensez-vous ?

Y a t’il possibilité de définir le délai de rafraîchissement afin d’augmenter ce dernier ?
J’ai tenté un http://192.168.xx.xx/settings?mqtt_update_period=30 mais cela ne change rien, j’ai l’impression que les données sont rafraichies toutes les secondes.

Auriez-vous une piste de ce bug ?

Cordialement

Hello @smoreau59,

Merci pour ton message et désolé que tu rencontres des problèmes avec le plugin.

Ce n’est qu’un warning, ça ne devrait pas empêcher la réception des données, mais t’alerter sur le fait que certaines commandes sont probablement très utilisées par d’autres et ralentissent considérable ton Jeedom.

Ces logs ont été mis en place suite à l’analyse faite dans ce message :

Peux tu vérifier que ces commandes ne sont pas en type info Autre et historisées ? (Fait voir un capture d’écran stp)

Regarde aussi quels équipements utilisent ces commandes, lors de l’analyse précédente, il y en avait des 10 aînés.

Bonne journée,
Bad

Hello @Bad,

merci pour ton retour.

Alors j’ai un brocker + 3 équipements dans JMQTT:
Capture d’écran 2023-04-17 à 08.28.30

Je n’historie rien dans ces équipements (ex. ci-dessous):

Par contre j’utilise ses infos dans des virtuels, ces infos sont utiliser pour lancer des calculs qui déclenche des scénarios (ex. ci-dessous):



et là l’historique est activé (sans lissage) et la purge ce fait tout les 7 jours.

Je remarque que quand certaines pinces ampéremetiques ne sont pas sollicité (valeur à 0w) RAS. Par contre si les 9 pinces sont en fonctionnement, les 9 envoient des refresh toutes les secondes et mes 3 équipements dans JMQTT finissent tous par perdre la connexion. Un reboot de ces derniers via l’appli Shelly relance la connexion.

A ton avis il faut que je travaille pour réduire la sollicitation des Infos ? Je n’ai pas possibilité de réduire la fréquence à laquelle le Brocker importe les données ?

Merci à toi pour ton aide.
Sébastien

Peux-tu partager le résultat sur ton navigateur de http://ip_module/settings/ ?

Après cette modification, as-tu fait un reboot du module ? Car certains changements nécessitent un reboot.

Oui en effet, regarde combien de scénario sont declanchés et de commandes sont mises à jour pour ces commandes jMQTT et ce virtuel.

Si tu peux lancer des scénarios programmés (même toutes les minutes), la où tu n’as pas besoin de valeurs exactes instantanément, plutôt que de les déclancher à chaque changement, ça allègera déjà bien ton système.

Par exemple, j’avais un virtuel qui me calculait la température moyenne, min et max, intérieur et extérieur sur mes 15 sondes.
Je n’avais pas besoin d’une température à la seconde où un capteur se mettait à jour, j’ai donc retiré les calculs de mon virtuel et fait un scénario déclanché toutes les 5 minutes qui fait les calculs et maj le virtuel.
Gain de pref instantané !

Bad

Oui, voilà le résultat:

{"device":{"type":"SHEM-3","mac":"C8C9A3704FB5","hostname":"shellyem3-C8C9A3704FB5","num_outputs":1,"num_meters":0,"num_emeters":3,"report_period":1},"wifi_ap":{"enabled":false,"ssid":"shellyem3-C8C9A3704FB5","key":""},"wifi_sta":{"enabled":true,"ssid":"OWRT_2G","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"ap_roaming":{"enabled":false,"threshold":-70},"mqtt": {"enable":true,"server":"192.168.1.28:1883","user":"","id":"shellyem3-C8C9A3704FB5","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":true,"keep_alive":60,"max_qos":0,"retain":false,"update_period":30},"coiot": {"enabled":true,"update_period":15,"peer":""},"sntp":{"server":"time.google.com","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"admin"},"pin_code":"","name":null,"fw":"20221027-110030/v1.12.1-ga9117d3","discoverable":false,"build_info":{"build_id":"20221027-110030/v1.12.1-ga9117d3","build_timestamp":"2022-10-27T11:00:30Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Paris","lat":48.831299,"lng":2.266500,"tzautodetect":true,"tz_utc_offset":7200,"tz_dst":false,"tz_dst_auto":true,"time":"14:41","unixtime":1681735293,"led_status_disable":false,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":true,"names":["out_on_url","out_off_url","over_power_url","under_power_url","over_power_url","under_power_url","over_power_url","under_power_url","over_power_url","under_power_url","n_mismatch_url"]},"hwinfo":{"hw_revision":"dev-prototype", "batch_id":0},"cf_output":0,"relays":[{"name":null,"ison":false,"has_timer":false,"default_state":"last","auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[]}],"emeters":[{"name":null,"appliance_type":"General","max_power":0,"range_extender":1},{"name":null,"appliance_type":"General","max_power":0,"range_extender":1},{"name":null,"appliance_type":"General","max_power":0,"range_extender":1}],"emeter_n":{"range_extender":1,"mismatch_threshold":1.00},"eco_mode_enabled":true}

J’ai rebooté hier à minuit et pour le moment ça semble tenir le coup. J’ai dans les Setting un update tout les 15sec mais dans mes historiques jeedom j’ai une valeur tout les 4 à 5 secondes.

@Bad,

sur base de ton 1er message j’ai allégé mes virtuels et depuis hier minuit ça semble stable. Je vais suivre tes conseils. Ton idée du calcul avec scénario me semble pas mal pour alléger le sytème. Je tente ça dès ce soir et je croise les doigts.

Merci

As-tu essayé avec "coiot" si cela a une incidence ?

http://192.168.xx.xx/settings?coiot_update_period=30

Ah non, je test de suite sur l’un de mes 3 Shelly pour voir si ça change quelquechose. Merci :wink:

Pendant qu’il teste, je fais mon incrust :innocent:
Justement c’est quoi coiot
Il faut cocher ou pas, ça sert à quoi. J’ai cherché mais tout ce que je trouve est en anglais que je speak très mal :confused:

A part te dire que c’est un autre protocole de communication, je n’ai pas été chercher plus loin pour le moment.

Ne pas confondre avec coït car même en cochant la case, ça ne changera rien :smiley:

C’est ce que j’avais cru comprendre aussi, mais tu m’a mis un doute en lui demandant de modifier l’update de ce protocole alors qu’on utilise mqtt :slight_smile:

J’ai testé de passer l’update du COIOT à 30 secondes + reboot mais ça ne change rien, j’a toujours un refresh des valeurs toutes les 4/5 secondes.

"device":{"type":"SHEM-3","mac":"244CAB435603","hostname":"shellyem3-244CAB435603","num_outputs":1,"num_meters":0,"num_emeters":3,"report_period":1}

Je vois un report_period=1; est-il possible de changer cette valeur ?

Rien trouvé dans la doc.

@Jeandhom, j’ai cherché également mais je n’ai pas trouvé. Pour le moment la solution de @Bad semble fonctionner. J’ai allégé mes virtuels + scénarios et maigres le refresh JMQTT toutes les 4/5s ça semble tenir.

1 « J'aime »

Capture d’écran du 2023-04-17 17-12-21

Peut-être un dernier test en décochant CoIoT ?

Tes 3 modules ont le même hardware ? "hw_revision":"dev-prototype"

Parfait !
Comme dit, c’est plus un souci avec « l’usage que tu faisais de Jeedom », et je mets bien des guillemets par ce qu’il n’est pas question de te jeter la pierre, mais de noter que ça aurait pu se produire avec n’importe quel autre plugin qui mitraille Jeedom d’événement : il faut faire attention à ne pas déclancher des actions trop coûteuses ou trop fréquentes derrière.

Quand jMQTT se connecte à mon broker, Jeedom prend ~2700 event en l’espace de quelques secondes. Pourtant il ne sourcille même pas et les éponge en moins de 10s (VM 2vCPU 2Go de RAM) parce que je fais attention à ce qui est déclanché.

Mais le but n’est pas de donner des leçons, plus d’expliquer que jMQTT est fait pour en bouffer une sacrée louche.

Bad

1 « J'aime »

@Jeandhom, je viens de tenter de désactiver CoIoT sur un module Shelly → Malgré un reboot du module, j’ai perdu la connexion avec Jeedom
J’ai réactivé CoIoT et la connexion est revenue…

Oui J’ai bien le même hardware « hw_revision »:« dev-prototype » sur mes 3 modules.

Ca va faire 24h que ça semble tourner, je vous tiens au courant :hand_with_index_finger_and_thumb_crossed:

J’ai fait la même manip et aucun soucis de mon côté.
Je vais d’ailleurs faire la même chose sur mes autres Shellies car cela doit utiliser des ressources pour rien.