ESPEasy-Plugin "FHEM" / ESPEasy-Modul - deepSleep Command

[Elektrofreak]

Hallo zusammen,

ich habe neulich im letscontrollit-Forum gelesen, dass der deepSleep-Befehl mittlerweile per Hand (z.B. per Regel) ausgeführt werden kann.

https://www.letscontrolit.com/forum/viewtopic.php?f=4&t=5013

Ich habe schon lange nach einer Option gesucht, den ESP mit der ESPEasy-Firmware geflasht z.B. nachts oder wenn keiner zuhause ist in den Tiefschlaf zu versetzen. Dies könnte mit einem DOIF geschehen.

Da mittlerweile der deepSleep-Befehl Teil der ESPEasy-Firmware ist, würde ich vorschlagen, diesen Befehl in das entsprechende FHEM-Modul sowie in das ESPEasy-Plugin einzupflegen. Gibt es diese Möglichkeit?

Der Entwickler des ESPEasy-Moduls Dev0 hat auf eine Anfrage per PN gebeten, die Anfrage hier im Forum zu stellen.

Ich hoffe dass es noch weitere Interessenten und Vorschläge gibt 

[dev0]

Wenn der deepSleep Befehl über HTTP aufrufbar ist und nicht nur ESP intern verfügbar ist, dann baue ich das ein. Da ich momentan nicht zum Testen komme, könntest Du schon einmal ausprobieren welche URL dazu aufgerufen werden muss.
Ich vermute, dass es eine der beiden tun sollte, vermutlich die Erste:

Code Auswählen Erweitern


http://ip/?cmd=deepSleep,60
http://ip//control?cmd=deepSleep,60


Muss für diese Methode GPIO-16 und RST gebrückt sein?

[dev0]

@Elektrofreak: Kein Interesse mehr?

[BumpetyBoo]

http://ip//control?cmd=deepSleep,60 funktioniert nicht.
mit http://ip/?cmd=deepSleep,60 funktionierts.

GPIO-16 und RST müssen gebrückt sein.

Getestet mit einem Wemos D1 mini, geflasht mit version: mega-20180421 (ESP82xx Core 2_4_0)

Danke für den Hinweis Elektrofreak, nun kann ich den ESP von Fhem aus schlafen schicken. Die buildin Funktion geht wieder in den deepsleep bevor Daten an FHEM geschickt werden.

[dev0]

mit http://ip/?cmd=deepSleep,60 funktionierts.

OK, dann baue ich das bei Gelenheit ein.

Die buildin Funktion geht wieder in den deepsleep bevor Daten an FHEM geschickt werden.

Das scheint dann ein Bug in (Deiner?) ESPEasy Firmware Version zu sein. Zumindest mit R147+ wurden die Sensordaten, auch bei aktiviertem Sleep, über das FHEM Controller Plugin an FHEM übertragen.

[Porsti]

Hi,

spiele auch gerade mit der neuen Version von Easyesp und bin dabei auch über den deep sleep gestpolpert.
Wäre eine coole erweiterung wenn man den ESP nach abruf der Daten wieder für 5min schlafen schickt um ihn
für längere Zeit über Akku zu betrieben.

Habe zur Zeit die Version: Release mega-20180524

Gruß
Porsti

[dev0]

Eine neue Modulversion zum Testen habe ich hier bereitgestellt. Diese Version kennt das DeepSleep Command bereits. Diskussionen zum DeepSleep Befehl bitte in diesem Thread führen. Es können auch auch (beliebige?) Befehle via Attribut nachgerüstet werden.
Da ich den DeepSleep Befehl selbst zZ. nicht testen kann, wäre eine Rückmeldung hier hilfreich.

[dev0]

habe gerade die neue Version in fhem eingebunden und mal versucht den deepsleep zu testen.
Dabei ist mir aufgefallen das ich über das Modul keine Zeit mit angeben kann.

Das kann ich nicht nachvollziehen, zeige bitte ein verbose 5 log der bridge, wenn der Befehl gesendet wird.

Code Auswählen Erweitern


2018.05.30 19:45:58 1: PERL WARNING: Use of uninitialized value in lc at ./FHEM/34_ESPEasy.pm line 515.


Ist in der nächsten Version gefixed, hat aber auch keinen Einfluss auf den deepsleep Befehl.

[Porsti]

Hi,

hier ist der Log auszug mit verbose 5:

Code Auswählen Erweitern


2018.05.31 07:27:46 3: ESPEasy: set ESPEasy_Wetter_BMP180 deepsleep
2018.05.31 07:27:46 5: ESPEasy ESPEasy_Wetter_BMP180: set ESPEasy_Wetter_BMP180 deepsleep  (mappings done)
2018.05.31 07:27:46 5: ESPEasy ESPEasy_Wetter_BMP180: IOWrite($defs{ESPEasy_Wetter_BMP180}, $defs{ESPEasy_Wetter_BMP180}, deepsleep, )


und das hier kommt im log auf dem esp an:

Code Auswählen Erweitern


433624: Command: deepsleep


Ich vermute daher das keine Zeitangabe für den deepsleep übermittelt wird.

Über diesen Link klappt es:  http://ip/?cmd=deepSleep,60

Gurß & Danke
Porsti

[dev0]

Das ist zwar das Log vom Device und nicht von der Bridge, aber da fehlt bei Dir das erste Argument (die Zeitangabe). Ich verstehe jetzt aber was Du wohl meintest: In FHEMWEB konnte man keinen Argument angeben. Das habe ich jetzt behoben, ich hatte es nur über die Command Line getestet: "set xxx deepsleep 10"

Code Auswählen Erweitern


set KE deepsleep 10
2018.05.31 07:50:09.523 3: ESPEasy: set KE deepsleep 10
2018.05.31 07:50:09.524 5: ESPEasy KE: set KE deepsleep 10 (mappings done)
2018.05.31 07:50:09.524 5: ESPEasy KE: IOWrite($defs{KE}, $defs{KE}, deepsleep, 10)


Edit:
Nimm mal bitte die angehängte Version.
Die aktuelle Testversion befindet sich hier: https://forum.fhem.de/index.php?topic=88552

[Porsti]

Hallo dev0,

konnte es gerade erfolgreich testen!!!

Danke für deine Arbeit.

Großes Danke
Porsti

[dev0]

Entspricht der angegebene Wert Sekunden oder Minuten?

[Porsti]

Der Wert wird als sekunden übergeben

[MrTom]

Hallo zusammen

ich habs auch mal getestet und bei mir funktioniert der deepsleep als Kommando leider nicht. Als Ausgabe mit verbose 5 bekomme ich:

Code Auswählen Erweitern

2018.06.02 17:00:07.675 3: ESPEasy: set ESPEasy_ESP_Easy_Test_Temp_Hum deepsleep 10
2018.06.02 17:00:07.676 5: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: set ESPEasy_ESP_Easy_Test_Temp_Hum deepsleep 10 (mappings done)
2018.06.02 17:00:07.676 5: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: IOWrite($defs{ESPEasy_ESP_Easy_Test_Temp_Hum}, $defs{ESPEasy_ESP_Easy_Test_Temp_Hum}, deepsleep, 10)
2018.06.02 17:00:10.749 5: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: Received: ESP_Easy_Test_Temp_Hum::10.195.1.44::1::1::1::e||_lastError||10.195.1.44: Keine Route zum Zielrechner||0
2018.06.02 17:00:10.749 2: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: WARNING: 10.195.1.44: Keine Route zum Zielrechner
2018.06.02 17:00:18.051 5: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: Received: ESP_Easy_Test_Temp_Hum::10.195.1.70::1::1::1::i||unit||0||0|||i||sleep||0||0|||i||build||20102||0|||i||build_git||mega-20180524||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||Temperature||24.30||2|||r||Humidity||48.90||2
2018.06.02 17:00:18.051 2: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: RESOLVED: 10.195.1.44: Keine Route zum Zielrechner
2018.06.02 17:00:18.052 4: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: Temperature: 24.30
2018.06.02 17:00:18.052 4: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: Humidity: 48.90
2018.06.02 17:00:18.052 5: ESPEasy ESPEasy_ESP_Easy_Test_Temp_Hum: Internals: unit:0 sleep:0 build:20102 build_git:mega-20180524 build_notes: - Mega version:2 node_type_id:17: ESP Easy Mega


Wenn ich aber über http://ip/?cmd=deepSleep,60 den sleep antriggere, dann gehts wie gewünscht. (Auf dem fhem-system mit curl)

Ich verwende die ESP_Easy_mega-20180524_normal_ESP8266 und das im Thread bereit gestellte Modul. An meinem ESP habe ich einen DHT22 und eine Batterie-Spannungsmessung angeschlossen.

Gruss
Thomas

[Porsti]

Hi,

versuche doch mal eine längere Zeit.
Bei 10 sekunden ist der ja kaum im deepsleep und muss schon wieder aufwachen.
Mache es doch mal mit 60 sekunden.

Gruß
Porsti

[MrTom]

Hallo

danke für den Hint, aber ob 10 oder 60 Sekunden spielt in meinem Fall keine Rolle, da FHEM gemäss Log gar nicht zum ESP durchkommt. Was aber gemäss meinem Versuch mit curl auf dem fhem-system funktionieren sollte.

Weitere ideen?

Gruss
Thomas

[dev0]

Die Fehlermeldung ist eindeutig, die IP 10.195.1.44 ist nicht erreichbar.

[MrTom]

Ich habs gefunden  , ich musste die DEF mit der richtigen IP anpassen. Mein neues Device bekam eine neue IP vom DHCP.

Was aber interessant war, dass trotz falscher IP Werte empfangen wurden.

Danke für die Hilfe
Thomas

[Wernieman]

Naja .. senden konnter er doch .. auch mit einer anderen IP, oder?

[yersinia]

Hallo zusammen,
ich mach diesen Thread nochmal auf (oder soll ich einen neuen beginnen?).
Ich habe einen nodeMCU mit ESPEasy mega 20181015 geflasht und einen Lichtsensor drangehängt. Weiterhin habe ich einen DeepSleep mit 900 Sekunden eingestellt.
Das funktioniert auch alles soweit gut - ich empfange Daten in FHEM entsprechend.

Nun würde ich gern den DeepSleep Nachts auf 4200 Sekunden verlängern und Morgens wieder auf 900 Sekunden zurückstellen. Das Ganze würde ich gern über ein DOIF lösen - als Bedingung habe ich erstmal Twilight sr_naut und ss_naut verwendet.

Zum Spielen habe ich mal set <esp> deepsleep 900 abgesetzt. Der Log gab mir einen Fehler; klar, der ESP ist gerade im DeepSleep und daher nicht im WLAN.
Wie kann ich sicherstellen, dass der ESP Bereit ist, den Command zu empfangen? Kann ich das irgendwie abprüfen?
Oder wartet das ESP Modul bis der ESP sich meldet und sendet dann die Daten?

Im log hab ich folgendes stehen:

Code Auswählen Erweitern

2018.10.17 17:41:16 3: ESPEasy ESPEasy_ESP_Easy_01_LightSensor01: set ESPEasy_ESP_Easy_01_LightSensor01 deepsleep 900
2018.10.17 17:41:26 2: ESPEasy ESPBridge: connect to http://192.168.60.70:80 timed out [set ESPEasy_ESP_Easy_01_LightSensor01 deepsleep 900]
2018.10.17 17:41:26 2: ESPEasy ESPEasy_ESP_Easy_01_LightSensor01: WARNING: connect to http://192.168.60.70:80 timed out
2018.10.17 17:51:40 2: ESPEasy ESPEasy_ESP_Easy_01_LightSensor01: RESOLVED: connect to http://192.168.60.70:80 timed out
Um 17:51:40 ist der ESP kurz aus dem DeepSleep aufgewacht.

Danke im Voraus.

[RaspiLED]

Hi,
Ich würde eine rules verwenden,
Die a direkt auf dem espeasy läuft und b die aktuelle Uhrzeit zum Wechsel der deepsleep zeit verwendet.
Per fhem könnte ein attribut die dauer aufnehmen, welches in der rule ausgelesen wird!? Funde ich aber unnötig
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[dev0]

Wie kann ich sicherstellen, dass der ESP Bereit ist, den Command zu empfangen?

Vermutlich gar nicht: Zumindest vor einiger Zeit war es noch so, dass ESP Easy nach dem 'Aufwachen' die anstehenden Tasks abarbeitet und dann direkt wieder 'schlafen geht'. So habe ich es zumidnest damals verstanden/gelesen. Ein HTTP Request in dieser Zeit würde vmtl. nicht bearbeitet werden.

WENN das nicht so ist, dann könnte ich mir vorstellen, dass der 'FHEM HTTP' Connector etwas erweitert wird und ich das Modul entsprechend anpassen würde...

[Peteruser]

Hallo,
wenn gerade ein Messwert angekommen ist, dann ist das Teil doch online?
Oder auch ganz trivial mit Ping? https://wiki.fhem.de/wiki/Anwesenheitserkennung

Grüße Peter

[Wernieman]

Der ESP ist dann doch relativ schnell. Wenn die Meßwerte versendet wurde, ist er eigentlich schon wieder "schlafend". Da dürfte eine Anwesenheitserkennung immer etwas zu langsam sein ..

[dev0]

wenn gerade ein Messwert angekommen ist, dann ist das Teil doch online?

Und ist der ESP dann auch solange wach, dass ein eingehender Request verarbeitet würde und würden auch die dazugehören Antworten via Controller versendet werden?
Wenn Du mir im aktuellen Quellcode die Stelle dazu zeigst oder zumindest ein ESP Easy Firmware Maintainer das bestätigt, dann könnte man Deine Anforderung im Modul umsetzen.

[Peteruser]

Hallo,
nach diesem Link kann die Wachzeit eingestellt werden:
https://www.letscontrolit.com/forum/viewtopic.php?t=5240

Damit könnte dann genug Zeit für die Überprüfung vorhanden sein.

Peter

[dev0]

nach diesem Link kann die Wachzeit eingestellt werden:

Ab welcher Release ist das so, wo gibt es ein Image, dass ich flashen kann, um es testen zu können.

[yersinia]

Ab welcher Release ist das so, wo gibt es ein Image, dass ich flashen kann, um es testen zu können.

Ich hab die Version mega_20181015  und da ist es implementiert.
Die releases gibt es hier: https://github.com/letscontrolit/ESPEasy/releases

[dev0]

Hier findest Du eine Vorabversion, die auch Befehle an ESP Easy Knoten sendet, die deep sleep benutzen. Bitte testen.

[yersinia]

Super, ich probiere es mal aus (mit der neusten ESPEasy mega-20181127). Danke.

[yersinia]

Hi,
nachdem ich lange gebraucht habe, den ESP überhaupt aus dem DeepSleep wieder heraus zu bekommen (eine Powerbank kappt die Stromzufuhr wenn kein Verbraucher dran hängt, dann wacht der ESP mangels Strom nicht mehr auf), läuft der DeepSleep des ESP allerdings nun. Der DeepSleep ist auf 300 Sekunden eingestellt (Sleep Awake time ist auf 10 Sekunden gesetzt), aber ich kann den DeepSleep nicht anpassen und bekomme immer folgende Fehlermeldung:

Code Auswählen Erweitern

2019.01.06 19:00:00 3: ESPEasy ESPEasy_ESP_Easy_02_DHT22: set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600
2019.01.06 19:04:07 2: ESPEasy ESPBridge_TEST: read from http://192.168.60.71:80 timed out [set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600]
2019.01.06 19:04:07 2: ESPEasy ESPEasy_ESP_Easy_02_DHT22: WARNING: read from http://192.168.60.71:80 timed out
Na klar, der ESP hat sich in dieser Zeit wahrscheinlich nicht mehr gemeldet...

ESPEasy build ist mega-20181231.

Mir fehlt ein Ansatz den Fehler weiter einzugrenzen. Liegt es an FHEM, an dem Modul, an Armbian, am Router oder am ESP bzw dessen firmware. Wie könnte ich das eingrenzen?

[dev0]

Zeige lists von Bridge und Device nachdem Daten von dem ESP emfangen wurden und ein verbose 5 log, wenn der ESP erwacht und Daten schickt. Jeweils in code tags, bitte.

2019.01.06 19:00:00 3: ESPEasy ESPEasy_ESP_Easy_02_DHT22: set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600
2019.01.06 19:04:07 2: ESPEasy ESPBridge_TEST: read from http://192.168.60.71:80 timed out [set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600]

Du hast den deepsleep doch schon auf dem ESP aktiviert mit 300s, wenn ich Dich richtig verstanden habe. Warum willst Du dann, via deepsleep Befehl, auf 3600s ändern? Die Logeinträge sind in diesem Fall aber normal, da der ESP direkt nach dem deepsleep Befehl schlafen geht und keine Antwort mehr sendet, wie es das HTTP Protokoll vorsieht. Mmn sollte das in der ESP Easy Firmware gefixed werden. Ggf. könnte man die Logeinträge dazu noch unterdrücken.

[yersinia]

Danke dev0.
Meine Grundidee war, Nachts dem ESP ein größeres deepsleep Interval zu geben als Tagsüber. Ich möchte Helligkeistwerte ermitteln und benötige die Daten dann Nachts nicht so häufig - um Batterie zu sparen. (Der Test-ESP hat zu Testzwecken erstmal nur einen DHT22 dran) Tagsüber benötige ich dann ein 300 Sekunden Interval.

Nach meinem Verständnis nach, kann ich den deepsleep mode ansich nicht von Außen de/aktivieren - zumindest nicht mit der ESPeasy firmware, da ich ja GPIO16 und RST verbinden muss, sonst wacht der ESP nicht mehr selbstständig auf:

You need to connect GPIO-16 with the RST pin to make this work.

(Infos zu Sleep Mode)

Ich ging daher davon aus, dass ich das deepsleep intervall mit

Code Auswählen Erweitern

set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600
dynamisch verändern kann. Die Wachzeit bleibt gleich (derzeit bei 10s).

Ich sehe anhand der Rückmeldung der Daten, dass der Wert auch Nachts weiterhin alle 300s kommt, also hat der ESP anscheinend den deepsleep intervall nicht angepasst (die Theorie empfangen, umgesetzt aber nicht geantwortet scheint auch damit hinfällig zu sein).

Daher auch meine Frage in #19:

Wie kann ich sicherstellen, dass der ESP Bereit ist, den Command zu empfangen? Kann ich das irgendwie abprüfen?
Oder wartet das ESP Modul bis der ESP sich meldet und sendet dann die Daten?

Vielleicht ist aber auch mein Ansatz einfach nicht realisierbar weil zB die Firmware dies nicht ermöglicht!? 

List etc. reiche ich nach sofern ich wieder zuhause bin.

[dev0]

Ob der ESP Easy deepsleep Befehl zur Zeit korrekt funktioniert und/oder noch ein save (ins eeprom) benötigt wird oder sonst etwas, kann ich Dir nicht beantowrten. Zur Zeit wird aber an dem Befehl geschraubt. Sie aktuelle pull requests bzw. issues auf github.

Das ESPEasy FHEM Modul unterstützt in der aktuellen Version ESP Easy nodes im deep sleep mode, um Befehle in den Wachphasen an die ESPs zu senden. Wenn Du die Lists und Log geliefert hättest, dann könnte ich mehr zu Deinem Setup sagen. So leider nicht.

Edit:

zumindest nicht mit der ESPeasy firmware, da ich ja GPIO16 und RST verbinden muss

Das geht auch mit keiner anderen Firmware, afaik.

[yersinia]

wie versprochen hier die lists...

...von der Bridge:

Code Auswählen Erweitern

Internals:
   .AttrList  allowedIPs authentication:1,0 autocreate:1,0 autosave:1,0 combineDevices deniedIPs disable:1,0 disabledForIntervals do_not_notify:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading httpReqTimeout maxHttpSessions:0,1,2,3,4,5,6,7,8,9 maxQueueSize:10,25,50,100,250,500,1000,2500,5000,10000,25000,50000,100000 resendFailedCmd
   .bap       
   .bau       
   CONNECTS   775
   DEF        bridge 8383
   FD         4
   HOST       bridge
   IPV        4
   MAX_HTTP_SESSIONS 3
   MAX_QUEUE_SIZE 250
   NAME       ESPBridge_TEST
   NOTIFYDEV  global
   NR         17
   NTFY_ORDER 50-ESPBridge_TEST
   PORT       8383
   STATE      Initialized
   SUBTYPE    bridge
   TYPE       ESPEasy
   VERSION    2.14
   WARNING_192.168.60.71 read from http://192.168.60.71:80 timed out
   .attraggr:
   .attrminint:
   .clientArray:
     ESPEasy
   READINGS:
     2019-01-06 19:48:32   state           Initialized
   helper:
     awaked:
       192.168.60.71 0
     maxCmdDuration:
       192.168.60.71 1
     pm:
       Encode     1
       JSON       1
     sessions:
       192.168.60.71 0
Attributes:
   authentication 0
   combineDevices 0
   group      ESPEasy Bridge
   room       ESPEasy
   verbose    5


..vom Device:

Code Auswählen Erweitern

Internals:
   .AttrList  IODev Interval adjustValue colorpicker:RGB,HSV,HSVp deepsleep:0,1 disable:1,0 disableRiskyCmds disabledForIntervals displayTextEncode:1,0 displayTextWidth do_not_notify:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading mapLightCmds:lights,nfx maxCmdDuration:slider,0,0.25,15,1 parseCmdResponse pollGPIOs presenceCheck:1,0 readingPrefixGPIO readingSuffixGPIOState readingSwitchText:1,0,2 rgbGPIOs setState:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,25,50,100 useSetExtensions:0,1 userSetCmds:textField-long wwcwGPIOs
   DEF        192.168.60.71 80 ESPBridge_TEST ESP_Easy_02_DHT22
   ESPBridge_TEST_MSGCNT 259
   ESPBridge_TEST_TIME 2019-01-07 17:13:58
   ESP_BUILD  20103
   ESP_BUILD_GIT mega-20181231
   ESP_BUILD_NOTES  - Mega
   ESP_NODE_TYPE_ID ESP Easy Mega
   ESP_SLEEP  10
   ESP_UNIT   2
   ESP_VERSION 2
   HOST       192.168.60.71
   IDENT      ESP_Easy_02_DHT22
   INTERVAL   300
   IODev      ESPBridge_TEST
   LASTInputDev ESPBridge_TEST
   MAX_CMD_DURATION 1
   MSGCNT     259
   NAME       ESPEasy_ESP_Easy_02_DHT22
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-ESPEasy_ESP_Easy_02_DHT22
   PORT       80
   STATE      Hum: 58.9 Tem: 19.8
   SUBTYPE    device
   TYPE       ESPEasy
   VERSION    2.14
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-07 17:13:58   Humidity        58.9
     2019-01-07 17:13:58   Temperature     19.8
     2019-01-07 17:15:02   presence        present
     2019-01-07 17:15:02   state           Hum: 58.9 Tem: 19.8
   helper:
     fpc        1546800519
     pm:
       Encode     1
       JSON       1
     received:
       Humidity   1546877638
       Temperature 1546877638
   sec:
     admpwd     
Attributes:
   IODev      ESPBridge_TEST
   Interval   300
   group      ESPEasy Device
   presenceCheck 1
   readingSwitchText 1
   room       ESPEasy
   setState   3
   verbose    5

...und vom verbose 5 log:

Code Auswählen Erweitern

2019.01.07 17:13:58 4: Connection accepted from ESPBridge_TEST_192.168.60.71_49153
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Peer address 192.168.60.71 accepted
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Received content too small, awaiting more content: 549:395
POST /ESPEasy HTTP/1.1
Content-Length: 549
Host: 192.168.0.206:8383
User-Agent: ESP Easy/20103/Dec 31 2018 03:12:49
Connection: close

{"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"ESP_Easy_02","unit":2,"version":2,"build":20103,"build_notes":" - Mega","build_git":"mega-20181231","node_type_id":17,"sleep":10,"ip":"192.168.60.71"},"SENSOR":{"0":{"deviceName":"FHEM_ESP_TEST","valueName":"RSSI","type":7,"value":"31.0"},"1":{"deviceName":"FHEM_ESP_TEST","valueName":"FreeRAM","type":7,"value":"22032.0"},"2":{"device
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Peer address 192.168.60.71 accepted
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Received header: {'Host' => '192.168.0.206:8383','Content-Length' => 549,'User-Agent' => 'ESP Easy/20103/Dec 31 2018 03:12:49','Connection' => 'close'}
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Received content: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"ESP_Easy_02","unit":2,"version":2,"build":20103,"build_notes":" - Mega","build_git":"mega-20181231","node_type_id":17,"sleep":10,"ip":"192.168.60.71"},"SENSOR":{"0":{"deviceName":"FHEM_ESP_TEST","valueName":"RSSI","type":7,"value":"31.0"},"1":{"deviceName":"FHEM_ESP_TEST","valueName":"FreeRAM","type":7,"value":"22032.0"},"2":{"deviceName":"FHEM_ESP_TEST","valueName":"uptime","type":7,"value":"0.00"},"3":{"deviceName":"FHEM_ESP_TEST","valueName":"system_load","type":7,"value":"100"}}}}
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: No basic authentication required
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Send http close '200 OK'
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Src:'ESP_Easy_02'/'FHEM_ESP_TEST' => ident:ESP_Easy_02_FHEM_ESP_TEST dev:ESPEasy_ESP_Easy_02_FHEM_ESP_TEST combinedDevice:0
2019.01.07 17:13:58 5: ESPBridge_TEST: dispatch ESP_Easy_02_FHEM_ESP_TEST::192.168.60.71::1::1::1::r||sleepState||awaked for 10s (-1s): 1546877647.289||0
2019.01.07 17:13:58 5: ESPBridge_TEST: dispatch ESP_Easy_02_FHEM_ESP_TEST::192.168.60.71::1::1::1::i||unit||2||0|||i||sleep||10||0|||i||build||20103||0|||i||build_git||mega-20181231||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||uptime||0.00||7|||r||RSSI||31.0||7|||r||system_load||100||7|||r||FreeRAM||22032.0||7
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49153: Closing tcp session.
2019.01.07 17:13:58 4: Connection accepted from ESPBridge_TEST_192.168.60.71_49154
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Peer address 192.168.60.71 accepted
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Received header: {'Host' => '192.168.0.206:8383','Content-Length' => 374,'Connection' => 'close','User-Agent' => 'ESP Easy/20103/Dec 31 2018 03:12:49'}
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Received content: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"ESP_Easy_02","unit":2,"version":2,"build":20103,"build_notes":" - Mega","build_git":"mega-20181231","node_type_id":17,"sleep":10,"ip":"192.168.60.71"},"SENSOR":{"0":{"deviceName":"DHT22","valueName":"Temperature","type":2,"value":"19.8"},"1":{"deviceName":"DHT22","valueName":"Humidity","type":2,"value":"58.9"}}}}
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49154: No basic authentication required
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Send http close '200 OK'
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Src:'ESP_Easy_02'/'DHT22' => ident:ESP_Easy_02_DHT22 dev:ESPEasy_ESP_Easy_02_DHT22 combinedDevice:0
2019.01.07 17:13:58 5: ESPBridge_TEST: dispatch ESP_Easy_02_DHT22::192.168.60.71::1::1::1::i||unit||2||0|||i||sleep||10||0|||i||build||20103||0|||i||build_git||mega-20181231||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||Humidity||58.9||2|||r||Temperature||19.8||2
2019.01.07 17:13:58 5: ESPEasy ESPEasy_ESP_Easy_02_DHT22: Received: ESP_Easy_02_DHT22::192.168.60.71::1::1::1::i||unit||2||0|||i||sleep||10||0|||i||build||20103||0|||i||build_git||mega-20181231||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||Humidity||58.9||2|||r||Temperature||19.8||2
2019.01.07 17:13:58 4: ESPEasy ESPEasy_ESP_Easy_02_DHT22: Humidity: 58.9
2019.01.07 17:13:58 4: ESPEasy ESPEasy_ESP_Easy_02_DHT22: Temperature: 19.8
2019.01.07 17:13:58 5: ESPEasy ESPEasy_ESP_Easy_02_DHT22: Internals: unit:2 sleep:10 build:20103 build_git:mega-20181231 build_notes: - Mega version:2 node_type_id:ESP Easy Mega
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49154: Closing tcp session.
2019.01.07 17:13:58 4: Connection accepted from ESPBridge_TEST_192.168.60.71_49155
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Peer address 192.168.60.71 accepted
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Received header: {'User-Agent' => 'ESP Easy/20103/Dec 31 2018 03:12:49','Connection' => 'close','Content-Length' => 291,'Host' => '192.168.0.206:8383'}
2019.01.07 17:13:58 5: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Received content: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"ESP_Easy_02","unit":2,"version":2,"build":20103,"build_notes":" - Mega","build_git":"mega-20181231","node_type_id":17,"sleep":10,"ip":"192.168.60.71"},"SENSOR":{"0":{"deviceName":"VIN","valueName":"VIN","type":1,"value":"100.0"}}}}
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49155: No basic authentication required
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Send http close '200 OK'
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Src:'ESP_Easy_02'/'VIN' => ident:ESP_Easy_02_VIN dev:ESPEasy_ESP_Easy_02_VIN combinedDevice:0
2019.01.07 17:13:58 5: ESPBridge_TEST: dispatch ESP_Easy_02_VIN::192.168.60.71::1::1::1::i||unit||2||0|||i||sleep||10||0|||i||build||20103||0|||i||build_git||mega-20181231||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||VIN||100.0||1
2019.01.07 17:13:58 4: ESPEasy ESPBridge_TEST_192.168.60.71_49155: Closing tcp session.
2019.01.07 17:14:07 5: ESPBridge_TEST: dispatch ESP_Easy_02_FHEM_ESP_TEST::192.168.60.71::1::1::1::r||sleepState||sleep awaited in 1s: 1546877648.289||0
2019.01.07 17:14:08 5: ESPBridge_TEST: dispatch ESP_Easy_02_FHEM_ESP_TEST::192.168.60.71::1::1::1::r||sleepState||sleeping||0
2019.01.07 17:15:02 4: ESPEasy ESPEasy_ESP_Easy_02_DHT22: set statusRequest
2019.01.07 17:15:02 4: ESPEasy ESPEasy_ESP_Easy_02_DHT22: presence: present
2019.01.07 17:15:02 5: ESPEasy ESPEasy_ESP_Easy_02_DHT22: Start internalTimer +300 => 2019-01-07 17:20:02


[DasQ]

Man muss beachten, das in ESPEASY zweierlei verschiedene Deepsleep zum einsatz kommen.
Hab mich mit dem thema vor ein paar monaten, für einige wochen beschäftigt, um zu kapieren was die jungs da gebaut haben. Und zwar kann man von einem "ewigen" deepsleep und einem deepsleep auf "zeit" unterscheiden (glaub maximal 71minuten, links häng ich unten an).

wichtig ist aber mal grundsätzlich, um nicht vollenz wahnsinnig zu werden, das man sich ein "fallback zugang" einbaut. sonst kommt man schier garnicht mehr auf den esp. ich hab mir einen gpio gesetzt, der wenn low ist, in den rules den deepsleep auf zeit abfängt nach einem reset. sprich setz ich ein jumper auf gnd und resete schläft der esp nicht ein.

grundsätlich gings mir darum einen türkontakt an einer kellertür, mit einem LiPo Akku (18650) so lang als möglich laufen zu lassen. dabei bin ich zunächst zu blauäugig und gierig an die sache herangegangen und wollte noch parallel alle paar stunden/minuten die werte aus einem dht11(am2302)(temperatur und luftfeuchte sensor) per mqtt gesendet haben. das war/ist aber unfug und ich reduziere die akkulaufzeit von bis zu über einem jahr, auf wenige tage. das wollt ich eigentlich nicht und hab mich wie zuvor schon geschieben mit der materie näher befasst.

also es ging mir primär, um so wenig als möglich strom zu verbrauchen. dazu habe ich erstmal recherchiert wie ich das anstelle. den eingesetzten wemos D1 (clone) hab ich auf lowpower umgerüstet, in dem ich den spannungsregler gegen einen ldr regler tauschte (bild mit dem schwarzen kästchen und den kondensatoren). den programmieradapter ch340 hab ich gekappt. die satatus led entlötet.
das alles hat dazu gesorgt, dass mein esp jetzt im deepsleep nur noch ca. 17uA strom zieht. (rundungs und messfehler vom multimeter inkls)
der hacken an der sache, ich kann damit echt nur ein wakeup und den analogwert vom akku erkennen, für mehr reichts nicht, denn der geht sofort wieder schlafen ... übern daumen, minimal nach 3-4 sekunden. (habs jetzt auf fixe 10 sekunden eingestellt)
klar man braucht auch noch was um zu registrieren wieviel steckt denn eigentlich noch in dem akku. dazu habe ich per spannungsteiler, die spannung des akkus am netzteil vorbei an den analog input vom ESP gezogen. dafür reicht die zeit mit hängen und würgen.

ich hab ne zeitlang gesucht um ne schaltung zu finden, die auf reset und zeit funktioniert. muss mal suchen wo ich den link vergraben hab, wenn ich ihn nicht find zeichne ichs per frizing selbst.

Code Auswählen Erweitern

On MQTT#Connected Do //when the broker is connected
If [nosleep#sleepstate]=1
  publish /%sysname%/mode,"Deepsleep aktiv"
  timerSet,1,1
  timerSet,2,10
Else
  publish /%sysname%/mode,"Deepsleep deaktiv"
  timerSet,1,1
EndIf
EndOn

on nosleep#sleepstate=1 do
  timerSet,1,1
  timerSet,2,10
endon

On Rules#Timer=1 Do
  publish /%sysname%/Batterie,[battery#Batterie]
  Publish /%sysname%/systemname,%sysname%
  Publish /%sysname%/ip,%ip%
  Publish /%sysname%/RSSI,%rssi%
EndOn

On Rules#Timer=2 Do
  deepsleep,4294 // eine stunde elf
EndOn

https://www.letscontrolit.com/wiki/index.php/SleepMode  <-- deepsleep auf zeit
https://www.letscontrolit.com/forum/viewtopic.php?t=5240 <-- config in espeasy!!!
https://www.letscontrolit.com/wiki/index.php/EasyNotifications <-- deepsleep für immer / wakeup per reset

[dev0]

wie versprochen hier die lists...

Ich kann nicht erkennen, das auf FHEM-Seite etwas nicht korrekt funktioniert: Dein ESP meldet sich korrekt mit "sleep":10 (ab diesem Moment ist er für ~10s erreichbar). Die Daten werden auch an das logische Device weitergeleitet (dispatch). Ob die Daten korrekt im logischen Modul verarbeitet werden (davon gehe ich aus) kann ich nicht erkennen, da das Log die Daten von "ESPEasy_ESP_Easy_02_FHEM_ESP_TEST" zeigt, das list aber von "ESPEasy_ESP_Easy_02_DHT22" ist (Edit: hatte nicht weit genug geschaut). Weiterhin vermute ich, dass das Log nicht vollständig ist, da mir zwischen 17:14:08 und 17:15:02 Einträge fehlen (Setzen der Readings).

@DasQ: Vielen Dank für Deine Erläuterung.

[yersinia]

Weiterhin vermute ich, dass das Log nicht vollständig ist, da mir zwischen 17:14:08 und 17:15:02 Einträge fehlen (Setzen der Readings).

Der Log ist ungekürzt und genauso kopiert aus dem FHEM log. Mehr gab es nicht.

[dev0]

Mehr gab es nicht.

Und alle ESPEasy Devices bzw global war auf verbose 5 gesetzt? Kann ich nicht nachvollziehen.

[yersinia]

Und alle ESPEasy Devices bzw global war auf verbose 5 gesetzt? Kann ich nicht nachvollziehen.

Nein, weder global verbose 5 noch alle ESP Devices. Nur die Bridge und das betreffende eine ESP Device hatte ich auf verbose 5 gesetzt gehabt. War wohl ein Missverständnis meinerseits. >.<

[DasQ]

so den schaltplan bin ich noch schuldig, leider sagt mir das posting oben, das bild wär zu gross .... mit sein 360kb, wärs angeblich über 10mb groß.

[Wernieman]

Ist für Deine Beschreibung (D8=High) die Diode nicht verkehrt herum?

[DasQ]

das ist nicht D8, sondern D0
der high pegel von rst muss an D0 anliegen, sonst geht kein deepsleep, wird rst auf ground gezogen, resettet der esp.


der hats ähnlich gemacht
https://diyprojects.io/esp8266-deep-sleep-mode-test-wake-pir-motion-detector/#.XDuIqfyNzmE

[Klaus0815]

Habe das Thema gerade gefunden und bin neugierig geworden - was stellt Ihr mit dem deep sleep an?
Mir ist klar was er ESPEasy-intern macht, und das man damit Batterieleistung sparen kann

Aber was ist der Sinn, das von FHEM aus zu triggern?

Das einzige was mir einfällt, wäre sicher zu gehen das erst nachdem ein Wert von FHEM definitiv empfangen wurde, FHEM das deep sleep auslöst?

An welche Szenarien denkt ihr, wo das nützlich sein könnte?

[yersinia]

Ich für meinen Teil denke an folgendes Scenario (hatte ich weiter oben schon einmal beschrieben):

Ich habe einen nodeMCU mit ESPEasy mega 20181015 geflasht und einen Lichtsensor drangehängt. Weiterhin habe ich einen DeepSleep mit 900 Sekunden eingestellt.
Das funktioniert auch alles soweit gut - ich empfange Daten in FHEM entsprechend.

Nun würde ich gern den DeepSleep Nachts auf 4200 Sekunden verlängern und Morgens wieder auf 900 Sekunden zurückstellen. Das Ganze würde ich gern über ein DOIF lösen - als Bedingung habe ich erstmal Twilight sr_naut und ss_naut verwendet.

Wenn ich das, sagen wir dynamisch, von FHEM aus steuern kann, dann kann ich in der Winterzeit mehr Batterie sparen als im Sommer. Ich könnte auch die Auslesefrequenz der Helligkeit tagsüber erhöhen, im Sommer wird man das kaum benötigen.

Weitere Idee, die mir vorschwebt ist eine Füllstandsanzeige der Regenwasserzisterne. Wenn es nicht regnet, könnte man die Auslesefrequenz höher lassen, wenn es regnet aber verringern (statistische Zwecke).

[dev0]

Um ggf. ein paar Unklarheiten auszuräumen:

Ein ESP, der keinen deepsleep via ESP Config nutzt, geht via deepsleep Befehl für die angegebene Zeit in den deepsleep. Möchte man, dass der ESP nach den entsprechenden Datenübertragungen immer wieder schlafen geht, dann muß immer wieder deepsleep als Befehl aufgerufen werden.
Ich habe das gerade getestet und es funktioniert bei mir so wie es soll. GPIO16 und RST sind natürlich verbunden, sonst funktioniert das deepsleep auf dem ESP nicht. Das hat nichts mit der ESP Easy Firmware oder ESPEasy Modul noch ggf. mit MQTT zu tun.

Code Auswählen Erweitern


2019.01.14 09:06:13.349 4: ESPEasy em1: Humidity: 49.80
2019.01.14 09:07:13.348 4: ESPEasy em1: Humidity: 49.90
2019.01.14 09:08:13.344 4: ESPEasy em1: Humidity: 49.80
2019.01.14 09:09:13.348 4: ESPEasy em1: Humidity: 49.60
2019.01.14 09:10:13.344 4: ESPEasy em1: Humidity: 49.70
2019.01.14 09:11:13.349 4: ESPEasy em1: Humidity: 49.60

2019.01.14 09:11:14.072 3: ESPEasy em1: set em1 deepsleep 180
2019.01.14 09:11:24.221 2: ESPEasy eb: read from http://192.168.30.146:80 timed out [set em1 deepsleep 180]
2019.01.14 09:11:24.222 2: ESPEasy em1: WARNING: read from http://192.168.30.146:80 timed out
2019.01.14 09:14:10.821 2: ESPEasy em1: RESOLVED: read from http://192.168.30.146:80 timed out

2019.01.14 09:14:11.108 4: ESPEasy em1: Humidity: 49.80
2019.01.14 09:15:04.081 4: ESPEasy em1: Humidity: 49.80

Wenn man das automatisieren will, dann muss man ein zB. notify auf einen empfangenen Wert triggern lassen und den deepsleep Befehl mit einer entsprechenden Verzögerung und Zeit aufrufen. Liefern mehere ESP Firmware Devices Daten, dann auf Werte des ESP Device triggern, dass die Werte zuletzt liefert, sonst kappt der ESP die Verbindung. Das ist in der ESP Easy Firmware mMn verbesserungswürdig.

Wenn der ESP bereits den deepsleep nutzt, dann kann man in den Wachphasen den deepsleep Befehl nutzen, um die nächste Schlafphase zu ändern. Will man das über einen gewissen Zeitraum machen, dann kann man zB. auf "sleepState: awaked for.*" triggern und den deepsleep Befehl aufrufen lassen (via notify etc.). In diesem Beispiel ist sleep auf 120/10 eingestellt und wird via deepsleep Befehl für 240s schlafengelegt:

Code Auswählen Erweitern


2019.01.14 09:48:41.526 4: ESPEasy em1: sleepState: awaked for 10s (-1s): 1547455730.52595
2019.01.14 09:48:41.811 4: ESPEasy em1: Humidity: 49.90
2019.01.14 09:48:50.527 4: ESPEasy em1: sleepState: sleep awaited in 1s: 1547455731.52595
2019.01.14 09:48:51.527 4: ESPEasy em1: sleepState: sleeping

2019.01.14 09:50:51.743 4: ESPEasy em1: sleepState: awaked for 10s (-1s): 1547455860.7424
2019.01.14 09:50:52.027 4: ESPEasy em1: Humidity: 50.20

2019.01.14 09:50:55.958 3: ESPEasy em1: set em1 deepsleep 240

2019.01.14 09:51:00.744 4: ESPEasy em1: sleepState: sleep awaited in 1s: 1547455861.7424
2019.01.14 09:51:01.744 4: ESPEasy em1: sleepState: sleeping
2019.01.14 09:51:05.968 2: ESPEasy eb: read from http://192.168.30.146:80 timed out [set em1 deepsleep 240]
2019.01.14 09:51:05.968 2: ESPEasy em1: WARNING: read from http://192.168.30.146:80 timed out
2019.01.14 09:54:53.352 2: ESPEasy em1: RESOLVED: read from http://192.168.30.146:80 timed out

2019.01.14 09:54:53.352 4: ESPEasy em1: sleepState: awaked for 10s (-1s): 1547456102.35139
2019.01.14 09:54:53.636 4: ESPEasy em1: Humidity: 50.50
2019.01.14 09:55:02.352 4: ESPEasy em1: sleepState: sleep awaited in 1s: 1547456103.35139
2019.01.14 09:55:03.352 4: ESPEasy em1: sleepState: sleeping

2019.01.14 09:57:05.881 4: ESPEasy em1: sleepState: awaked for 10s (-1s): 1547456234.88095
2019.01.14 09:57:06.168 4: ESPEasy em1: Humidity: 50.50
2019.01.14 09:57:14.882 4: ESPEasy em1: sleepState: sleep awaited in 1s: 1547456235.88095
2019.01.14 09:57:15.882 4: ESPEasy em1: sleepState: sleeping


[dev0]

Die Logmeldungen bzgl. Timeout beim deepslep Befehl werden, mit der aktuellen Modulversion (rev.18288/v2.16), nicht mehr ins Log geschrieben.

[Raspi-lars]

Hallo Zusammen,

ich versuche gerade einen ESP8266 Wemos d1 mini als Batteriebetriebenen Lichtsensor einzusetzen. Hierfür verwende ich ESPEasy Build 20111 - Mega.

Der Sensor und der ESP funktionieren so auch einwandfrei. Nun versuche ich, den Sensor nachts mit einem größeren Deepsleep zu versehen als Tagsüber. Dies würde ich gerne über das ESPEasy- Plugin erschlagen. Leider funktioniert

Code Auswählen Erweitern

set espeasy-sensor deepsleep 120 bei mir nicht. Daraufhin habe ich dann

Code Auswählen Erweitern

http://<espeasyip>/control?cmd= deepsleep,120 ausprobiert. Als Rückmeldung kam die  Meldung: Command unknown: deepsleep,120.  GPIO16 auf RST ist gebrückt

Kann es sein, das im aktuellen Build die Möglichkeit nicht mehr vorhanden ist, oder liegt der Fehler auf meiner Seite?

Gruß
Lars

[andies]

Das Kommando funktioniert bei mir insofern, dass die Weboberfläche nicht mehr erreichbar ist. Danach erschien

Code Auswählen Erweitern

Unknown or restricted command!
Der Stromverbrauch bleibt aber die ganze Zeit konstant - und das ist ja der Sinn der Übung. Ich nehme auch EspMega.

PS Im Logfile des ESP jetzt auf einmal

Code Auswählen Erweitern

227786: HTTP: deepsleep,120
227789: Command: deepsleep
227794: Command unknown: 'deepsleep,120'
242350: WD : Uptime 5 ConnectFailures 0 FreeMem 22512 WiFiStatus 3
259312: SLEEP: Entering deep sleep in 30 seconds.
259313: EVENT: System#NoSleep=30

[andies]

Bin zu Tasmota gewechselt. Das läuft stabil.

[Raspi-lars]

Hallo andies,

ich schau mir die Tasmato Firmware mal an. Könnte interessant sein
Danke für den Hinweis.

Gruß
Lars

[andies]

Noch eine Ergänzung. Da zitiere ich mich mal, denn das ist auch so ein Klassiker

...Wemos: Hier muss man ein wenig aufpassen. An sich stellt espressif eine Spezifikation bereit, wie der ESP auf einem Board anzusteuern ist. Ich habe inzwischen gelernt, dass es neben den Qualitätsherstellern wie zB Lolin auch Anbieter in China gibt, die von diesen Spezifikationen ein wenig abweichen. Da sind dann keine 10k Widerstände da, ok, nimmt man halt 100k, die sind noch vor Ort. Das Ergebnis kann (muss aber nicht) sein, dass der Wemos oder besser der Clon viele Dinge kann, aber bei anderen unerklärlicherweise ausfällt. Mir ist das gerade beim deepsleep passiert - der ging einfach nicht. Zwei Dinge stören da besonders. Erstens ist es nicht ein kleiner Händler, der den Mist verklickert. Vielmehr kann es sein, dass dieser falsch spezifizierte Clone tausendfach (!) produziert wurde und von vielen Händlern über einen langen Zeitraum angeboten wird. Man kauft dann einen Monat später bei einem völlig anderen Händler (selbst bei conrad habe ich das erlebt), um denselben Fehler wieder festzustellen. Zweitens merkt man das Problem zwar, denkt aber im worst case daran, man selbst sei hier der Idiot. Also kurz gesagt: Wenn irgendwas nicht so geht, wie es soll und man alles durchprobiert hat, bitte den Clone entsorgen oder eben gleich ein Markenboard (Lolin beispielsweise) kaufen. Kostet dann paar Euro mehr.

Also wenn Du alles richtig machst und es trotzdem nicht geht, kann es auch am Wemos liegen!

[Wernieman]

Wobei aber die Angedeutete Lösung: "Markenboard (Lolin beispielsweise) kaufen. Kostet dann paar Euro mehr.", leider nicht die Lösung ist. Das "Problem" kann alle betreffen ....

[Udomatic]

Hallo,

ich verwende einen D1 mini an einer Powerbank und möchte deepSleep nutzen, um Strom zu sparen.
Habe bedenken, dass nach Aktvierung des deepSleep, der D1 nicht mehr aufwacht, wegen der Powerbank.

Weiss jemand, ob deepSleep mit einer Powerbank funktioniert?

Gruß
Udo