Bonjour, Une modif de Tasmota est en cours pour corriger les problèmes du mode Standard. Il me reste juste a vérifier que la modif n'a pas dégradé le mode Historique. Est-ce que quelqu'un pourrait me fournir une capture brute d'un mode Historique pour que je puisse tester ? Il me faut une capture binaire, sans conversion sur les LF/CR. Merci d'avance Barbudor

... et bien j'ai trouvé... Je trouvais dommage de mettre un raspi pour broadcaster le message de téléinfo même si c’était un raspi zéro. J'ai donc utilisé WifInfo avec un WEMOS et effectué les modifications suivantes : /* ====================================================================== Function: NewFrame Purpose : callback when we received a complete teleinfo frame Input : linked list pointer on the concerned data Output : - Comments: it's called only if one data in the frame is different than the previous frame ====================================================================== */ void UpdatedFrame(ValueList * me) { char buff[32]; // Light the RGB LED (purple) if ( config.config & CFG_RGB_LED) { LedRGBON(COLOR_MAGENTA); // led off after delay rgb_ticker.once_ms(BLINK_LED_MS, LedOff, RGB_LED_PIN); } sprintf_P( buff, PSTR("Updated Frame (%ld Bytes free)"), ESP.getFreeHeap() ); Debugln(buff); /* */ // Envoi d'une trame en broadcast // Got at least one ? if (me) { WiFiUDP myudp; IPAddress ip = WiFi.localIP(); // start UDP server myudp.begin(1201); ip[3] = 255; // transmit broadcast package myudp.beginPacket(ip, 1201); // start of frame myudp.write(TINFO_STX); // Loop thru the node while (me->next) { me = me->next; // prepare line and write it // sprintf_P( buff, PSTR("%s %s %c\n"),me->name, me->value, me->checksum ); sprintf_P( buff, PSTR("\n%s %s %c\r"),me->name, me->value, me->checksum ); myudp.write( buff); } // End of frame myudp.write(TINFO_ETX); myudp.endPacket(); myudp.flush(); } j'ai juste modifié la "fabrication de la trame UDP. Maintenant ça fonctionne et ma BDD se rempli correctement. La trame udp est seulement transmise à l'occasion d'une évolution d'une valeur. ... INSERT INTO DbiTeleinfo (DATE,ADCO,OPTARIF,ISOUSC,HCHC,HCHP,PTEC,IINST1,IMAX1,PAPP,HHPHC,MOTDETAT) VALUES (NOW(),'xxxxxxxxxxxx','HC..','45','009607033','000293332','HP..','003','090','00780','A','000000'); ... Merci à Charles pour le travail effectué. Nouveau sur le raspi, si quelqu'un peut me proposer des outils efficaces pour programmer et debugger dans un environnement confortable... Bonne journée.

Bonjour, J'ai finalement acheté l'adaptateur ci-dessus, mais ça ne fonctionne pas du tout en lui reliant Pitinfo (GND sur GND, Vcc sur Vcc et Tx sur Rx)

Coucou, je viens de tester ce montage (j'ai un autre montage avec juste un opto et une résistance qui arrivait à être lisible par un nodemcu, mais y'a un peu de bruit on dirait du coup j'essaye de faire un truc plus propre), et tout fonctionne bien à condition que je ne branche pas le 3v3 (enfin, « 3v » sur mon nodemcu). Le montage ressemble à ça: [image: 1598198461039-img_20200823_175917-resized.jpg] Une idée de ce qui pourrait ne pas fonctionner ? Rémy

Bonjour, Oui c'est possible, surtout si tu es en Linky, tu es en mode standard ou historique ?

Cela fonctionne parfaitement. J'avais bien testé avec 4.7k sur la pulldown mais je n'étais pas descendu en dessous de 2.2k sur R1. Merci beaucoup.

Bonjour Thierry, Tu essais de compiler quel programme à la base ? pour faire quoi ?

Bonjour C'est en grande partie ce que je fait dans mon application piloteVmc Dans lequel j'ai modifié le logiciel Teleinfo qui affiche les courbes tempo avec le logiciel Hignchart Highstock. Marc

Piste 1, la config n'est pas bonne. Comme indiqué ici, le plugin n'accepte plus les requêtes en GET. Il faut utiliser le script GWTeleinfo.php comme intermédiaire. Et du coup dans URL il faudra mettre /GWTeleinfo.php Piste 2, oui ça paraît très long. Pas moyen de tester plus proche ? Et puis ça paraît très bizarre de mettre du 1.5mm² pour de la téléinformation. T'es sur quelles bornes du compteur électrique ? Certain de ne pas être sur le contact HP/HC ? Une fois validé le fonctionnement, un câble blindé avec paire torsadé pourrait aider. Tu peux utiliser un câble ethernet, c'est pas très cher. Piste 3, t'es parti sur quel schéma ? Celui sur cette page ? A priori je dirais que c'est bon oui. Au pire tu le retournes pour essayer. Par contre, t'as un compteur Linky ou pas ? Parce qu'avec le Linky, certains ont été obligés de changer une résistance, en abaissant la valeur de celle de 4,7k.

Bon je me réponds à moi même: il manque (au moins) la diode tête bêche en entrée de l'opto-coupleur

Comiling Problem

Je m'auto-réponds (pas vu d'option d'édition) pour corriger l'énormité que j'ai commise : bien entendu, si la réponse passe par un simple module FTDI, ce ne seront certainement pas Tx et Rx qu'il faudra relier, mais, je suppose, Tx et Ground. J'ai beau être une brêle en électronique, il y a des limites ! Ceci étant précisé, la question du comment faire reste ouverte. Merci.

@charles merci! Je me suis servi de cette aide sur mysql pour avoir des commandes en lignes. Ca marche! https://doc.ubuntu-fr.org/mysql

J'apporte un petit retour sur mon "expérience". Enedis est intervenu au coin de la rue pour corriger le soucis après 22 jours ! Et fiers d'eux, ils me proposent de ne pas faire de régularisation car le tarif était à mon avantage (tous les jours rouges ont basculé en blanc à 11h54).. Mouais, sauf que le compteur ayant fournit des informations erronées à ma maison domotisée, la conso à été supérieure à ce qu'elle aurait été sans cette panne. En jours rouge, mon chauffe-eau ne se déclenche pas, les radiateurs non plus (j'utilise la cheminée) mais la maison se croyant en blanc, j'ai consommé chaque jour un peu de 'blanc' au lieu de rien en 'rouge'. Je pensais profiter de cette panne, au final, elle va me couter.

Je me réponds à moi-même. Je suis passé en version 1.0.6 et ça a fonctionné du premier coup !