WifiInfo, le serveur WEB Téléinfo aux multiples facettes

[AuFilElec]

Salut @Benjy-Net

Je pense que tu devrais regarder du côté de la Remora

[mjeanne]

@Benjy-Net Bonjour, si je comprends bien votre problématique vous souhaitez utiliser la paire pour remonter le signal de téléinfo à la place de celui du contacteur.
Perso j'utilise Wifinfo sur un wemos D1 mini, et le relai du chauffe-eau reste branché sur la sortie du compteur, bien que je ne l'utilise plus. Le Wemos communique en wifi, donc pas besoin de fils, juste d'une prise proche du compteur et d'une vieille alim usb. Le wemos est placé dans une boite de dérivation, pour l’esthétique..
La remonté d'info vers ma domotique se fait chez moi vers une box jeedom, sans difficulté, puisque intégré au logiciel de Charles. Et c'est ensuite ma box qui décide d'allumer ou non le chauffe-eau, selon la tarification la plus avantageuse (j'ai l'option tempo, il est préférable de chauffer un jour blanc plutôt qu'une nuit rouge..). Pour cela, j'ai un module zwave qui remplace le relai EDF (ne pas piloter directement le chauffe-eau, à moins d'avoir un module qui gère la puissance nécessaire !)

[Benjy Net]

@mjeanne
Oui je comprends, mais j'ai le compteur EDF sur la rue à 25m de la maison et j'ai pas la possibilité d'y glisser le wemos (en plus du wifi qui est complètement dans les choux). Je suis donc obligé de récupérer mes 2 fils qui servent d'asservissement pour y faire passer à la place la téléinfo. Pour ce qui est de la domotique je pourrais faire pareil, mettre un relais zwave sur le contacteur du chauffe eau et laisser la box gérer mais si par mégarde il y a plantage de la box alors pas d'eau chaude. J'aurai finalement préféré avoir directement un MOC ou relais commandé par le Wifinfo sur réception de la trame HC. J'ai regardé rapidement mais toutes les pins sont utilisées, je pense passer sur un esp12E mais Wifinfo n'a pas l'air de fonctionner dessus, surement dû au changement des pins. J'ai mis le nez dans le code de Charles et pfiou quand on est pas codeur, il faut ingurgiter pas mal de choses pour pouvoir le modifier/adpater à ses besoins !

[Benjy Net]

Bon, j'ai mangé de la ligne de code, j'arrive à comprendre à peu près ce que @Charles a fait. C'est super chiadé quand même ! Reste mon problème de pin pour activer ou non mon relais. Je pensais utiliser la RED_LED_PIN car j'ai l'impression qu'elle ne sert à rien pour le moment dans son code (ou alors carrément utiliser la GPIO 14 qui a l'air dispo).
Petite évolution à prévoir aussi, mais je crois que c'est dans la todolist, pouvoir envoyer une notification push lors d'un dépassement ADPS pour pouvoir gérer du délestage par exemple par les box domotiques.
Dernière chose, j'ai pris un Wemos D1 mini pro, on est plus à l'aise pour la mémoire... nettement supérieure et en plus équipé d'une antenne et d'un connecteur externe.

[Doume]

Bonjour à tous
Dans le code de Wifinfo, on constate qu'il peut faire du debugging serial
Dans Arduino IDE, j'ai le choix pour sélectionner le port sérial, mais dans ce cas il ne m'affiche que des caractères illisibles dans le Moniteur série, ou alors via l'adresse IP de la Wemos.
Mais via l'adresse IP, lors du lancement du Moniteur Série, il me demande un mot de passe d'accès à la console.... C'est quoi, ce mot de passe ? je ne le trouve nulle part dans le code...

[mjeanne]

@Doume Je ne me souviens plus du code exact, mais le port série pour le débug n'est pas le même que pour la programmation. Je crois qu'il y a un swap de serial et serial1 à un moment.

[Doume]

Effectivement, j'ai bien constaté qu'il y avait un 'swap' entre Serial et Serial1
Car je pense que le port série standard est occupé par l'interface Teleinfo vers le compteur

Mais comment fait-on ? il faut connecter un USB/TTL sur le port secondaire, et monitorer ce port USB additionnel dans Arduino IDE ?

[Charles]

@Doume
Alors oui il y a bien un SWAP mais c'est pas un swap entre Serial et Serial1 c'est un swap de pin pour la Serial. C'est pour éviter un conflit entre l'arrivée téléinfo RX et le RX lors d'une reprogrammation série (que ce soit sur la même pin),

Pour le débug, je conseille d'utiliser le Serial1 (TX seulement) car si on utilise le Serial par défaut il est configuré pour la téléinfo, donc a 1200bps (mais c'est possible, il suffit d'avoir un moniteur serie ou terminal en 1200bps

Pour débugger via la Serial1 à 115200, et oui avec un adaptateur USB TTL tel que celui-ci (ils sont top car configurable en 3.3V ou 5V avec régulateur 3.3V embarqué). Il suffit de brancher le cavalier entre TX et TX1 de mémoire (ou TX et TX0 je crois qu'il y avait une erreur d'écriture sur le PCB de WiFinfo d'ailleurs)
Ou sinon juste GND et le TXD1 de WifiInfo vers l'adaptateur USB Serial

Pour le Serial1, c'est d'ailleurs la configuration par défaut

Pour débugger via la Serial1 (a 115200bps)

#define DEBUG
#define DEBUG_SERIAL	Serial1
#define DEBUG_SERIAL1

Pour debugger en normal (Serial) a 1200bps

#define DEBUG
#define DEBUG_SERIAL	Serial
//#define DEBUG_SERIAL1

[mjeanne]

This post is deleted!

[Doume]

@Charles
Merci pour ces éclaircissements : Je n'étais pas très loin de la solution, après tout !
Faudra que je trouve quelles pins sont utilisés pour Serial1 sur une Wemos....

Je me suis essayé à modifier les sources de Wifinfo, pour gérer une table de log circulaire en mémoire, qui serait affichée sur un onglet supplémentaire de la page Web, un peu comme ESPeasy (ce serait quand même plus confortable à debugger...)
Mais les macros utilisées par le soft ( Debug, DebugF, etc... ) ne rendent pas la chose facile, compte-tenu de la variété des paramètres passés !

[Doume]

Complément d'information : Sur une Wemos D1, le Serial1 TXD est en D4
Et effectivement, ça fonctionne....

Merci encore pour les infos

[Doume]

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

Les 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

[Charles]

@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

[Doume]

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 ?

[Charles]

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

[Doume]

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 ?

[Doume]

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

[Charles]

@Doume
Merci de l'information. Ton montage a bien le transistor mosfet, c'est ce que je voulais vérifier

[Doume]

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

[Doume]

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 ?