Befehl nach DeepSleep akzeptieren

  • Hallöchen,


    nachdem ich nun endlich mal bei einem ESP Chip erfolgreich den Deepsleep aktiviert habe (wer lesen kann ist klar im Vorteil X/) , würde ich gern die Geräte die mit Tasmota geflasht und bereits erfolgreich in Betrieb sind in den DeepSleep versetzen.
    Leider sind dort auch Geräte in Betrieb die ein Relais betreiben. d.h. ich schalte damit gewisse Geräte ein / aus. Die Sachen werden aus FHEM heraus gesteuert und solange die Chips nicht in DeepSleep sind, funtkioniert es auch wunderbar. Nun würde ich gern (mit Hilfe einer Regel, oder .....? ) gern geräte schalten auch wenn der Chip im deepsleep ist, bzw danach. Derzeit ist es so:

    Deepsleep läuft ->Gerät erwacht -> Routinen laufen ab -> Relais wird geschaltet -> Set_ON ->Tasmota erkennt -> schaltet das Relais -> Zeit läuft ab -> Gerät geht in DeepSleep


    schalte ich nun in der Zwischenzeit das Gerät das oben eingeschaltet wurde, aus soll folgendes passieren:

    Deepsleep läuft -> Gerät erwacht -> Routinen laufen ab -> Set_OFF wird abgefragt -> Relais wird geschaltet -> Zeit läuft ab -> Gerät geht in DeepSleep


    es ist aber derzeit so dass der o.g. Ablauf dann folgendermaßen abläuft:


    Deepsleep läuft -> Gerät erwacht -> Routinen laufen ab -> Zustand vom Relais wird abgefragt (on) -> Set_OFF wird ignoriert -> Relais wird NICHT geschaltet -> Zustand on bleibt -> Zeit läuft ab -> Gerät geht in DeepSleep



    Ist das möglich ? Ich würde mich sehr freuen, wenn mir da jemand einen kleinen Tipp in die richtige Richtung geben kann.


    Vielen Dank schon im Voraus dafür

    Grüße

    Andreas

  • Du kennst diesen Eintrag?:

    https://tasmota.github.io/docs…-algorithm-general-timing

    Da gibt es schon ein paar Besonderheiten und Einschränkungen. Kannst ja im ersten Durchlauf mal checken, ob etwas offensichtlich gegen deine Idee spricht.

    Übrigens eine Super Übersetzungsengine hier:

    https://www.deepl.com/translator

  • Hallo Jörg,


    zunächst einmal vielen Dank für Deine Antwort, allerdings werde ich daraus nicht so wirklich schlau (oder verstehe es trotz des genialen Übersetzers, den ich schon kenne, nicht richtig? )

    Dass das DeepSleep erst nach erfolgreichem MQTT Versand erfolgt, habe ich endlich auch so verstanden und umgesetzt. Habe tatsächlich meine Teleperiod Zeit testweise auf 20 Sek geändert. Somit ist die "Wach-Zeit" relativ gering gehalten. Allerdings wird dann auch (bedingt durch die kurze "Wach-Zeit" ?) nicht mein "Wunschzustand" abgefragt, sondern der Ist-Zustand überschreibt meinen Wuschzustand :/


    Was mir halt fehlt, ist wie ich den

    Code
    cmnd/ESP_NAME/POWER1 0

    Teil abfragen / abfangen kann, bevor dieser durch den derzeitigen Zustand überschrieben wird.

    Ich hoffe ich habe das verstädnlich geschrieben =O:/


    Grüße

    Andreas

  • Moin.


    Ich hab mich jetzt nicht aktuell eingelesen (irgendwie will github bei mir gerade nicht) aber soweit ich das im Kopf habe überleben "Zustande" den Deepsleep nicht. Du musst also vor dem Deepsleep deinen Wunschzustand per Rule in einen Memory "mem1" schreiben und dann nach dem aufwachen mit dem weiterarbeiten

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • Ach HoerMirAuf, - Ne bitte nicht. Vielen Dank auch für Deine Antwort :)

    Schade dass sie nicht so ausfällt, wie ich mir erhofft hatte. Aber da ich mich mit den Regeln mal so noch gar nicht auskenne, stehe ich genauso wie "n Ochs vorm Berg" wie vorher auch. Es gibt also keine Möglichkeit die Wunschzustund (in diesem Fall in Fhem) abzufragen?
    Ich fürchte mal dann bleibt nur etwas derartiges übrig:
    ->deepsleep->aufwachen->Normaldurchlauf->"AWAKE" an Fhem melden -> von Fhem den Wunschzustand bekommen -> (per Rule?) Wunschzustand abwarten -> Fhem "SLEEP" melden -> und dann erst wieder in Deepsleep landen
    Irgendwie treibt mir selbst diese Vorstellung schon Rauch in den Schädel 8|:D
    Vielleicht hat ja noch jemand eine gute (bessere) Idee.


    Grüße

    Andreas

  • 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

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • Oh mann .... ich bin wahrlich nicht unerfahren, was Programmierung etc angeht. Aber jetzt grad komme ich mir vor wie der letzte Anfänger -.-

    Wie muss ich mir das vorstellen:

    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.

    Wie kann ich das herausfinden ?

    Wie gesagt, die Geräte kommunizieren ansich per MQTT. Solange das entsprechende Gerät "wach" ist, funktioniert auch alles einwandfrei. Ich weiss dass ich von FHEM aus senden / empfangen kann und vom ESP auch. Ich weiss auch dass ich (scheinbar) keinen Zustand von Fhem abfragen kann und diesen auf dem ESP übernehmen kann.
    Aber mir fehlt irgendwie der Ansatz wie ich herangehen könnte, bzw VOR ALLEM es testen könnte?
    ....on Dimmer#Boot AND Mqtt#Connected .... habe ich aus einigen Dokus heraus gefunden um die Rule zu starten, wenn der ESP aus dem Sleep erwacht UND per MQTT verbunden ist. Weiss aber nicht ob es korrekt ist ? Wie wäre es denn am einfachsten die Rules Schritt für Schritt zu verfolgen, ob sie korrekt ausgeführt werden?

    Sorry für die vielen dummen Fragen, aber irgendwie stehe ich grad komplett aufm schlauch :(

    Grüße

    Andreas

  • Puh ... ich würde jetzt mal warten ob sich hier einer einklinkt der sich mit FHEM auskennt... da hab ich wie gesagt keine Ahnung, wie und ob das dort abgefragt werden kann

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • ich bin wahrlich nicht unerfahren, was Programmierung etc angeht.

    Das ist schon mal richtig gut! Für mich kann ich (leider) nur sagen, dass ich im Moment keine Zeit habe, mich mit dem Deep Sleep Thema zu befassen. Deswegen kann ich mich derzeit nicht tiefer reinhängen. Aber wer FHEM einsetzt, ist doch eher ein Hardcore-Hausautomatisierer, dachte ich bislang. Über das von FHEM verwendete PERL wird man doch jede Menge machen können.

    Rules sind von HoerMirAuf im Forum-Wiki doch gut erklärt. Klicke einfach auf Rules.

    Dass der Austausch von Informationen über MQTT läuft/laufen soll ist doch super. Damit kannst du doch Nachrichten beliebigen Inhalts generieren und von Geräten bzw. Diensten subskribieren lassen, die dann alles weitere verlassen. Wie Hoermirauf schon schrieb ... publish was/auch/immer.


    Ich habe eben (ohne mich groß einzulesen) die Probleme durch die fehlende MQTT-Kommunikation während des Deep Sleeps gesehen. Denn auf der von mir angegebenen Seite steht ja:

    To use rules, use the System#Save trigger. This will be executed just before the device goes into deep sleep.


    Für Verhalten/Aktionen beim Systemstart hast du den Trigger on system#boot do .... endon.

    Für dauerhafte Variablen hast du mem1 bis mem5; für Laufzeitvariablen var1 bis var5.

    Die Systemvariable %value% speichert immer die gerade abgefragten Zustände oder Werte und kann den vorgenannten Variablen zugewiesen oder durch Vergleichsoperatoren wie <, >, !=, = ausgewertet werden.


    Ich hoffe mit diesen - zugegeben unkonkreten - Hinweisen habe ich dir für eigene Programmierung ein wenig die Richtung zeigen können. Mehr geht im Moment zeitlich bei mir nicht. Viel Glück!

  • Hallo Joerg,


    vielen herzlichen dank auch Dir noch mal für diese ausführliche Antwort.

    Ich bin ehrlicherweise sehr verwundert, dass ich scheinbar einer der ersten bin, die auf die Idee kommen, das umzusetzen 8| Daher war für mich der Aufwand der Umsetzung so wohl auch nicht erwartet, was aber nicht tragisch ist:

    To use rules, use the System#Save trigger. This will be executed just before the device goes into deep sleep.


    Für Verhalten/Aktionen beim Systemstart hast du den Trigger on system#boot do .... endon.

    Für dauerhafte Variablen hast du mem1 bis mem5; für Laufzeitvariablen var1 bis var5.

    System#Save trigger => hab ich bereits gelesen und für meine Testversuche bereits eingebunden

    system#boot etc ebenso.


    Wo ich Verständnisprobleme habe ist, sind die Sachen mit mem1-5 und var1-5 aber auch da hilft wohl nur lesen lesen lesen , bis ich es irgendwann doch richtig verstanden habe.

    Aber wer FHEM einsetzt, ist doch eher ein Hardcore-Hausautomatisierer, dachte ich bislang. Über das von FHEM verwendete PERL wird man doch jede Menge machen können.

    Genauso ist es ja. Ich kenne mich mit FHEM und Perl relativ gut aus und kann so hier schon recht viel umsetzen. Daher ist für mich der Weg den ich oben bereits genannt hab:

    ->deepsleep->aufwachen->Normaldurchlauf->"AWAKE" an Fhem melden -> von Fhem den Wunschzustand zugesandt bekommen -> erst nach Erhalt dieser weitermachen ->Fhem "SLEEP" melden -> und dann erst wieder in Deepsleep landen


    Das in FHEM umzusetzen erfordert allerdings auch einiges an hin und her springen (so mein bisheriges Verständnis dafür). Daher hatte ich gehofft, dass es irgendwie eine Möglichkeit gibt ein MQTT Befehl abzufragen / lesen und nicht nur zu senden.


    Vielleicht hängt sich noch jemand mit ran, der das schon mal gemacht hat ..... in der Zwischenzeit werde ich einfach mal weiter lesen gehen.

    Danke Euch beiden bis hierhin schon mal


    Grüße

    Andreas

  • Hallo Joerg,


    vielen herzlichen dank auch Dir noch mal für diese ausführliche Antwort.

    Ich bin ehrlicherweise sehr verwundert, dass ich scheinbar einer der ersten bin, die auf die Idee kommen, das umzusetzen 8| Daher war für mich der Aufwand der Umsetzung so wohl auch nicht erwartet, was aber nicht tragisch ist:

    To use rules, use the System#Save trigger. This will be executed just before the device goes into deep sleep.


    Für Verhalten/Aktionen beim Systemstart hast du den Trigger on system#boot do .... endon.

    Für dauerhafte Variablen hast du mem1 bis mem5; für Laufzeitvariablen var1 bis var5.

    System#Save trigger => hab ich bereits gelesen und für meine Testversuche bereits eingebunden

    system#boot etc ebenso.


    Wo ich Verständnisprobleme habe ist, sind die Sachen mit mem1-5 und var1-5 aber auch da hilft wohl nur lesen lesen lesen , bis ich es irgendwann doch richtig verstanden habe.

    Aber wer FHEM einsetzt, ist doch eher ein Hardcore-Hausautomatisierer, dachte ich bislang. Über das von FHEM verwendete PERL wird man doch jede Menge machen können.

    Genauso ist es ja. Ich kenne mich mit FHEM und Perl relativ gut aus und kann so hier schon recht viel umsetzen. Daher ist für mich der Weg den ich oben bereits genannt hab:

    ->deepsleep->aufwachen->Normaldurchlauf->"AWAKE" an Fhem melden -> von Fhem den Wunschzustand zugesandt bekommen -> erst nach Erhalt dieser weitermachen ->Fhem "SLEEP" melden -> und dann erst wieder in Deepsleep landen


    Das in FHEM umzusetzen erfordert allerdings auch einiges an hin und her springen (so mein bisheriges Verständnis dafür). Daher hatte ich gehofft, dass es irgendwie eine Möglichkeit gibt ein MQTT Befehl abzufragen / lesen und nicht nur zu senden.


    Vielleicht hängt sich noch jemand mit ran, der das schon mal gemacht hat ..... in der Zwischenzeit werde ich einfach mal weiter lesen gehen.

    Danke Euch beiden bis hierhin schon mal


    Grüße

    Andreas

  • die Sachen mit mem1-5 und var1-5

    mit mem1 bis mem5 hast du 5 Variablen, die einen Neustart und einen Spannungswegfall überstehen. var1 bis var5 sind nur in der aktuellen Laufzeit mit den zugewiesenen Werten verfügbar. Das "Merkwürdige" ist, dass die Benutzung der Variablen unbdingt in der Schreibweise %Mem1% bzw. %Var1% geschehen muss, also mit großem Anfangsbuchstaben.

    Beispiele z. B. für einen Temperatursensor:

    Du setzt eine dauerhafte Variable, indem du auf dem Kommandozeile Mem1 25 (oder mem1 25) eingibst. Beim Definieren ist die Groß-/Kleinschreibung egal. Die Variable Mem1 wird dauerhaft gespeichert, selbst wenn der Strom vom Gerät abgeklemmt wird.

    Du definierst eine rule z. B. rule1 on DHT11#Temperature >%Mem1% do publish Message/Geraet_1 zu_warm endon und natürlich rule1 1 zum Aktivieren. Beachte: Die Schreibweise bei der Benutzung von Mem1 muss %Mem1% sein (also mit großem M). Genauso verhält es sich mit var1 und Var1 - beim Setzen ist die Schreibweise egal, beim Benutzen geht nur %Var1%.


    Ich habe ein ganz anderes Problem bei, dem du mir vielleicht helfen kannst oder HoerMirAuf :

    Bei mir wird kein Gerät wieder wach, nachdem ich eine DeepSleepTime gesetzt habe (Tasmota 8.1.0). Ich habe es so verstanden:

    Wenn ich eine Teleperiod von 10 setze und eine DeepSleepTime von 60, dann geht das Gerät nach Ablauf der ersten Teleperiod für 60 Sekunden in den Deepsleep und meldet sich vorher per MQTT als Offline beim MQTT Broker ab. Nach 60 Sekunden wird es kurz wach, sobald es eine MQTT-Verbindung hat, setzt es eine Tele-Meldung ab (z. B. Sensordaten) und geht wieder in den Tiefschlaf (Quelle hier: https://tasmota.github.io/docs/#/DeepSleep ). Bei mir gehen die Geräte (getestet an Basic und S20) sofort in den Tiefschlaf, melden noch die korrekte Uhrzeit des Endes der DeepSleepTime aber bleiben im Tiefschlaf! Ich muss sie hart vom Netz nehmen, im Bootvorgang per MQTT den Befehl deepsleeptime 0 übermitteln, damit ich sie wieder bedienen/benutzen kann. Was mache ich falsch oder missverstehe ich dabei? (Oder muss ich ein eigenes Thema aufmachen?)

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

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • Das heißt, es geht tatsächlich nur über Hardware? Wirklich? Was soll denn das? Ich hatte diesen Satz durchaus gelesen hielt es aber für eine Option das Gerät aufzuwecken, ohne gleich an die Versorgungsspannung zu gehen. 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?

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

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

    Einmal editiert, zuletzt von HoerMirAuf ()

  • Moinsen,


    vielen Dank für Deine Erklärung Joerg ... so ist es jetzt viel einfacher, das nachzuvollziehen und zu verstehen :thumbup: Ich bin am WE wegen unserer Reisevorbereitungen nicht dazu gekommen, viel zu lesen. Aber ich denke das werde ich im Urlaub nachholen 8o


    Ich habe ein ganz anderes Problem bei, dem du mir vielleicht helfen kannst oder HoerMirAuf :

    Na toll... nu hab ich gedacht, ich könnte auch endlich mal helfen, nachdem mir schon einiges geholfen wurde und dann hört hoermirauf nicht in Turbo zu antworten :D


    Das heißt, es geht tatsächlich nur über Hardware? Wirklich? Was soll denn das? Ich hatte diesen Satz durchaus gelesen hielt es aber für eine Option das Gerät aufzuwecken, ohne gleich an die Versorgungsspannung zu gehen. 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?

    Genau das war der Grund warum ich "ewig" gebraucht habe um es einmal hin zu bekommen. Ich habe es tatsächlich exakt genauso verstanden, nämlich dass man es OPTIONAL über den GPIO16 / RST wecken kann, oder eben nach Ablauf der Zeit. Dass das eine aber zwingend für das andere nötig ist, habe ich auch erst vor meinem Eingangsposting und der dazu gehörenden Bastelei heraus gefunden...... Somit hast Du (leider) die Lösung, die Dich aber wahrscheinlich auch nicht glücklich macht..... ABER vielleicht verstehst Du sie genauso falsch wie ich vorher:
    Die Brücke kann / darf / muss dauerhaft drauf sein. Sie führt nicht dazu, dass Du das Gerät weckst, sondern, dass das Signal durchkommt. Also wenn Du Hardwaretechnisch an den GPIO16 kommst -> lösbar.


    Was für ein Gerät wäre das wo Du das machen wolltest?
    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 ;)

    Grüße

    Andreas

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

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • Nun würde ich gern (mit Hilfe einer Regel, oder .....? ) gern geräte schalten auch wenn der Chip im deepsleep ist, bzw danach

    Das heißt, dass das, was unser Freund flummy gerne hätte ("was machen, wenn im deepsleep") geht schlicht und einfach nicht. Es sei denn er hat den GPIO 16 mit einem Taster belegt, den er über ein anderes Gerät, das er aus FHEM steuert, drücken lässt, etwa wie in diesem lustigen Video dargestellt:

    https://youtu.be/dzrv3KNQR7c

    Was habe ich gelacht...


    Deutscher Text dazu hier:

    https://coolsten.de/fingerbot-roboter-adaprox-smart-home/


    Also, lieber flummy , du kannst zwar durch system#boot was beim Starten auslösen, aber wenn die Kiste im Deepsleep ist, geht nichts mehr bis auf die Benutzung des Triggers System#Save, mit dem du kurz vor dem Koma noch eine Meldung absetzen oder irgend eine andere Aktion auslösen kannst. Da hilft also nur der Fingerbot, den du per FHEM antriggerst, der einen Taster drückt, den du mit dem GPIO 16 und Ground (den 10 K Widerstand nicht vergessen) verbunden hast, um dein Gerät wieder aufzuwecken.

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

    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: BME280/BMP280/HC-SR501/HC-SR04/ACS712

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

  • # Edtih sagt: Hab zu lange gebraucht mit dem Abschicken, hat sich mir Hoermirauf überschnitten ;)


    Immerhing konnten wir Dir so auch helfen, Joerg... Wenn auch leider nicht mit dem entsprechendem Erfolg.....


    Aber nochmal onTopic:


    Mhmmm irgendwie werd ich das Gefühl nicht los, meine Ursprungsintention wurde falsch verstanden bzw interpretiert:

    Es ging mir nicht darum, dass ich von FHEM aus etwas steuere und es unmittelbar vom Gerät umgesetzt wird. Sondern es ging darum, dass in der Zeit in der das Tasmota Gerät schläft sich möglicherweise der Zustand ändern soll . Das soll dann beim Aufwachen erkannt werden und entsprechender Zustand erfolgen. Also alá:
    -> Deepsleep -> FHEM arbeitet weiter und stellt fest dass das Relais geschaltet werden soll -> Deepsleep läuft weiter -> Ablauf der Deepsleepzeit -> Gerät wacht auf und fragt den SOLL Zustand ab -> Entspricht der SOLL nicht dem IST , wird geschaltet -> Ablauft läuft weiter -> bist zu Deepsleepzeit -> DeepSleep -> usw .......


    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.


    Grüße

    Andreas