Se connecter

Lolo69 · (Modification du message : 22-08-2025, 10:21 PM par Lolo69.)

pour la compil j'ai trouvé, je n'avais pas téléchargé le bon zip...

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
tout fonctionne et la mesure beaucoup plus proche de la réalité

FastFrench · (Modification du message : 22-08-2025, 10:06 PM par FastFrench.)

(22-08-2025, 08:07 PM)Lolo69 a écrit :
(22-08-2025, 08:04 PM)FastFrench a écrit :
(22-08-2025, 07:32 PM)Lolo69 a écrit : 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é.)

Lolo69 · (Modification du message : 22-08-2025, 11:04 PM par Lolo69.)

j'avais répondu un peu trop vite
ta version me semble donc au taquet , je vais voir demain en terme de routage ce que ca donne, ( j ai remis par dessus ta version mon algorithme de regulation personalisé.
on chope même le pic d'intensité de demarrage des moteurs Wink

pour le Telnet c est un plus en effet
par contre je te confirme que sur un shelly EM ( et je crois que le pro c est pareil) il rafraichi sa mesure toutes les secondes, ta vitesse de lecture pourrait sembler inutile , mais pas du tout car du coup on est sur de pas rater le 1er changement et réagir des qu'il arrive. je te ferais un retour demain soir si soleil il y a ; car là je peux pas tester le seuil du thermostat CE est deja atteint ;-)

59jag · (Modification du message : 22-08-2025, 10:51 PM par 59jag.)

pour ce qui est du shelly 3em j ai mesurer sur le miens, le temps échantillonnage est d environ 1s.
resultat de 30 requêtes tous les 100ms
Puissance -7.35W stable pendant 1.02s (6 mesures)
Puissance -61.97W stable pendant 0.97s (5 mesures)
Puissance -68.27W stable pendant 1.13s (5 mesures)
Puissance -30.02W stable pendant 0.94s (5 mesures)
Puissance -2.77W stable pendant 0.93s (5 mesures)
Puissance 46.75W stable pendant 1.13s (5 mesures)
ici pour tester votre shelly peux etre adapter le code car j ai tester qu avec shellyem

https://drive.google.com/file/d/1_Hx2hqFa7tOrbUoOA4JH7k-fmIZsXbuP/view?usp=drivesdk

Lolo69 · (Modification du message : 22-08-2025, 11:37 PM par Lolo69.)

(22-08-2025, 10:49 PM)59jag a écrit : pour ce qui est du shelly 3em j ai mesurer sur le miens, le temps échantillonnage est d environ 1s.
resultat de 30 requêtes tous les 100ms
Puissance -7.35W stable pendant 1.02s (6 mesures)
Puissance -61.97W stable pendant 0.97s (5 mesures)
Puissance -68.27W stable pendant 1.13s (5 mesures)
Puissance -30.02W stable pendant 0.94s (5 mesures)
Puissance -2.77W stable pendant 0.93s (5 mesures)
Puissance 46.75W stable pendant 1.13s (5 mesures)
ici pour tester votre shelly peux etre adapter le code car j ai tester qu avec shellyem

https://drive.google.com/file/d/1_Hx2hqFa7tOrbUoOA4JH7k-fmIZsXbuP/view?usp=drivesdk

on a du faire a peu pres le meme programme ;-) et les resultats sont similaires ;-) sur un shelly em

(22-08-2025, 10:49 PM)59jag a écrit : pour ce qui est du shelly 3em j ai mesurer sur le miens, le temps échantillonnage est d environ 1s.
resultat de 30 requêtes tous les 100ms
Puissance -7.35W stable pendant 1.02s (6 mesures)
Puissance -61.97W stable pendant 0.97s (5 mesures)
Puissance -68.27W stable pendant 1.13s (5 mesures)
Puissance -30.02W stable pendant 0.94s (5 mesures)
Puissance -2.77W stable pendant 0.93s (5 mesures)
Puissance 46.75W stable pendant 1.13s (5 mesures)
ici pour tester votre shelly peux etre adapter le code car j ai tester qu avec shellyem

https://drive.google.com/file/d/1_Hx2hqFa7tOrbUoOA4JH7k-fmIZsXbuP/view?usp=drivesdk

On a du faire a peu pres le meme programme ;-) et les resultats sont similaires ;-) sur un shelly em avec un polling à 100ms

23:25:26.739 -> [00:00:10.281] UPDATE POLL => Power=132.11W (Δt=1000ms)
23:25:27.716 -> [00:00:11.287] UPDATE POLL => Power=132.81W (Δt=1004ms)
23:25:28.715 -> [00:00:12.286] UPDATE POLL => Power=140.97W (Δt=1000ms)
23:25:29.712 -> [00:00:13.282] UPDATE POLL => Power=133.47W (Δt=1000ms)
23:25:30.745 -> [00:00:14.279] UPDATE POLL => Power=129.28W (Δt=1000ms)
23:25:31.717 -> [00:00:15.284] UPDATE POLL => Power=130.78W (Δt=1000ms)
23:25:32.708 -> [00:00:16.279] UPDATE POLL => Power=130.30W (Δt=1000ms)
23:25:33.703 -> [00:00:17.274] UPDATE POLL => Power=132.05W (Δt=1000ms)
23:25:34.703 -> [00:00:18.274] UPDATE POLL => Power=131.39W (Δt=1000ms)
23:25:35.705 -> [00:00:19.273] UPDATE POLL => Power=130.34W (Δt=1000ms)
23:25:37.030 -> [00:00:20.582] UPDATE POLL => Power=132.55W (Δt=900ms)
23:25:37.726 -> [00:00:21.273] UPDATE POLL => Power=135.27W (Δt=1039ms)

ta page HTML ne fonctionne pas pour mon shelly EM je jeterai un oeil demain pour savoir pourquoi , si je trouve je te dis

FastFrench · (Modification du message : 22-08-2025, 11:46 PM par FastFrench.)

OK, merci pour l'info (et votre intérêt pour ces changements :p). Donc sur les Shelly pro 3em et les Shelly (3)em, on a bien une mise à jour de la puissance mesurée toutes les secondes (j'ai fait des tests intensifs sur ce point, en saturant mon Shelly Pro 3em de requêtes pendant une heure pour m'en assurer).

Comme je n'ai pas de Shelly simple sous la main, je n'ai pas pu aller aussi loin que sur le Pro 3EM sur les optimisations. Mais les traces sur Telnet devrait vous donner l'info qui me manque: les données sont-elles récupérées en une seule lecture ou bien en faut-il plusieurs ? (sur mon Shelly, si je le laisse faire, une première lecture me donne plus de 95% des données en 60ms, mais il reste un petit reliquat qu'on peut récupérer moyennant une seconde lecture qui elle coûte autour de 400ms. Or dans les fait les données manquantes ne nous servent à rien. C'est la raison d'être du dernier paramètre de ma fonction de lecture: elle permet de savoir si on a reçu assez de données. Si ce paramètre est omis (chaîne vide) et que tout n'arrive pas en une seule lecture, alors la fonction va attendre d'avoir reçu toutes les données pour s'arrêter. On peut raisonnablement supposer que le Shelly simple avec 2 capteurs doit tout doit arriver en une seule lecture (à moins que les buffers soient plus petits). Pour celui avec 3 capteurs, je ne sais pas).

Je vais peut-être essayer de rendre l'algo un peu plus astucieux, et faire qu'il ne retourne que les mesures effectives du Shelly (sorte de pooling jusqu'à détection d'un changement ou 1 seconde écoulée). Car c'est le vrai besoin. Ce qui est assez pénible ici c'est la diversité des cas de figure à prendre en compte (configs Shelly différentes, retournant des flux de données différents). J'ai bien mis une IA sur le coup pour me réécrire tout ça (architecture objet propre), mais sans succès pour l'instant.

Lolo69 · (Modification du message : 23-08-2025, 01:18 AM par Lolo69.)

chat gpt pedale dans la choucroute ....
je n'ai pas trop compris ce que tu veux que je te donne du telnet sur un shelly em, mais là je commence à saturer lol
en tout cas je n'ai pas encore les resultats sur la regulation mais en terme de navigation sur les pages web pwaaaaaaaaaaaaa c est une tornade maintenant bravo bravo bravo

59jag · 23-08-2025, 07:56 AM

c est getpowervalue a modifier essai celle ci .

Code :
function getPowerValue(data, model) {

    if (model === 'em') {

        // Shelly EM : total_power directement

        return data?.total_power ?? "inconnu";

    } else {

        // Shelly Pro EM : structure différente

        if (data?.em && data.em["0"] && data.em["0"].total_act_power !== undefined) {

            return data.em["0"].total_act_power;

        }

        if (data?.em1 && data.em1["0"] && data.em1["0"].act_power !== undefined) {

            return data.em1["0"].act_power;

        }

        return "inconnu";

    }

}

***F1ATB*** · 23-08-2025, 11:55 AM

J'ai mis en ligne ce jour une version 15.04 du logiciel du routeur. Elle apporte les améliorations suivantes :
- règle un conflit Oled/Wifi dans des cas bien particuliers
- accélère les transferts avec les Shelly. Le code initial s'appuyait sur les Timeout pour détecter les fins de message, A présent, on utilise une chaine de caractère typique au modèle de Shelly comme proposé par FastFrench. Le codage a été fait suivant des données de ChatGPT, je ne dispose pas de tous les modèles de Shelly et m'appuie sur vos remarques et expériences.
André

Lolo69 · (Modification du message : 23-08-2025, 02:27 PM par Lolo69.)

(23-08-2025, 11:55 AM)F1ATB a écrit : J'ai mis en ligne ce jour une version 15.04 du logiciel du routeur. Elle apporte les améliorations suivantes :
- règle un conflit Oled/Wifi dans des cas bien particuliers
- accélère les transferts avec les Shelly. Le code initial s'appuyait sur les Timeout pour détecter les fins de message, A présent, on utilise une chaine de caractère typique au modèle de Shelly comme proposé par FastFrench. Le codage a été fait suivant des données de ChatGPT, je ne dispose pas de tous les modèles de Shelly et m'appuie sur vos remarques et expériences.
André

Aujourd'hui j ai testé la version fastfrench avec un Shelly EM et SSR( un peu customisée par mes soins)
Réactivité de la mesure au top,
Ressource CPU ESP divisé par plus de 5 , au top
Coté régulation au début très bof , car la mesure trop réactive pour un SSR , j'ai pas le courage de tester sur mon RMS Triac mobile sur lequel ca doit etre incroyablement précis
Pour faire fonctionner correctement avec SSR j'ai recréer un filtre exponentiel 3 seconde( que je prefere au filtre RC mais c est une histoire de gout, moi une constante de temps me parle plus qu un rapport A B)
Et apres , bah mon CE est arrivé à sa temperature max , fin des tests !!!
suite demain , mais pour le coup je ferais le retour avec la 15.04

en tout cas Fastfrench , grand Bravo à toi c est de l'art
Et André je n'ai plus de superlatif pour décrire ton travail

Se connecter
Utilisateur :
Mot de passe :	Mot de passe oublié ?
	Se rappeler