Hier, 10:25 AM (Modification du message : Hier, 10:27 AM par PabloR.)
(Hier, 10:02 AM)Alain_C38 a écrit :
(Hier, 09:41 AM)PabloR a écrit :
(Hier, 08:47 AM)Alain_C38 a écrit : Première idée qui ùe vient à l'idée (j'ai eu la même chose ) : Tes actions sont t-elles bien actives ?
Dans mon cas, je les avaient désactivées le temps de trouver cette nouvelle version, et oublié de les réactiver avec cette nouvelle version.
Maintenant je pilote le SSR avec la fonction on/off et selon l'heure du jour. Je limite aussi la puissance envoyée pour avoir de la marge pour les autres appareils mais c'est clair que ce n'est pas optimal comme avant ?. On a la chance que ça est tombé pendant ces jours où il n'y a pas un seul nuage.
Si je met un action de routage le relais passe à zero car il détecte pas d'injecton.
On ne se comprends peut-être pas. Si tu es en fonctionnement On/Off, il n'y a pas de routage possible.
Il faut que tu sois en Demi-sinus, Multi-sinus, Train de sinus ou PWM pour que le routage se fasse (et avoir sauvegarder les config pour que cela soit pris en compte).
Oui je suis d'accord. Avec la foncion on/off il n'y a pas de routage mais aujourd'hui c'est mon seul moyen de faire que mon chauffe eau marche (apart le contacteur HC/HP). Si je programme une action de routage à la place (en demi-sinus par exemple) le routage ne demarre pas car pour lui je n'injecte pas.
Nos messages se sont croisés. Je n'ai pas touché au cablage et ça marché nickel avant
(Hier, 10:46 AM)Sgb31 a écrit : Hello PabloR,
peut tu partager ta page données brutes et page actions stp ?
Salut.
Voici les les images de chaque page, avec les actions en mode on/off et en mode routage.
La puissance réseau public correspond à ma consommation actuelle et la puissance produite correspond à la production des panneaux mais la valeur puissance consommée n'est pas bonne.
(26-06-2026, 02:37 PM)Pecheur021 a écrit : bonjour à tous,
chez moi je suis passé en 17.23 et ca fonctionne meme avec quelques messages d'erreurs.
depuis la mise a jour j'ai enormement de redemarrage de l'ESP, vous aussi? normal?
est ce que l'on peut faire en OTA un downgrade en 17.22?
Salut,
Oui en OTA tu peux faire un downgrade comme tu veux.
Par contre cest bizarre les redémarrages.......
De mon côté aucuns soucis par contre jai mis un reset de l’esp32 si il n’y a plus de communication apres 30min et pas 3 min comme par defaut....
oui j'ai mis aussi à 12h...
mais je me souviens maintenant c'est pour cela que je restais en 14.24, car passé cette version mon ESP faisait beaucoup de reboot, mais je ne sais pas pourquoi
(27-06-2026, 10:13 PM)tsabran a écrit : Merci pour les feedbacks
@Alex11 pour le pb d'affichage, ca pourrait etre soit un problème de hard refresh à faire vu que le code javascript a un peu changé (en effet le screenshot n'affiche pas les nouvelles lignes du tableau), soit c'est lié au bug de chargement des JS que j'ai corrigé entre-temps (lien édité hier à 23h, certaines resources JS etaient tronquées par le serveur).
En tout cas, les lignes de log sont celles attendues, il faut que je les nettoie pour les rendre plus explicites
@Pliz72 le pb d'accès a la page parametre est vraissemblablement ce bug de resource JS vide (content-length=0). C'est un pb aleatoire lié à une pénurie de mémoire silencieux au moment du Send(), et amplifié sur ma version car je gardais plus de buffer en mémoire. Je crois l'avoir corrigé avec la version compilée à 23h: le fichier ...20260626-225251.ino.bin sur le meme lien.
L'url /OTA n'est pas impactée (moins de JS), ce qui permet qd meme d'uploader une nouvelle version.
Pour rappel, cette version essaie de conserver la connexion TCP avec l'Envoy le plus longtemps possible, au lieu de la réouvrir toutes les 500ms. Inévitablement, cette connection se retrouve fermée de temps en temps et il faut la rouvrir.
-> ca logge la detection de la connection fermée et sa réouverture, qui est une chose normale lorsque c'est detecté au début de la lecture
- Envoy connection is closed. (Re)connecting...
- Connected to Envoy-S server HTTPS!
-> ca logge une erreur quand on arrive pas à obtenir tout le JSON attendu, au milieu du decoding de payload, après avoir recu un début de réponse...
- Envoy ... reading failed ... -> permettent d'identifier le type d'erreur (essentiellement timeout ou connection closed) et à quel moment dans le code ca se produit. Ces erreurs correspondent à priori aux "Envoy refused request" des précédentes version
De mon point de vue, les connection closed/reopened ne sont pas un pb, vu qu'elles sont detectées rapidement, et tant que leur fréquence reste assez faible pour ne pas trop impacter le temps de reponse moyen -> je vais probablement cacher ces logs, les metriques suffisent.
Je suis plus embêté par les erreurs de timeout... on ne les detecte qu'après avoir attendu 500ms sans réponse, donc ca retarde fortement le prochain retry ! Et je trouve suspect d'avoir ces timeouts de l'Envoy qui s'arrete d'emettre au milieu d'une réponse
Bonjour tsabran ,
Je viens de testé la mise a jour que tu as fait hier soir.
J'arrive de nouveau a accéder a la page paramètres, les valeurs de puissance apparente semble plus cohérente
ça tourne depuis 5h sans problème de routage. Je joint une capture d’écran des données brutes
voici un nouveau build https://drive.google.com/file/d/1JpeVhL1...sp=sharing.
Pas de gros changements, essentiellement le rebase 17.25 et du nettoyage de logs.
Je laisse les logs et compteurs de timeout pour l'instant pour surveiller la stabilité de l'API Envoy... surtout s'ils nous délivrent une nouvelle version sous peu.
@rdsoft30 / @michy Je n'ai pas du tout touché à la logique fonctionnelle de decoding de la payload, normalement ca doit etre exactement la meme que la base 17-25 que j'ai utilisé. Vu les échanges sur la gestion tri/mono, j'ai supposé que vos contributions etaient présentes, mais je n'ai pas fait de tests supplémentaires à ce propos.
De mon coté je suis en conso tri + production tri, et les chiffres m'ont semblé cohérents pour mon installation.
) : Tes actions sont t-elles bien actives ?
