Beiträge von JoergZ

    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.

    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.

    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 :(.

    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.

    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.

    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.

    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?

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

    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!

    Was hast denn bei WifiConfig eingetragen?

    boris03 :

    Und hast du den Nummernbereich in deinem Router von der DHCP-Verwaltung ausgeschlossen?


    Was heiß das genau:

    bei einem Neustart des Routers nicht mehr verbinden, also im LAN nicht mehr erscheinen.

    Du kannst dann in einem Browser nach der Eingabe einer IP eines Gerätes die Weboberfläche nicht erreichen oder siehst du auf Übersichtsseiten des Routers deine Geräte nicht?

    Ich vermute mal, dein Thema ist besser in einem OpenHAB2-Forum aufgehoben. Mit der von OpenHAB verwendete Programmiersprache Java oder Java-Script(?), kannst du vermutlich alles hinbekommen, was du willst. Dein Vorhaben mit Rules abzubilden, dürfte komplizierter sein. Schau mal in die Rules. Trigger, die du sicher brauchst, sind (im Groben): onboot, ruletimer. Unklar ist was du mit folgendem meinst:

    NAch dem spannunglos machen soll ebenfalls eine Messung erfolgen.

    Wie soll das gehen? Ohne Strom nichts los...

    Kann's leider nicht praktisch überprüfen mangels Gerät, aber es gibt folgenden Trigger für Rules:

    RfReceived#Data

    der hexadezimale Signale auswertet. Wäre zu testen, ob deine Sender ihre Funksignale in diesem Format senden. Die allgemeine Form einer rule wäre dann:

    rule1 on  RfReceived#Data=0xE8329E do publish mach/was jetzt endon,

    wobei "mach/was" ein beliebiges MQTT-Topic und "jetzt" die Payload für das Topic wäre. Was du mit einer solchen Payload machst. steuerst du dann mit Skripten. Die Topics können auch realen Geräten entsprechen, die dann direkt gesteuert werden z. B. cmnd/Terrassenbeleuchtung/Power ON. Mehr dazu findest du in unserem Wiki zu Rules bzw. hier.

    rule1 on Power1#state=1 do backlog power1 %value%; status 8; ruletimer1 0.1 endon on rules#timer=1 do power1 off endon

    OK, habe allerdings festgestellt, dass mit einem Sonoff Basic (Firmware 8.1.0) - und vermutlich anderen Sonoff-Geräten - das Zeitfenstter ruletimer1 0.1 nicht funktioniert, sondern der Wert mindestens 1 sein muss.

    Gib mal noch ein paar Infos:

    • die Ausgabe von status 8 auf der Konsole bei aktiviertem Sensor und die entsprechende Meldung, die an den MQTT-Broker übermittelt wird
    • die Rule(s), die du bisher selbst aufgestellt hast