Beiträge von HoerMirAuf

    Ne ... das sind nur Zeilennummern wenn man hier Textr als Code formatiert.

    Nur den Text ind die Konsole eingeben. Es muss auch kein Zeilenumbruch gemacht werden zwischen den Zeilen ...


    das einzige ist die letzte Zeile:


    rule1 1


    das besser einzeln eingeben um die rule zu aktivieren

    GuMo.


    Du solltest dich schon ein wenig in die Rules einlesen wenn du damit arbeiten möchtest. So schwer ist das nicht.

    Ich ergänze mal Einstein67 Rule


    Code
    1. rule1
    2. on Energy#Power>100 do websend [IP vom ersten Basic] power1 1 endon
    3. on Energy#Power<80 do websend [IP vom ersten Basic] power1 0 endon
    4. on Energy#Power>300 do websend [IP vom zweiten Basic] power1 1 endon
    5. on Energy#Power<240 do websend [IP vom zweiten Basic] power1 0 endon
    6. on Energy#Power>500 do websend [IP vom dritten Basic] power1 1 endon
    7. on Energy#Power<420 do websend [IP vom dritten Basic] power1 0 endon
    8. rule1 1


    Verweildauer etc. ist hier nicht berücksichtigt. Wie ich dir bereits sagte, wird das zu komplex. Das müsste dann mit Ruletimer die andere Rules aktivieren, bzw. deaktivieren etc. (wäre ja im Prinzip if else then Anweisungen). Das macht einfach keinen SInn sowas mit Rule zu versuchen.


    Was das schwingen angeht .... so wild wird das nicht. Hast ja immerhin ne Hysterese drin zwischen ein und ausschalten.

    Notfalls die einfach größer machen,

    Was für ne Pin Belegung?


    Die Power Platine hat doch nur die 4 Stifte mit der die Spannung an die Steuerplatine geliefert wird und die anderen beiden Pins werden wohl das Relais ansteuern.

    @Einstein67 hat dir doch schon den Lösungsansatz geliefert?


    siehe:
    RULE für den Sonoff POW r2 gesucht


    Du musst nur deine Energiewerte und IP's der anderen Basic ergänzen bzw. die Rule darum erweitern.

    Was Deine Verweildauer angeht ... wann soll wer wie lange verweilen?


    Und ich fürchte wenn du mit Mindestlaufzeiten kommst dann sind wir wieder beim Komplex. Dann muss ja abgeprüft werden


    - ist der Wert über oder unter eine Grenze

    - wie lange läuft die untere Stufe

    - ist der Wert größer als Stufe eins, wie lange läuft den schon Stufe 1? Darf den Stufe 2 überhaupt schon schalten? Und wenn ja wer schaltet dann Stufe 1 aus? usw usw....


    Solche Logiken machen wie bereits erwähnt mehr Sinn über nen Server Zentral zu steuern.

    Mhmmmm ob es dann wirklich immernoch schwer ist selbst zu kompilieren ? Ich meine auf der Virtual-Maschine läuft es ja (dauert halt etwas). In meinem Fall wäre wohl das Problem dass das Ding im Optimalfall 2 Relais zur unterschiedlichen AN-Dauer schaltet, einen Helligkeit und Temp Sensor übermittelt. Helligkeit zwischen 7 und 9 Uhr sehr oft danach nur noch stündlich.
    Sobald ich eine Lösung gefunden habe, wie ich das mit dem DeepSleep löse, bekomme ich alles andere über FHEM und die internen Regeln hin.

    Noch kurz dazu:


    Macht eigentlich keinen Sinn mehr da selbst was zu kompilieren.

    Tasmota ist viel besser zu konfigurieren und vielseitiger als alles selbstgemachte.


    Es sei denn man hat nen portablen Button den man in unterschiedlichen MQTT Brokern betreiben will.

    Ich hatte da im Sketsch die Möglichkeit drin an 2 MQTT Broker zu senden.

    Moment mal ... Entweder hab ich das jetzt falsch verstanden, JoergZ oder wenn ich das richtig verstehe, was in der Doku steht, könnte man doch auch einen anderen GPIO, als den 16er zum MANUELLEN aufwecken nutzen ? Automatisch geht nur die dauerhafte Brücke auf GPIO16-GND aber manuell könnte man doch den GPIO14 als "DeepSleep" konfigurieren und müsste ihn damit manuell geweckt bekommen oder nicht ?

    So ... nun nochmal:


    Manuell kann der ESP aus dem Deepsleep NUR aufgeweckt werden wenn:


    - der RST Pin kutzzeitig auf GND gelegt wird. Ob das mit nem Taster geschieht oder mit GPIO16 oder wie auch immer ist Wurst,

    - die Versorgungsspannung kurz weggenommen wird.


    Automatisch geht NUR mit PIN16 auf RST und dem Deepsleeptimer.


    Zitat

    manuell könnte man doch den GPIO14 als "DeepSleep" konfigurieren und müsste ihn damit manuell geweckt bekommen oder nicht ?

    Nein !! Im Deepsleep arbeitet GAR nix mehr außer der RTC (GPIO16) und somit kann auch nix anderes den ESP wecken (außer manuell mit RST auf GND)

    siehe Post #27

    Hmmm ... ich glaub das ist so gemeint:


    Wenn ein GPIO als DeepSleep definiert ist und du diesen GPIO dann im Normalbetrieb auf GND legst (z.B. mit nem Schalter) lässt sich der deepsleep mode nicht aktivieren bzw. wird diese Funktion in Tasmota deaktiviert

    Weder durch Aufschalten von Spannung noch durch Unterbrechung kam es zu irgend einer Reaktion


    Hmmm ... ich glaub das ist so gemeint:


    Wenn ein GPIO als DeepSleep definiert ist und du diesen GPIO dann im Normalbetrieb auf GND legst (z.B. mit nem Schalter) lässt sich der deepsleep mode nicht aktivieren bzw. wird diese Funktion in Tasmota deaktiviert


    EDIT:
    aufwecken aus dem Deepsleep geht definitiv NUR über einen Reset ... läuft ja nix mehr auf dem ESP außer der RTC (RealTimeClock) und die arbeitet auf GPIO16 (Wake) der über die Brücke auf den RST (Reset) Pin diesen dann kurz auf GND zieht und damit einen Reset auslöst.


    EDIT2:

    Oder eben manuell mit nem Taster den RST mal kurz auf GND setzen.

    HoerMirAuf Den Beitrag habe ich hier sogar meine ich mal gelesen (entweder war das dieser oder ein anderer mit ähnlichem Inhalt) Ich hab auch daraus gaaaaaaaaaanz kurz gebastelt, aber bedingt dadurch, dass ich noch nie nen Arduino Sketch selbst gebaut hab (mir einfach die Kentnisse in dieser Sprache fehlen) und noch nie selbst ne Firmware compiliert habe, war das schon etwas komplizierter für mich. Habs zwar mit ner Virtuellen Maschine und ner Arduino Software drauf, dann doch zum laufen bekommen, aber bin da wie gesagt eher so der learning by doing Typ .... Wenn gefühlt jedes Compilieren und übertragen auf den Chip 10 Min dauert, weil ich einen Buchstaben geändert habe war es schon nervig.
    Daher mein Versuch das mit Tasmota hin zu bekommen.

    Denn Sketch hab ich bestimmt auch noch irgendwo falls interesse.

    Da müssen nur die WLAN Daten und die MQTT Daten eingetragen werden und dann mit der Arduino IDE kompiliert werden.

    Allerdings isses wohl leichter mit Tasamota umzusetzen als selbst zu kompilieren.

    Im Tasmota-(Original)-Wiki befindet sich dieser Satz:

    If you want to temporarily disable deep sleep mode, you can use any GPIO and connect this through a 10k resistor to GND. Using D0/GPIO16 is acceptable. You can define a (182) DeepSleep component as shown below.

    (Zweite Hervorhebung von mir) Ich werde mal versuchen, den GPIO14 umzubiegen oder bin ich da wieder auf dem Holzweg.

    Das geht auch mit dem GPIO16. Wenn du denn GPIO in den Tamsota-Einstellungen als DeepSleep definierts, dann ist der so wie ich es lesen entweder temporär aktiviert oder eben deaktiviert ... das wäre jetzt zu testen, da werd ich auch nicht ganz schlau draus.


    Aber ich vermute mal wenn da dann deepsleep drin steht ist der deaktiviert? :/

    @flummy


    ahh ... jetzt wirds klarer was du möchtest:

    Gerät wacht auf und fragt den SOLL Zustand ab

    Das ist das eigentliche Problem.


    Aktiv einen Wert abfragen kann Tasmota in diesem Sinne nicht.


    Was machbar wäre, wäre eine Rule die beim Systemboot eine MQTT Nachricht an FHEM sendet mit der bei FHEM das senden des aktuellen Schaltzustandes für das Relais angefordert wird.


    z.B.

    rule1 on System#Boot do publish <MQTT/NACHRICHT/an/FHEM/Schaltzustand/senden> endon


    EDIT:

    Mehrt braucht's da nicht, denn:

    Ist das Gerät bereits EIN und bekommt einen weiteren "ein" Befehl passiert gar nix. Bekommt's "aus" schaltet es eben aus. Und ist es bereits aus isses daselbe. Du musst nur FHEM dazu bewegen denn Soll Zustand zu senden.


    EDIT2:

    oder noch besser mit dem trigger:


    Mqtt#Connected


    arbeiten.

    @ JoergZ


    neeee ... ich glab das hast du faslch verstanden oder ich sitz jetzt auf der Leitung? :/


    Wenn die Brücke zwischen GPIO16 und RST gesetzt ist, DANN wacht der ESP nach ablauf des Deepsleeptimers auch wieder von ganz allein auf.

    Aber eben OHNE irgendwelche Werte (ist ja kein echtes "aufwachen" sondern ein Reset durch die RTC von GPIO16), es sei denn die wurden zuvor in ner MEM Variable dauerhaft gespeichert.


    Das was flummy machen möchte würe eigentlich schon beantwortet.

    Er muss seinen Wert den er nach dem Aufwachen (ablauf des Timers) wieder haben möchte, per Rule in MEM speichern und damit arbeiten.


    Die Frage wie dieser Memeory in FHEM abgebildet wird steht noch offen aber das läßt sich ja mit ner Rule (wurde auch schon erwähnt) ja in jeder Form als MQTT Telegramm senden.

    Ich frage aus dem Grund, weil es in meinem Fall darum ging herauszufinden wie lange ich mit Batterie, Solarpanel einem ESP-12F und einer Relaiskarte auskomme, bevor mir "der Saft ausgeht". Da ich in dem Fall natürlich Problemlos an GPIO16 komme, stört mich die eine Brücke mehr oder weniger nicht ;)


    Das kommt ganz auf den Akku/Batterie an.


    Der User @premo hat da mit nem ESP12 bzw 01 schon ESP Button gebastelt und experimentiert.

    Allerdings kein Tasmota sondern mit nem Arduino Sketch den ich damals für ihn modifiziert habe und der ne MQTT bzw HTTP Message absetzt nach dem aufwecken und dann wieder in den DS geht.


    Mit 2x AA Batterien kam der bei mehrmaliger täglicher Betätigung bis zu 3 Monaten oder so, glaub ich.

    Beim echten Deepsleep ist nur noch die RTC aktiv:


    https://randomnerdtutorials.co…p-sleep-with-arduino-ide/


    Keine CPU ... nix anderes. Und die RTC macht nach Ablauf nix außer den GPIO16 (der ist deshalb auch im Datenblatt mit "Wake" bezeichnet) auf GND zu setzen. Also kurzum:


    Das heiß deepsleep ist so eine Art One-Shot-Funktion: Beim Aufwachen kann man was machen lassen, danach verabschiedet sich der Prozessor in den Scheintod?


    Jepp ! ;) ... und aufwachen eben nur wenn der GPIO16 auch auf RST liegt.



    EDIT:

    Ich hatte diesen Satz durchaus gelesen hielt es aber für eine Option das Gerät aufzuwecken, ohne gleich an die Versorgungsspannung zu gehen

    Ne, leider nicht. Ist ein MUSS damit das Teil wieder aufwacht.


    Die Option ist das:

    Zitat

    If you want to temporarily disable deep sleep mode, you can use any GPIO and connect this through a 10k resistor to GND. Using D0/GPIO16 is acceptable. You can define a (182) DeepSleep component as shown below.

    Hi JoergZ


    ich hab mit dem Deepsleep noch nicht gearbeitet (zumindest nicht bei Tasmota. Bei Arduino schon). Ist zwar ein netter Gimmick aber bei Aktoren die immer erreichbar sein müssen nicht wirklich sinnvoll.

    Bei Sensoren mag das Sinn machen aber auch nur dann wenn es Daten sind die nicht permanent anstehen müssen.


    Um das gerät aus dem Deepsleep aufwachen zu lassen musst du allerdings:

    Zitat


    Please be aware that the minimum deep sleep time is 10 seconds. To wake the device, the RST pin must be connected to the D0/GPIO16 pin because the wake-up signal is sent through D0/GPIO16 to RST.


    Das muss so sein, weil der Timer nach Ablauf nicht einfach den ESP bootet sondern nur den GPIO16 auf GND zieht und damit das Gerät resetet, wenn der auf RST gelegt wurde. Deshlab überleben auch nicht in Mem Variablen gespeicherte Werte den Deepsleep nicht.

    Ganz so wild ist das nicht.


    ich hab keine Ahnung von FHEM. In IoBroker werden, wenn ich das richtig in Erinnerung habe, auch Datenpunkte für die Speicher, also MEMx abgebildet. Falls das in FHEM genauso wäre, ist so ne Rule die nen Triggerwert in nen Speicher zu schreibt nix aufwendiges.


    rule1 on <trigger> do mem1 %value% endon


    Und falls das nicht als Datenpunkt abgebildet wird könnte man auch immer wenn sich der Wert vom Speicher ändert ein MQTT Signal als eigenen Datenpunkt absetzten:


    rule2 on Mem1#State do publish <mqttnachricht/was/auch/immer> endon