WifiInfo, le serveur WEB Téléinfo aux multiples facettes
-
Complément d'information : Sur une Wemos D1, le Serial1 TXD est en D4
Et effectivement, ça fonctionne....Merci encore pour les infos
-
Et bien voilà : Hier, ENEDIS m'a fait installer un compteur Linky triphasé : Enfin !
Hélas, lorsque j'y ai connecté mon module équipé de Wifinfo (qui avait été testé avec succès sur l'ancien compteur numérique de mon voisin), nada ! Aucune info détectée, aucun caractère reçu !
En lisant la doc des compteurs Linky, j'ai vu que la vitesse de transmission était 9600 Bds
Or, dans le source de Winfinfo.ino, je constate ceci :// Teleinfo is connected to RXD2 (GPIO13) to
// avoid conflict when flashing, this is why
// we swap RXD1/RXD1 to RXD2/TXD2
// Note that TXD2 is not used teleinfo is receive only
#ifdef DEBUG_SERIAL1
Serial.begin(1200, SERIAL_7E1);
Serial.swap();
#endifLes 1200 bauds sont-ils exclusivement relatifs au port Debug ? (D4 de la Wemos)
Ou serait alors configuré le port GPIO13 de réception téléinfo ?~Dernière minute :~ Il semblerait que les Linky puissent être configurés pour le TIC en plusieurs modes :
- mode STANDARD = 9600 Bds, et un protocole récent
- mode HISTORIQUE = 1200 Bds, et un protocole compatible avec les anciens compteurs numériques (et Wifinfo, donc... )
Mon compteur affichant bien MODE TIC = HISTORIQUE, il devrait émettre en 1200 Bds
-
@Doume
Aucun problème, tu as quel montage d'entrée ? Normalement tu change R1 par une 1.5K en entrée (tu remplaces R1 4.7K par une 1.5K ou 1.2K) et c'est reparti si ton linky est en mode historique bien sur -
J'ai bénéficié d'un circuit équipé offert gracieusement par un membre du forum 'easydomoticz.com', à savoir 'totof60' : Le PCB est estampillé 'By Chris 11/16 V0.9'
Il est équipé d'un SFH620A et effectivement, il présente une résistance de 4.7 K en entrée.
Donc tu recommandes de mettre une 1.5 K, exact ? -
C'est ça, tu peux même souder la 1.5K en // sur la 4K7, c'est ce que je fais.
T'aurais une photo du PCB, tjs intéressant de voir ce que font les autres avec des projets opens source
-
Bingo : Avec une 1,5 K en // sur la 4.7 K, la téléinfo est détectée !
Merci infiniment, Charles ! J'étais un peu frustré depuis Jeudi !Les linky auraient donc une impédance différente.....
NB : Comment je peux t'adresser les schémas dont je dispose ?
-
Le PCB que j'utilise a été créé par 'Christopheleneuf', alias 'totof60' , et visible ici :
https://oshpark.com/shared_projects/hSgAFVbn -
@Doume
Merci de l'information. Ton montage a bien le transistor mosfet, c'est ce que je voulais vérifier -
Bonjour,
Je rencontre 2 problèmes avec Wifinfo sur un module Wemos D1 :
1°) Lorsque j'utilise l'appel à la requête http://ip_wifinfo/json , je reçois bien une réponse au format json.
Note : J'ai un abonnement EDF triphasé !
Toutefois, à la fin de la liste, deux valeurs sont 'doublonnées', et leur nom contient des carcatères ^M (0x13) ou ^D (0x04) (voir les deux derniers params ci-dessous, après PPOT){
"_UPTIME":9111,"ADCO":xxxxxxxxxxx,"OPTARIF":"HC..","ISOUSC":30,"HCHC":34000,"HCHP":33660,"PTEC":"HC..","IINST1":13,"IINST2":0,"IINST3":0,"IMAX1":60,"IMAX2":60,"IMAX3":60,"PMAX":6150,"PAPP":3380,"HHPHC":"A","MOTDETAT":0,"PPOT":0,"IINT3":0,"MOTETAT":0
}On dirait que pendant la construction de la liste, le process est interrompu, et à sa reprise la liste chainée a été modifiée ( par la lib Tinfo ?)
La page /tinfo ne semble pas affectée par cela, mais la fonction qui construit cette page execute un ESP.wdtFeed() , que ne fait pas la fonction sendJSON(void)~Dernière minute :~ Je viens de tester une version modifiée, avec un appel à ESP.wdtFeed() au début de la fonction sendJSON()
Bingo : La réponse ne contient plus de doublon, ni de caractères 0x13 ou 0x04 !2°) Lorsque je mets en oeuvre l'option 'emoncms', tout fonctionne bien durant 20 heures environ. Puis Wifinfo devient inaccessible via Web et cesse d'alimenter emoncms.
Et il semblerait que je ne sois pas le seul dans ce cas (forum easydomoticz.com)
Pour l'instant j'ai désactivé emoncms pour voir si le soft reste stable.... -
J'avance un peu sur ce problème :
1°) Il semble concerner plutôt les utilisateurs en triphasé, que ceux en monophasé
2°) En triphasé, le tableau Teleinformation contient 17 lignes, donc le temps de mise à jour / construction est probablement plus long....
3°) Dès que l'on constate un 'blocage' de la page Teleinformation, une requête directe au module de type /tinfo.json retourne une structure 'polluée', donc le browser ne sait plus l'afficher (et ça semble 'définitif', jusqu'au reboot.
Donc c'est probablement le librairie Tinfo qui a niqué la liste, et jamais elle ne sera régénérée 'propre' !
[
{"na":"ADCO", "va":"XXXXXXXXX", "ck":"I", "fl":4},
{"na":"OPTARIF", "va":"HC..", "ck":"<", "fl":4},
{"na":"ISOUSC", "va":"30", "ck":"9", "fl":4},
{"na":"HCHC", "va":"000047194", "ck":"_", "fl":4},
{"na":"HCHP", "va":"000054402", "ck":""", "fl":4},
{"na":"PTEC", "va":"HP..", "ck":" ", "fl":4},
{"na":"IINST1", "va":"001", "ck":"I", "fl":4},
{"na":"IINST2", "va":"000", "ck":"I", "fl":4},
{"na":"IINST3", "va":"000", "ck":"J", "fl":4},
{"na":"IMAX1", "va":"060", "ck":"6", "fl":4},
{"na":"IMAX2", "va":"060", "ck":"7", "fl":4},
{"na":"IMAX3", "va":"060", "ck":"8", "fl":4},
{"na":"PMAX", "va":"04450", "ck":"3", "fl":4},
{"na":"PAPP", "va":"00510", "ck":"'", "fl":4},
{"na":"HHPHC", "va":"A", "ck":",", "fl":4},
{"na":"MOTDETAT", "va":"000000", "ck":"B", "fl":4},
{"na":"PPOT", "va":"00", "ck":"#", "fl":4},
{"na":"ACO", "va":"XXXXXXXXX", "ck":"I", "fl":2} cette ligne est excédentaire !
]~Workaround :~ Pour l'instant, j'ai limité la boucle de la fonction tinfoJSONTable() à 17 tours, le maximum en triphasé. Mais ce n'est pas vraiment élégant !
Tests en cours.....
PS : Y-a-t-il un moyen, sur ESP8266, de rendre non interruptible une séquence ?
Par exemple lorsque la librairie Tinfo met à jour la ListValues et ses indexs ? -
@Doume
ça me rappelle un problème avec une version précédente de la librarie LibTeleinfo, tu as bien la dernière version ?
C'est un problème de corruption de données reçues, pas de temps. comme la données corrompue est différente, elle est ajoutée à la liste.
Le même type de problème était décrit par iciPour info, la fonction tinfoJSONTable n'est jamais interrompue par la librairie.
Faudrait passer tout ça avec les nouvelle lib Async et ArduinoJSON, ce serait bien plus rapide et performant mais j'ai pas le temps pour ça, dommage.
Je crois que ça à été implementé dans Remora
A voir et à tester. -
Effectivement , certaines données sont corrompues ( caractères 0x04 ou 0x13 en plein milieu de noms de variables).
Par contre, si les données sont corrompues à la réception sur le port série, la checksum devrait permettre de détecter cette corruption, et ignorer cette data, non ?J'ai fait un 'filtre' qui écarte les variables dont le nom n'est pas dans la liste de 35 noms connus : En cas de nom inattendu, je force la loop() du main sketch à réinitialiser la liste LibTeleInfo
==> tinfo.init()
Et je compte le nombre de fois où ça se produit...
En 24 heures de fonctionnement => 13 reinit !
Mais plus aucun blocage dû à des tables json impropres !Je ne sais pas si j'utilise la dernière version de la lib Teleinfo, et je n'ai pas encore compris comment la recompiler et l'installer....
Dans le Github AufiElec, je n'ai pas identifié les modifs à ce sujet !
-
OK, si j'ai compris ce que j'ai lu sur le Blog concernant Remora, une version de LibTeleinfo a été modifiée, pour corriger ce problème de mauvais alignement lors de l'allocation en liste chainée...
Mais toutes les LibTeleinfo.cpp que je trouve pour l'instant ne semblent pas utiliser les fonctions suggérées :#ifdef ESP8266
lgname = xPortWantedSizeAlign(lgname+1); // Align name buffer
lgvalue = xPortWantedSizeAlign(lgvalue+1); // Align value buffer
// Align the whole structure
size = xPortWantedSizeAlign( sizeof(ValueList) + lgname + lgvalue ) ;
#else
size = sizeof(ValueList) + lgname + 1 + lgvalue + 1 ;
#endifCelle qui est utilisée actuellement est comme ceci :
// Our linked list structure sizeof(ValueList)
// + Name + '\0'
// + Value + '\0'
size_t size ;
#ifdef ESP8266
lgname = ESP8266_allocAlign(lgname+1); // Align name buffer
lgvalue = ESP8266_allocAlign(lgvalue+1); // Align value buffer
// Align the whole structure
size = ESP8266_allocAlign( sizeof(ValueList) + lgname + lgvalue ) ;
#else
size = sizeof(ValueList) + lgname + 1 + lgvalue + 1 ;
#endifest-ce la dernière version ?
Si non, où trouver la bonne ?
Je suis un peu paumé....je ne trouve pas de Github incluant une librairie avec les fonctions nouvelles suggérées....
-
Il y a un repo officiel pour la librairie
https://github.com/hallard/LibTeleinfo -
Ok, donc la suggestion trouvée dans le Blog Remora n'a pas été avalisée.... (xPortWanted....)
Dans ce cas, il semblerait que j'utilise la dernière version du Github officiel (marquée 1.0.2)
Mais le canard est alors toujours vivant.... -
Je ne comprends pas pourquoi la structure _ValueList contient , pour name et value, des pointeurs vers elle-même sur les tableaux de char alloués en même temps que la structure, de manière contigüe...
Pourquoi ne pas allouer directement les tableaux de char dans la structure , comme suit :
struct _ValueList
{
ValueList *next; // next element
uint8_t checksum;// checksum
uint8_t flags; // specific flags
char name[16]; // LABEL of value name
char value[16]; // value
};Note : Il semble qu'aucun nom ne dépasse 8 caractères (MODETAT) et aucune valeur ne dépasse 12 ( N° ADCO )
Je pense qu'il y aurait moins de soucis d'alignements , non ?
-
Je me suis fait une version de LibTeleinfo qui n'utilise plus du tout de malloc / free.
Un tableau de 50 entrées maximum est alloué en statique, dans lequel sont gérées les variables et leur valeur.
Pour l'instant, je n'ai plus constaté la moindre altération des noms de variables.
Après des tests sur la durée, je mettrai en ligne cette version modifiée de Wifinfo si la robustesse se confirme.Je pense que la gestion dynamique de la mémoire par malloc et free est buggée sur le SDK Arduino IDE. Ou alors, le fait de faire des malloc d'un structure + lgname+1 + lgvalue+1 sème la zizanie dans la gestion de mémoire. C'est la seule explication plausible que je vois à l'altération aléatoire des noms de variables. Car elles étaient bonnes au moment où elles sont créées (checksum correcte) , et on les retrouve altérées quand on les relit : Donc il y a eu recouvrement des allocations !
A suivre....
-
Je pense que la preuve est faite, en ce qui me concerne :
Version officielle de LibTeleinfo (utilisant malloc / free ) : En 48 heures, 55 détections de data altérées
Version modifiée (tableau statique) : En 48 heures, 0 détection de data altérée... -
bonjour doume,
j ai aussi des problèmes comme toi.enfin moi je suis en monophasé. mes retour sont bon un moment et après un temp variable 5min a 24h c'est caractère bizarre et décalage.
si ça peux faire avance le schmilblick et que tu veux bien partager ta modif je la testerai.merci par avance.
-
Je te propose de flasher le binaire pointé ci-dessous :
http://www.dambrain.fr/zip/Wifinfo.cpp.bin.gz
Tu devras bien sûr le dézipper pour obtenir un fichier Wifinfo.cpp.bin pour le flasher.Tu verras que dans l'onglet 'Système', il y a une ligne 'Altérations Data détectées' qui affiche un compteur des noms de variables abîmés : Il devrait rester à zéro (c'est mon cas sur les dernières 72 heures).
Alors qu'avec la version classique, j'avais environ 50 altérations sur 48 heures.
Note : Cette version contient aussi la fonctionnalité "HttpRequest" dans la configuration, qui permet d'interfacer Domoticz....Mais pour cela il faut aussi flasher le SPIFFS correspondant :
http://www.dambrain.fr/zip/Wifinfo.spiffs.bin.gz
Mais ça n'est pas nécessaire si tu n'as pas besoin de cette interface !Si tu me confirmes que c'est OK chez toi, en monophasé, je mettrai les sources modifiées en ligne sur Github
