Beiträge von flummy

Hallo zusammen,

hier hat sich ja noch einiges getan... Finde ich gut. Zumindest dass einige andere auch etwas davon haben. Bei mir hat sich leider aus Zeitgründen diese Variante erstmal erledigt. Ich hab einfach nicht so viel Zeit wie ich gern basteln würde.... dabei habe ich schon extra bedacht, dass der Tag 24 Std hat und wenn es nicht reicht man ja die Nacht dazu nehmen könnte ... Reicht nicht
Egal ... Sobald ich wieder etwas Luft habe, werde ich mich auch dem wieder widmen und auch wenn ich es mittlerweile selbst ganz gut verstanden hab:

abudu Tolle Anleitung . Ich denke mal das ist für viele Verständlicher. Ich glaube da sollte allerdings mal ein Mod dran und das Ganze als normalen Beitrag oben anpinnen. Die PDF werden die wenigsten findn / öffnen. Ich finde sie gut

Viele Grüße

Andreas

Hallöchen,

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

Zitat von HoerMirAuf

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.

Zitat von JoergZ

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

# 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

Moinsen,

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

Zitat von JoergZ

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

Zitat von JoergZ

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

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 Daher war für mich der Aufwand der Umsetzung so wohl auch nicht erwartet, was aber nicht tragisch ist:

Zitat von JoergZ

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.

Zitat von JoergZ

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 Daher war für mich der Aufwand der Umsetzung so wohl auch nicht erwartet, was aber nicht tragisch ist:

Zitat von JoergZ

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.

Zitat von JoergZ

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

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:

Zitat von HoerMirAuf

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

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
Vielleicht hat ja noch jemand eine gute (bessere) Idee.

Grüße

Andreas

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

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

Grüße

Andreas

Hallöchen,

nachdem ich nun endlich mal bei einem ESP Chip erfolgreich den Deepsleep aktiviert habe (wer lesen kann ist klar im Vorteil ) , 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

Hallöchen zusammen,

hab mich extra registriert, weil ich hier noch mal den Beitrag reaktivieren muss.

Ich habe das gleiche Problem schon mal bei Shelly1 gehabt (dann aber mit anderer Firmware gelöst) nun habe ich heute meine - Beim Hersteller bestellten Shelly2.5 bekommen und mit der Einstellung das gleiche Problem ?

Manchmal bleibt der Haken drin, manchmal verschwindert er einfach von sich aus, nachdem ich die Daten übernommen habe. ABER in jedem Fall ist die Oberfläche ohne Passwortabgfrage erreichbar

Gibt es da irgendwie nen Bug ? Ist da was bekannt ?

Würde mich über Tipps und Hinweise sehr freuen.

Vielen Dank im Voraus

Grüße

Andreas