Version V15.01 du routeur

[Lolo69]

De mon côté je n'ai plus aucun messages d'échec de connexion ou de timeout avec vraiment une impression de régulation plus efficace 

Merci pour ton retour, je constate la même chose.
Pour rappel Clyon44 à mis à jour la version RMS 15.01 par celle-ci RMS 15.01 Lolo69  qui corrige des bugs qui sont décrits à la page 3 de cette discussion

De mon coté j'ai également rajouter une réactivité variable tel que codée ci-dessous, Clyon si tu veux essayer je pourrais de mettre le bon a dispo
le principe est de pouvor garder une reactivité assez grande quand on est loin du seuil PW mais de ne plus trop bouger la sortie quand cette ci est proche du seuil
la petite partie derivative permet d'accelerer la sortie quand un gros consommateur se met en marche ou s'arrete ou qu 'un gros nuage passe

Code :

          float error=(Puissance - SeuilPw) ;
          error=(abs(error)<100)? error/10 : error;
float derivative = Puissance - previous_error;
RetardF[i] = RetardF[i] + error * GainBoucle / 10000 + derivative/2500000000;
previous_error = Puissance;

[Sgb31]

@ lolo69
ta version RMS 15.01 lolo69 est elle full identique à celle d'André hormis cette évolution propre au Shelly ou ya-t-il également d'autres modifs ?
Si ok, je suis assez fan de la tester également ;-) !

[Lolo69]

@ lolo69
ta version RMS 15.01 lolo69 est elle full identique à celle d'André hormis cette évolution propre au Shelly ou ya-t-il également d'autres modifs ?
Si ok, je suis assez fan de la tester également ;-) !

Ma version 15.01.LBE1 est full identique à celle d André hormis le bug wifi shelly et reconnection automatique en cas d arret bref du wifi

Je mettrai la version régulation optimisée ici un peu plus tard

[Lolo69]

Deux nouvelles versions qui découlent directement de la V15.01 d'André

Si vous êtes en V15 ou V15.01 vous pouvez directement faire la mise à jour OTA , il n'y a pas de modifications des paramètres

Solar_Router_V15.01.Lolo69.1.ino
Par rapport à la version d 15.01 d'André celle-ci corrige les 2 bugs Suivants
- Redemarrage de la liaison wifi avec la box en cas defaut de WIFI de courte durée, cela evite de nombreux Reset d ESP inexpliqués
- Fermeture des liaisons TCP apres lecture des données dans les Shelly EM et Shelly Pro EM , cela devrait eliminer une grande majorité des message connexion Shelly Failed ou TimeOut 
- La conséquence est une lecture des puissances plus fluide qui améliore donc la régulation.
(Testé sur un Shelly Em et RMS connecté via repeteur TPLINK à 60 mètres de la box)

Solar_Router_V15.01.Lolo69.2.ino
Cette version reprend les correctifs de la Lolo69.1 et vous propose en plus de tester un algorithme qui devrait améliorer la performance de la régulation de puissance.
Selon vos réglages initiaux de la réactivité, vous aurez peut être besoin d'augmenter celle-ci légèrement pour observer l'amélioration.
Dans le principe s'il y a un écart important entre les SeuilPW et la mesure de puissance , on booste la réactivité pour revenir rapidement à la consigne mais sans rentrer en oscillation.
(Testé sur RMS avec SSR Mode Multisinus sur CE Electronique 2,4kW )

[Sgb31]

De mieux en mieux Lolo69, tu est à fond sur ce coup , bravo à toi ;-) !
perso, je vais d'abord tester le V1.lolo69 demain avant de passer sur l'autre
je ferais bien entendu un retour de ce que je constate sur une à deux journée d'exploitation.
Actuellement depuis la V15.01 d'André , moins d'erreur constatées ( voir recopie écran jointe)

[Lolo69]

J' ai integré sur les memes liens la correction egalement pour la connexion RMS

[clyon44]

Deux nouvelles versions qui découlent directement de la V15.01 d'André

Si vous êtes en V15 ou V15.01 vous pouvez directement faire la mise à jour OTA , il n'y a pas de modifications des paramètres

Solar_Router_V15.01.Lolo69.1.ino
Par rapport à la version d 15.01 d'André celle-ci corrige les 2 bugs Suivants
- Redemarrage de la liaison wifi avec la box en cas defaut de WIFI de courte durée, cela evite de nombreux Reset d ESP inexpliqués
- Fermeture des liaisons TCP apres lecture des données dans les Shelly EM et Shelly Pro EM , cela devrait eliminer une grande majorité des message connexion Shelly Failed ou TimeOut 
- La conséquence est une lecture des puissances plus fluide qui améliore donc la régulation.
(Testé sur un Shelly Em et RMS connecté via repeteur TPLINK à 60 mètres de la box)

Solar_Router_V15.01.Lolo69.2.ino
Cette version reprend les correctifs de la Lolo69.1 et vous propose en plus de tester un algorithme qui devrait améliorer la performance de la régulation de puissance.
Selon vos réglages initiaux de la réactivité, vous aurez peut être besoin d'augmenter celle-ci légèrement pour observer l'amélioration.
Dans le principe s'il y a un écart important entre les SeuilPW et la mesure de puissance , on booste la réactivité pour revenir rapidement à la consigne mais sans rentrer en oscillation.
(Testé sur RMS avec SSR Mode Multisinus sur CE Electronique 2,4kW )

j'aurais bien testé cette 2ème version volontiers mais cela ne va pas être possible car je dois m'absenter pour quelques jours. Je verrais donc ça à mon retour.

[F1ATB]

Il y a une version V15.02 qui reprend les corrections de Lolo69 sur le Shelly.
André

[clyon44]

Un grand merci André !

[michy]

Bonjour,

  si on veut fermer les connexions client pour toutes les situations, il faut le faire a chaque fois qu'on appel le .connect , que ça réussit, faire le .stop avant de sortir de la fonction et aussi quand il y a un return dans la fonction

  J'imaginais que le destructeur de WifiClient devait faire ce travail au moment ou il est nettoyé en sortant du bloc dans lequel il est déclaré/utilisé


  j'ai quelques cas qui ressorte : (sur la base source 15.02)

dans Actions.cpp / Call Externe +1 (ligne 321) juste après le dernier while qui utilise clientExt

dans EcranLCD / AccueilForceClick +1 (ligne 421) juste après le dernier while qui utilise clientESP_RMS

dans RMS_Externes.ino / Liste_NomsEtats  +1 (ligne 71) juste après le dernier while qui utilise clientESP_RMS

dans server.ino / handleAjaxRMS  +1 (ligne 177) juste après le dernier while qui utilise clientESP_RMS

dans Source_EnphaseEnvoy / LectureEnphase  +1 (ligne 171) juste après le dernier while qui utilise clientFirmV5

dans source_Externe / CallESP32_Externe +1 (ligne 42) juste après le dernier while qui utilise clientESP_RMS  [il y en a un ligne 144 qui fait le job]

dans source_HomeWizard / LectureHomeW  +1 (ligne 39) juste après le dernier while qui utilise clientESP_RMS

dans MQTT.ino / testMQTTconnected() +1 (ligne 99) avant le return pour quitter la fonction

dans source_ShellyProEm / LectureShellyProEm  +1 (ligne 59) juste après le dernier while qui utilise clientESP_RMS pour le GetDeviceInfo / !! Le client est connecté une nouvelle fois ligne 72 pour faire l'appel GetStatus

dans Source_SmartG / LectureSmartG  +1 (ligne 38) juste après le dernier while qui utilise clientESP_RMS

--------

Bien que moins problématique :  les .stop() qui ne sont pas utiles car on vient de faire un test qui permet de savoir qu'on est pas connecté   if(!xxxx.connected( donc il n'y a rien a stopper ...
Action.cpp / CallExterne -1 ligne 299

RMS_Externes.ino / Liste_NomsEtats -1 ligne 45

server.ino / handleAjaxRMS -1 ligne 155

Source_Externe.ino / CallESP32_Externe -1 ligne 16

Source_HomeWizard / LectureHomeW -1 ligne 16

Source_ShellyEm.ino / LectureShellyEm -1 ligne 18

Source_ShellyProEm.ino / LectureShellyEm -1 ligne 73

Source_SmartG.ino / LectureSmartG -1 ligne 15

----
Questionnement pour les spécialistes :
 la fonction .stop() n'est pas utile/traité si tous les octets envoyés par le serveur n'ont pas été lu, il faudrait donc faire un .flush() avant de faire le .stop()?
 ou en alternative un vider le buffer réception avant fermeture : while (client.connected()) {while (client.available()) {client.read()} delay(1);} client.stop();