Beiträge von eich

    Energy ist nicht Power. Energy dürfte hier Energie = physikalische Arbeit bedeuten. Leistung kann auch nicht anliegen. Leistung ist Arbeitsgeschwindigkeit.

    Die Energiezuführung oder Energieentnahme, wohin auch immer, ist das Produkt aus Leistung und Zeitspanne, wie auch die Einheit kWh erkennen lässt.

    Soviel an Physik Grundlagen. :)

    Ich kenne, wie so vieles hier, auch einen "POWR2" nicht. Trotzdem eine Anmerkung:

    Wenn Energiefluss in kurzen Zeitabständen gemessen werden soll, dürfte die Einheit kWh wenig geeignet sein. Eine Einheit kWs wäre dann vermutlich passender. Es sei denn, es wird viel oder sehr viel geleistet.

    Möglicherweise wird intern der Energiefluss erfasst, die Anzeige aber nur bei wesentlichen Änderungen aktualisiert.

    Was stört dich an den relativ seltenen Aktualisierungen?

    Die Abbildung sieht nach Tasmota aus. Hast du mal recherchiert, welche Parameter du dort per Kommandos einstellen kannst?

    Ich kenne diese Dinger nicht und kann leider nur meinen kleinen Kommentar abgeben.

    Ich halte nicht viel von solchen getricksten "ohne Nullleiter" Schaltungen.

    Ich kenne die Technik dahinter nicht, vermute, dass das Gerät bei Stromfluss aktiviert/eingeschaltet wird.

    Kannst du keine technisch sauberen Sonoff einbauen, also mit Nullleiter vor Ort? Oder einen Platz finden, wo L und N vorliegen?

    Deine Skizze zeigt farbige Adern, wie sie so nicht verbunden werden sollten. Du solltest die Finger davon lassen und jemanden darum bitten dir vor Ort zu helfen, der Ahnung von Elerktroinstallationen hat. Vermutlich wird er murmeln: "Oh oh oh." Da sind Messungen/Prüfungen durchzuführen, um Gewissheit zu gewinnen. Alles andere ist eher eine Mutprobe für Leichtsinnige. Hier wird dir keiner so weiterhelfen können/wollen, wie du es möchtest. Leider

    Grüße

    Nachfrage:

    Geht es um einen Shelly mit Original-Firmware und die Shelly App?

    Leicht vorgewagt, nur gültig, wenn beide Fragen mit "ja" zu beantworten sind:

    Die Shelly App kann nicht mit einem AP Shelly kommunizieren, weil sie nur mit der Cloud kommuniziert.

    Die AP WLAN Verbindung nutzen (umständlich) und im Browser die IP-Adr. des Shelly eingeben!

    Ich hatte noch nie das Bedürfnis, die IP-Adresse eines Shelly im AP-Modus einzustellen und weiß nicht, ob das geht.

    Imho ist es durchaus sinnvoll, dass die App nicht direkt mit einem Shelly kommuniziert. Dazu gibt es Browser und der Shelly hat dafür einen Webserver. Das Umständliche ist doch wohl nur die "Umverbindung" mit dem Shelly AP. Und das Problem bleibt, solange der Shelly nicht im WLAN sitzt.

    Warum ist dieser Garagen-Shelly nicht in's WLAN eingebunden? Entfernung zu weit?

    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

    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

    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

    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

    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

    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

    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

    Sorry, ich kenne dieses Rule-Problem überhaupt nicht.

    Sie sollten im nichtflüchtigen Speicher abgelegt werden, was hoffentlich auch der Fall ist.

    Vermutlich nimmst du dafür die Tasmota Webkonsole. Damit arbeite ich für die Rules nicht. Ich nutze MQTT und habe mir hierfür per Node-RED eine eigene Webkonsole erstellt. Diese gab/gibt mir bessere Möglichkeiten, Rules zu erstellen und zu testen.

    Falls du MQTT und Node-RED nutzt, kannst du meine Konsole gerne bekommen.

    Hallo Ralf123,


    Ich nutze diesen Sensor zur Füllstandsmessung in meiner Zisterne, allerdings an einem Arduino Uno. Er wird mit 5V versorgt, was auch empfehlenswert ist.

    Ich verwende die Erfassung der Schalllaufzeit, also Trig und Echo. Meine Leitung zwischen Arduino und Platine des Sensors ist etwa 15m Lang.


    Man kann diesen Sensor auch für eine serielle Kommunikation "jumpern", per Widerstandsbrücke neben den Stiften - afaik mit R27 beschriftet.


    Meine Tests mit Tasmota und einem ESP8266 Board waren ebenso erfolgreich.


    Dieser Sensor hat allerdings größere Richtkeulen als ein HC-SR04 und man kann ihn schlecht/gar nicht mit Rohren in der Richtwirkung verbessern.


    Vermutlich liegt dein Problem nicht an Hindernissen im Bereich der US-Wellen, da der Sensor, wie du schreibst, auch im ausgebauten Zustand 18cm anzeigt. Überprüfen könntest du dies aber mal. Und versorge den Sensor mit 5V - sicherheitshalber! Dazu ist dann ein Spannungsteiler für das Echo-Signal am Eingang des µC erforderlich, wie Seppel24 bereits schrieb.

    Du könntest zwei weitere events definieren, welche in event#t1 genutzt werden:

    ON event#t1 DO Backlog var2 %value%; add2 3 ENDON
    ON event#t1 DO Backlog var3 %value%; add3 6 ENDON

    Beispiel-Teillösung:

    on event#t1 do backlog var2 %value%; var3 %value%; event a2=3; event a3=6 endon

    on event#a2 do add2 %value% endon

    on event#a3 do add3 %value% endon


    Ob so dein Ziel erreicht wird, kann ich derzeit nicht einschätzen, aber die Addition sollte so erfolgen, wie du beabsichtigst.

    Ich kenne deine Hardware nicht. Trotzdem ein paar kurze Bemerkungen:

    * GIPO lässt sich vielleicht leichter aussprechen, die Dinger heißen aber GPIO (General Purpose Input Output). ;-)

    * Zwei 4,7 kOhm parallel ergibt 2,35kOhm, schalte sie für die 10kOhm besser in Reihe oder nimm einen 4,7kOhm - ist eh nur ein Pullup Widerstand.

    * Rechne mit Prellen des Reed-Kontaktes und denke an das Einstellen des softwareseitigen Entprellens!

    Da du bisher keine Reaktion erfahren hast, gehe ich mal kurz darauf ein, obwohl ich bisher die 2.5er shellies noch nicht eingesetzt habe und schon gar nicht mit tasmota geflasht habe.

    Ich setze mal die passende Konfiguration voraus und überprüfe das jetzt (noch) nicht.


    1. Ich würde es so machen wie du.


    2. Hast du statt Button mal Switch versucht?


    3. Es bleibt der Versuch eines Debugging. Baue doch dazu einfach mal in das Backlog die Speicherung in Variable ein, bspw.

    Rule3 ON button1#state DO Backlog var1 1; var2 %value%; Power1 %value%; RuleTimer1 1200 ENDON ON Rules#Timer=1 DO Power1 off ENDON


    Lasse nach der Aktivierung von Button1 mal die Werte in den Variablen anzeigen und ändere diese ggf., um ein Nichteintreffen des Ereignisses button1#state eindeutig detektieren zu können. ...


    Viel Erfolg und nicht allzuviel Frustration wünsche ich. ;-)

    Es fehlt schlicht eine Schalthysterese. Versuche es doch mal mit zwei Schaltschwellen, bspw. mem3 40, mem4 35 - oder so!

    Wenn das funktioniert und es noch weitere Probleme mit den Rules geben sollte, schaue ich mir diese Rules evtl. mal genauer an. ;-)

    Trotzdem noch ein Hinweis:

    ON event#t1 DO Backlog var2 %value%; add2 3 ENDON

    Es sollte dir klar sein, dass hier mit add2 3 zum Inhalt von var2 VOR dem Eintritt in dieses Event 3 addiert wird. %value% wirkt somit nicht.