+- 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)
Optimisation partie UXIX3 - piamp - 14-06-2024
Bonjour,
Je suis à l'origine du code pour la lecture de données en triphasé avec UXIX3
Je m'amuse a essayer d'optimiser tout ça et en particulier à avoir des mesures plus rapides.
Première chose à faire : utiliser l'outil exe disponible sur le site de jsy pour passer le module en 19200 bps.
Ensuite, le code du fichier "Source_UxIx3.ino".
Une première amélioration est de ne pas travailler en float mais de faire les opérations de décalage en binaire. Facile et plus efficace.
Ensuite, on lit beaucoup de données à chaque fois, et c'est ça qui fixe le délai entre chaque requête au module JSY (en dessous de 600ms, ça bugue).
J'ai donc écrit une nouvelle version du code qui ne lit et calcule que ce qui est nécessaire : la puissance active en W, et le sens.
La puissance apparente ne sert à rien ; quand aux consommations et injections en kWh, elles sont inutiles car totalement faussées par le fonctionnement du routeur.
Avec ce code, on peut descendre en delay à 400ms :
Code :
// *************************************************
// * Client lecture JSY-MK-333 * Triphasé *
// * Développement initial de Pierre F (Mars 2024) *
// *************************************************
void Setup_JSY333() {
MySerial.setRxBufferSize(SER_BUF_SIZE);
MySerial.begin(19200, SERIAL_8N1, RXD2, TXD2); //PORT DE CONNEXION AVEC LE CAPTEUR JSY-MK-333
}
void Lecture_JSY333() {
float Tension_M1, Tension_M2, Tension_M3;
float Intensite_M1, Intensite_M2, Intensite_M3;
float PVAS_M_inst1, PVAS_M_inst2, PVAS_M_inst3;
byte Lecture333[200];
bool injection;
bool sens1, sens2, sens3;
int i;
byte msg_send[] = { 0x01, 0x03, 0x01, 0x09, 0x00, 0x30, 0x94, 0x20 };
for (i = 0; i < 8; i++) {
MySerial.write(msg_send[i]);
}
int a = 0;
while (MySerial.available()) {
Lecture333[a] = MySerial.read();
a++;
}
if (a==101) { //message complet reçu
injection = (Lecture333[86] >> 3) & 0x01; //si sens est true, injection
if (injection) {
PuissanceS_M_inst = 0;
PuissanceI_M_inst = float((Lecture333[3] << 24) + (Lecture333[4] << 16) + (Lecture333[5] << 8) + Lecture333[6]);
} else {
PuissanceI_M_inst = 0;
PuissanceS_M_inst = float((Lecture333[3] << 24) + (Lecture333[4] << 16) + (Lecture333[5] << 8) + Lecture333[6]);
}
MK333_dataBrute = "<strong>Triphasé</strong><br>Sens : " + String(injection,BIN) + "</br>";
MK333_dataBrute += "<br>Puissance active soutirée : " + String(PuissanceS_M_inst) + "W</br>";
MK333_dataBrute += "<br>Puissance active injectée : " + String(PuissanceI_M_inst) + "W</br>";
MK333_dataBrute += "<br>Données reçues : " + String(a) + "</br>";
Pva_valide=true;
filtre_puissance();
esp_task_wdt_reset(); //Reset du Watchdog à chaque trame du JSY reçue
EnergieActiveValide = true;
if (cptLEDyellow > 30) {
cptLEDyellow = 4;
}
} else {
StockMessage("Pas tout reçu, pas traité... nombre de données : " + String(a));
}
}Cela fonctionne très bien et la réactivité s'améliore. Mais cela force toujours à lire 48 octets (0x30 dans msg_send) car la donnée de sens est très éloignée de la puissance active.
J'essaie donc de faire 2 lectures, mais c'est là ou j'ai besoin d'aide car ça ne fonctionne pas !
Code :
int i;
byte msg_send[] = { 0x01, 0x03, 0x01, 0x09, 0x00, 0x02, 0x15, 0xF5 };
for (i = 0; i < 8; i++) {
MySerial.write(msg_send[i]);
}
int a = 0;
while (MySerial.available()) {
Lecture333[a] = MySerial.read();
a++;
}
byte msg_send2[] = { 0x01, 0x03, 0x01, 0x32, 0x00, 0x01, 0x24, 0x39 };
for (i = 0; i < 8; i++) {
MySerial.write(msg_send2[i]);
}
Lecture333[7] = MySerial.read();les données sortent totalement incohérentes.
Voilà, il y a peut etre un expert dans la salle
RE: Optimisation partie UXIX3 - PhDV61 - 14-06-2024
Félicitations pour le code initial.
Je l'ai modifié pour retrouver les données Linky, à savoir le Linky "signe" les puissances apparentes avant de les sommer, là où le JSY-MK-333 fait une simple somme arithmétique non signée. et le facteur de puissance ne veut rien dire.
Par ailleurs les compteurs d'Energie soutirée et consommée somment ce qui passe dans un sens , et dans l'autre.
Dans le cas du tri-phasé, on peut être en injection sur une ou deux phases, et en soutirage sur la ou les autres.
Le Linky fait le compte de ce qui est "facturable" donc une somme du "net" soutiré dans le temps, et idem pour l'injecté.
Comme je suis en CACSI, ces deux compteurs m'intéressaient. Et du coup, comme j'avais pour chaque phase la puissance instantanée, la puissance apparente, et le sens, je pouvais calculer le net soutiré, le net injecté (en intégrant les mesures dans le temps), et un facteur de puissance par phase. Toujours intéressant.
Si seules deux valeurs vous intéressent, la puissance instantanée soutirée ou consommée il ne vous faut pas beaucoup de data :
1/ Three-phase active total power 0109H 010AH read Unsigned number, value = DATA, unit W (0109H register corresponds to the upper 16 bits)
la réponse à l'interrogation comprend
address 01H command 03H Data length 04H Data segment (4 bytes) Checksum (2 bytes), soit 9 octets (0 -> 8)
Je suppose que vous avez vérifié le checksum en 7,8 et récupéré vos 4 octets au bon endroit dans votre tableau "lecture" ? 0,1,2 -> (3,4) et (5,6)
2/ L'octet de status 0132H
Vous lisez (read) directement après avoir envoyé la requête, mais vous n'avez pas attendu l'arrivée de l'octet, qui peut ne pas être encore arrivé car votre code va bien plus vite que le port série. Je ne sais pas si ce read attend l'octet s'il n'est pas arrivé ( read "bloquant" ?).
Après, si vous avez tout vérifié et que les données reçues sont totalement incohérentes, êtes-vous sûr de travailler avec les bons bauds ?
Les 19200 que vous avez modifiés sont-ils "persistants" ou avez-vous besoin de renvoyer la commande à chaque re-démarrage ? Il se peut qu'au démarrage le port série soit d'office et par défaut à 9600, et qu'il faille envoyer la commande de passage à 19200 au module avant de passer l'ESP32 à 19200 lui aussi. Ceci pourrait expliquer cela.
Enfin, la doc dit : "data update rate of 1000ms". donc une lecture plus rapide que la seconde serait inutile... car les données seraient les mêmes (?) ou pas disponibles (?). A vérifier.
Je n'ai pas d'autre idée à soumettre.
Bon courage.
RE: Optimisation partie UXIX3 - piamp - 15-06-2024
Merci pour votre réponse détaillée !
Oui tout est vérifié (19200, checksum). Je pense effectivement qu'il faut trouver un moyen d'attendre la fin de la réponse avant d'en reposer une, ce qui est contreproductif avec l'objectif d'interroger a une fréquence élevée !
Concernant les mesures, êtes vous parvenu a une lecture coherente avec celle du linky des consommations et injections en wh ? Dans ce cas pourriez vous partager le code ?
RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024
Oui, j'ai modifié votre code pour obtenir
- L'énergie soutirée et injectée 'vues comme par le linky'.
- j'ai transmis le code à André pour une future version.
Il faut ajouter 3 variables globales, une pour l'Energie journalière soutirée, une autre pour celle injectée, une mesure du temps entre deux lecture de la puissance instantanée "globale". Ajouter une mise à jour des variables journalières au changement de jour. Et j'ai fait de même avec les puissances apparentes en les signant avant de les sommer ( comme Linky ), et j'ai enfin utilisé toutes les valeurs instantanées par phase pour calculer les facteurs de puissance de chaque phase.
Nota : la doc du JSY-MK-333 dit que les données ne sont rafraichies que toutes le 1s. donc je pense que ce n'est pas nécessaire de vouloir lire plus vite.
Par contre, j'ai mes ESP32 qui plantent en 9.02 lorsqu'ils sont tous clients de mon serveur UxIx3, alors que tout marchait bien en 8.09. Je cherche la cause. Je me demande pour améliorer s'il ne faut pas tout simplement attendre que les données en réponse soient toutes reçues/bufferisées avant de les lire, ce qui suppose de modifier le code lecture, de l'appeler plus souvent, et de vérifier combien de données ont été reçues dans le buffer avant de commencer à les lire, et en une fois.
Ci-dessous les modifs :
variables globales à ajouter dans Solar_router... de tête.
// !! <<<<<<<< ajout PhDV61 compteur d'énergie quotidienne soutirée et injectée comme calculées par le Linky >>>>>>>
float Energie_jour_Soutiree = 0;
float Energie_jour_Injectee = 0;
long Temps_precedent = 0; // mesure précise du temps entre deux appels au JSY-MK-333
mise à zéro journalière dans cette fonction de stockage.ino
void LectureConsoMatinJour(void) {
....
LectureConsoMatinJour();
// !! <<<<<<< Modification PhDV61 Raz compteurs Energie soutirée et injectée journaliers type "linky" >>>>>>>>
Energie_jour_Soutiree = 0; // en Wh
Energie_jour_Injectee = 0; // en Wh
....
Et enfin votre code modifié ;
// *************************************************
// * Client lecture JSY-MK-333 * Triphasé *
// * Développement initial de Pierre F (Mars 2024) *
// * update PhDV61 Juin 2024 *
// *************************************************
void Setup_JSY333() {
MySerial.setRxBufferSize(SER_BUF_SIZE);
MySerial.begin(9600, SERIAL_8N1, RXD2, TXD2); //PORT DE CONNEXION AVEC LE CAPTEUR JSY-MK-333
}
void Lecture_JSY333() {
float Tension_M1, Tension_M2, Tension_M3;
float Intensite_M1, Intensite_M2, Intensite_M3;
float PVA_M_inst1, PVA_M_inst2, PVA_M_inst3;
float PW_inst1, PW_inst2, PW_inst3;
byte Lecture333[200];
bool injection;
bool sens1, sens2, sens3;
long delta_temps = 0;
int i;
byte msg_send[] = { 0x01, 0x03, 0x01, 0x00, 0x00, 0x44, 0x44, 0x05 };
for (i = 0; i < 8; i++) {
MySerial.write(msg_send[i]);
}
int a = 0;
while (MySerial.available()) {
Lecture333[a] = MySerial.read();
a++;
}
if (a == 141) { //message complet reçu
delta_temps = (unsigned long) (millis()-Temps_precedent); // temps écoulé depuis le dernier appel
Temps_precedent=millis(); // on conserve la valeur du temps actuel pour le calcul précédent
Tension_M1 = ((float)(Lecture333[3] * 256 + Lecture333[4])) / 100;
Tension_M2 = ((float)(Lecture333[5] * 256 + Lecture333[6])) / 100;
Tension_M3 = ((float)(Lecture333[7] * 256 + Lecture333[8])) / 100;
Intensite_M1 = ((float)(Lecture333[9] * 256 + Lecture333[10])) / 100;
Intensite_M2 = ((float)(Lecture333[11] * 256 + Lecture333[12])) / 100;
Intensite_M3 = ((float)(Lecture333[13] * 256 + Lecture333[14])) / 100;
sens1 = (Lecture333[104]) & 0x01;
sens2 = (Lecture333[104] >> 1) & 0x01;
sens3 = (Lecture333[104] >> 2) & 0x01;
if (sens1) { Intensite_M1 *= -1; }
if (sens2) { Intensite_M2 *= -1; }
if (sens3) { Intensite_M3 *= -1; }
injection = (Lecture333[104] >> 3) & 0x01; //si sens est true, injection
// Lecture des Puissances actives de chacune des phases
PW_inst1 = (float)(Lecture333[15] * 256.0) + (float) Lecture333[16];
PW_inst2 = (float)(Lecture333[17] * 256.0) + (float) Lecture333[18];
PW_inst3 = (float)(Lecture333[19] * 256.0) + (float) Lecture333[20];
//Lecture des puissances apparentes de chacune des phases, qu'on signe comme le Linky
PVA_M_inst1 = (float)(Lecture333[35] * 256) + (float)Lecture333[36];
if (sens1) { PVA_M_inst1 = -PVA_M_inst1; }
PVA_M_inst2 = (float)(Lecture333[37] * 256) + (float)Lecture333[38];
if (sens2) { PVA_M_inst2 = -PVA_M_inst2; }
PVA_M_inst3 = (float)(Lecture333[39] * 256) + (float)Lecture333[40];
if (sens3) { PVA_M_inst3 = -PVA_M_inst3; }
if (injection) {
PuissanceS_M_inst = 0;
PuissanceI_M_inst = ((float)((float)(Lecture333[21] * 16777216) + (float)(Lecture333[22] * 65536) + (float)(Lecture333[23] * 256) + (float)Lecture333[24]));
PVAS_M_inst = 0;
PVAI_M_inst = abs(PVA_M_inst1 + PVA_M_inst2 + PVA_M_inst3); // car la somme des puissances apparentes "signées" est négative puisqu'en "injection" au global
// PhDV61 : on considère que cette puissance active "globale" a duré "delta_temps", et on l'intègre donc pour obtenir une énergie en Wh
Energie_jour_Injectee += ((float) delta_temps / 1000 ) * ( PuissanceI_M_inst / 3600.0) ;
} else { // soutirage
PuissanceI_M_inst = 0;
PuissanceS_M_inst = ((float)((float)(Lecture333[21] * 16777216) + (float)(Lecture333[22] * 65536) + (float)(Lecture333[23] * 256) + (float)Lecture333[24]));
PVAI_M_inst = 0;
PVAS_M_inst = PVA_M_inst1 + PVA_M_inst2 + PVA_M_inst3;
// PhDV61 : on considère que cette puissance active "globale" a duré "delta_temps", et on l'intègre donc pour obtenir pour obtenir une énergie en Wh
Energie_jour_Soutiree += ((float) delta_temps / 1000 ) * ( PuissanceS_M_inst / 3600.0) ;
}
// PowerFactor_M = ((float)(Lecture333[53] * 256 + Lecture333[54])) / 1000; ce facteur de puissance ne veut rien dire en tri-phasé en cas d'injection sur au moins une phase
Energie_M_Soutiree = ((float)((float)(Lecture333[119] * 16777216) + (float)(Lecture333[120] * 65536) + (float)(Lecture333[121] * 256) + (float)Lecture333[122])) * 10;
Energie_M_Injectee = ((float)((float)(Lecture333[135] * 16777216) + (float)(Lecture333[136] * 65536) + (float)(Lecture333[137] * 256) + (float)Lecture333[138])) * 10;
MK333_dataBrute = "<strong>Triphasé</strong><br>Phase1 : " + String(int(Tension_M1)) + "V " + String(Intensite_M1) + "A</br>";
MK333_dataBrute += "<br>Phase2 : " + String(int(Tension_M2)) + "V " + String(Intensite_M2) + "A</br>";
MK333_dataBrute += "<br>Phase3 : " + String(int(Tension_M3)) + "V " + String(Intensite_M3) + "A</br>";
MK333_dataBrute += "<br>Puissance active soutirée : " + String(PuissanceS_M_inst) + "W</br>";
MK333_dataBrute += "<br>Puissance active injectée : " + String(PuissanceI_M_inst) + "W</br>";
MK333_dataBrute += "<br>Puissance apparente soutirée : " + String(PVAS_M_inst) + "VA</br>";
MK333_dataBrute += "<br>Puissance apparente injectée : " + String(PVAI_M_inst) + "VA</br>";
if (PVA_M_inst1 !=0 )
MK333_dataBrute += "<br>Facteur de puissance phase 1 : " + String(abs(PW_inst1/PVA_M_inst1)) + "</br>";
if (PVA_M_inst2 !=0 )
MK333_dataBrute += "<br>Facteur de puissance phase 2 : " + String(abs(PW_inst2/PVA_M_inst2)) + "</br>";
if (PVA_M_inst3 !=0 )
MK333_dataBrute += "<br>Facteur de puissance phase 3 : " + String(abs(PW_inst3/PVA_M_inst3)) + "</br>";
MK333_dataBrute += "<br>Energie jour nette soutirée (Linky): " + String(Energie_jour_Soutiree) + "Wh</br>";
MK333_dataBrute += "<br>Energie jour nette injectée (Linky): " + String(Energie_jour_Injectee) + "Wh</br>";
MK333_dataBrute += "<br>Energie totale soutirée : " + String(Energie_M_Soutiree) + "Wh</br>";
MK333_dataBrute += "<br>Energie totale injectée : " + String(Energie_M_Injectee) + "Wh</br>";
Pva_valide=true;
filtre_puissance();
esp_task_wdt_reset(); //Reset du Watchdog à chaque trame du JSY reçue
EnergieActiveValide = true;
if (cptLEDyellow > 30) {
cptLEDyellow = 4;
}
} else {
StockMessage("Pas tout reçu, pas traité... nombre de données : " + String(a));
}
}
RE: Optimisation partie UXIX3 - piamp - 15-06-2024
Intéressant...
Mais es tu sur que les données sont bien cohérentes avec celles du linky ?
Car selon ton code tu vas avoir une succession de puissance active positive puis négative, qui vont chacune incrémenter les compteurs d'énergie soutirée et injectée. En clair pendant les périodes de routage, de l'injection en kwh sera comptabilisée. Exactement comme les compteurs déjà codés en dur dans le JSY.
alors que le linky somme sur 1 seconde et (c'est le but) ne comptabilisera pas d'injection...
RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024
Et j'ai en retour une question pour vous sur votre code :
La liaison série est par définition asynchrone, et ici à 9600 bauds, soit un caractère toutes les ms environ.
La lecture MySerial.read() doit être ultra-rapide vu la vitesse du processeur, et donc on n'est pas sûr qu'un nouveau caractère soit arrivé entre temps lorsqu'on repasse dans la boucle suivante.
int a = 0;
while (MySerial.available()) {
Lecture333[a] = MySerial.read();
a++;
}
il serait plus sécurisant (et sécurisé) d'envoyer une requête en lecture, d'armer un timer, puis de venir scruter chaque ms (depuis la boucle principale comme c'est fait pour le Linky) si un caractère est arrivé, le lire et le stocker tant que le timer n'est pas épuisé, et qu'on n'a pas reçu le bon nombre de data.
Qu'en pensez-vous @piamp ?
cdlt,
Ph
RE: Optimisation partie UXIX3 - piamp - 15-06-2024
je ne suis pas expert des communications série d'où les talonnements...
Je ne comprends pas trop comment cela fonctionne, je pense que l'on reste dans la boucle while tant que des données arrivent, mais n'en suis pas sûr...
Dans la dernière version de mon code, on reçoit 101 octets soit 404 bits.
a 19200 bps, cela fait 20ms pour recevoir la totalité du message, si je ne me trompe pas ?
RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024
(15-06-2024, 12:18 PM)piamp a écrit : Intéressant...
Mais es tu sur que les données sont bien cohérentes avec celles du linky ?
Car selon ton code tu vas avoir une succession de puissance active positive puis négative, qui vont chacune incrémenter les compteurs d'énergie soutirée et injectée. En clair pendant les périodes de routage, de l'injection en kwh sera comptabilisée. Exactement comme les compteurs déjà codés en dur dans le JSY.
alors que le linky somme sur 1 seconde et (c'est le but) ne comptabilisera pas d'injection...
Oui, absolument sûr. Je suis en tri-phasé mais je n'injecte QUE sur la phase 1. Dans la journée, je suis en injection sur la 1, et en soutirage sur les autres. Pour une lecture de puissance active instantanée globale, le JSY-MK-333 fait bien une somme signée. En revanche, il ne le fait pas pour la puissance apparente, ce qui "fausse" ce qui est affiché et le ratio. J'ai vérifié en faisant moi-même les sommes des puissances actives signées et j'obtiens la même chose que le 333. En revanche, ce qu'il calcule en terme d'Energie totale fait d'un coté la comme de ce qui est soutiré sur chaque phase, et la somme de tout ce qui est injecté de l'autre. Ces deux sommes sont justes, mais on ne sait pas, s'il reste un peu d'injection, ce qui sera facturé par Enedis, ni ce qu'on a 'perdu' (si CACSI). C'est pourquoi il faut faire la somme de l'Energie 'nette' soutirée ou injectée ( comme le fait Linky).
Dans mon cas j'injecte beaucoup (puisque seulement sur la phase 1) et je soutire peu en "global "car mes 2400Wc suffisent amplement pour tout, piscine, spa, CE thermodynamique et CE tampons avec les routeurs bien "réglés". Et le Linky me dit que j'injecte très peu ( comme on le voit sur le Linky lui-même même en CACSI). Je voulais avoir les valeurs exactes pour piloter finement mes moteurs piscine et spa, "just for fun".
Le problème vient du fait que sur la page "MAIN" les valeurs d'Energie du jour soutirée et injectée sont calculées en faisant la différence entre les sommes globales de la veille, et les sommes globales actuelles. On n'obtient bien ce qu'on a "produit", et ce qu'on a consommé, mais pas ce qui est comptabilisé par le Linky et sera "facturé" ou "perdu".
RE: Optimisation partie UXIX3 - piamp - 15-06-2024
On a le même objectif : obtenir à partir du JSY333 les valeurs en kwh soutirées et injectées journalières, cohérentes avec le linky.
Ce serait d'autant plus utile qu'en CACSI on n'a pas accès à l'energie injectée (sauf en lecture directe du compteur).
Là ou je ne te suis pas c'est sur ta méthode.
Tu intègres la puissance active en W sur la durée de la mesure.
Lorsque le routeur fonctionne, la puissance active oscille autour de 0 avec des mini phases d'injection puis de consommation.
Les lectures du JSY par exemple donneront :
+15W
-20W
+12W
-14W
avec ta méthode, on intègre les valeurs et donc on aura d'un côté 2 périodes qui donnent de la consommation et 2 périodes qui donnent de l'injection. Sur les 4 périodes on va comptabiliser une valeur a peu prés égale d'injection et de consommation, qui ne seront pas nulles.
Or le linky ne comptabilisera aucune injection ! car il va faire l'intégration sur une durée plus longue et dans l'exemple donné comptabilisera 0 consomation, 0 injection. C'est bien le but du routeur...
Donc avec cette méthode, on n'approche pas les valeurs de consommation ( ni d'injection) que l'on verra le lendemain dans le relevé enedis...
RE: Optimisation partie UXIX3 - PhDV61 - 15-06-2024
(15-06-2024, 01:00 PM)piamp a écrit : On a le même objectif : obtenir à partir du JSY333 les valeurs en kwh soutirées et injectées journalières, cohérentes avec le linky.
Ce serait d'autant plus utile qu'en CACSI on n'a pas accès à l'energie injectée (sauf en lecture directe du compteur).
Là ou je ne te suis pas c'est sur ta méthode.
Tu intègres la puissance active en W sur la durée de la mesure.
Lorsque le routeur fonctionne, la puissance active oscille autour de 0 avec des mini phases d'injection puis de consommation.
Les lectures du JSY par exemple donneront :
+15W
-20W
+12W
-14W
avec ta méthode, on intègre les valeurs et donc on aura d'un côté 2 périodes qui donnent de la consommation et 2 périodes qui donnent de l'injection. Sur les 4 périodes on va comptabiliser une valeur a peu prés égale d'injection et de consommation, qui ne seront pas nulles.
Or le linky ne comptabilisera aucune injection ! car il va faire l'intégration sur une durée plus longue et dans l'exemple donné comptabilisera 0 consomation, 0 injection. C'est bien le but du routeur...
Donc avec cette méthode, on n'approche pas les valeurs de consommation ( ni d'injection) que l'on verra le lendemain dans le relevé enedis...
Garde en tête que le JSY 333 intègre déjà sur 1 seconde, et je pense que ce qu'on obtient, c'est déjà une puissance active moyenne consommée ou injectée. Je viens de vérifier à l'instant que si on interroge à plus que toutes les secondes, on n'obtient pas de réponse valide. Et donc je fais la supposition que cette puissance active dure jusqu'à la prochaine mesure. Et je te garantis que chez moi elle est équivalente à très peu de choses près à celle du Linky. Et le peu d'injecté est bon également. Fais un essai sur 24h.
Par ailleurs, pour ne pas avoir de messages incomplets, je confirme qu'il faut
1/ envoyer la requête
2/ attendre l'arrivée de TOUTES les data,
3/ puis les lire.
sinon on obtient des messages incomplets.
Pour l'instant, voilà ce que j'obtiens sur la page HTML data brute avec une interrogation toutes les secondes, et un délai d'attente d'une seconde également.
plus de "perte de message".