Tasmota
-
@Charles désolé je suis sous esp8266 avec Wemos D1. Je suis en train de regarder actuellement. Donc pour mémoire, le setoption 108 doit être a 0 ? le setoption102 à 0 en historique et a 1 en standard ?
-
@Seb-H C'est cela pour le SetOption102
Pour le SetOption108, 1 active l'envoi de la trame en RAW (et je crois que ca désactive d'autres foncitons). Donc pour les messages Tasmota Energy standatd, il faut rester en SO108 0
-
Ok, donc avec mon linky en mode standard, j'arrive bien à avoir les infos.
Si setoption108 à 0, j'arrive à lire les trames en direct et le comptage dans le menu principal ne se fait plus
Concernant l'envoie de données MQTT sur domoticz. Les données sont envoyés toutes les 5 minutes. On sais éventuellement changer à 1 minutes comme sur wifinfo ??
Autre question. Dans mon cas, j'utilise le P1 SmartMeter. Actuellement, on envoit l'état du compteur energie tasmota. Sait on envoyé comme actuellement avec wifinfo, l'état du compteur incrémental du linky ? (envoie simple de l'EASF01 et l'EASF02)
Voila ce que je reçoit sur mon domoticz. Etrange car le 1er compteur reste à 0. Il n'y a que le 2ème qui s'incrémente.
Je vais passer en mode historique pour voir si cela fonctionne
-
Bon en mode historique ca fonctionne aussi. C'est top !!
Même problèmatique qu'avec le linky. On ne reçoit l'état du compteur qu'en position n°2. Le 1er reste à 0.
J'ai les mêmes requetes pour l'envoie des données MQTT. Définition d'un timing d'envoie possible ? Peut choisir les données que l'on veut envoyé, soit au choix le comptage tasmota journalier, ou bien envoyé les index compteurs ?
-
@Seb-H la périodicité du message SENSOR est défini par la commande 'teleperiod tempsensecondes'
Je regarde le reste plus tard, j'ai une coupure de courant depuis 90min
-
@Barbu-Dor Pas de soucis, no stress ! Moi j'ai tout le temps de tester depuis ce matin..
-
@Seb-H
Je confirme que actuellement le driver ne fait rien avec l'EASF01 et l'EASF02. Uniquement une trace de log.
Je ne sait pas a quoi cela correspond pour le linky et s'il y a une equivalence dans le modèle "ENERGY" de Tasmota.
Si un champ existe pour cela, on peut bien sur rajouter l'info. Sinon, il faut rester sur le mode RAW (SO108 1). Le mode RAW devrait inclure tous les champs reçus sans aucun traitement.Pour la question du compteur 1 vs compteur 2 dans Domoticz, je ne sais pas parce que je ne connais pas Domoticz, mais si tu sais identifier ce qu'il manque coté Tasmota, je pourrais regarder.
-
@Seb-H
D'après mes recherches, les compteurs 1 et 2 seraient dans l'ordre Heure-Creuses et Heures-Pleines
Donc en fonction de ton abo et des heures, c'est peut être normal que tu n'ai rien sur Heures-Creuses -
En fait chez moi je suis configuré dans l'ordre ci dessous
Donc 987165 c'est l'index HP de mon linky, 849556 c'est l'index HC de mon linky, puis tu as HP du compteur 2, HC du compteur 2, puis 501 la puissance , puis 0 pour une autre valeur de puissance.
Bon a vrai dire la puissance en W on s'en fiche un peu, ce qui est sympa est de pouvoir faire l'acquisition des index de ton compteur.
Sur le linky en mode standard, tu as 10 index de comptage, EAST (qui est un total des compteur EASF01 à EASF10, EASF01 chez moi le compteur HC, EASF02 chez moi le compteur HP) mais après il se peut que cela change selon les différents opérateur d'énergie... Il y a 10 compteurs et je pense que l'opérateur peut les gérer comme il veut...
En fait, ce qu'il faudrait faire, c'est pouvoir laisser le choix à l'utilisateur d'envoyer dans la trame MQTT, les index qu'il veut Je sais pas si ça été prévu pour ou si on peut prévoir ? -
@Seb-H Pour l'instant je ne comprend pas trop ce que fait le code de @Charles. Apparemment il n'utilise même pas la notion de Tariff de Tasmota ou alors je n'ai pas compris comment.
En tout cas, il n'utilise ni EAST ni aucun EASFXX.Si tu confirmes que déjà ca marche comme avant à la fois en Historique et Standard, je propose qu'on fusionne ce code et qu'on réfléchisse ensuite aux éventuelles améliorations. Je peux y accorder un peu de temps si besoin.
Dans tous les cas le mode RAW permet de déporter tout traitement "custom" sur le système domotique.
@Charles qu'en penses tu ?
Merci de ton temps pour le test
-
@Barbu-Dor Merçi déjà à toi pour avoir pris le temps de debugger le mode standard ! Attention je n'ai testé que le HC/HP sur le mode standard et la tarification unique en historique. Sur le mode standard, Il y a encore le mode tarification simple et le tempo (avec les 6 compteurs) à tester et ca je ne pourrais le faire !
Bon donc alors tu dis qu'avec le mode RAW, on peut faire un custom pour l'envoie de données. Tu saurais m'aiguiller comment envoyer les données EASF01 et EASF02 via MQTT avec la trame standard pour le capteur P1 SmartMeter (tel que je le fessais avec WIFINFO)??
-
@Seb-H
Le mode RAW envoi l'intégralité des données en MQTT sous la forme d'un gros JSON. Donc tous les champs qui sont dans la trame sont envoyées. Tu peux vérifier cela sur ton système.Ton back-end peux probablement faire le traitement mais il faut peut être du dev. Par exemple moi je pourrais le faire avec Node-Red (Je n'ai pas Domoticz, HA ou OpenHAB)
Après, il est aussi possible avec les règles de Tasmota (Rules) d'intercepter le JSON du mode RAW et de préparer un JSON "custom" et de l'envoyer sur un topic particuler.
Par exemple la règle suivante devrait fonctionner:
Rule1 ON EASTF01#Data DO var1 %value% ENDON ON EASTF02#Data DO var2 %value% ENDON ON var2#state DO publish mon/topic/domoticz/linky {"compteur1":%var1%,"compteur2:"%var2%} ENDONEDIT : Dans la version actuelle la trame RAW ne passe pas dans le moteur de règles. Je suis en train de l'ajouter
-
Ca marche
Rule1 on EASF01 do var1 %value% endon on EASF02 do var2 %value% endon on var2#state do publish debug/energy { \"compteur1\":%var1%,\"compteur2\":%var2%} endon20:46:56.001 MQT: tele/nodemcu/RESULT = { "ADSC":"811775179984","VTIC":2,"NGTF":" BASE ","LTARF":" BASE ","EAST":3232240,"EASF01":3232240,"EASF02":0,"EASF03":0,"EASF04":0,"EASF05":0,"EASF06":0,"EASF07":0,"EASF08":0,"EASF09":0,"EASF10":0,"EASD01":3232240,"EASD02":0,"EASD03":0,"EASD04":0,"IRMS1":2,"URMS1":237,"PREF":9,"PCOUP":9,"SINSTS":539,"SMAXSN":2360,"SMAXSN-1":600,"CCASN":288,"CCASN-1":306,"UMOY1":237,"STGE":"003A0001","MSG1":" PAS DE MESSAGE ","PRM":2147483647,"RELAIS":0,"NTARF":1,"NJOURF":0,"NJOURF+1":0,"PJOURF+1":"00008001 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE"} 20:46:56.014 RUL: EASF01 performs "var1 3232240" 20:46:56.020 MQT: stat/nodemcu/RESULT = {"Var1":"3232240"} 20:46:56.028 RUL: EASF02 performs "var2 0" 20:46:56.035 MQT: stat/nodemcu/RESULT = {"Var2":"0"} 20:46:56.064 RUL: VAR2#STATE performs "publish debug/energy { \"compteur1\":3232240,\"compteur2\":0}" 20:46:56.071 MQT: debug/energy = { \"compteur1\":3232240,\"compteur2\":0}Bon je ne vais pas régénérer de binaire pour cela mais ca sera dans la version dev d'ici 48H
-
This post is deleted! -
@Seb-H la PR a été incluse ce matin à 9h00
C'est donc maintenant dans le tronc 'development' du github arendst/Tasmota
Par conte il faut toujours compiler soi même car ce n'est pas inclus par défaut dans le build -
@Barbu-Dor Ta version que j'ai récupéré sur ton lien initial est aussi à jour. Je l'ai récupérer il y a 5 minutes.. Je peux partir la dessus pour l'instant ??
-
@Barbu-Dor oui j'utilise pas la même notion de tarif car EdF gére trop de tarif (EJP et la totale) je ne sais pas si c'est supporté par tasmota. En plus j'ai codé a l'arrache (ça change) sans connaitre tasmota, alors j'ai certainement pas "bien fait" les choses mais si on améliore c'est top.
-
Top les règles sur des valeurs, faudra que je regarde comment tu as fait ça
l'ADPS sera utile.
-
@Seb-H oui c'est bon aussi
-
@Charles j'ai changé l'appel à MqttPublish() par MqttPublishRules() (ou du meme genre) ainsi le JSON est parsé par le moteur de règles
Chaque champ est alors un trigger
Pour composer un nouveau message il faut récupérer chaque champ dans une variable par son propre trigger puis sur la mise à jour de la dernière variable on peut publier.
Un peu lourd et intensif surtout avec un json à chaque seconde.
Il faudrait peut être considérer des évolutions pour réduire la fréquence du raw
