D'accord, je vais essayer ça dès que le soleil tape sur les PV. 
(mes derniers essais étaient avec Réactivité 4, train de Sinus, Réactivité CACSI x4)
Merci

---

Essai pas très concluant. 
   

A l'affichage, j'ai bien les mesures de puissance qui se mettent à jour toutes les 2 secondes, mais cependant quand même des messages TimeOut dans l'onglet Message. 

A noter que la puissance injectée n'est que de qqs watts (ce qui déclenche une consommation supérieure à 1000W en pic, et plusieurs centaines de watts en moyenne).

pourquoi mettre de la réactivité cacsi ? tu n'es pas en mesure linky, donc tu ne dois pas utiliser cette fonction, c'est ce qu'explique André.

(12-08-2025, 12:59 PM)grostoto a écrit : pourquoi mettre de la réactivité cacsi ? tu n'es pas en mesure linky, donc tu ne dois pas utiliser cette fonction, c'est ce qu'explique André.

Faute d'arriver à obtenir un fonctionnement adéquat avec des configurations "logiques", j'essaie un peu tout. 

A vrai dire, je n'ai vu nulle part que cette option était réservée pour les mesures Linky (pas même dans le code). Ça a du m'échapper.

André le précise dans une de ces réponses sur le forum je crois.
cela sert uniquement pour compenser le pb de réactivité de la mesure linky avec cacsi.

il faut rester sur des configurations normales, que tu trouves largement sur le forum, et trouver ou est la différence avec ton montage (défaillance electronique ou autre).

mais je pense que si tu ajoutes des paramètres non prévu..

d'ailleurs, tu n'as pas mis les copies écrans des tes configs paramètre et copie des listes de messages.. des fois cela aide...
on a parfois le défaut écrit devant le bout du nez sans le voir..

Hello. 
Là j'en suis à débugger les actions, pour comprendre comment ça marche et ce qui ne fonctionne pas (c'est finalement assez simple de debugger à distance - via WiFi. Si ça intéresse du monde, je peux faire un p'tit tuto). 
Un truc que j'ai remarqué, mais probablement pas le problème principal: avec une charge de 3kW, on est à une mesure de puissance toutes les 1,2 secondes. 
Sachant qu'en interne le Shelly fait une mesure par seconde (j'ai vérifié, c'et bien la moyenne et l'écart type est faible), en moyenne on connait la puissance consommée avec un retard de 1,7 secondes. C'est beaucoup, et ça pourrait être moins. Je ne comprend pas vraiment la logique de cette variable "ralenti" qui fait - si j'ai bien compris - que plus la charge est importante, plus on va ralentir la vitesse de lecture. Ca me semble particulièrement contre-intuitif: c'est surtout quand on consomme beaucoup qu'il est important d'optimiser la conso. 
Donc j'ai abaissé la vitesse de mesure à 0,2 secondes. Ainsi j'ai en moyenne la température avec seulement 0.7s de retard, en moyenne. C'est toujours ça de gagné. 

Là je pars 1 semaine, je reprendrai mes expériences ensuite.

(Hier, 08:31 AM)FastFrench a écrit : Hello. 
Là j'en suis à débugger les actions, pour comprendre comment ça marche et ce qui ne fonctionne pas (c'est finalement assez simple de debugger à distance - via WiFi. Si ça intéresse du monde, je peux faire un p'tit tuto). 
Un truc que j'ai remarqué, mais probablement pas le problème principal: avec une charge de 3kW, on est à une mesure de puissance toutes les 1,2 secondes. 
Sachant qu'en interne le Shelly fait une mesure par seconde (j'ai vérifié, c'et bien la moyenne et l'écart type est faible), en moyenne on connait la puissance consommée avec un retard de 1,7 secondes. C'est beaucoup, et ça pourrait être moins. Je ne comprend pas vraiment la logique de cette variable "ralenti" qui fait - si j'ai bien compris - que plus la charge est importante, plus on va ralentir la vitesse de lecture. Ca me semble particulièrement contre-intuitif: c'est surtout quand on consomme beaucoup qu'il est important d'optimiser la conso. 
Donc j'ai abaissé la vitesse de mesure à 0,2 secondes. Ainsi j'ai en moyenne la température avec seulement 0.7s de retard, en moyenne. C'est toujours ça de gagné. 

Là je pars 1 semaine, je reprendrai mes expériences ensuite.

hello je suis d'accord avec toi FastFrench , je ne comprend pas l'interet du 200+ralenti .... 
De mon coté en ayant corrigé le bug de connexion ( il manque une fermeture des socket TCP dans les programmes d'André , j'ai meme passé le timer fixe à 100ms et mes routeurs tournent comme des horloges depuis, plus de reset , plus de connection failed et un sentiment ( cela reste un sentiment) d'une meilleure régulation quelque soit le point de fonctionnement.
Si tu le souhaites je peux t'indiquer précisement les 3 lignes à rajouter dans le code source

(Hier, 08:31 AM)FastFrench a écrit : c'est finalement assez simple de debugger à distance - via WiFi. Si ça intéresse du monde, je peux faire un p'tit tuto

Bonjour,

  intéressé de connaitre la méthode utilisée

  Pour le tuto, certainement aussi, (ou un lien ailleurs qui explique)

Les mesures sont ralentis quand on est loin de l'equibre de régulation. Si par exemple vous consommez 2000w et vous avez un seuil à zero, vous n'allez probablement pas rejoindre l'équilibre dans les 200ms qui suivent.
André

(Hier, 02:41 PM)F1ATB a écrit : Les mesures sont ralentis quand on est loin de l'equibre de régulation. Si par exemple vous consommez 2000w et vous avez un seuil à zero, vous n'allez probablement pas rejoindre l'équilibre dans les 200ms qui suivent.
André

en ralentissant la mesure , tu augmentes le temps mort ce qui est ultra néfaste en régulation, il eut été plus judicieux de faire une "reactivité" variable ( comme je l ai fait sur mon RMS CE
         float error=(Puissance - SeuilPw) ;
          error=(abs(error)>50)? error*3 : error;
)

(Hier, 02:41 PM)F1ATB a écrit : Les mesures sont ralentis quand on est loin de l'equibre de régulation. Si par exemple vous consommez 2000w et vous avez un seuil à zero, vous n'allez probablement pas rejoindre l'équilibre dans les 200ms qui suivent.
André

D'accord, merci pour cette précision. Dans mon cas (où la régulation ne marche pas... encore), j'ai l'impression que ce ralentissement aggrave le problème. J'aurai peut-être un autre point de vue quand ça marchera

---

@Lolo69: je crois que j'ai bien compris le problème que tu as soulevé. Du coup le correctif est simple (ajouter un client.stop() après utilisation.

client.connection()
.. utilisation du client
client.stop()

Pour l'instant, le .stop n'est fait qu'en cas d'erreur.

A noter qu'on pourrait aussi envisager de garder la connexion ouverte (ni connection() ni stop() en utilisation normale). Pour une mesure toutes les 100ms, on chargerait moins le Wifi en agissant ainsi. Mais alors il faudrait vérifier la connexion à chaque utilisation, et rétablir la connexion (.stop + .connection) en cas de problème (timeout notamment).

---

(Hier, 02:12 PM)michy a écrit :

(Hier, 08:31 AM)FastFrench a écrit : c'est finalement assez simple de debugger à distance - via WiFi. Si ça intéresse du monde, je peux faire un p'tit tuto

Bonjour,

  intéressé de connaitre la méthode utilisée

  Pour le tuto, certainement aussi, (ou un lien ailleurs qui explique)

D'accord ça marche. Je vais essayer de ne pas oublier de faire ça, à mon retour dans qqs jours. 
Dans les grandes lignes, on peut le faire sans aucune librairie supplémentaire (juste Wifi qu'on utilise déjà). Il suffit de lancer un serveur Wifi (2 lignes) et écrire une petite fonction qui permet d'envoyer un message, qui remplacera les Serial.println().
Pour afficher les messages Debug, il faut juste lancer un client TelNet avec l'IP du routeur et le port utilisé pour le Debug. Telnet ou Putty par exemple. 

J'ai essayé RemoteDebugger au préalable, mais c'est bien plus lourd (le croquis devenait trop gros), et ne m'apporte rien de plus.