Tasmota
-
@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 -
@Barbu-Dor ah ah ok j'ai regardé tes changements vite fait j'ai pas vu de code pour les règles, je comprends mieux la subtilité, sur le publish. Tasmota est quand même super bien pensé, j'adore.
Ouais dans le loop téléinfo, peut être coller un compteur et envoyer le raw uniquement tous les X du compteurs (géré par un setoption ou autre) pour envoyer un raw uniquement tt les 10 secondes (environ) par exemple
Super boulot en tout cas, merci à toi d'avoir pris le temps. pour ta contribution ça te dirait que je t'envoi une carte WiFiInfo32 ? j'ai qq proto (et un cruel manque de temps)
De mémoire j'en ai envoyé un à @Seb-H, à moins que ce ne soit pas le meme seb, celui qui fait le zigbee de tasmota c'est pas toi @Seb-H ?
-
@Charles Salut Charles, non tu dois te tromper, c'est pas moi . J'ai pas la prétention de toucher du code comme vous le faites, moi je reste un petit rigolo , mouahhh !! Néanmoins, si tu veux que je teste avec un de tes protos, je suis partant, je te le retourne après test pas de soucis...
-
Petite question . Au niveau du hard, le signal téléinfo arrivait sur la pin D7 sur Esp8266 wemos D1. Actuellement, j'ai du faire une modif hard , que le signal arrive sur la pin RX. J'ai fait mes test uniquement en sélectionnant la pin RX sur tasmota. Est ce que ca pourrait fonctionner aussi avec la pin D7 ?
-
@Barbu-Dor Je crois que je viens de trouver un petit bug? Donc mon wemos vient d'être flashé et encore alimenté par le 5V de l'ordi. Je n'ai pas de signal téléinfo qui arrive dessus et pourtant il m'envoit une donnée sur le MQTT .. Il aurait gardé une mémoire d'avant ?? A moins que ce soit normal ??
-
arff quelle idée, deux s-h bossant sur tasmota
Pour info RX/GPIO3 et TX/GPIO1 sont les 2 pins officielles serial mais il y a un swap possible dans l'ESP8266 qui permet de passer ces 2 pins sur
D7/GPIO13/RX et D8/GPIO15/TX
C'est un swap hardware (positionné en software parSerial.swap()et c'est automatique dans tasmota si tu positionnes dans l'interface de config tasmotaTInfo Rx (210)sur GPIO7
donc la réponse est oui -
Pour info avec la téléinfo j'utilise que des ESP32 c'est trop chiant avec le 8266 pour débugguer car la sérial est prise par la téléinfo (bien qu'on puisse prendre TDX1 pour debug)
avec l'ESP32 je laisse la Serial par défaut pour le debug et je prends une 2eme pour la téléinfo, bien plus souple. -
@Barbu-Dor Alors je viens de tester. Je pense que j'ai louper une étape. J'obtiens les mêmes résultats que toi, mais ca ne modifie pas la trame MQTT qui part sur domoticz.
11:42:44.308 RUL: VAR2#STATE performs "publish debug/energy { "compteur1":856867,"compteur2":991027}"
11:42:44.313 MQT: debug/energy = { "compteur1":856867,"compteur2":991027}
11:42:45.265 RUL: EASF01 performs "var1 856867"
11:42:45.270 MQT: stat/tasmota_DB567A/RESULT = {"Var1":"856867"}
11:42:45.276 RUL: EASF02 performs "var2 991027"
11:42:45.282 MQT: stat/tasmota_DB567A/RESULT = {"Var2":"991027"}
11:42:45.309 RUL: VAR2#STATE performs "publish debug/energy { "compteur1":856867,"compteur2":991027}"
11:42:45.313 MQT: debug/energy = { "compteur1":856867,"compteur2":991027}
11:42:45.414 MQT: tele/tasmota_DB567A/STATE = {"Time":"2021-02-11T11:42:45","Uptime":"0T00:20:59","UptimeSec":1259,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"Sylvia&Seb","BSSId":"14:91:82:FC:0E:ED","Channel":1,"RSSI":62,"Signal":-69,"LinkCount":1,"Downtime":"0T00:00:03"}}
11:42:45.421 MQT: domoticz/in = {"idx":84,"nvalue":0,"svalue":"0.0;7.9;0.0;0.0;417;0","Battery":100,"RSSI":6} -
Je n'ai pas testé sur les ports alternatifs D7/D8 car comme je n'ai pas de vrai connexion, je n'ai testé qu'avec des trames pré-enregistrées poussées par mon PC via l'adaptateur USB intégré du nodemcu
Mais effectivement Tasmota fait automatiquement le swap si tu choisit D7/D8
Et si tu choisit d'autres pins, il prend un Uart soft qui risque de poser des problèmes de perfs, surtout en Standard vu le flux tenduSur ESP32, Tasmota laisse l'UART0 pour le debug console et n'autorise les drivers a n'utiliser que UART1 et 2 mais comme on peut remapper les pins n'importe comment ou presque ce n'est pas un problème.
-
@Seb-H Les règles ne permettent pas de modifier la trame qui est envoyée par le mode RAW mais d'en extraire info et d'en recomposer une autre
il faut que tu adapte le publish a ton besoin
