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 (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 :)
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:
http://ip/?cmd=deepSleep,60
http://ip//control?cmd=deepSleep,60
Muss für diese Methode GPIO-16 und RST gebrückt sein?
@Elektrofreak: Kein Interesse mehr?
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.
Zitatmit http://ip/?cmd=deepSleep,60 funktionierts.
OK, dann baue ich das bei Gelenheit ein.
ZitatDie 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.
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
Eine neue Modulversion zum Testen habe ich hier (https://forum.fhem.de/index.php/topic,73949.msg806052.html#msg806052) 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.
Zitat von: Porsti am 30 Mai 2018, 19:51:13
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.
Zitat
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.
Hi,
hier ist der Log auszug mit verbose 5:
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:
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
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"
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
Hallo dev0,
konnte es gerade erfolgreich testen!!!
Danke für deine Arbeit.
Großes Danke
Porsti
Entspricht der angegebene Wert Sekunden oder Minuten?
Der Wert wird als sekunden übergeben
Hallo zusammen
ich habs auch mal getestet und bei mir funktioniert der deepsleep als Kommando leider nicht. Als Ausgabe mit verbose 5 bekomme ich:
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
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
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
Die Fehlermeldung ist eindeutig, die IP 10.195.1.44 ist nicht erreichbar.
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
Naja .. senden konnter er doch .. auch mit einer anderen IP, oder?
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:
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.
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, ...
ZitatWie 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...
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
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 ..
Zitatwenn 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.
Hallo,
nach diesem Link kann die Wachzeit eingestellt werden:
https://www.letscontrolit.com/forum/viewtopic.php?t=5240 (https://www.letscontrolit.com/forum/viewtopic.php?t=5240)
Damit könnte dann genug Zeit für die Überprüfung vorhanden sein.
Peter
Zitatnach 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.
Zitat von: dev0 am 25 Oktober 2018, 13:04:11
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
Hier (https://forum.fhem.de/index.php/topic,93604.0.html) findest Du eine Vorabversion, die auch Befehle an ESP Easy Knoten sendet, die deep sleep benutzen. Bitte testen.
Super, ich probiere es mal aus (mit der neusten ESPEasy mega-20181127). Danke.
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:
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?
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.
Zitat
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.
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:
ZitatYou need to connect GPIO-16 with the RST pin to make this work.
(Infos zu Sleep Mode (https://www.letscontrolit.com/wiki/index.php/SleepMode))
Ich ging daher davon aus, dass ich das deepsleep intervall mit
set ESPEasy_ESP_Easy_02_DHT22 deepsleep 3600dynamisch 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 (https://forum.fhem.de/index.php/topic,85970.msg846899.html#msg846899):
ZitatWie 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.
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:Zitatzumindest nicht mit der ESPeasy firmware, da ich ja GPIO16 und RST verbinden muss
Das geht auch mit keiner anderen Firmware, afaik.
wie versprochen hier die lists...
...von der Bridge:
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:
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:
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
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.
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
Zitat von: yersinia am 07 Januar 2019, 17:20:21
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.
Zitat von: dev0 am 12 Januar 2019, 07:46:30Weiterhin 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. :(
ZitatMehr gab es nicht.
Und alle ESPEasy Devices bzw global war auf verbose 5 gesetzt? Kann ich nicht nachvollziehen.
Zitat von: dev0 am 12 Januar 2019, 14:58:15
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. >.<
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ß.
Ist für Deine Beschreibung (D8=High) die Diode nicht verkehrt herum?
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
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?
Ich für meinen Teil denke an folgendes Scenario (hatte ich weiter oben schon einmal beschrieben):
ZitatIch 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).
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.
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:
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
Die Logmeldungen bzgl. Timeout beim deepslep Befehl werden, mit der aktuellen Modulversion (rev.18288/v2.16), nicht mehr ins Log geschrieben.
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 set espeasy-sensor deepsleep 120 bei mir nicht. Daraufhin habe ich dann 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
Das Kommando funktioniert bei mir insofern, dass die Weboberfläche nicht mehr erreichbar ist. Danach erschien
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
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
Bin zu Tasmota gewechselt. Das läuft stabil.
Hallo andies,
ich schau mir die Tasmato Firmware mal an. Könnte interessant sein
Danke für den Hinweis.
Gruß
Lars
Noch eine Ergänzung. Da zitiere ich mich mal, denn das ist auch so ein Klassiker
Zitat von: andies am 26 Februar 2021, 15:40:37
...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!
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 ....
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