Codage Shelly

[FastFrench]

Bonjour, 

après quelques jours de vacances, je reviens pour tenter de mettre en marche mon routeur. 
Et pour cela je relis le code. 

J'avoue que le code du Shelly Pro me laisse perplexe. 
De ce que j'en comprends, on appelle la méthode de l'API REST qui va bien (Shelly.GetStatus) pour récupérer les informations de puissance. 
Cette méthode ne prend aucun paramètre, et renvoie les infos pour tous les capteurs du Shelly (3 dans mon cas pour le Shelly Pro 3EM). 

Mais une fois sur 6, on semble ignorer la puissance importante pour le routeur, pour ne prendre en compte qu'une autre puissance (l'autre + 1 modulo 3, c'est à dire arbitrairement la suivante). Dans mon cas, la voie correspondant à la consommation au niveau du compteur est la voie N° 2. Donc le code considère que la voie "secondaire" est la voie N° 0. Ce qui semble totalement arbitraire (ça pourrait aussi bien être la voie N° 1)
Et inversement les autres fois, on va consulter les données pour la voie principale et ignorer l'autre (ou les autres). Et, histoire de faire compliqué, on va jusqu'à lisser l'info pour la voir secondaire, au motif qu'on lit moins souvent la données (bizarre comme logique à mon avis).
Je vois donc là plusieurs problèmes qu'on pourrait éviter simplement (qui plus est, en simplifiant le code):
-> Pourquoi ne pas analyser à chaque fois l'ensemble du flux de données que de toutes façons on récupère déjà ? Et ainsi avoir un fonctionnement plus simple et cohérent, en mettant à jour à chaque fois toutes les puissances qu'on suit ?
-> Quand il y a 3 capteurs ou plus (en principe ça peut monter jusqu'à 4 pour les Shelly pro 3EM, mais le 4e est mal documenté, et ne semple pas pris en charge par l'API), il serait plus propre de suivre toutes les puissances, ou alors explicitement paramétrer la voie secondaire que l'on veut suivre.
-> J'ai l'impression que le problème concerne tous les Shelly, vu qu'il me semble que dans tous les cas on récupère toutes les données à chaque fois.
-> Cela permettrait de simplifier le code, et améliorer la fluidité dans la mesure des puissances.
-> J'ai du mal à comprendre pourquoi on utilise EnphaseSerial.toInt(); pour récupérer le N° de la voie à suivre. Juste pour obfusquer (= rendre illisible) le code ?

Ceux qui sont familier avec ce code peuvent-ils confirmer ou infirmer mon analyse ?

[FastFrench]

Nouvelle découverte (ou confirmation, pour ma part): même quand on essaie de lire la puissance du Shelly toutes les 100ms, en réalité la lecture prend plus d'une seconde (1080  à 1190ms dans mon cas, certainement encore plus en Wifi).
Je m'en doutais vu que j'avais déjà constaté que le Shelly refraichit la mesure toutes les secondes, mais les puissances ne se rafraichissaient sur le routeur au mieux que toutes les 2 secondes (voire plus).

Et c'est précisément cette boucle qui est en cause (consomme autour de 1090ms à chaque lecture): 
    // Lecture des données brutes distantes
    while (clientESP.available() && (millis() - t0 < timeOutMsReading)) {
        Shelly_Data += clientESP.readStringUntil('\r');
    }

Par ailleurs, le temps de connexion lui est très faible (en filaire): entre 3 et 28ms.
Donc conserver la connexion ouverte n'apporterait par grand chose. 

Remarque: j'ai enfin réussi à m'affranchir de Arduino IDE, grâce à l'extension "Visual Micro" pour VS 2022  
Maintenant les choses sérieuses devraient pouvoir commencer.

[Chris]

On peut aussi interroger les shelly par rpc.
On ouvre la connexion puis on attend d'être notifié.
Peut-être une piste à creuser...

[FastFrench]

Pas la peine, après optimisation de la lecture, je passe à environ 60ms en moyenne pour chaque lecture (au lieu de 1140ms).
Et à vrai dire cette solution (répondre aux notifications du Shelly) ne m'inspire guère confiance pour un fonctionnement fiable sur une longue durée.

En fait la dernière ligne envoyée par le Shelly ne se termine pas par un \r, donc on attend indéfiniment, jusqu'à déclenchement d'un TimeOut du WifiClient (après 1 seconde, la valeur par défaut) sanctionant l'échec de lecture de cette dernière ligne.

Par contre le code pour une lecture optimisée est sensiblement plus complexe. En fait c'est facile de descendre à 400ms environ, mais pour passer en-dessous de 100ms il faut creuser un peu plus.

[Lolo69]

Pas la peine, après optimisation de la lecture, je passe à environ 60ms en moyenne pour chaque lecture (au lieu de 1140ms).
Et à vrai dire cette solution (répondre aux notifications du Shelly) ne m'inspire guère confiance pour un fonctionnement fiable sur une longue durée.

En fait la dernière ligne envoyée par le Shelly ne se termine pas par un \r, donc on attend indéfiniment, jusqu'à déclenchement d'un TimeOut du WifiClient (après 1 seconde, la valeur par défaut) sanctionant l'échec de lecture de cette dernière ligne.

Par contre le code pour une lecture optimisée est sensiblement plus complexe. En fait c'est facile de descendre à 400ms environ, mais pour passer en-dessous de 100ms il faut creuser un peu plus.
cependant fast french si tu veux bien me mettre à dispo ton module shelly em je veux bien le tester pour mesurer les améliorations que cela peut apporter 

[FastFrench]

cependant fast french si tu veux bien me mettre à dispo ton module shelly em je veux bien le tester pour mesurer les améliorations que cela peut apporter 

OK merci. Je partage ça dès que j'ai terminé mes tests. Par contre pour l'instant je n'ai modifié que le code pour le Shelly pro.
Tu sauras te débrouiller avec un lien GitHub ? (nettement plus pratique pour voir les changements)

[Lolo69]

cependant fast french si tu veux bien me mettre à dispo ton module shelly em je veux bien le tester pour mesurer les améliorations que cela peut apporter 

OK merci. Je partage ça dès que j'ai terminé mes tests. Par contre pour l'instant je n'ai modifié que le code pour le Shelly pro.
Tu sauras te débrouiller avec un lien GitHub ? (nettement plus pratique pour voir les changements)

oui sans soucis

[FastFrench]

OK, super. 
Et, incroyable, tout d'un coup, au fil de mes essais et modifications, c'est soudain tombé en marche ?!
Aucune idée précise pourquoi (les derniers changements étaient au niveau des logs, pas supposés être impactants), ou alors c'est un hasard et ça ne va pas durer, mais indéniablement en ce moment depuis quelques minutes j'ai une régularisation assez crédible qui tient la route. Avec un ensoleillement assez instable, la consommation du ballon s'adapte assez rapidement.
A voir sur le plus long terme. 
Concernant mes changements, j'ai reporté les changements principaux dans le code du Shelly (en plus du Shelly pro). Mais pas le changement consistant à supprimer l'alternance des voies (cf premier message sur ce fil): en effet, le code du Shelly gère 3 configurations, dont l'une utilise une requête spécifique à la voie. Donc dans ce cas bien précis (et seulement lui), l'alternance est pleinement justifiée. 

Pour ceux qui veulent regarder ce que ça donne, mes changements sont dispo ici: 
  https://github.com/FastFrench/F1ATB_Rout...-Optimized

J'en profite pour rappeler la branche principale que je maintiens avec les versions officielles (à jour en v15.03), pratique pour ceux qui veulent suivre les changement et ne sont pas effrayés par Git: 
  https://github.com/FastFrench/F1ATB_Router/

Pour ceux qui veulent tester cette version, vous pouvez visualiser le détail des temps des mesures avec une console Telnet sur le port 2323 (j'utilise selon l'humeur Telnet ou PuTTY).

Et enfin si vous voulez tester cette version sans avoir à recompiler, vous trouverez l'image compilée ici:
https://github.com/FastFrench/F1ATB_Rout.../v15.03.01
(c'est une version marquée 15.03.01, pour la distinguer de la 15.03 officielle)

[Lolo69]

Bon j'ai retiré mon précédent message , j'avais répondu un peu trop rapidement
je transforme mon ouai bof en Wahoouuu top

[FastFrench]

ta version shelly em optimisée me laisse dubitatif...
il n'y aura plus de message shelly failed car ils ne sont simplement pas traqués ni affichés....
tu as integré le lissage que André fait dans void externe de la meme façon
je n'arrive pas à voir en quoi cette version est optimisée et en quoi elle apporte une amélioration dans le routage...
Si tu pouvais eclairer ma lanterne, ce serait top

Telnet ou putty ou interface Arduino ca ne change pas vraiment on ecoute le port serie....
sinon dans ton suivi de version cela aurais été plus clair de mettre "ton" numero de version 15.03.01 par exemple
De nature curieuse je vais tester pour voir ....mais bon j ai des erreurs de compilation dans ton code
1171 |    GestionMQTT();
924 |    GestionMQTT();

Les messages d'erreur existent toujours. Simplement, au lieu de répéter le code de connexion 3 fois, c'est implémenté dans une fonction réutilisée. Idem plus globalement pour lire les infos du Shelly, tu as maintenant une méthode qui fait tout le boulot (ces méthodes sont dans  le source de Shelly Pro, mais partagées et utilisées dans Shelly aussi). 

Telnet, PuTTY c'est différent de la communication par port série. Car là on passe par le réseau, et on n'a donc pas besoin d'avoir un cable USB jusqu'au routeur. 
Si tu veux revenir à une communication série plutôt que par Wifi, il suffit de modifier la fonction Debug dans le module principal (mettre Serial.println en remplacement de tout le code de la fonction). 
Bizarre tes erreurs de compilation, je ne pense pas avoir touché à GestionMQTT(). 
Je vais réessayer de compiler avec Arduino IDE. 
Tu as bien récupéré tous les sources du projet ?