12-08-2025, 03:41 PM (Modification du message : 12-08-2025, 03:55 PM par Sgb31.)
je veux bien fastfrench mais pas chez moi actuellement, difficile de lancer ton script comme ça ...
A voir si lolo69 ou André ont une idée sur ce comportement ..
Pour ma part, je pense que le routage s'effectue bien malgré tout .
Je passe parfois 1 à 2 minutes entre 2 erreurs de timeout jusqu'à 15 minutes environ ...
FastFrench
Coté actions sur le routeur principal, j'ai un paramétrage des plus simples
un triac piloté ainsi ( voir le scan )
Config : 3 routeurs F1ATB en V14.25 - 2 routeurs fixes en mode Triacs + 1 routeur mobile polyvalent en mode : Triac+SSR
PV 3kw (8 panneaux TrinaSolar 425W + Onduleur SunGrow 3KW) - Supervision : Home Assistant / Shelly & MQTT
Autoconsommation moyenne >96 % depuis l'usage des routeurs f1atb
OK merci.
Comme tu utilises un triac, le fonctionnement et les temps de réactions peuvent être différents. Donc ça peut expliquer que tu n'aies pas les mêmes symptômes.
(12-08-2025, 07:41 AM)Sgb31 a écrit : Bonjour ,
Petit retour sur la maj 15.01
précédemment j'avais pas mal de messages Shelly Failed ...
si avec la 15.01, j'ai moins de messages ou plutôt les messages sont plus espacés ,
j'ai maintenant des messages " client Shelly Em Timeout !" que je n'avais pas avant .
voir en PJ recopie écran des données brutes de mon routeur maitre situé à 1 m du shelly dans la même pièce.
Salut , je ne suis pas encore en version 15.01 mais j'ai aussi des alarmes de shelly failed et de client shelly em timeout avec les versions 15.00, 14.25 et encore d'autres précédentes.
Pourtant la box se trouve 1m au dessus du shelly et le shelly est à moins de 2m du routeur separé par un mur en placo donc trés proche.
12-08-2025, 07:52 PM (Modification du message : Hier, 12:10 AM par Lolo69.)
Ce n est pas un problème de distance. Ce n’est pas la com ethernet ni wifi qui sont en causes. C’est presque le contraire… le shelly peine parfois à répondre aux requêtes get envoyées par le routeur son micro contrôleur arrive à ses capacités de traitement
Je vais essayer d’analyser les trames ethernet car paradoxalement c est mon esp 32 que j’ ai boosté les requetes à 100ms qui est le plus stable par rapport à l esp que j ai ralenti à 10 secondes !!! J ai une petite idée du pourquoi mais cela demande vérifications . J imagine que quand les requetes get sont rapprochés le shelly ne ferme pas les sockets donc pas besoin de les rouvrir donc gain de temps car moins de travail avec des trames complexes
Sinon cote reboot la modif apportée par la ré connexion automatique en cas de perte wifi à eliminé à 100% les reset intempestifs. Affaire à suivre
12-08-2025, 10:14 PM (Modification du message : Hier, 09:09 AM par michy.)
Bonjour,
une piste :
je n'ai pas de Shelly mais de ce que je comprends, il y a plusieurs modèle (Shelly EM, Shelly 3EM, shelly PRO, PRO EM50 ... ) mais seulement 2 choix dans le prog d'André
chacun des choix est programmé légèrement différemment dans le programme RMS
pour identifier le problème :
Si vous pouviez préciser le modèle que vous utilisez, celui qui vous avez sélectionné dans les paramètres et si vous êtes dans le cas 'tout va bien' ou le cas "Au secours"
+ il semble qu'on peut programmer un relais sur ce/certain modèle, faire du MQTT ... donc si vous avez paramétré quelque chose sur votre exemplaire, dites le et aussi les informations concernant la version firmware de votre Shelly
Modèle physique du Shelly :
Paramètre Source de mesure:
Quantité d'erreurs (par heure ou par jour)
Les erreurs apparaissent aussi la nuit :
Version firmware shelly:
Paramétrage modifié sur le shelly :
Version RMS F1ATB :
Hier, 08:57 AM (Modification du message : Hier, 08:57 AM par cupriste.)
(12-08-2025, 10:14 PM)michy a écrit : Bonjour,
une piste :
je n'ai pas de Shelly mais de ce que je comprends, il y a plusieurs modèle (Shelly EM, Shelly 3EM, shelly PRO, PRO EM50 ... ) mais seulement 2 choix dans le prog d'André
chacun des choix est programmé légèrement différemment dans le programme RMS
pour identifier le problème :
Si vous pouviez préciser le modèle que vous utilisez, celui qui vous avez sélectionné dans les paramètres et si vous êtes dans le cas 'tout va bien' ou le cas "Au secours"
+ il semble qu'on peut programmer un relais sur ce/certain modèle, faire du MQTT ... donc si vous avez paramétré quelque chose sur votre exemplaire, dites le et aussi les informations concernant la version firmware de votre Shelly
Modèle physique du Shelly :
Paramètre Source de mesure:
Quantité d'erreurs (par heure ou par jour)
Les erreurs apparaissent aussi la nuit :
Version firmware :
Paramétrage modifié sur le shelly :
Bonjour,
Voici les informations me concernant, j'ai des défauts qui apparaissent dans la page données brutes mais à l'utilisation je ne remarque rien de particulier . J'ai un probléme de sondes de températures mais je ne pense pas que cela soit lié .
Modèle physique du Shelly : Shelly pro em 50
Paramètre Source de mesure: Shelly pro em
Quantité d'erreurs (par heure ou par jour) : client shelly em timeout2! ( toutes les 10 minutes) , connection to shelly em failed ( toutes les 10 secondes)
Les erreurs apparaissent aussi la nuit : oui
Version firmware : Version 15:00 ( je l'avais dèjà dans les versions précédentes)
Paramétrage modifié sur le shelly : non
Hier, 09:59 AM (Modification du message : Il y a 1 heure par Lolo69.)
Oui,ne vous torturez quand meme pas trop avec les connexion shelly failed, globalement cela n'empeche pas le routeur de fonctionner.
( je n'ai pas regardé le code v15.01 d André pour voir s'il a aussi fait une reconnexion automatique wifi en cas de perte de celui ci plutot que d'attendre le watchdog ( reset) pour le faire.
Finalement je viens de regarder le code de la v15.01 et André n'a pas jugé utile de rajouter les 2 lignes
WiFi.begin(ssid.c_str(), password.c_str()); //LBE WIFI auto restart
StockMessage("wifi reinitialisé");
apres la ligne 1180 du module Solar_router_v15_01
Sans doute l'a t il jugé inutile ou incorrect, en tout cas de mon coté cela à eliminé 100% de mes reboots intempestif d ESP suite à des "micros" coupures de liaison wifi
@André je reviens sur le module source_shellyEm je ne vois aucune fermeture de la connexion clientESP_RMS.stop hormis en cas d'erreur ce qui n'est pas bon puisque la void LectureShellyEm est lancée toutes les 200ms depuis le programme principal et donc ouvre à chaque fois un socket sans jamais le refermer sauf en cas d'erreur : soit il ne faut pas ouvrir la connexion à chaque cycle soit la refermer apres chaque get,
je vais faire les corrections sur ma v12 et je vous donnerai le resultat Apres 14h de fonctionnemet en ayant rajouté un clientESP_RMS.stop apres le requete Get , je n'ai plus aucune erreur de Shelly connexion failed.... avant j'en avais 3 ou 4 par heure , du coup j'ai poussé le bouchon à passer l'echantillonnage à 100ms au lieu de 200+ralenti et ca continue de répondre . je vous confirmerai les résultats demain
=> Bug reset et Shelly résolus ( pas uniquement masqués)
J ai corrigé que pour le shellyEM mais il y a sûrement le meme bug sur les autres modules
Il y a 2 heures(Modification du message : Il y a 2 heures par FastFrench.)
Intéressant. Il y a aussi un autre petit oubli dans le cas du Shelly Pro (pas regardé pour les autres): on utilise l'API pour identifier le Shelly utilisé, et son paramétrage (mono ou triphasé notamment, car ça change la structure des données renvoyées). Mais après cet appel, on oublie de faire un client.stop() avant de faire la connexion suivante.
Par contre lors des mesures par la suite, on pense bien à faire le client.stop() après.
Pour les temps de réponse, j'invite ceux qui ont un Shelly à essayer (ou adapter) le script Python que j'ai donné plus haut: ça vous donne une bonne vision des temps de réponse du Shelly.
Sur une heure, j'ai lancé plus de 30 000 requêtes, sans aucun échec. Par contre à deux reprises (seulement), le temps de réponse était entre 2 et 3 secondes. Et à une dizaine de reprises autour de 1 seconde. La très grand majorité des fois (et en moyenne), c'est autour de 100ms.
Dans mon test, c'était tout en filaire (Shelly sur RJ 45, interrogé depuis un PC connecté aussi en RJ 45): pas de Wifi.
Il y a 1 heure(Modification du message : Il y a 30 minutes par Lolo69.)
(Il y a 2 heures)FastFrench a écrit : Intéressant. Il y a aussi un autre petit oubli dans le cas du Shelly Pro (pas regardé pour les autres): on utilise l'API pour identifier le Shelly utilisé, et son paramétrage (mono ou triphasé notamment, car ça change la structure des données renvoyées). Mais après cet appel, on oublie de faire un client.stop() avant de faire la connexion suivante.
Par contre lors des mesures par la suite, on pense bien à faire le client.stop() après.
Pour les temps de réponse, j'invite ceux qui ont un Shelly à essayer (ou adapter) le script Python que j'ai donné plus haut: ça vous donne une bonne vision des temps de réponse du Shelly.
Sur une heure, j'ai lancé plus de 30 000 requêtes, sans aucun échec. Par contre à deux reprises (seulement), le temps de réponse était entre 2 et 3 secondes. Et à une dizaine de reprises autour de 1 seconde. La très grand majorité des fois (et en moyenne), c'est autour de 100ms.
Dans mon test, c'était tout en filaire (Shelly sur RJ 45, interrogé depuis un PC connecté aussi en RJ 45): pas de Wifi.
wiifi ou filaire les connexions doivent etre refermées, ou en tout cas etre maitrisées, pour ne pas ouvir une connexion toutes les 200ms sans les refermer
pour le shellypro je ne suis pas tout à fait ok avec l analyse de Fast French...pour obtenir le device info on fait bien un get sur une connexion ouverte avant, il ne fait donc refermer la connexion apres ce get car il y en a d'autres Get apres, par contre tout comme le shelly EM la connexion est ouverte toutes les 200 + ralenti ms , mais n'est jamais refermé tant qu'il n'y a pas un falied, qui finit donc forcement par arrivé, et de plus le failed ferme une connexion parmi la pile donc le failed suivatn arrive très vite...
idem pour les module RMS_Externes et source_externe, source_smartG il manque un clientESP_RMS.stop apres le dernier get ( sans erreur de timeout)
