Befehl nach DeepSleep akzeptieren

  • 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, es sei denn die wurden zuvor in ner MEM Variable dauerhaft gespeichert.

    Das wäre wirklich gut und sinnvoll und wäre zu testen - vielleicht schaffe ich es heute - habe frei aber auch andere ToDos - doch das Video, dessen Link du uns geschickt hast, zeigt ja einen Taster, der mit einem menschlichen Finger gedrückt wird. Dann wacht der ESP auf. Schaun wir mal, was nach dem Löten rauskommt.


    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.

  • @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.

    Online Compiler


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / HomeMagic / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E Sensoren

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/3xGoogle-Home-Mini

    4 Mal editiert, zuletzt von HoerMirAuf ()

  • Gerät wacht auf und fragt den SOLL Zustand ab

    Wenn der Sollzustand in einer Mem-Variablen des DeepSleep-Geräts abgelegt ist, geht das. Wenn der Soll-Zustand nur FHEM bekannt ist, dann muss FHEM die Steuerung übernehmen.

    Mir scheint Letzteres der Fall zu sein, denn du schreibst:

    -> Deepsleep -> FHEM arbeitet weiter und stellt fest dass das Relais geschaltet werden soll -

    Dann muss FHEM, wenn es mitbekommt, dass das DeepSleep-Gerät wieder wach ist, entsprechend reagieren. So verstehe ich deine Beschreibung.

  • 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? :/

    Online Compiler


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / HomeMagic / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E Sensoren

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/3xGoogle-Home-Mini

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

    Online Compiler


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / HomeMagic / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E Sensoren

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/3xGoogle-Home-Mini

  • Hab das jetzt mal versucht über den GPIO 14 was mit deepsleep zu machen, weil der beim Basic so schön auf der Pinleiste hearusgeführt wird. Aber das war ein Schuss in den Ofen: Im Deepsleep-Status ist es mir nicht gelungen, das Gerät aufuwecken. Weder durch Aufschalten von Spannung noch durch Unterbrechung kam es zu irgend einer Reaktion. Die Loglevel Weblog und Mqttlog waren beide auf 4 hochgedrejt. Wenn der GPIO 14 eine Auswirkung hätte, hätte irgendwas erscheinen müssen.Ich stelle erst einmal weitere Untersuchungen zu diesem Thema ein :(.

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

    Online Compiler


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / HomeMagic / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E Sensoren

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/3xGoogle-Home-Mini

    3 Mal editiert, zuletzt von HoerMirAuf ()

  • Hallöchen,


    nachdem ich jetzt zu Hause genug gearbeitet hab, hab ich noch mal kurz Zeit, also ..... der Reihe nach:

    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.

    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.


    Hab das jetzt mal versucht über den GPIO 14 was mit deepsleep zu machen, weil der beim Basic so schön auf der Pinleiste hearusgeführt wird. Aber das war ein Schuss in den Ofen: Im Deepsleep-Status ist es mir nicht gelungen, das Gerät aufuwecken. Weder durch Aufschalten von Spannung noch durch Unterbrechung kam es zu irgend einer Reaktion. Die Loglevel Weblog und Mqttlog waren beide auf 4 hochgedrejt. Wenn der GPIO 14 eine Auswirkung hätte, hätte irgendwas erscheinen müssen.Ich stelle erst einmal weitere Untersuchungen zu diesem Thema ein :(.

    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 ?


    ".....Use any GPIO and connect it through a 10k resistor to GND. Using D0/GPIO16 is acceptable. You can define the (182) DeepSleep component as shown below........"


    Ich hoffe ich stehe damit nicht ganz auf dem Holzweg.....


    grüße

    Andreas

  • Teste zur Zeit mit DeepSleepTime.

    Tasmota 7.2.0 läuft auf einem ESP12e.

    Betriebsspannung erfolgt über 2xAA Batterien.

    Gpio16 wird mit RST über einen Jumper verbunden.

    Aktivierungssignal für den Tiefschlaf erfolgt über Gpio16 an RST.

    Testweise habe ich DeepSleepTime 7200 gesetzt und das Gerät wird alle 2 Std. geweckt.

    Also, in der Konsole :

    savedata 1

    DeepSleepTime 7200

    jetzt Jumper setzen und Batteriespannung kurz weg und wieder verbinden.

    Gerät geht jetzt in den Tielschlaf.

    Zur Überwachung der Ausgaben von Informationen in Tasmota nutze ich VIS.

    Dort kann ich Grund für Neustart (Deep Sleep Wake), DeepSleepTime und Batteriespannung abfragen.

    Angeschlossen ist ein DHT22 und die Werte werden alle 2 Std. an IOBroker gesendet.


    Um den Tiefschlafmodus zu beenden muss ein beliebiger Gpio (bei mir Gpio4) mit einem

    10K Widerstand auf GND gesetzt werden.

    Jetzt den Jumper entfernen und die Batteriespannung kurz weg.

    Nun hat man wieder Zugang auf Tasmota.

    In der Konsole DeepSleepTime 0 eingeben und DeepSleepTime ist deaktiviert.


    Um jetzt wieder DeepSleepTime zu aktivieren folgendes ausführen.

    DeepSleepTime 7200 eingeben

    Gpio4 und GND trennen

    Jumper setzen und Batteriespannung kurz weg.

    In IOBroker kann eingesehen werden was alles passiert.

    Unter Objekte/Datenpunkte wird bei RestartReason zb. Deep-Sleep Wake nach ablauf der 2 Std. angezeigt.

    Bei DeepSleepTime die Weckzeiten alle 2 Std.

  • Danke premo für die ausführliche Darstellung. Das war noch mal eine zusätzliche Bestätigung, dass Deepsleep nur über die Brücke des RST Pins zusätzliche Hardware realisiert werden kann. und mit Strom an/aus, Jumper drauf/weg und Taster an GPIOx und GND doch eine aufwändige Geschichte. Schade, ich dachte das sei ein Software steuerbare Angelegenheit. Wieder was gelernt.

  • Also bei mir läuft Deepsleep irgendwie anders.


    Die einzige "zusätzliche Hardware" ist ein kleiner Tropfen Lötzinn. ;)

    Bei jedem Spannung-Ein bootet das Ding und kann ca. 15 Sekunden lang durch den (zB) Befehl:


    "http://192.168.0.228/cm?cmnd=deepsleeptime%200"


    wieder dauerhaft aktiviert werden. Im IOBroker wird auch Sekunden-genau die Uhrzeit des nächsten Neustarts angezeigt, und zu der Uhrzeit funktioniert der Befehl dann auch ...

  • Bei jedem Spannung-Ein bootet das Ding und kann ca. 15 Sekunden lang durch den (zB) Befehl:

    Ja schon klar, dass das im Bootvorgang möglich ist bzw. bis zum ersten Raushauen der Teleperiod-Message. Aber danach kommt man ohne GPIOx to GND und/oder Strom aus/Strom an nicht mehr dran. Es ging in diesem Feed zum einen um die Auswertung/Verarbeitung von (Sensor-)Daten während des deepsleeps und zum anderen (mein Thema) um das Aufwecken aus dem Deepsleep eben OHNE Hardware-Einfluss. Strom aus/Strom an bewerte ich ebenfalls als "Hardware-Aktion". Ich dachte, man kann ein Gerät aus dem Deepsleep per Software (MQTT, HTTP) holen. Dann hatte ich die Hoffnung, dass ich den GPIO 14, der ja an der Pinleiste eines Basics anliegt, als WakeUp benutzen könnte. Geht aber auch nicht.