Optimisation partie UXIX3 - Version imprimable +- F1ATB forum (https://f1atb.fr/forum_f1atb) +-- Forum : Forum de F1ATB (https://f1atb.fr/forum_f1atb/forum-3.html) +--- Forum : Routeur Photovoltaïque (https://f1atb.fr/forum_f1atb/forum-4.html) +--- Sujet : Optimisation partie UXIX3 (/thread-100.html) |
RE: Optimisation partie UXIX3 - piamp - 15-06-2024 Je prends une mesure toutes les 400ms,.les messaages sont complets et les fonnees varient... Le doc du jsy est truffé d'erreur. Tu n'arrives pas a descendre sous les 1000ms car tu es en 9600 et tu lis l'ensemble des trames je pense Je vais essayer ta méthode. En routage, ma puissance active oscille entre +20 et -20 a peu près. Même si l'intégrale est fausse ca fera au max 450wh d'injection ce qui est pas si mal comparé aux valeurs du jsy... Copie d'écran qui montre la réactivité avec mesures toutes les 400ms: RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024 (15-06-2024, 12:42 PM)piamp a écrit : Je ne suis pas expert des communications série d'où les talonnements... Moi non plus, mais j'ai bricolé pas mal sur Arduino et les ports série. Et non, malheureusement, cela ne fonctionne pas comme cela. Je pense en fait que c'est par 'hasard' (ou miracle ?) que ça marche plus ou moins en l'état. Rien n'est "bloquant dans ces échanges totalement asynchrones, et quelques lignes de code tournent bien plus vite sur l'ESP32 que 'arrivée d'un nouvel octet chaque 1ms. Et dans tous les cas, la doc indique que les données ne sont pas rafraichies à plus de 1s. Ce que j'ai fait pour le moment pour sécuriser, c'est > ajouter un simple timer d'attente des données (une seconde) > lancer une requête initiale à la fin de l'init_UxIx3 et armer le timer d'attente de lecture à 1 seconde. > lire les données toutes les secondes, et à la fin de la lecture, envoyer une nouvelle requête et ré-armer le timer d'attente. Avec ce principe, on doit je pense lire correctement un message toutes les secondes. A moins de 1s, j'obtiens des messages incomplets une fois sur 2. cdlt, RE: Optimisation partie UXIX3 - piamp - 15-06-2024 Il y a déjà un timer dans le .ino principal, regle a 600ms par defaut je teste votre code Les nouvelles données calculées ne sont pas celles qui remontent en MQTT à priori ? RE: Optimisation partie UXIX3 - piamp - 15-06-2024 J'ai modifié MQTT.ino pour faire remonter ces valeurs je verrai demain si c'est cohérent avec les exports linky ! RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024 (15-06-2024, 04:46 PM)piamp a écrit : Il y a déjà un timer dans le .ino principal, regle a 600ms par defaut non, les nouvelles données calculées apparaissent seulement dans la page "données brutes" à ce stade. Les données qui apparaissent sur la page "main" comptabilisent le total injecté, et le total soutiré par jour, et depuis le démarrage du module. J'essaie de suivre les évolutions d'André, mais lorsqu'on développe d'autres choses dans son coin, cela devient de plus en plus dur, car il faut sans cesse recoller à la "baseline". Je vous invite à vous connecter sur votre serveur UxIx3 et à vérifier que lorsque vous interrogez à 600ms, vous avez bien des réponses valides et complètes (et non des lectures de ... 0 octets ). Lorsque je questionne le 333, il met parfois plus de 500ms à répondre, et jusque 1000ms (je pense que cela dépend où en est son firmware interne. Je doute qu'on puisse aller plus vite que ce que donne la doc comme limite de rafraichissement des données (1000ms). Le 600ms est donc je pense trop "rapide", et inutile. Une fois sur deux vous ne lisez pas toutes les données (quand ce n'est pas juste zéro data). Pour faire "mieux" et "en temps réel", la seule solution est celle qu'André propose en monophasé avec bobine etc.. et la multiplier par trois. pas sûr que cela en vaille la peine pour quelques dizaines de watts par-ci par-là. Et encore moins quand des nuages passent... Edit : je vous relis et comprend qu'en questionnant seulement quelques données, et en deux fois, et à 400ms, les données reçues varient toutes ? Si tel est le cas, oui la doc est erronée ou incomplète. Et c'est une bonne nouvelle. Vous avez donc résolu votre problème d'appel en deux fois ? De mon coté, je bataille avec UxIx3 en serveur, avec trois routeurs clients, et de multiples plantages que je n'avais pas en V8.09 dès que j'affiche de multiples pages html sur l'ordi et/ou le smartphone. Edit : Problème solutionné en repassant le serveur UxIx3 en version V9.01 et la bibliothèque ESP32 associée. RE: Optimisation partie UXIX3 - PhDV61 - 16-06-2024 Voilà ce matin, alors que la production de mes 6 panneaux a commencé$ ce que voit le Linky ( pas d'injection ) ce que mesure et reporte le JSY-MK-333 ( le soutirage complet, et l'injection complète, avec la puissance apparente "corrigée" par logiciel ) et ce que calcule le logiciel en parallèle "à la manière Linky" Attention, tout n'est pas pris exactement à la même heure, d'où les petits écarts. Sinon, pour moi, le compte est bon... RE: Optimisation partie UXIX3 - piamp - 16-06-2024 J'ai repris votre code et l'ai fusionné au mien, en ne lisant que les données nécessaires et en faisant les calculs en binaire, c'est parfaitement stable avec un délai de 400ms défini dans le ino principal les mesures de conso et injection semblent fiable, je vais tester sur plusieurs jours ! Code : // ************************************************* RE: Optimisation partie UXIX3 - Alain_C38 - 16-06-2024 Vous m’impressionnez les gars. Merci, je suis incapable de faire ça ! RE: Optimisation partie UXIX3 - PhDV61 - 16-06-2024 (16-06-2024, 12:29 PM)piamp a écrit : J'ai repris votre code et l'ai fusionné au mien, en ne lisant que les données nécessaires et en faisant les calculs en binaire, c'est parfaitement stable avec un délai de 400ms défini dans le ino principal Parfait. Je suggère que vous ajoutiez un StockMessage(" heure d'arrivée message complet "+String( millis()/1000) ); pour vérifier que vous avez bien un nouveau message valide toutes les 400ms. J'ai un gros doute, car c'est ce qui se passe avec 141 data requises toutes les 600ms. Il en manque... Sinon, un octet c'est 8 bits, et sur une ligne série, il commence souvent par un "start bit" et se termine par un "stop bit" soit 10 bits en tout. A 19200 bauds, 192 octets (= 1920 bits) prennent environ 100 ms. Soit un octet toutes les 0.5ms environ. C'est très très long par rapport à la capacité d'un ESP32 à plusieurs dizaines de MHz. A 9600 bauds, c'est 200ms, soit bien inférieur aux requêtes chaque 600ms. Et pourtant, il manque des réponses aux requêtes lorsqu'on questionne plus vite. Donc ce n'est peut-être pas 1s comme dit la doc, mais peut-être que le 1s est "garanti", alors que toute requête plus rapide est servie "seulement si c'est possible" par rapport à ce qu'est entrain de faire le uC du JSY-MK-333 à ce moment-là. en tout cas, c'est ce que j'ai constaté. Plus j'essaie de m'écarter des 1000ms, plus il manque des messages ( avec a=0 d'ailleurs, comme si le JSY-MK-333 ignorait purement et simplement la requête. D'ailleurs, si on ne relance pas à nouveau une requête, on ne recevra alors plus rien en réponse comme je l'ai testé). Cdlt, RE: Optimisation partie UXIX3 - PhDV61 - 16-06-2024 Pour illustrer mon propos ci-dessus, voilà ce que donne la décorrélation de la requête d'une part, et l'attente de la réponse d'autre part : Le temps indiqué à droite est le temps mesuré entre deux messages reçus. L'heure à laquelle la requête avait été faite est sur la gauche. On voit que parfois le module répond 200ms après la requête. Parfois 400ms... Au vu de la répétibilité des timings, il semblerait que la latence de réponse dépend du moment où la requête est envoyée au module ( qui la traite lorsqu'il en a envie... Normal, c'est totalement asynchrone tout ça). Même en lisant 141 valeurs, le module répond parfois rapidement (200ms), ce qui est cohérent avec la vitesse de transmission, mais parfois il tarde jusqu'à ... 800ms. Et on n'y peut rien. J'ai mis un timer d'attente à 600ms, et je viens vérifier toutes les 100ms si la réponse a été reçue. Peut-être qu'en doublant la vitesse de transmission le module répond deux fois plus vite. ou pas. |