Tasmota
-
@sebh oui tu as tjs le pb car en mode standard, c'est depuis que j'ai changé des choses pour afficher dans l'interface, j'ai du faire une boulette quelque part mais sans linky je ne peux pas débugguer cette partie.
Essaie de suppriler toute cette partie, c'est la dedans que j'ai fais des modifs
https://github.com/arendst/Tasmota/blob/development/tasmota/xnrg_15_teleinfo.ino#L873-L897Pour le reset en changement de pin rx comme l'a indiqué @Barbu-Dor c'est normal ca reset juste après pour recharger la nouvelle config serial. mais après le reset la config ne dois pas être perdue.
Tu peux aussi passer ta téléinfo en mode historique (ca fonctionnera pas nous sommes d'accord) mais ca ne devrait au moins pas planter.
-
@charles Page de doc créée
https://github.com/tasmota/docs/blob/development/docs/Teleinfo.mdPour la mise a jour, comme pour le code, soit tu fork, tu clones, tu PR
Ou alors directement en ligne dans GitHub (GitHUb fork et crée les branches et PR automatiquement)Attention MKDOCS demande une syntaxe de markdown un peu particulière et la preview de GitHub n'est pas forcément correcte.
Tagguer quand tu aurs fait la PR pour que je vérifie (j'ai les outils mkdocs pour vérifier)
La page est dans la branche développement car elle se rapporte a des modifications disponibles dans la branche développement de Tasmota. Donc elle n'est pas visible autrement que sur GitHb (la doc publiée est celle de la release).
Elle passera en master quand la 9.3 sortira (avant fin avril) -
@barbu-dor Oh nice, tu as même déjà documenté, merci à toi. Oui pour la doc je le fais les edit depuis github, c'est assez pratique. Mais j'ai aussi déjà payé le prix du preview correct mais une fois mergé ca ne l'était plus, donc je vais faire attention
Merci à toi en tout cas, je pense que j'aurais quelques questions aussi sur les triggers et berry un peu plus tard.
-
@barbu-dor Merci pour ton retour concernant les triggers sur les messages JSON.
Je précise mon problème.
Cela marche bien sur la version 9.3.1.1 que j'ai compilé.
Par contre sur la 9.3.1, de Nicolas Bernaerts, les triggers sur les messages JSON ne marchent pas.
Est-ce que cela pourrait venir de la forme des messages JSON qui ne sont pas formatés de la même façon que sur la version tasmota standard?19:49:06.821 MQT: tele/tasmota_DF20CB/SENSOR = {"Time":"2021-04-10T19:49:06","TIC":{"ADSC":"031776013513","VTIC":"02","DATE":"E210410194907","NGTF":"BASE","LTARF":"BASE","EAST":"027416815","EASF01":"015506752","EASF02":"009861893","EASF03":"000826037","EASF04":"000514699","EASF05":"000442412","EASF06":"000265022","EASF07":"000000000","EASF08":"000000000","EASF09":"000000000","EASF10":"000000000","EASD01":"009975618","EASD02":"008227431","EASD03":"002960408","EASD04":"006253358","IRMS1":"002","IRMS2":"002","IRMS3":"002","URMS1":"223","URMS2":"242","URMS3":"243","PREF":"12","PCOUP":"12","SINSTS":"01370","SINSTS1":"00462","SINSTS2":"00480","SINSTS3":"00428","SMAXSN":"06243","SMAXSN1":"03094","SMAXSN2": ...La règle que j'utilise est
rule1 on URMS1 do var4 %value% endonJe te remercie.
-
@vincent835
Par rapport au message SENSOR que tu postes il manque le niveauTIC
Donc le trigger estTIC#URMS1et la règle correspondanterule1 on TIC#URMS1 do var4 %value%Le message a t'il un format différent entre les 2 versions ?
-
@barbu-dor
Je viens d'essayer ta proposition de règle sans succés.
Voici le message JSON sur la version 9.3.1.119:53:50.015 MQT: tele/tasmota_DF20CB/RESULT = { "ADSC":"031776013513","VTIC":2,"NGTF":" BASE ","LTARF":" BASE ","EAST":27416857,"EASF01":15506794,"EASF02":9861893,"EASF03":826037,"EASF04":514699,"EASF05":442412,"EASF06":265022,"EASF07":0,"EASF08":0,"EASF09":0,"EASF10":0,"EASD01":9975618,"EASD02":8227473,"EASD03":2960408,"EASD04":6253358,"IRMS1":2,"IRMS2":2,"IRMS3":2,"URMS1":225,"URMS2":237,"URMS3":245,"PREF":12,"PCOUP":12,"SINSTS":1305,"SINSTS1":482,"SINSTS2":390,"SINSTS3":433,"SMAXSN":6243,"SMAXSN1":3094,"SMAXSN2":3214,"SMAXSN3":2158,"SMAXSN-1":5714,"SMAXSN1-1":3559,"SMAXSN2-1":1954,"SMAXSN3-1":2064,"CCASN":790,"CCASN-1":1550,"UMOY1":229,"UMOY2":240,"UMOY3":239,"STGE":"003A4001 -
@vincent835
SiMQT: tele/tasmota_DF20CB/SENSOR = {"Time":"2021-04-10T19:49:06","TIC":{"ADSC":"031776013513", ....les champs sont sous l'object TIC alors =>
on TIC#URMS1 do ...Si
tele/tasmota_DF20CB/RESULT = { "ADSC":"031776013513","VTIC":2,"NGTF":" BASE " ....Les champs sont a la racinedu JSON alors =>
on URMS1 do ...(ou bienon URMS1#data do ....)
Je ne me rappelle jamais la règle exacte quand il faut ajouter#datapour un champ à la racine. Je crois que c'est quand il est orphelin mais dans si le 1er ne marche pas essaye le 2ndSi ca ne marche pas il faudra que je remonte une manip de test
-
@barbu-dor
Lorsque les champs sont à la racine du JSON, il n'y a pas de problème:on URMS1 do...marche même sans#data.
C'est lorsque les champs sont sous un objet que je n'arrive pas à faire déclencher le trigger.
Même avec la formeon TIC#URMS1 do...
Si tu trouves une solution, je suis preneur.
Merci. -
@Seb-H as tu solutionné ton problème?
J'essaie d'investiguer sur les bugs du mode standard avant la prochaine release, et j'ai créé un outil pour enregistrer les trames (et donc pouvoir les rejouer pour les tests et corriger les bugs)
L'outil est ici https://github.com/hallard/tinfo_replay des informations de bases sont dispo dans le readme
Je suis donc preneur de tout enregistrement de trame en provenance du linky avec idéalement une sur un contrat base et l'autre un contrat heures creuses, ca m'aiderait vraiment a améliorer la fiabilité.
vous pouvez poster le fichier .txt directement sur un post de réponse ici (bouton upload file)
Surtout pas d'édition des fichiers dans un éditeur texte ça foutrait tout en l'air
Merci à tous
PS : il est aussi possible qu'en mode standard avec MQTT la trame soit trop longue ca fait beaucoup d'étiquettes et valeurs à mettre dans le payload, il faudrait peut être définir une liste des étiquettes à renvoyer pour limiter la taille du payload MQTT
ADSC J21976885617 I DATE E200811150447 ? NGTF BASE < LTARF BASE F EAST 002493204 ' EASF01 002493204 : EASF02 000000000 # EASF03 000000000 $ EASF04 000000000 % EASF05 000000000 & EASF06 000000000 ' EASF07 000000000 ( EASF08 000000000 ) EASF09 000000000 * EASF10 000000000 " EASD01 40 @ URMS2 240 A URMS3 238 I PREF 09 H PCOUP 09 " SINSTS 00897 ^ SINSTS1 00267 F SINSTS2 00591 G SINSTS3 00038 D SMAXSN E200811115306 03320 . SMAXSN1 E200811115306 03050 _ SMAXSN2 E200811131815 02350 % SMAXSN3 E200811095922 00130 ( SMAXSN-1 E200810192506 04240 T SMAXSN1-1 E200810192506 03970 N SMAXSN2-1 E200810103044 00340 8 SMAXSN3-1 E200810085137 00380 I CCASN E200811150000 00578 > CCASN-1 E200811143000 00558 \ UMOY1 E200811150000 239 UMOY2 E200811150000 240 $ UMOY3 E200811150000 238 , STGE 00 MSG1 PAS DE MESSAGE < PRM 19858176535209 F RELAIS 000 B NTARF 01 N NJOURF 00 & 1JOURF+100008001 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE 9 -
@charles hello, effectivement, sur ma version j'ai été obligé d'augmenter la taille du buffer MQTT par défaut a 2200 octets du fait du nombre d'étiquettes. J'ai également limité la taille des données à 32 octets (pour éviter les NON UTILE à répétition). D'apres le standard, on peut avoir jusqu'a 74 donnees par message. Sur un compteur triphase en mode standard, j'ai eu jusqu'a 64 donnees.
-
Je suis donc preneur de tout enregistrement de trame en provenance du linky avec idéalement une sur un contrat base et l'autre un contrat heures creuses, ca m'aiderait vraiment a améliorer la fiabilité.
J'essayerai de faire un enregistrement ce soir.
J'ai un contrat base triphasé . -
@vincent835 Top ca le triphasé, merci
-
@charles Non, le problème est toujours d'actualité. Je crois que l'esp plante dès la sélection du 9600 baud. Comme fonctionne ton code de capture ?? Tu le charges dans l'ESP ??
De mon coté pour la capture, ca sera un contrat BASE en mode standard.
Je regarde pour la capture ce soir.
-
@nicolas-bernaerts ouais tu m'étonnes surtout si en mode raw tt les secondes ça doit échanger un max.
D'ou le mode skip sur la nouvelle version, faut que je réflléchisse avec @Barbu-Dor comment faire un truc simple style une white (ou black) list des etiquettes (peut être un fichier sur le filesystem) ça doit pas être trop compliqué.
-
@sebh non tu le lances sur un ordi (PI, PC, Mac, ...) c'est du code python (lis le readme), il te faut juste un module téléinfo pour pouvoir decoder la téléinfo (pitinfo, microteleinfo ou un custom peut importe).
-
Cette semaine j'ai reçu un nouveau joujou, je vous en dis plus rapidement
-
@charles Sauf que je n'ai que des ports USB sur mon PC (fini le port série..), et qu'actuellement la seule liaison qui est possible entre ma téléinfo et mon PC , c'est le wifi via l'ESP. Je dois avoir du code pour l'esp, pour recevoir les trames sur le wifi via le soft Putty....
-
@sebh ne t'embête pas tu vas galérer et à passer pas plusieurs outils et le format à l'arrivée sera changé (CR/LF et autre)
La solution que tu peux faire est effectivement un passthru usb avec l'esp mais si c'est un ESP8266 la encore galère car un seul port série. En revanche, si c'est un ESP32 je peux te donner le code passthru.
-
@charles Désolé j'ai pas d'ESP32 en stock, que du wemos d1... Ecoute j'avais déjà fait une capture par le passé, c'était relativement simple à faire. Je test, je te l'envoie et tu me diras si c'est bon ou pas...
-
@charles pour la partie message tic, je suis parti sur une approche un peu differente : je ne selectionne pas les donnees, car toutes les etiquettes ne sont pas envoyees tout le temps ( type ADIR) et je ne sais pas forcement ce qui est exploite au bout de la chaine. Je suis parti sur l'approche d'envoyer le message complet suivant des declencheurs : jamais, a chaque message, a chaque fois que la puissance evolue de +- 1% ou seulement en cas de message de depassement de contrat. C'est plus simple a configurer et cela fait le job.
