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

Begonnen von Elektrofreak, 19 März 2018, 20:22:20

Vorheriges Thema - Nächstes Thema

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:
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?
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

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.

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.

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:
ZitatYou 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
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:
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.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

dev0

#33
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.

yersinia

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
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

DasQ

#35
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
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

dev0

#36
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.

yersinia

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. :(
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

dev0

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

yersinia

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. >.<
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

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ß.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Wernieman

Ist für Deine Beschreibung (D8=High) die Diode nicht verkehrt herum?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

DasQ

#42
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

Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

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):
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).
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl