WifiInfo, le serveur WEB Téléinfo aux multiples facettes
-
@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
-
Bonjour et merci pour ces informations.
C'est Super curieux car ce problème a été réglé l'année dernière et je sais de quoi je parle j'y ai passé un moment avant de trouver le problème et depuis il a complètement disparu.
Donc d'une soit la librairie utilisée par le compilateur n'est pas la dernière où il ne prends pas les sources au bon endroit soit c'est un bug introduit par une maj du SDK.
Je recompilerais donc tout avec tout à jour pour vérifier si j'ai aussi le soucis. @AuFilElec tu as le soucis toi ? -
Je suis convaincu de ne pas utiliser la dernière release du SDK, car les versions récentes de Arduino IDE ne voulaient pas fonctionner sur Ubuntu 16.04 64 bits.
J'utilise donc l'IDE version 1.6.5
En ce qui concerne la LibTeleinfo, je me suis assuré qu'il compilait bien la dernière version en y introduisant une erreur de syntaxe, pour vérifier que le compilateur coinçait !
Je penche indéniablement pour un SDK buggé sur la gestion de mémoire, au moins sur ESP-8266 .Mais plutôt que de chercher une aiguille dans une meule de foin, j'ai préféré me passer des malloc / free, et opter pour une allocation statique : Je doute qu'un installation Wifinfo dépasse les 50 variables, et aucun nom ni valeur ne dépasse 16 octets...
Au moins, ce genre de solution est robuste, et ne sera pas dépendant de la version SDKPar contre, je n'ai pas pu essayer la solution sur autre chose qu'un ESP-8266 (Wemos D1 mini).
-
@Doume
je viens de vérifier un truc, tu pourrais essayer en supprimant tous les #pragma pack / push de la LibTeleinfo pour voir, j'ai un doute. -
@Doume
merci je viens de finir l install non sans mal l' update par wifinfo plantait bon il ne faut pas utiliser Firefox comme browser ça marche pas avec chrome impeccable.
donc en test je donne un retour d ici 48h.
merci encore. -
@Charles said in WifiInfo, le serveur WEB Téléinfo aux multiples facettes:
@Doume
je viens de vérifier un truc, tu pourrais essayer en supprimant tous les #pragma pack / push de la LibTeleinfo pour voir, j'ai un doute.Je l'avais essayé, sans succès : Je continuais à détecter des noms de variable altérés....
-
bon, je viens de vérifier et faire un pull de toutes les versions des librairies et de LibTeleinfo.
J'ai refait une compilation de WifInfo toute fraîche, voici ce que ça donne une fois tout uploadé.
Plus qu'a attendre de voir si j'ai des étiquettes altérées. J'en avais pas jusqu'ici mais au moins on saura si ça vient du SDK
-
Effectivement, ma version de SDK est 1.5.3, alors que tu as compilé avec une version 2.0.0.
Ca peut faire la différence quant à la gestion de la mémoire
