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

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 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

Derzeit verkaufe ich es nicht.

Ich kann es bei Nachfrage zur Verfügung stellen. Da es inzwischen einen mittleren Umfang aufweist, scheue ich mich davor, es hier offenzulegen. Dazu sehe ich bisher bzgl. tasmota32 und Berry kein hinreichendes Interesse.

Ich habe dir inzwischen per eMail geantwortet.

Bei Fragen stehe ich zur Verfügung.

Gruß
Gerhard

Nachtrag:
Ich dachte bereits darüber nach, das Messsystem zum Verkauf anzubieten. Allerdings wäre es dazu sinnreich, Elektriker für die Montage an der Hand zu haben. Eine bisher erste Anfrage bei einem Elektriker in meiner Nähe ergab kein geeignetes Interesse. Also bleiben (vorerst) nur Nerds ...

Sorry, ich war längere Zeit mit anderem als diesem Forum beschäftigt.

Hallo "3306"!

Mein Füllstands-Messsystem arbeitet nach wie vor relativ zuverlässig. Ausreißer werden durch meine Berry-Erweiterungen eliminiert, was durch eine modifizierte mediane Mittelwertbildung bestens gelingt. Die Schaltung liefert sogar trotz in das Gehäuse eingedrungenen Wassers brauchbare Werte. Ich will die Box in diesem Jahr neben die Zisterne in's Erdreich versenken und noch einmal sorgfältig abdichten.

Nun zu deiner ... hmm "Anfrage"?

Ich habe an Hand der knappen Beschreibungen der Tasmota32 Schnittstellenfunktionen und vielen Versuchen gelingende Kommunikationen zwischen den Rules und Berry-Funktionen herausgefunden und teile bei Interesse diese gerne mit.

Wesentlich dabei ist, Rule-Kommandos selbst definieren und nutzen zu können. Solche Kommandos sorgen für Aufrufe von Berry-Funktionen, die per tasmota.add_cmd in Tasmota eingetragen/registriert werden. So ist es möglich, bspw. eintreffende Rohmesswerte per Aufrufparameter an Berry-Funktionen zu liefern, wo sie geeignet verarbeitet werden. Damit ist Tasmota mit seinem Rule-System gewaltig erweiterbar. Dabei ist die Standard-Parameter-Struktur (Signatur) von Tasmota-Kommandos zu beachten, die bis zu vier Parameter in fester Folge vorgibt:

Kommandoname, Index, Nutzwert, Nutzwert in JSON

Im Zusammenhang mit den Rules nutze ich den vierten Parameter nie.

Ich verwende für Rule-Kommandos möglichst kurze Namen, wie bspw. "d" für data.

Dann sind z.B. d0, d1, d2, d3, ... gültige Rule-Kommandos - der Index 0 ist eigentlich nicht vorgesehen, aber möglich.

Einfaches Beispiel:

Rule: ... backlog d1 %var5%; d2 %timestamp% ...

Dies ruft die spezifizierte Berry-Funktion zum Kommando "d" zweimal auf.

Die Berry Funktion importiert jeweils als Kommando die Zeichenkette "d", was zumeist ignoriert werden kann.

Im ersten Aufruf per d1 ist der Indexwert 1 und der importierte Wert der Inhalt der Rule-Variablen Var5.

Im zweiten Aufruf per d2 ist der Indexwert 2 und der importierte Wert der aktuelle Zeitstempel.

Das ist das Prinzip und erscheint vermutlich noch zu abstrakt.

Wenn du dir aber denkst, dass in Var5 ein Messwert liegt, dann ist bereits erkennbar, dass dieser Messwert von der aufgerufenen Berry-Funktion bestens verarbeitet werden kann - mit allen Möglichkeiten, die diese Programmiersprache bietet, was nicht wenig ist. Sowohl der verarbeitete Messwert - oder eine Messwertfolge - kann schließlich per MQTT und einem Zeitstempel übertragen werden, evtl. im JSON-Format.

Mit Hilfe des Index kann man bspw. den Fortschritt der Messung für die interne Verarbeitung mitteilen.

Falls du mehr wissen möchtest, erscheint es mir ratsam, wenn du einen einfacheren Implementationswunsch anführst, welcher per Rule und Berry zu implementieren wäre. Dann kann ich (hoffentlich) gezielt darauf eingehen. Ein komplettes Durchgehen meiner Füllstandsmessungssoftware erscheint mir hier deutlich zu aufwändig. Ich stelle sie aber gerne zur Verfügung und kann bei Bedarf Fragen dazu beantworten.

Ich favorisiere übrigens MQTT, Node-RED, InfluxDB und Grafana. Diese Kombination bietet mir sehr flexible Möglichkeiten und ich muss mich nicht mit vorgefertigten Schablonen abmühen, die mich letztlich doch einschränken. Aktuell implementiere ich Heizkörperregelungen und ersetze sukzessive herkömmliche Thermostate an den Heizkörpern. Tatsächlich bin ich mit meiner Software bereits fertig. Neue Thermostatgeräte brauche ich für die Regelung nur in eine Namensliste einzutragen. Das sind Shelly-TRV sowie Shelly1 mit Addon + DHT22 und Ventil-Stellantriebe. Meine Frau ist sehr zufrieden.

Danke für dein Interesse

Gruß Gerhard

Hallo Norbert,

mein Messsystem arbeitet wegen eingedrungener Feuchtigkeit derzeit nicht.

Ich muss es gelegentlich außerhalb der Zisterne platzieren oder die Elektronik eingießen.

Wenn du es nachbauen willst, solltest du auf jegliche Vermeidung von Wassereindringung achten.

Du brauchst dazu Tasmota32 mit kleinem Filesystem, notfalls selbst compilieren.

Den Berry-Code stelle ich selbstverständlich zur Verfügung, inkl. Tasmota-Rules.

Beides ist erforderlich, da die Abstands-Messwerte per Rule entgegengenommen und an die verarbeitenden Berry-Funktionen weitergeleitet werden.

Ich werde mir gelegentlich bei genügend Zeitreserve die aktuelle Tasmota32 Firmware ansehen.

Habe bitte noch etwas Geduld, da ich momentan wenig Zeit dafür habe und die Software-Teile sorgfältig zusammenstellen will.

Frage:

Hast du bereits eine aktuelle Version von Tasmota32 auf deinem ESP32-Board installiert?

Wenn ja, solltest du dich mit den Konsolen vertraut machen, insbesondere der zum Filesystem und Berry.

Beides wirst du für mein Projekt brauchen, um die Anwendu7ngs-Software installieren zu können.

Auch der Tasmota Device Manager (tdmgr_0.2.13) ist zum installieren der Rules nützlich - und im Bedarfsfalle zum Beobachten und/oder Fehlersuche.

Lasse mich bitte wissen, wenn du mit diesen Mensch-Maschinen-Schnittstellen zurechtkommst!

Ich werde auf deine Mitteilungen und/ Fragen gerne reagieren.

Viel Erfolg bei deinem Vorhaben

Gerhard

Edit:

Wenn du Messdaten aufzeichnen willst, empfehle ich einen Raspberry Pi (Generation 3 oder höher) mit Mosquitto, Node-RED, Influx und Grafana.

Diese Dinge können aber auch später aufgebaut und genutzt werden.

Sehr gut.

Ich werde ein zip Archiv auf meiner Doku-Website ablegen, welches du dann herunterladen können wirst.

Wenn ich dies getan habe, werde ich dir das mitteilen.

Gruß

Gerhard

Hallo Norbert,

Auf meiner Projekte Website findest du nun ein ZIP-Archiv zum herunterladen aller Dateien zu "Zisternenmessungen".

Der Link liegt im Einführungsbereich, also noch vor dem "Weiterlesen".

Inzwischen gibt es neuere Tasmota32 Versionen, welche ich noch nicht einbezog und testete.

Ich wünsche guten Durchblick und viel Erfolg.

Gruß

Gerhard