Posts made by Doume

Dommage : Le concept de shield pour Wemos me plait bien...
Mais la soudure composants CMS, je le sens pas trop (je suis plus à l'aise avec le soft !)
Merci, quoi qu'il en soit.

On peut acheter ce lot de 4 cartes avec les composants soudés dessus ?

La version que j'ai modifiée est capable d'envoyer des datas vers Domoticz, car deennoo avait fait le nécessaire en implémentant la configuration d'une requête Http.
Par contre, rien n'est prévu pour utiliser le SSL (port 443 vers Domoticz).

Si tu tiens à conserver l'accès à Domoticz en SSL, le mieux serait d'utiliser un script shell pour interroger périodiquement Wifinfo, extraire les données Jason qui t'intéressent, et les soumettre à domoticz via MQTT, par exemple. C'est ce que je fais chez moi, pour être capable de tirer parti de toutes les données Teleinfo rendues par un compteur triphasé.

Eventuellement, s'il y a des gens intéressés, la version 'LibTeleinfo statique' est disponible ici :
https://github.com/Doume/LibTeleinfo.git
Utiliser la branche 'static' du Github (branche par défaut)

Voir le README pour la liste des modifications apportées.

Pour info, elle tourne depuis 9 jours chez moi, avec 0 altération détectées, sur un Wemos D1.

Damned : Cela veut dire qu'il y a encore un loup quelque part....
Chez moi, ce compteur est à 0 depuis 5 jours....

En fait, a chaque fois que la table des variables est balayée pour construire une page, ou préparer la requête vers emoncms, ~chaque nom de la table~ est comparé aux 35 noms connus.
Si le nom est inexistant dans la liste de référence ( caractère binaire au milieu, par exemple ) , le compteur est incrémenté de 1 et à la prochaine boucle loop() , on réinitialise la Teleinfo ( tinfo.init()

Le canard est donc encore vivant !

Par contre tu ne devrais plus constater de blocage complet, grâce au réinit sur erreur

@difful : Tu pourrais me préciser quelles interfaces tu utilises ( emoncms, jeedom, httprequest ) ?
et avec quelle fréquence ?

Tu peux préciser, quand tu dis '1 erreur' ?
C'est le compteur affiché dans l'onglet 'Système' , ou bien un blocage de l'interface emoncms ou jeedom ?
La version que je t'ai proposé d'installer, en cas de détection d'erreur, redémarre l'interface Teleinfo, donc ça devrait pas bloquer....

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

@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....

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 SDK

Par contre, je n'ai pas pu essayer la solution sur autre chose qu'un ESP-8266 (Wemos D1 mini).

@difful

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

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...

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 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 ?

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....

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 ;
#endif

Celle 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 ;
#endif

est-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....

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 !

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 ?

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....

Le PCB que j'utilise a été créé par 'Christopheleneuf', alias 'totof60' , et visible ici :
https://oshpark.com/shared_projects/hSgAFVbn

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 ?