Codage Shelly

[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 ?

pour la compil j'ai trouvé, je n'avais pas téléchargé le bon zip...
sinon on parle d'optimisation de code pas de performance donc, ton code est sans doute plus "lisible" et le telnet /putty interessant, mais me confimes tu qu en terme de performance de routage ca ne changera rien ?
a la premiere analyse on voit tes mesures moins lissées ...
En tout cas apres reflexion je pense que ta version possède un gros potentiel meme si je n'arrive pas à me connecter en telnet dessus l esp.....=> parfois je suis trop con ( ca va plaisir à certains) j'avais oublier de deconnecter mon vpn

OK, ça me rassure (je n'utilise plus Arduino IDE, mais en principe ça reste compatible. Ca m'aurait ennuyé que ça ne le soit pas.). 
En terme de routage, le changement essentiel, c'est que comme la mesure des puissance est beaucoup plus rapide, on peut avoir un système bien plus réactif, qui donc pourrait s'adapter plus rapidement aux changements de consommation. 
Concernant le lissage, je suis un peu perplexe sur sa pertinence. Surtout que ça me semble redondant avec le réglage de la réactivité. Enfin je n'ai pas encore regardé cet aspect du code, donc je ne sais pas en quoi le réglage de la réactivité diffère d'un lissage. Sur le principe, les deux devraient être assez similaires. Mais dans les faits, je ne vois pas trop l'impact de la réactivité dans mes essais. Bref je me demande si avoir les deux est bien utile. 
Ceci dit, je n'ai rien changé à ce niveau dans le code. Mais comme maintenant on récupère la puissance plus de 15 fois par seconde (sur le Shelly Pro 3 EM) alors qu'avant il fallait entre 1,15 à 3,7 secondes par accès à la puissance, forcément ça à un impact sur le lissage (vu qu'on fait un pseudo-lissage sur les points de mesure, pas explicitement en fonction du temps). 
D'ailleurs du coup récupérer la puissance 15 fois par secondes n'est pas très forcément utile. Autour de 4 fois, ça suffirait déjà. Vu que le Shelly actualise les puissances mesurées toutes les secondes. 
Concrètement, si on a brusquement un doublement de la puissance consommée (disons 100W avant t0, 200W après t0), alors avec l'ancien fonctionnement et le pseudo-lissage en place, il fallait attendre la 4° mesure pour constater la moitié de l'augmentation de la puissance. Et la 11° mesure pour prendre en compte 90% de cette augmentation. Soit près de 10 secondes pour constater 50% du changement, et pas loin de 30 secondes pour ne constater encore que 90% du changement de la puissance mesurée.
Comme je n'ai rien changé au principe du lissage, on garde le même nombre de mesures nécessaires pour constater un changement de puissance, mais avec des temps au moins 20 fois plus rapides. Donc on passe à 240ms pour constater 50% du changement et 660ms pour 90%. Comme la puissance mesurée au niveau du Shelly ne change que toutes les secondes, le lissage est donc maintenant globalement très peu impactant.

Quoi qu'il en soit, pour moi la priorité est d'arriver à avoir un routeur qui fonctionne de façon stable / fiable, pour voir comment améliorer son fonctionnement (au niveau filtrage ou autres). Pour l'instant c'est plus une intuition qu'un constat. 
Le fait de faire des requêtes aussi rapides que possibles ne peut qu'être bénéfique au fonctionnement global du routeur (quitte à introduire un délai entre chaque). Car avoir un cœur sur lequel un client Wifi est presque en permanence avec une requête en cours qui ne répond pas (attente du Time Out) n'est probablement pas TOP pour les autres communications Wifi que le routeur tente de gérer sur l'autre cœur (MQTT, Server Web...).  

A noter que si je me suis attaqué à ce problème en premier, c'est parce que j'avais l'impression que ça pouvait être la source du dysfonctionnement de mon routeur (il réagissait à contrecoup, avec des périodes OFF de plusieurs secondes, alternant avec des périodes de surconsommations très marquées. Et cela même en jouant sur la réactivité.)