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
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.
Ah ja.
Ich habe es in Version 8.3.0 und in 9.5.0 getestet, sowohl Web-Konsole als auch TDM.
Stimmt, bei diesen Eingaben gibt es diesen Fehler. Aber meine vollgestopften Rules funktionieren wie gewünscht.
Ich habe das vorher nicht festgestellt, weil ich eine selbst erstellte Konsole verwendete, wo es diesen Fehler wohl nicht gab.
Ich habe vor ca. 2 Jahren sehr ausgiebig mit den Rules experimentiert, um das Rule-Verhalten zu verstehen und meine Anwendungen zu implementieren. In den Abarbeitungen/Interpretationen der Rules habe ich nie einen solchen Fehler festgestellt, solange ich diese geeignet erstellte.
Deshalb vermute ich den Fehler eher in der Konsole, also dieser Mensch-Maschinen-Schnittstelle.
Ich verstehe noch nicht ganz, was dich verwirrt oder stört. Die Konsolenausgaben erscheinen mir schlüssig.
Für etwas mehr Komfort, vor allem, was eine Editierbarkeit der Rules betrifft, sorgt bspw. der "Tasmota Device Manager".
Er ist afaik allerdings auf MQTT Kommunikation angewiesen, was einen MQTT Broker voraussetzt.
Er hat zwar eine Macke, ist aber insgesamt hilfreich.
Die zweite Generation der Shellies kann ein Subset von JavaScript interpretieren. Man kann also dem Shelly (mit ESP32) Skripte einverleiben. In solchen Skripten lassen sich u.a. MQTT Subscriber und Publisher unterbringen. Imho ist MQTT erheblich flexibler als HTTP Requests.
Falls Node-RED verfügbar ist, lassen sich damit auch Konverter zwischen HTTP Request und MQTT erstellen.
Ist das ein Problem einer neueren Tasmota Version?
Ich habe schon lange keine Rules mehr erstellt. Auf einem meiner Shelly 1 und Tasmota 8.3.0 läuft bspw. u.a. die folgende Rule fehlerfrei:
on mem2#state do
backlog var7 %mem2%;add7 1;event p6
endonNever change a running system. 
Deine letzte Codezeile ist dann geeignet, wenn du einen nicht konstanten Parameter verwenden willst, dessen Wert bspw. vom Anwender gelegentlich geändert werden können soll. Auch wenn deine Rule leicht pflegbar sein soll, ist die Verwendung einer mem-Variablen ein gutes Mittel.
Wenn allerdings der Aktualparameter an dieser Stelle grundsätzlich unveränderlich festliegt, lohnt die Verwendung einer mem-Variablen kaum.
Wenn du bspw. codest
event a2=123und der Wert 123 ist per se nicht veränderbar, brauchst du dafür %mem1% nicht wirklich.
event a2, event a3 sind so, wie deine Codezeile lautet, events bzw. trigger für solche events. Innerhalb des eventhandlers (Ereignisbehandler) steht der jeweilige Wert (hier 3, 5) per %value% zur Verfügung. a2, a3 sind Ereignisnamen, keine Variable. Die Werte 3 und 5 sind Parameter, die per value an den eventhandler a2 bzw. a3 übergeben werden.
mem3 ist der Name einer Variablen, ebenso bspw. var1. memx liegt im nichtflüchtigen Speicher (nvs=non volatile storage), während varx im flüchtigen Speicher (RAM) liegt. Bei Stromausfall oder zwischenzeitlichem Abschalten der Stromversorgung bleibt der memx-Inhalt erhalten, der varx-Inhalt geht verloren. memx verträgt weniger Schreibzugriffe (speichern) als varx.
Somit ist hoffentlich erkennbar, warum event a2=3 grundsätzlich etwas völlig anderes ist als bspw. mem3 40.
Fachgerechter (notfalls übergehen): 3 bzw. 5 sind sog. Aktualparameter. Diese werden mit dem Auslösen des Ereignisses an den jeweiligen eventhandler übergeben. Einem eventhandler steht ein solcher Aktualparameter-Wert per Formalparameter value zur Verfügung.
Wenn du variable Werte als Aktualparameter verwenden willst, kannst du dafür eine Variable einsetzen, bspw. so:
event a2=%var1%Damit wird der Wert (=Inhalt) der Variable var1 als Aktualparameter an den eventhandler a2 übergeben.
Ich weiß derzeit nicht mehr, ob man per Kommando ein Ereignis auslösen kann. Wenn dies geht, dann einfach so:
event a2=irgendein_WertIch hoffe, deine Unsicherheit hiermit nicht vergrößert zu haben.
Nachgereicht:
Das Speichern in einer Variablen (bspw. mem3 40) entspricht etwa dem Notieren auf einem Zettel.
Das Auslösen eines Ereignisses (bspw. event a2=3) entspricht etwa einer Aufforderung, etwas mit dem Wert 3 zu tun.
Ich nutze ioBroker nicht.
Vermutlich liegt die MQTT Payload im JSON Format vor. Das erkennst du an einer Struktur '{key:value}'.
key und/oder value können in Anführungszeichen stehen.
value kann auch strukturiert sein, also selbst ein Objekt {...} oder ein Array [...] sein.
Ich weiß nicht, wie das im ioBroker zu verarbeiten ist, sollte aber gut möglich sein, bspw. per JSON.parse(Payload).
Die Anzeige der vollständigen Payload in MQTTfx oder ioBroker oder im Weblog von Tasmota wäre für weiteres hilfreich.
Erste Shelly Generation: 1PM
Zweite Shelly Generation: Plus 1PM, Plus 2PM, Pro 1PM, Pro 2PM
Jeweils nur mit RC Snubber!
Ich würde keinen Shelly der ersten Generation mehr kaufen, wenn es einen entsprechenden der zweiten Generation gibt.
Sorry, ich bin etwas von C und C++ geprägt. Der Vergleich des Statuswertes in den Rules wird mit einem einfachen Gleichheitszeichen codiert:
on button1#state=1 ...Vielleicht werden Zeichenkettenwerte (Strings) per == verglichen - ich wusste das mal, als ich mich eingehend mit den Rules beschäftigte. 
Du kannst auch mal nur mit dem Ereignis "button1#state", also ohne Vergleich experimentieren.
Die Rules sind Ereignis gesteuert. Die Struktur einer einzelnen Rule ist prinzipiell:
on Ereignis do Anweisung endonbzw. für mehrere auszuführende Anweisungen bei eintretendem Ereignis
on Ereignis do backlog Anweisung1; Anweisung2; Anweisung3; ... endonIn meinen Prinzipbeispielen ist "Ereignis" ein Platzhalter für ein bestimmtes Ereignis wie power1#state ...
Eine Rule beginnt also immer mit EINEM Ereignis und kann mehrere Anweisungen enthalten. Vor diesem Hintergrund ist deine Zeile ungeeignet, weil "rules#timer=1" ein Ereignis und keine Anweisung ist. "rules#timer=1" bedeutet, dass der ruletimer 1 abgelaufen ist und muss demzufolge hinter einem "on" stehen. Aus deiner Zeile wird dann folgendes:
on button1#state=1 do backlog power1 1; ruletimer1 %mem1% endon
on rules#timer=1 do power1 0 endonBei den button state Werten bin ich wenig bewandert und müsste diese selbst testen. In den Tasmota Dokus sind diese afaik aber auch zumindest beispielhaft aufgeführt.
Eine Anweisung kann auch ein Ereignis auslösen.
on Ereignis do backlog ...; event e endon
on event#e do ..."e" ist der Name bzw. der Trigger des Ereignisses und kann durch einen beliebigen syntaxgerechten Namen ersetzt werden. Das braucht man bspw. dann, wenn der Inhalt einer Variablen manipuliert werden soll. Wird bspw. der Variablen var1 ein Wert zugewiesen, was ein Ereignis ist, und soll dieser Wert verdreifacht sowie schließlich 4 addiert werden, so gelingt das folgendermaßen.
on var1#state do backlog mult1 3; event add4to1 endon
on event#add4to1 do add1 4 endonHm, es könnte sein, dass in Zeile 1 mult1 3 das Ereignis var1#state auslöst. Dann ergäbe dies ein endlos wiederholt eintretendes Ereignis. In diesem Fall muss etwas aufwändiger codiert werden. Am Grundverständnis ändert das aber nichts.
Hilfreich ist das Auslösen eines Ereignisses per Anweisung auch dann, wenn Anweisungen bei eintreten verschiedener Ereignisse auszuführen sind.
on event#p1 do publish lampe1/ist/geschaltet %var5% endon
on Ereignis1 do backlog ...; var5 1; event p1 endon
on Ereignis2 do backlog ...; var5 0; event p1 endonEreignis p1 sendet eine MQTT Nachricht mit dem Topic "lampe1/ist/geschaltet" und als Payload (Wert) der Inhalt von var5. Die Tasmota Doku bezeichnet #p1 auch als Trigger.
Sowohl Ereignis1 als auch Ereignis2 veranlassen nach spezifischen Anweisungen, hier als ... dargestellt, das Senden der Nachricht.
Falls dir MQTT nichts sagt, kannst du stattdessen irgendetwas anderes einsetzen, wie das Schalten einer Lampe.
Ich hoffe, dass ich hiermit ein paar grundlegende Sachverhalte ein wenig aufhellen konnte.
Nicht verzagen ...
Nachgereicht
Bei einer genaueren Betrachtung deines Schaltplans sehe ich jeweils 2 in Reihe geschaltete Taster bzw. Schalter. Taster würde ich parallel schalten. In Reihe sind imho nur Schalter zweckmäßig. Es sind, soweit ich dein Anliegen erfasste, zu einer Lichtquelle zwei Taster vorhanden, die beide die gleiche Funktionalität haben sollen, also schaltungstechnisch und in der Anwendung nicht zu unterscheiden sind. Demzufolge Parallelschaltung ...
Hm, ich benutze doch Taster - Shelly i4, noch recht frisch. Das ist eine interessante Anwendung. Ich werde mal die Scriptmöglichkeiten testen ...
Tasmota Rule für die Timerfunktion bei kurzen Tasterdrücken.
In mem1 liege die Dauer in Sekunden(?) als Parameter. Wenn der Wert häufiger geändert werden soll, ist es zweckmäßig, diesen im flüchtigen Speicher var1 ... var 16 abzulegen. memx liegt im nichtflüchtigen Speicher, der weniger Schreibzugriffe aushält als der flüchtige Speicher.
Rule1: Statt power1#state>0 kann auch ...state=1 eingesetzt werden.
on power1#state>0 do ruletimer1 %mem1% endon
on rules#timer=1 do power1 0 endon
rule1 1Die erste Zeile sorgt für das Starten des Timer1, wenn eingeschaltet wird. Dies ist allerdings unabhängig von der Einschaltquelle. Als Quelle könnte bspw. auch eine Sprachsteuerung vorliegen. %...% ist der Wertoperator, d.h. es wird der Wert von ... genommen - und nicht etwa ... als Text verwendet.
Die zweite Zeile wartet auf das Ereignis Timer1 abgelaufen und schaltet aus, sobald dieses Ereignis eintritt.
Die dritte Zeile ist in der Konsole einzugeben und aktiviert Ruleset 1.
Das sind erst einmal die Grundlagen zur Verwendung eines Timers. Es gibt afaik 8 solcher Ruletimer, vielleicht sind es auch "nur" 4.
Die folgende Rule reagiert ausschließlich auf ein Drücken eines Tasters. Um die Werte zu kurzen vs. langem Drücken zu erfassen, kannst du währenddessen die Ausgaben in der Konsole beobachten und daraus deine Selbsthilfeschlüsse ziehen.
on button1#state==1 do backlog power1 1; ruletimer1 %mem1% endonVielleicht kannst du weitere Dinge selbst noch herausfinden.
Langes drücken ist afaik per button1#state==3 abzufangen - bzw. button2...
Nun noch viel Erfolg beim experimentieren. Dies soll ein Beitrag zwecks "Hilfe zur Selbsthilfe" sein.
Ich nutze keine Buttons und hoffe, dass meine Info fehlerarm ist.
Ich habe mich mit den Möglichkeiten der Shellies der zweiten Generation beschäftigt. Die bisher von mir genutzten Geräte sind Shelly 1 Plus und Shelly i4. Diese beinhalten den Mikrocontroller ESP32, welcher erheblich mehr Ressourcen besitzt als der in die Jahre gekommene ESP8266.
Die neuen Shellies bieten u.a. die Möglichkeit, die Funktionalitäten durch zusätzliche Scripts zu erweitern bzw. den eigenen Bedürfnissen anzupassen. Hierfür steht die Programmiersprache Shelly Script zur Verfügung, ein stark reduziertes JavaScript mit zusätzlichen Funktionen. Diese zusätzlichen Funktionen nutzen in der Firmware verfügbare Informationen und Ereignisse. Die Sprache ist einigermaßen gut beschrieben unter Shelly Script Language Features.
Ich beschäftige mich nach wie vor privat mit komfortablen Steuerungen von Gartenbewässerungen, die auch aus der Ferne nutzbar sind. Hierfür habe ich drei virtuelle Geräte (VG) implementiert, die per MQTT kommunizieren. Jedes VG ist per Script implementiert.
Diese drei VG implementieren als Gruppe auf einem Shelly 1 Plus die fernsteuerbare Bewässerungssteuerung. Der Anwender braucht ein MQTT fähiges Frontend um sie zu nutzen. Dies kann eine Smartphone App oder eine Website sein, die die Bedienungselemente zur Verfügung stellt. Ich verwende hierfür die Android App "mqtt dash" und Node-RED.
Die oben kurz beschriebenen VG können auch auf verschiedenen Shellies verteilt werden, bspw. "mono" und "timer" auf einem Shelly i4, "switch" auf einem Shelly 1 Plus. Entscheidend ist die MQTT Kommunikation. Die drei VG besitzen ein definiertes Verhalten bei MQTT Ausfall, also falls der Broker oder das Netzwerk ausfällt. Ein wesentlicher Vorteil solcher Scripts besteht in der flexiblen Anpassbarkeit an die Wünsche des Anwenders.
Falls jemand an diesen Scripts interessiert ist, stelle ich diese gerne zur Verfügung. Sie sind inzwischen ausgiebig getestet. Auch sind sie bei Bedarf erweiterbar. Ich werde vielleicht noch Zufallssteuerungen für das Schalten von Beleuchtung bei Abwesenheit implementieren.
Falls Fragen zur Script-Programmierung bestehen, gebe ich gerne Auskunft, soweit ich kann.
Zusatzhinweis:
Zur Erfassung des Zeitpunktes des letzten Einschaltens verwende ich einen kleinen, von mir auf einem Raspberry Pi erstellten Dienst, der bei eintreffender MQTT Nachricht im JSON Format das Datum und, wenn man will, die Uhrzeit sendet, beides oder mehr nach Belieben formatierbar. Diesen kleinen MQTT basierten Dienst nutze ich, weil auf einem Shelly zwar die Uhrzeit und der Unix Zeitstempel, nicht aber das Tagesdatum erfragbar sind. Wenn kein Tagesdatum gebraucht wird, kann auf den kleinen Dienst verzichtet werden. Diesen Dienst betreffend danke ich JoergZ für seine Mitwirkung.
Screenshot von MQTT Dash kurz nach dem Einschalten per Schaltuhr (timer)
Hier steht m ausnahmsweise für Minuten, s für Sekunden.
Hm, ich habe über den Hinweis von HoerMirAuf noch einmal nachgedacht.
Folgendes sollte technisch gelingen: (Ich editiere dazu jetzt kein Bild, zu aufwändig.)
So würde auch bei von HoerMirAuf eingekreister bestehender Verbindung kein Problem bestehen. Der Schalter würde in seiner Ein-Position L und in seiner Aus-Position N auf den Sw(itch) Eingang des Shelly legen. Ob solches nach evtl. anderer Vorlage des Schalterherstellers zulässig ist, weiß ich derzeit allerdings nicht. Ein(e) Fachmann/-frau sollte dies aber locker verdrahten können.
Voraussetzung: Im Schaltergehäuse gibt es keine sonstige Beschaltung zwischen den beiden oberen Kontakten, was ich vermute.
Ich habe allerdings nicht getestet, ob N auf Sw(itch) für den Shelly ein Problem wäre. Ich vermute nicht. Dies wäre ggf. zu prüfen.
Schließe die Leuchte (Glimmlampe o.ä.) doch einfach an den Ausgang des Shelly an, falls du an deren Kontakte kommen kannst.
Um Heizungen zu schalten, sollte kein RC "Snubber" benötigt werden. Dieser, so schreibt Allterco Robotics selbst, sollte bei induktiven Lasten zugefügt werden. Eine Heizpatrone ist aber keine induktive Last. Du kannst es ja versuchen, ich glaube aber nicht, dass dies helfen wird.
Hmm, nach meiner etwas zurückliegenden Erfahrung mit den Rules gelingt keine zusammengesetzte Wertänderung einer Variablen in einer backlog Anweisung. Dafür braucht es mehrere Anweisungen, bspw. zwei.
Prinzipbeispiel: <trigger> ist ein Platzhalter für irgendeinen Trigger.
on <trigger> do backlog var1 3; add1 2 endonHier erwartet man vermutlich in var1 den Wert 5, darin steht aber der Wert 3. Gründe dafür liegen in der Abarbeitung der Rules, was ich mal genauer wusste, aber jetzt nicht parat habe.
Folgendes sollte gelingen, um das Gewünschte zu erhalten: 'v1plus2' ist ein Ereignisname, welcher durch einen besser passenden ersetzt werden kann.
on <trigger> do backlog var1 3; event v1plus2 endon on event#v1plus2 do add1 2 endonDeine Ziele habe ich jetzt nicht genau erlesen, weshalb ich dazu auf die Schnelle nichts schreiben kann. Ich vermute aber, dass in obigem ein Kernproblem liegt.
Ich würde einen Shelly 1 (PM) nicht mit 3kW Schalt-/Messleistung belasten. Ich kenne die Schaltung darin zur Leistungsmessung nicht, aber irgendwie muss die Stromstärke in eine Spannung umgewandelt werden. Vermutlich wird genau dieser Schaltungsteil auf diese Weise sehr warm.
Hast du dafür mal einen Shelly 1 ohne Leistungsmessung, also ohne 'PM' eingesetzt?
Die maximale Leistung von 3,5 kW lese ich als Grenzwert. Demzufolge überrascht es mich nicht, wenn das Gerät bei 3kW sehr warm (heiß) wird. Irgendwo muss diese Wärme hin. Normalerweise stattet ein Elektroniker dafür das warm werdende Teil mit einem Kühlkörper aus, was bei dieser sehr geringen Größe wohl kaum möglich sein dürfte. Du könntest bspw. das Gehäuse öffnen und die Schaltung einem kühlenden Luftstrom aussetzen. Ich weiß nicht, ob auf der Schaltung Platz ist, einen Kühlkörper anzubringen. Technisch sinnvoll wäre das sicher bei einer solch hohen Leistung. Ich schätze dafür das Gerät als zu eng gebaut ein. Wer Wärme ableiten will, braucht dafür Platz.