Tasmota
-
@Nicolas-Bernaerts : bon, j'ai remis en service mon vieux RPi 2B et installé ton script.
Mais j'ai à nouveau un problème (décidément) :
tasmota-flash --esp32 --flash 'tasmota32-teleinfo-denkyd4-8m4m.bin' ----- Device ----- Model : unknown ESP32 (revision 3) Size : Unknown MAC : 4c:75:25:eb:1f:5c ----- Flash ESP32 ----- esptool.py v2.8 Found 2 serial ports Serial port /dev/ttyAMA0 Connecting........_____....._____....._____....._____....._____....._____....._____ /dev/ttyAMA0 failed to connect: Failed to connect to Espressif device: Timed out waiting for packet header Serial port /dev/ttyACM0 Connecting.... Detecting chip type... ESP32 Chip is unknown ESP32 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 4c:75:25:eb:1f:5c Enabling default SPI flash mode... Configuring flash size... Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB Erasing flash... A fatal error occurred: Timed out waiting for packet headerJ'ai le même souci avec le factory et avec l'argument "erase".
La fin de mon dmesg si ça peut aider :
[ 1862.620959] usb 1-1.5: new full-speed USB device number 4 using dwc_otg [ 1862.765506] usb 1-1.5: New USB device found, idVendor=1a86, idProduct=55d4, bcdDevice= 4.44 [ 1862.765551] usb 1-1.5: New USB device strings: Mfr=0, Product=2, SerialNumber=3 [ 1862.765575] usb 1-1.5: Product: USB Single Serial [ 1862.765594] usb 1-1.5: SerialNumber: 556B000342 [ 1862.987071] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device [ 1862.987295] usbcore: registered new interface driver cdc_acm [ 1862.987311] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adaptersMerci
EDIT : mais il est antédiluvien mon esptool !
-
-
@Charles J'avais vu après avoir posté mon message. Quelle galère pour avoir une version récente sur RPiOS (pourtant une bookworm).
apt ne propose que la V2.8 et pip refuse d'installer quoique ce soit en "imposant" de passer par le gestionnaire de paquets
J'ai dû bricoler en récupérant les binaires arm sur le dépôt d'espressif et remplacer à la main ceux fournis par Debian. C'est sale !!!
Mais c'est passé.
-
@Wendigogo bravo !
-
Et une procédure de flash une https://community.ch2i.eu/topic/1450/, désolé j'ai pas indiqué la méthode root avec
esptool
-
@Charles Je viens de la lire.
J'espère que ESP Flasher ne posera pas trop de soucis sous Windows.
J'ai compris pourquoi il disparaissait même quand j'autorisais le téléchargement : c'est mon antivirus (F-Secure imposé par mon travail) qui le mettait en quarantaine.
Je l'ai déclaré comme faux-positif mais je ne suis pas sûr que ça change quelque chose.
-
@Wendigogo yes si il disparait c'est soit un anti-virus ou anti-spyware les usines à gaz je prend un coeur de CPU rien que pour ça
T'facons avec les PC d'entreprises et les restrictions dans tous les sens, les dev ne peuvent plus bosser quasi -
@Wendigogo Esp Flasher sous windows fonctionne très bien. Je l'ai utiliser hier soir pour un flash d'ESP32, mais même souscis que toi, il était détecté comme un virus... Tu le déclares en faux positif, tu l'acceptes sous ton antivirus et ca roule....
-
@SebH : il m'a fallu un peu de temps pour comprendre que ça n'était pas mon navigateur qui refusait de le télécharger, alors que je l'ai autorisé, mais mon anti-virus qui le faisait disparaitre en quarantaine sans m'en informer.
Et une fois trouvé l'origine de la disparition, il a fallu sortir le fichier temporaire du navigateur de la quarantaine (avec élévation des privilèges), relancer le téléchargement, débloquer l'exécutable (bloqué par un autre morceau de l'antivirus) et le lancer en administrateur pour qu'il reste enfin à sa place.
L'anti-virus décide pour moi et, surtout, sans me consulter ce qui est autorisé ou pas sur ma machine : cette infantilisation des utilisateurs me gonfle assez fort ! 🤬
-
Hello,
Merci pour le travail sur Teleinfo et Tasmota, c'est top
J'avais une solution à base d'esp8266 maison qui fonctionnait bien en mode "historique". Je me suis dis que tant qu'à faire j'allais passer en mode standard mais depuis je n'ai plus rien.EDF m'a changé le mode cette nuit, mon home assistant n'a donc plus reçu d'infos depuis minuit car tasmota 13.1.0 était configuré en mode historique, ça ne me choque pas.
En revanche, en voulant passer en mode standard, mon esp reboot avec ces erreurs :
10:54:25.958 RSL: INFO3 = {"Info3":{"RestartReason":{"Exception":3,"Reason":"Exception","EPC":["4000e1f0","00000000","00000000"],"EXCVADDR":"4029f116","DEPC":"00000000","CallChain":["4021eeca","4010387e","40245a19","4000050c","4000066d","40245c41","4025226e","40252264","40245db8","4021f9ea","4022d6c6","40221a68","40223c14","402218c8","40222aa7","4023f3d4","4023f420","401009c4","40250238","40101de9"]},"BootCount":4}}Auriez vous une idée ? je suis obligé de faire un reset de la configuration pour qu'il redémarre correctement (donc en mode historique à nouveau), et je reproduis ce phénomène à chaque passage en mode standard.
Comment je pourrais débugguer ça ?
Merci
-
@olivierboudet Hello,
Le problème est logiquement lié à la résistance à mettre en tête de l'optocoupleur. Vous pouvez essayer de flasher mon fork pour vérifier le nombre d'erreurs de réception. Les erreurs ne devraient pas provoquer d'exception et sont affichées en temps réel sur la page d'accueil. -
@olivierboudet said in Tasmota:
Comment je pourrais débugguer ça ?
Merci
J'ai eu exactement le même cas de figure, appétit pour le monde standard et patatras, le firmware tasmota qui crache une exception on mode standard, tristesse et désolation. J'ai mis selon les excelleeeentes indications de @Charles une résistance d'1k sur un des conducteurs en provenance de la grosse boite verte (ca ne sera peut être pas nécessaire pour toi), et avec un esp8266 le fork de @Nicolas-Bernaerts s'est révélé fonctionnel (j'ai pris le tout petit sans littlefs).
-
@Nicolas-Bernaerts Petit retour d'expérience chez un de mes amis sur un linky en triphasé. A la base, il tournait sur ESP8266 avec ta dernière version , il avait une résistance de 1K et avec la commande ENERGYCONFIG STATS , il affichait 0 erreurs et pourtant avec les captures de données tcp_start, on pouvait voir des erreurs dans l'écriture du fichier.... (ce qui a attiré mon attention). Il y a peu de temps, je l'ai passer en ESP32 et la mystérieusement, il avait une tonne d'erreur signalé sur la page principale avec des étiquettes qu'il perdait et retrouvait par moment....
J'ai du donc lui descendre la valeur de cette résistance proche des 330 Ohms, et plus de signalement d'erreur sur la page principale. Néanmoins, je tiens a attirer l'attention, quand l'ESP vient à booter, quoi que tu as comme valeurs de résistance il te détecte des erreurs qui viennent a s'estomper au bout de 10 à 20 secondes. (l'ESP doit faire tout un tas de chose à l'init et ca doit freiner la réception des données au départ ) .
Petite annotation, malgré l'ESP32 utilisé, j'arrive a surcharger le CPU en utilisant des RULES pour l'envoie des données des différents compteurs vers mon domoticz, du coup j'ai des étiquettes qui viennent à disparaitre de temps à autre dans la TRAME TIC, et c'est assez flagrant. Il suffit que je désactive les 3 rules que j'utilise et toutes les étiquettes ré apparaissent
-
@SebH Hello Seb
Effectivement, je soupçonne que la mise en route du wifi stresse l'ESP et que du coup certains caractères soient perdus lors du boot. J'observe ce phénomène quelquz soit l'ESP. La solution est peut être de traiter les trames reçues uniquement quand le wifi est up. -
@SebH
Merci pour les retours. Effectivement j'ai une résistance 1k actuellement je vais essayer de baisser pour trouver la bonne valeur.
Et je vais aussi essayer le fork que je n'ai jamais essayé !
Merci je vous tiendrais au courant. -
@SebH Je viens de faire quelques tests concernant les erreurs de réception.
J'ai tout d'abord fait évoluer mon fork afin de ne recevoir les données du Linky que lorsque le réseau est monté et stable (adresse IP obtenue en Wifi ou Ethernet).
Sur un ESP32S3, je n'ai plus qu'une seule erreur de réception au démarrage, ce qui est normal puisque la première étiquette est logiquement incomplète.
Mais j'ai également observé quelque chose d'assez étonnant.
Avec un ESP32S3 accessible en LAN avec bonne connexion Wifi, très très peu d'erreurs.
Avec le même ESP32S3 accessible en 4G via un VPN Wireguard, beaucoup plus d'erreurs.
Cela semble donc indiquer que les erreurs de réception peuvent venir de 2 causes très différentes :- la résistance dont ce forum parle très souvent
- la qualité de la transmission par le réseau
(qualité de réception Wifi et/ou vitesse de transmission globale)
C'est comme si l'ESP ne gère plus la réception série en cours tant qu'il n'a pas réussi à envoyer une trame TCP complète.
-
Hello @Nicolas-Bernaerts, Je repenche sur l'evolution de mon wifinfo ESP8266, et je suis parti sur l'utilisation de Wemos ESP32-C3 => Du coup , existe il une version binaire compilé pour ESP32-C3 de votre version Teleinfo/Tasmota ? (je ne vois que des S2/S3 sur le repository) ? Merci !
-
Bonjour @Nicolas-Bernaerts je suis repassé sur une résistance de 220 en entrée de l'optocoupleur et j'ai flashé mon esp8266 avec le fork dans sa version "Teleinfo 13.3 (esp8266-4m-2m)" grâce au binaire pré-compilé.
Je ne vois pas de différence, dès que je vais dans la configuration du module pour configurer le bon GPIO en TInfo RX, le module restart mais semble faire un reset dans la foulée (la configuration n'est plus visible après le restart).
Dans la console, la commande EnergyConfig est aussi inconnue :
00:00:00.001 HDW: ESP8266EX 00:00:00.014 UFS: FlashFS mounted with 1984 kB free 00:00:00.076 CFG: Loaded from File, Compte 28 00:00:00.081 SER: Set to 8N1 115200 bit/s 00:00:00.151 Projet tasmota - Tasmota Version 13.2.0(tasmota)-2_7_4_9(2023-12-23T07:15:45) 00:00:00.151 HLP: ftp_help to get help on FTP Server commands 00:00:00.152 HLP: tcp_help to get help on TCP Server commands 00:00:00.152 HLP: tz_help to get help on Timezone commands 00:00:00.053 WIF: Connexion à l'AP1 XXXXXXX Channel 6 BSSId XX:XX:XX:XX:XX:XX en mode 11n comme tasmota-C68EAD-3757... 00:00:04.676 WIF: Connecté 22:16:17.005 HTP: Serveur web actif sur tasmota-C68EAD-3757 avec l'adresse IP 192.168.1.167 22:16:17.957 RSL: INFO1 = {"Info1":{"Module":"Generic","Version":"13.2.0(tasmota)","FallbackTopic":"cmnd/DVES_C68EAD_fb/","GroupTopic":"cmnd/tasmotas/"}} 22:16:17.959 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-C68EAD-3757","IPAddress":"192.168.1.167"}} 22:16:17.961 RSL: INFO3 = {"Info3":{"RestartReason":"Software/System restart","BootCount":9}} 22:16:22.792 RSL: STATE = {"Time":"2024-01-06T22:16:22","Uptime":"0T00:00:11","UptimeSec":11,"Heap":16,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":38,"MqttCount":0,"Wifi":{"AP":1,"SSId":"Box_Homgoz","BSSId":"68:A3:78:04:8A:81","Channel":6,"Mode":"11n","RSSI":100,"Signal":-37,"LinkCount":1,"Downtime":"0T00:00:05"}} 22:16:50.091 CMD: EnergyConfig 22:16:50.096 RSL: RESULT = {"Command":"Unknown"} 22:21:22.816 RSL: STATE = {"Time":"2024-01-06T22:21:22","Uptime":"0T00:05:11","UptimeSec":311,"Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"XXXXXX","BSSId":"XX:XX:XX:XX:XX:XX","Channel":6,"Mode":"11n","RSSI":100,"Signal":-37,"LinkCount":1,"Downtime":"0T00:00:05"}} -
@olivierboudet
Si EnergyConfig est inconnue, cela signifie que dans Configuration / Module, l'entrée Teleinfo Rx n'a pas été sélectionnée.
Ensuite, le log en 8N1 115200 montre que la configuration n'est pas bonne. Il faut aller dans Configuration / Configure Teleinfo, sélectionner Mode standard (9600) et faire un restart. Cela devrait être mieux. -
@nherreyre il n'y a pas de version esp32 C3 pour le moment, mais cela devrait être très simple à compiler. Je vais ajouter cette cible sur le prochaine version.
