Beiträge von eich

    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:

    Code
    on mem2#state do
        backlog var7 %mem2%;add7 1;event p6
    endon

    Never 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

    Code
    event a2=123

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

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

    Code
    event a2=irgendein_Wert

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

    Sorry, ich bin etwas von C und C++ geprägt. Der Vergleich des Statuswertes in den Rules wird mit einem einfachen Gleichheitszeichen codiert:

    Code
    on button1#state=1 ...

    Vielleicht werden Zeichenkettenwerte (Strings) per == verglichen - ich wusste das mal, als ich mich eingehend mit den Rules beschäftigte. :D

    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:

    Code
    on Ereignis do Anweisung endon

    bzw. für mehrere auszuführende Anweisungen bei eintretendem Ereignis

    Code
    on Ereignis do backlog Anweisung1; Anweisung2; Anweisung3; ... endon

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

    Code
    on button1#state=1 do backlog power1 1; ruletimer1 %mem1% endon
    on rules#timer=1 do power1 0 endon

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

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

    Code
    on var1#state do backlog mult1 3; event add4to1 endon
    on event#add4to1 do add1 4 endon

    Hm, 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.

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

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

    Code
    on power1#state>0 do ruletimer1 %mem1% endon
    on rules#timer=1 do power1 0 endon
    rule1 1

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

    Code
    on button1#state==1 do backlog power1 1; ruletimer1 %mem1% endon

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

    • "switch" ist ein Schalter, der auf Schaltereignisse und auf Schalten-Nachrichten reagiert. Er erfasst jeweils die Einschaltzeit und die Einschaltdauer. Beide Informationen sendet er nach dem Ausschalten. So ist immer ablesbar, wann und wie lange zuletzt bewässert wurde.
    • "mono" ist ein parametrierbares Monoflop. Mit dem Einschalten wird es getriggert und sendet nach Ablauf der eingestellten Dauer eine Nachricht, die bspw. "switch" zum ausschalten bewegt. Nach der Triggerung läuft ein Abwärtszähler, der nach jeder Periode, bspw. 1 Minute, um 1 herunterzählt und eine Nachricht mit dem Zählerstand sendet. So ist die Restdauer jederzeit im Minutentakt ablesbar.
    • "timer" ist eine Schaltuhr für 24h. Sie sendet eine Schalten-Nachricht zur eingestellten Zeit und eine Nachricht mit der Einschaltdauer, welche bspw. "mono" empfängt und damit getriggert wird.

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

    • Schalterkontakt unten links mit dem Sw(itch) Eingang des Shelly verbinden.
    • Schalterkontakt oben links mit dem L-Leiter verbinden.
    • Glimmlampenkontakt oben mit dem N Leiter verbinden.
    • Glimmlampenkontakt unten mit dem Shelly Ausgang (O) verbinden.

    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.

    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.

    Code
    on <trigger> do backlog var1 3; add1 2 endon

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

    Code
    on <trigger> do backlog var1 3; event v1plus2 endon on event#v1plus2 do add1 2 endon

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

    Hallo zusammen.


    Ich sitze - auch nächtens - konzentriert am PC und freue mich über die Shelly Plus Serie von Allterco Robotics - in etwa weitgehend. ;)

    Durch meine Vorerfahrungen mit Tasmota32 und der ziemlich gelungenen Hybridsprache Berry haben sich meine Erwartungen etwas hochgeschraubt.

    Ich belasse die originale Firmware auf meinem Shelly Plus 1 und auch auf Plus i4 und versuche, die Möglichkeiten des Scriptings auszuleuchten. Mit etwas Durchärgereien und der print-Anweisung (zum debugging und Erfahrungs-/Experimentierlernen) komme ich inzwischen sehr gut zurecht. Das mJS (reduziertes JavaScript) bietet zwar nicht sehr viel Komfort, das Fehlende code ich dann halt selbst zusammen, was bisher auch gut gelingt.


    Nun stoße ich aber auf derbe Einschränkungen:

    • Es gibt nichts, was einem include entspricht.
    • Ich finde keine qualified identifier, die Datei übergreifend nutzbar sein könnten.
    • Mir fehlen forward Deklarationen, was vermutlich in JavaScript eh nicht existiert.

    Ok, ich bin von C++ etwas verwöhnt und erwarte hier nicht annähernd deren Leistungsumfang. Wenn wenigstens einer dieser obigen Punkte implementiert wäre, käme ich ein Stück weiter. Es ist schlicht sehr unübersichtlich, alles in einer einzigen Scriptdatei zu pflegen. Typischerweise stellt sich die Frage: "In welcher Datei, welchem Objekt/Datenstruktur bringe ich die erwünschte Funktionalität unter?"


    Bspw. kann man in Tasmota32 eine Datei "autoexec.be(c)" erstellen, die andere Dateien lädt. Damit existiert wenigstens ein workaround für ein fehlendes include und man kann die Gesamtfunktionalitäten sehr gut auf mehrere Dateien verteilen. So habe ich bspw. mein Zisternenmessgerät realisiert. Nun implementiere ich auf Shelly Plus (1) all das, was ich per Tasmota/Rules auf einem Shelly 1 (mühsam) für zeitgesteuerte Bewässerungen bereits implementierte. Die Vorteile des Shelly Scriptings auf ESP32 gegenüber einem Tasmota auf ESP8266 und Rules erscheinen mir sehr deutlich. Ich genieße die Freiheiten des MQTT subscriben und publishen mit selbst zusammengestellten Topics und Payloads. Bisher funktioniert alles sehr gut. Die Flexibilität des Zusammenstellens genieße ich - nur die o.a. Einschränkungen machen mir inzwischen so sehr zu schaffen, dass ich mich deshalb hier etwas auslasse.


    Falls hier jemand Kenntnisse hat, obige Einschränkungen zu umschiffen, würde ich mich über eine Reaktion freuen.


    Gruß Gerhard


    P.S.: Ich treibe mich ungerne in mehreren Foren um. Deshalb habe ich noch kein Konto im Shelly Forum. Vielleicht muss ich mich dann doch dort mal registrieren lassen - leider.

    Das sollte gelingen. Zu ioBroker kann ich nichts sagen, weil ich den nicht nutze.

    Die Relais - vermutlich über Optokoppler - werden ganz normal über Power(1) oder so angesteuert. Dies lässt sich, wie du vermutlich weißt, in der Konfiguration einstellen, wie auch die PWM-Dimmung.

    Falls du vor etwas Programmierung nicht zurückschreckst, stehen Rules, eine Scriptsprache und mit Tasmota32 sogar eine Hochsprache Berry zur Verfügung.

    Hast du es denn schon versucht mit der Konfiguration?