tasmota32

  • Hallo und guten Tag.

    Ich bin mal seit langem wieder hier. Sorry

    Derzeit experimentiere ich mit Tasmota32 Release 9.5.0 auf einem ESP32, Berry, Kommunikationen zwischen Berry Funktionen/Kommandos/Rules und den nativen, also herkömmlichen Rules.

    Es gelingt mir inzwischen einiges. Ich kann nach Belieben Kommandos erstellen und hinzufügen. Auch die Kommunikation mit nativen Rules gelingt.

    Ich versende gerne selbst zusammengestellte MQTT Nachrichten - zumeist im JSON Format. Auch das gelingt vorzüglich.

    Mich stört allerdings, dass Tasmota ständig per MQTT Nachrichten das Geschehen protokolliert und viele Nachrichten sendet, die ich nicht gesendet haben will.

    Nun habe ich mit SetOption3 0/1 versucht, ob ich kurzzeitig MQTT für meine eigene Nachricht freigeben kann.

    Es war ein totaler Reinfall, weil das System nach SetOption3 1 (und vielleicht auch bei 0) neu startet. Ich kenne leider keine Möglichkeit, nur meine selbst zusammengestellten MQTT Nachrichten senden zu lassen.

    Das ist sehr bedauerlich, weil ein ESP32 Sensorwerte per Berry vorzüglich verarbeiten kann, was mir mit einem Ultraschallsensor zur Abstandsmessung bestens gelingt. Ich lasse den ESP32 daraus den Füllstand meiner Zisterne berechnen und so die fertigen Nutzdaten liefern. Auch die Minuten Modulo Zeitsteuerung in einer Rule ist bestens geeignet und gelingt.

    Beispiel: on time#minute|%mem14% do p time endon

    In Mem14 liegt das Modul, bspw. 15 -> immer wenn die Minutenzahl des Tages durch 15 geteilt aufgeht (ohne Rest) triggert dies.

    "p" ist ein in Berry geschriebenes Kommando und "time" ist der an die p Kommandofunktion gelieferte Wert, den ich hier als Wert zum Key "trigger", also {..., "trigger":"<value>", ...} einsetze. "<value>" ist in diesem Fall "time".

    Hoffentlich bringen die spitzen Klammern die Textdarstellung nicht durcheinander.

    Eigentlich bin ich total von Tasmota32 begeistert. Nur die verda... ständigen unerwünschten MQTT Nachrichten stören mich.

    Kennt jemand eine Möglichkeit, diese Nachrichten zu verhindern?

    Liebe Grüße

  • Nein. Ich stelle bereits TelePeriod mit 0 ab und triggere bei Bedarf per Kommando tasmota.cmd('TelePeriod') oder in den nativen Rules.

    In einer Rule setze ich die automatische, zeitgesteuerte Abtastung ein. Diese ist parametrierbar, damit der Anwender die Abtastrate ändern kann. mem14 enthält hier das Modul, wie ich bereits oben beschrieben habe

    on time#minute|%mem14% do

    process time

    endon

    "process" ist ein Kommando der Berry Ebene, "time" ist der Trigger. So kann ich (in Node Red) die Daten in Dateien abspeichern, die im Namen den Trigger, hier <qualifizierter Sensorname>.time haben.

    So kann ich im Speicherverzeichnis die Trigger bezogenen Daten leicht finden und das Speichersystem leicht verwalten. Ein anderer Trigger lautet bspw. "adhoc", der angibt, dass ein Benutzer mal eben Messdaten abgefragt hat.

    Ich will ja gerade den Tasmota-Automatismus durch meinen eigenen ersetzen. Dies bezieht sich auch auf die MQTT Topics, in denen ich qualifizierte Namen einbaue, um so flexibel eine Hierarchie aufbauen und pflegen zu können,

    auch wenn sie in meinem privaten Fall recht flach ist, aber nicht flach sein muss. Und ich plane, dass der Benutzer mit einer App (bspw. MQTT Dash) auf einfache Weise die qualifizierten Bezeichner von Sensoren ändern kann. Wie sich dies auf das gesamte System aus Tasmota Geräten und Node Red auswirken muss, werde ich mir noch überlegen. Jedenfalls wird es möglich sein. Ich denke auch, dass Sensoren datentechnisch überhaupt nicht an devices zu binden sind. Ein Sensor liefert Werte. Über welches Gerät dies läuft, interessiert den Anwender und die Datenspeicherung in keiner Weise. So sind die Geräte austauschbar bzw. ein Sensor an ein anderes Gerät anschließbar, ohne dass dies Auswirkungen auf die MQTT Topics und die Datenstruktur hat.

    Ich schreibe dies hier alles, um aufzuzeigen, dass ich notfalls die Tasmota Topics nehmen muss, diese voraussichtlich aber per Node Red MQTT Clients adaptieren werde, um die Sensoren (ggf. auch Aktoren) device unabhängig zu bekommen.

    Am liebsten wäre mir, wenn ich dies auf dem ESP32 ohne zusätzliche Node Red Adapter implementieren könnte, was das Tasmota32 per Berry zweifellos ermöglicht. Deshalb stören mich die dafür total überflüssigen Tasmota Tele-Nachrichten, die zudem auch noch Performance fressend sind. Ansonsten ist Tasmota32 ein wunderbares System.

    Ich danke dir trotzdem für deine Hinweise.

    Gruß Gerhard

  • Nachtrag:

    Ich habe mir das Zeug mal speichern lassen, was das gebrannte Tasmota32-DE.bin Version 9.5.0 per MQTT sendet, wenn alle Logs ausgeschaltet sind (0) und TelePeriod auf 0 gesetzt ist.

    Und ich lasse das Kommando "TelePeriod" in meiner Experimentier- und später Anwendungs-Software nicht mehr aufrufen. Ich habe naiv erwartet, dass Tasmota dann von sich aus keine MQTT Nachricht sendet ... aber ...

    Es werden ständig Dinge gesendet, die mit meinen Rules und dem Status des Tasmota Systems zu tun haben. Mal sehen, wie das in folgenden Versionen sein wird.

    Jedenfalls ist dieses Tasmota eine unglaubliche MQTT Quasselstrippe.


    Ok, ich müsste mal Tasmota selbst compilieren. Kurze Versuche mit der Arduino IDE schlugen fehl, vermutlich weil ich zu viele Bibliotheken an verschiedenen Stellen für Unos, ESP8266 ... installiert hatte.

    Ich möchte mich lieber auf die Erweiterungsmöglichkeiten von compilierten Tasmotas und Node Red konzentrieren. Dazu gibt es sehr viel zu tun und ich habe keine(n) Assistent*in. ;-)

    Trotzdem bin ich von Tasmota32 mit Berry-Erweiterungen total begeistert.

    In hoffnungsvollen Erwartungen

    Gerhard

  • Jedenfalls ist dieses Tasmota eine unglaubliche MQTT Quasselstrippe.

    Naja, das kann man so oder so sehen. Bei meinen Tasmota (ESP8266) Geräten ist es bei teleperiod 0 erstaunlich ruhig. Da werkeln aber auch keine rules und kein Sensor will was mitteilen. Wenn deine rules Zustände abfragen oder Zustände ändern, dann ist das für den Broker schon interessant. Denn möglicherweise gibt es einen Abonnenten, der etwas wissen will. Ich denke, es ist eher der Zweck von MQTT, Mitteilungen zu produzieren. Allerdings gehen die nur bis zum Broker, wenn sonst keiner (subscriber) was wissen will. Von der Datenmenge her sind die JSON-Schnipsel ja Peanuts. Da ist vermutlich der Kommunikationsoverhead, der unsichtbar in einem WLAN permanent hin und her gejagt wird, wesentlich umfangreicher.

    Ich will ja gerade den Tasmota-Automatismus durch meinen eigenen ersetzen. Dies bezieht sich auch auf die MQTT Topics, in denen ich qualifizierte Namen einbaue, um so flexibel eine Hierarchie aufbauen und pflegen zu können,

    Wenn du so tief eingreifen willst, musst du vermutlich tatsächlich eine eigene Firmware programmieren, die mit deinen eignen Begriffen kommuniziert. Hast du mal ein paar Beispiele für eigenen Topics. So recht verstehe ich noch nicht, was das Problem ist. Nicht, dass ich eine Lösung hätte - es interessiert mich einfach.

  • Vorbemerkung: Von meiner Progammierung stammen diese Quasselnachrichten nicht. Wenn bspw. eine Variablenänderung (Var1 bis Var16 aus den Rules) per MQTT übertragen wird, ohne dass ich dies beauftragt habe, dann bleibt mir die Hoffnung, dass dies Bestände sind, die evtl. aus der noch existierenden Beta Phase des Projektes Tasmota32 kommen und Arends und andere dies schlicht beim Compilieren nicht zuvor deaktiviert haben.

    Konkret: Ich verwende die Zeitsteuerung, und der Benutzer kann ad hoc zusätzlich einen Messauftrag erteilen. Dazu verwende ich folgendes Prinzip.

    Bei jeder Messung sollen n Sensoren abgefragt werden. Rule1: Ich initialisiere Var1 mit 0 und aktiviere Rule2 mit Rule2 1. Rule 2 ist mit 5 auf One Shot eingestellt. In Rule2 wird mit jedem Sensorereignis der Wert per Berry Kommando übertragen und in einer globalen Datensruktur gespeichert. Var1 um 1 hochgezählt. Sobald Var1 größer als n-1 ist, wird der Berry Kommandofunktion mitgeteilt, dass die Messwerterfassung abgeschlossen ist und Rule2 deaktiviert sich per Rule2 0 am Ende selbst. Dies findet bspw. alle 15 Minuten statt, wenn in Mem14 (Minutemodul) eine 15 steht.


    In Rule1:

    on time#minute|%mem14% do var2 time endon

    on var2#state do backlog d0 %timestamp%;d1 %var2%;var1 0;rule2 5;rule2 1 endon


    Rule2:

    on ESP32#Temperature do backlog d2 %value%;add1 1 endon

    on DS18B20#Temperature do backlog d3 %value%;add1 1 endon

    on SR04#Distance do backlog d4 %value%;add1 1 endon

    on var1#state>2 do backlog d5 done;Rule2 0 endon


    Var2 nimmt das Triggerereignis auf, hier ist es "time", was zeigt, dass die per Node Red gespeicherten Messwerte aus der Zeitsteuerung kommen.

    Das Ereignis var2#state habe ich separiert, weil noch andere Trigger als die Zeit implementiert sind/sein werden. Da dieses Tasmota32 fast unerschöpfliche Möglichkeiten der Programmierung bietet (allerdings muss man auf Ereignissteuerung achten), ist es bspw. möglich, dass mein Zisternenfüllstands-ESP32 dem Wasserzulauf-ESP32 sinngemäß mitteilt: Beauftragter Füllstand ist erreicht, Zulauf schließen!


    "d" ist das indexierte Kommando in Berry geschrieben. Dieses quatsch nur per MQTT, sobald d5 mit dem Wert "done" eintrifft. Ich versichere dir, dass weder in Rule1 noch in der d-Kommandofunktion (Berry) sonst irgendwelche MQTT Nachrichten gesendet werden. Und wenn, dann lasse ich noch vorsichtshalber eine Variable Debug abfragen. Wenn diese true beinhaltet, gibt die entsprechende MQTT Sendefunktion das Gesendete zusätzlich per print(...) aus. Dies kann ich bestens in der Konsole oder besser in der Berry Konsole sehen und Fehler in der Nachrichtenstruktur finden (JSON). Dieses habe ich inzwischen voll im Griff.


    Wenn also bspw. alle 15 Minuten (vielleicht werden es später 60 Minuten) eine Messung per Rule2 durchgeführt wird, dann ist das einzige auftretende Triggerereignis time#minute|%mem14%, d.h. dass das Teilen der Tagesminuten durch %mem14% ohne Rest aufgeht. Und dies tritt bspw. nur alle 15 Minuten ein.

    Meine Protokollierung per Node Red und dem Subscriber mit dem Topic "+/ESP32-01/+" zeigt u.a. Nachrichten, die das Ändern meiner Zählvariablen Var1 zeigt. ^^ Btw, ESP32-01 ist das Topic während meiner Entwicklungsphase. Die Platine für die ZIsternenmessung ist seit gestern fertig und läuft seitdem bestens. Wenn das Teil in Kürze in der Zisterne sitzend per WLAN (bereits ausgiebig getestet) kommuniziert, erhält es das Topic "Zisterne" und mein selbst verwendetes Topic "aussen.Zisterne". Dies gelingt btw wunderbar per MQTT dash, eine für meine Zwecke erstklassige Android App. Und, noch erwähnt, von dieser App kommen nur dann Nachrichten, wenn ein Anwender etwas damit tut. XD


    Fazit:

    Tasmota32 sendet DInge, die ich nicht gesendet haben möchte und die absolut kein anderes Gerät zu interessieren hat. Wie bereits erwähnt, hoffe ich, dass dieses Gequassel spätestens dann verschwindet, wenn Tasmota32 aus der Beta Phase heraus ist. Ich werde bei Muße mal einen ESP8266 mit Tasmota diesbezüglich einsetzen, auch wenn ich keinen Bock mehr habe, weniger flexibel einsetzbare µC als den ESP32 zu verwenden.


    Gruß und danke für dein geduldiges Lesen meiner Postings

    Gerhard

  • Hallo Eich

    Bin schwer beeindruckt, wieviel Zeit, Wissen und Energie du in die Sache reinsteckst. Hoffe das deine Probleme gelöst werden können. Ich kann zwar die Dinge nachvollziehen,die du hier beschreibst,aber du spielst in einer anderen Liga und so kann ich nur meinen Hut ziehen. Super

  • Hallo Athen2004

    Ich finde, dass es auch eine echte Leistung ist, mein Geschriebenes nachzuvollziehen. Dazu brauchst du auch nicht wenige Kenntnisse.

    Deine Anerkennung schmeichelt mir und sie tut zugegebenermaßen auch gut. Diese Probleme sind ja keine wirklichen, weil mein Projekt sehr gut funktioniert. Es handelt sich mehr um eine Art überflüssiges, unschädliches Rauschen, welches ich bisher nicht abstellen kann und das ein wenig die MQTT Kommunikation belastet. Meine Rahmenbedingungen sind relativ gut. Ich bin im Ruhestand, habe also Zeit. Ich habe etwas Programmiervorerfahrung in verschiedenen Sprachen (am meisten in C++). Und meine Frau kann es ertragen, wenn sie auch mal ein paar Tage wenig mit mir anfangen kann. ;-)

    Das, was ich oben teilweise aufzeigte, ist das Resultat einiger alternativer Erprobungen verschiedener Wege. Dabei habe ich einiges kennengelernt und nicht weniges wieder verwerfen müssen. Nun, so findet lernen eben statt.

    Falls du dich nicht nur als Konsument, sondern auch ein wenig als Entwickler siehst, kann ich den ESP32 mit Tasmota32 sehr empfehlen. Hier bietet sich ein sehr offenes Feld an kreativen Möglichkeiten.

    Ich steuere seit etwa einem Jahr Gartenbewässerung und Rasenberegnung mit Shelly1, Tasmota und vollen Rulesets. Da ich Flexibilität sehr schätze, können wir diese mit MQTT Dash steuern, ad hoc ein- und ausschalten - inkl. Dauereinstellung, innerhalb 24 Stunden eine Einschaltzeitpunkt mit eigener Dauer festlegen und auch die Zeitauflösung parametrieren. Ich will hiermit aufzeigen, dass mit einem Shelly1 und Tasmota schon recht viel möglich ist, was Steuerung betrifft. Die Kosten dafür sind eh sehr gering, wenn man bereits einen MQTT Broker am laufen hat. Aber...

    Damit lässt sich keine Messstation brauchbar aufbauen. Bleibt also ein ESP8266 Board mit der Freiheit der Pinbelegungen. Ich werde ein solches Board vermutlich kaum noch einsetzen, weil das Tasmota32 mit der Sprache Berry dem herkömmlichen Tasmota weit überlegen ist, wenn man sich nicht scheut, selbst zu programmieren.


    Als Schmankerl zeige ich noch ein kleines Workaround von mir auf, welches u.a. die Umwandlung in Großbuchstaben seitens Tasmota verhindert und zudem viel Ruleset Platz einsparen kann. Ich kam auf diese Idee, als die herkömmliche Variante den Platz von Ruleset3 sprengte. Man braucht dazu zwei freie Variable, hier Var3, Var4 und eine sehr kurze Rule:

    on var3#state do %var3% %var4% endon


    Dazu habe ich folgende Berry Funktionenkombination erstellt:

    var PreParamBeg = 8 # mem8 vor den Parametern

    var nParam = 8 # Anzahl Parameter

    var readStr1, readStr2


    def setParamPost()

    tasmota.cmd(readStr1)

    tasmota.cmd(readStr2)

    end


    # Parameter setzen

    # idx Parameter Offset zu PreParamBeg

    # 1:System Topic, 2:Name ESP32-Temperatur, 3:Name Umgebungstemperatur, 4:Name Ultraschall Abstand

    # 5:Name verfügbares Volumen, 6:Minuten Modul für Zeit Triggerung, 7:Radius Zisterne, 8:Max. Tiefe unter Sensor

    def setParam(cmd, idx, val)

    if idx<1 | | idx>nParam waste(cmd, idx, val) # die | | real ohne Leerzeichen, emoticon stört, waste ist eine meiner Berry Funktionen, die unpassendes in einem lesbaren Mülleimer ablegt.

    else

    if val!='' # zuerst schreiben, wenn Anwender nach antippen der MQTT Dash Kachel nichts eingibt und senden lässt, wird nur gelesen

    tasmota.cmd('var4 '+str(val))

    tasmota.cmd('var3 mem'+str(PreParamBeg+idx))

    end

    # lesen: s1 %mem10%, allg. s<idx> %mem<PreParamBeg+idx>%

    readStr1 = 'var4 %mem'+str(PreParamBeg+idx)+'%'

    readStr2 = 'var3 s'+str(idx)

    tasmota.set_timer(50, setParamPost)

    end

    end

    tasmota.add_cmd('setparam', setParam)


    Ich mag "elif" statt "else if ..." nicht, weil es mir das richtige setzen von "end" sehr erschwert.

    Da hier ausschließlich Ereignissteuerung wirkt, kann man sich in der Kommunikation mit Rules nicht auf die vermeintlich "richtige" Abfolge verlassen.

    Deshalb ist nach dem Schreiben per setParam für ein Lesen und Rückmelden per MQTT eine Zeitspanne einzubauen, per Tasmota.set_timer().

    50ms sind vermutlich nicht erforderlich, ich habe aber kürzere Zeiten noch nicht getestet.


    Allgemein lassen sich mit der kleinen Rule oben noch andere Dinge umsetzen. Die Platzersparnis in den Rulesets kann erheblich sein.

    Gruß

    Gerhard

  • Hallo in die (kleine) Runde.

    Dieser Thread soll nicht zu meinem Monolog werden. Deshalb mal diese Frage:

    Gibt es hier überhaupt Interesse am etwas Nerd-igen Thema Tasmota32/ESP32 mit Berry als, in meinen Augen, wunderbares, weil leistungsfähiges und flexibles Konzept zur komfortablen Nutzung von ESP32 Schaltungen?

    Ich könnte mich daran beteiligen.

    Mein Zisternen-Messprojekt hat inzwischen die Version 1.0 erreicht und kann sehr viel ... ;-)


    Und zu meinem Ausgangsproblem(chen). Ich vermute inzwischen, dass Tasmota(32) wegen des Tasmota Device Manager (TDM) soviel MQTT quasselt. Btw ist der TDM imho zwar ein hübsches Werkzeug, aber mit zwei mich nervenden Unarten.

    Es stirbt ohne jeden Hinweis, wenn ich in den Rule-Variablen Zeichen wie '/' und nach meiner Erinnerung auch andere Zeichen verwende. Das ist nicht akzeptabel. Außerdem schaltet es plötzlich auf eine soeben durch die Programmierung aktivierte Rule um, ohne dass dies in der Kopfanzeige ('Rule<x>') zu sehen ist. Für mich ist der TDM ein noch missratenes Werkzeug. Vielleicht reaktiviere ich gelegentlich mein kleines, per Node Red erstelltes Tool mit ähnlichen Möglichkeiten des TDM wieder. Das braucht das Tasmota-MQTT-Gequassel nicht, weil die gewünschten Daten erst nach Anfrage von Tasmota gesendet werden müssen. Ok, vorläufig verwende ich den TDM noch, aber als gut kann ich diesen nicht bewerten.


    Auf eine Rückmeldung bzgl. Tasmota32/Berry täte ich mich freuen, wie sie auch ausfallen mag.

    Grüße

    Gerhard

  • Abschluss meines Monologs:

    Ich habe soeben auf https://www.zisteich.de (alles werbefrei) ein wenig dokumentiert. Diese Doku beschreibt kurz die Eigenschaften von Tasmota32 und Berry allgemein. Dies ist auf der Startseite zu finden.

    Zusätzlich habe ich dort unter Projekte/Zisternenmessungen die Eigenschaften und Möglichkeiten meines Zisternen-Messsystems dargelegt. Sollte jemand an meinem System interessiert sein, bitte ich um eine entsprechende Nachricht oder eine Antwort in diesem Thread.

    Ich verbessere nach wie vor das Messsystem und dokumentiere dies - Link s.o.

    Grüße

    Gerhard