ESPEasy (20200608) und deep sleep modus

Begonnen von aw, 24 Juni 2020, 08:36:50

Vorheriges Thema - Nächstes Thema

aw

Hallo
ich betreibe den ESPEasy mega (aktuell mit 20200608) mit fhem bridge connection als Überwachung von Hörmann Garagentoren. Im Prinzip funktioniert das prima, auch die eingebundene WhatsApp Benachrichtigung.
Allerdings habe ich das Problem, dass sobald ich den ESPEasy im Deep sleep Modus betreibe, er nach ca. 4-5 Tagen einfach hängen bleibt. Ich muss ihn dann kurz vom Netz trennen, danach läuft alles wie gehabt. Es erscheint mir, als ob irgendwie ein interner Speicher im Wemos D1 "vollläuft". Sobald ich den Deep sleep deaktiviere, kann ich das Verhalten nicht feststellen.
Da ich in diesem Zustand nicht mehr auf den ESPEasy zugreifen kann, ist es schwierig weiter zu forschen.
Habt Ihr Erfahrungen dazu oder gute Tipps um das fehlerhafte Verhalten weiter einzugrenzen?
VG

steffen83

Hallo, ich kann die bei deinem Problem nicht weiterhelfen aber mich würde interessieren wie oder ob du diese WhatsApp Benachrichtigung nur über den Wemos läuft.
Raspberry Pi 3 (Noobs, aktuelle Fhem und Pilight) | FHEMduino | HM-OCCU-SDK | HM-Sec-SCo | HM-Sec-SD-2 | HM-CC-RT-DN | HM-LC-Bl1PBU-FM

aw

WhatsApp läuft auf einem Raspberry und da über FHEM. Also FHEM wertet über ESPEasy die Bewegungen des Tors aus und sendet dann Messages. Ist ein nice-to-have feature und eigentlich aus Spass entstanden.

parabacus

Hallo!
Ich hab immer wieder ähnliche Probleme mit Verbindungs-Verlusten.
Eine Lösung bzw. ein 100%iges Analyse-Ergebnis hab ich auch nicht, bin aber der Meinung, dass das großteils an der WLAN-Verbindungs-Qualität liegt. Ich hab aktuell 7 WEMOS D1 im Einsatz und die, die sende-/empfangs-technisch kritisch sind, verabscheiden sich hin und wieder (derzeit nur einer) und nach einem Reset sind sie sofort wieder da. Ich hab auch schon mal mit zyklischen Resets experimentiert, was eine kleine Verbessung der Verfügbarkeit gebracht hat.
Bei einem Device war die Ursache aber auch noch anders. Ich hab in dem Fall einen RF-ID-Leser per I2C dran und hatte andere Pins als vorgeschlagen genutzt. Seit ich das geändert habe, ist dieser nie mehr ausgefallen.

Btw. - Benachrichtigungen schicke ich mir auch zu (auch zur Garagentor-Position/Status  ;D) - allerdings mach ich das per Telegram.
Ich hab dazu einen WEMOS mit induktiven Sensoren zur Positions-Ekennung und werte die Statusinfo über FHEM aus. Dann hab ich noch einen Telegram-Bot, über den ich mir dann aus FHEM Nachrichten senden kann. Seit gestern klappt's auch noch mit der Sprachausgabe auf'm Smartphone, das die Telegram-Nachrichten bekommt. Dazu hab ich eine App (Notification Listener), die die Telegram-Nachricht filtert und über eine Tasker-Regel wird dann die Sprach-Nachricht ausgegeben.

Braucht man nicht - ist aber cool...  ;D 8)
Stiebel Eltron LWZ 504 / FHEM auf Rasperry Pi 3 / THZ / Weather / TABLETUI / SB_SERVER / SB_PLAYER  / OBIS / Verkehrsinfo / speedtest / Presence / FRITZ / ZWDongle / ZWAVE / Calendar / CALVIEW/ IPCAM/ ABFALL / ESPEasy

aw

Zitat von: parabacus am 24 Juni 2020, 12:01:43
Hallo!
Ich hab immer wieder ähnliche Probleme mit Verbindungs-Verlusten.
Eine Lösung bzw. ein 100%iges Analyse-Ergebnis hab ich auch nicht, bin aber der Meinung, dass das großteils an der WLAN-Verbindungs-Qualität liegt. Ich hab aktuell 7 WEMOS D1 im Einsatz und die, die sende-/empfangs-technisch kritisch sind, verabscheiden sich hin und wieder (derzeit nur einer) und nach einem Reset sind sie sofort wieder da. Ich hab auch schon mal mit zyklischen Resets experimentiert, was eine kleine Verbessung der Verfügbarkeit gebracht hat.
Bei einem Device war die Ursache aber auch noch anders. Ich hab in dem Fall einen RF-ID-Leser per I2C dran und hatte andere Pins als vorgeschlagen genutzt. Seit ich das geändert habe, ist dieser nie mehr ausgefallen.

Btw. - Benachrichtigungen schicke ich mir auch zu (auch zur Garagentor-Position/Status  ;D) - allerdings mach ich das per Telegram.
Ich hab dazu einen WEMOS mit induktiven Sensoren zur Positions-Ekennung und werte die Statusinfo über FHEM aus. Dann hab ich noch einen Telegram-Bot, über den ich mir dann aus FHEM Nachrichten senden kann. Seit gestern klappt's auch noch mit der Sprachausgabe auf'm Smartphone, das die Telegram-Nachrichten bekommt. Dazu hab ich eine App (Notification Listener), die die Telegram-Nachricht filtert und über eine Tasker-Regel wird dann die Sprach-Nachricht ausgegeben.

Braucht man nicht - ist aber cool...  ;D 8)

Ich vermute auch, dass es mit dem Wlan selbst zu tun hat, d.h. dass der Wemos beim hochfahren nicht schnell genug die Verbindung aufbauen kann und sich dann irgendwie verrennt. Evtl liegt es an wechselnden Kanälen, die vom Router seit der letzten Verbindung vor dem Deep sleep gewechselt wurden. Es wundert mich eben, dass ich im Dauerbetrieb diese Probleme nicht feststellen kann.

Sprachausgabe ist wirklich cool, sollte ich mal auf meine Liste setzen  ;)

JoWiemann

Zitat von: aw am 24 Juni 2020, 12:15:55
Ich vermute auch, dass es mit dem Wlan selbst zu tun hat, d.h. dass der Wemos beim hochfahren nicht schnell genug die Verbindung aufbauen kann und sich dann irgendwie verrennt. Evtl liegt es an wechselnden Kanälen, die vom Router seit der letzten Verbindung vor dem Deep sleep gewechselt wurden. Es wundert mich eben, dass ich im Dauerbetrieb diese Probleme nicht feststellen kann.

Das Problem ist eigentlich bekannt. Gib dem Wemos eine feste IP und es sollte besser laufen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

parabacus

Feste IP hab ich auch schon mal versucht - eine Änderung konnte ich nicht wirklich feststellen, liegt aber vielleicht an der ungünstigen Position dessen.
Ausserdem bin ich mir sicher, dass es mit den China-Clone-Teilen auch qualitative "Streuungen" gibt.
Erst kürzlich hatte ich grössere Probleme mit einem ESP_01 in Verbindung mit Deep-Sleep und zyklischem Aufwecken (wacht erst bei zweimaligen Reset-Impuls auf). Wie sich herausstellte, lag es daran.
Stiebel Eltron LWZ 504 / FHEM auf Rasperry Pi 3 / THZ / Weather / TABLETUI / SB_SERVER / SB_PLAYER  / OBIS / Verkehrsinfo / speedtest / Presence / FRITZ / ZWDongle / ZWAVE / Calendar / CALVIEW/ IPCAM/ ABFALL / ESPEasy

aw

Zitat von: JoWiemann am 24 Juni 2020, 12:31:21
Das Problem ist eigentlich bekannt. Gib dem Wemos eine feste IP und es sollte besser laufen.

Grüße Jörg
Er hat eine feste IP. Daran kann es nicht liegen.

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

parabacus

..interessant - dass die Induktivitäten mit Kondensatoren bestückt sein könnten, wäre ich nicht gekommen - muss ich mal checken.
Bei meinen "nicht sleep-fägigen" ESP_01-Bausteinen hätte ich nur unterschiedliche Flash-Bausteine ausgemacht und auf die getippt, dass das nicht korrekt aus'm Sumpf kommt.
Aktuell hab ich die Analyse aber abgebrochen und benutze dafür die Module, die eh schon funktionieren.
Stiebel Eltron LWZ 504 / FHEM auf Rasperry Pi 3 / THZ / Weather / TABLETUI / SB_SERVER / SB_PLAYER  / OBIS / Verkehrsinfo / speedtest / Presence / FRITZ / ZWDongle / ZWAVE / Calendar / CALVIEW/ IPCAM/ ABFALL / ESPEasy

aw

Zitat von: MadMax-FHEM am 24 Juni 2020, 12:53:11
Vielleicht auch betroffen: https://forum.fhem.de/index.php/topic,112191.msg1065223.html#msg1065223

Gruß, Joachim

Das hört sich sehr plausibel für einen solchen nicht produzierbaren Effekt an. Ich werden die Schaltung bei Gelegenheit nochmal abbauen und dann das Board auf den entsprechenden Kondensator hin untersuchen.
Auf jeden Fall schon mal vielen Dank für die konstruktiven Vorschläge.

Gisbert

Hallo aw,

ich benutze eine ESP mit Tasmota und deepsleep. In der Zeit in der er nichts zu senden hat (bei mir spätabends bis zum nächsten Mittag) habe ich die Zeit auf 7200 Sekunden gesetzt, um Strom zu sparen. Ich habe über Wochen keinen Ausfall festgestellt. Mit Tasmota kann man mehr als die üblichen ~71 Minuten deepsleep machen. Ich hatte einen fork compiliiert, mittlerweile scheint es in Tasmota vonhause aus drin zu sein.

"Gutes" Wlan ist natürlich essentiell, wobei Fritzbox nicht "gut" ist.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

aw

Danke nochmal für eure Hinweise!
Zur Zeit führe ich jede Nacht automatisch einen Reboot durch. Ob es daran liegt, weiß ich nicht, aber auf jeden Fall läuft er immer noch problemlos und stabil. Hoffen wir mal, dass es so bleibt  :)

aw

Zitat von: Gisbert am 24 Juni 2020, 19:59:56
Hallo aw,

ich benutze eine ESP mit Tasmota und deepsleep. In der Zeit in der er nichts zu senden hat (bei mir spätabends bis zum nächsten Mittag) habe ich die Zeit auf 7200 Sekunden gesetzt, um Strom zu sparen. Ich habe über Wochen keinen Ausfall festgestellt. Mit Tasmota kann man mehr als die üblichen ~71 Minuten deepsleep machen. Ich hatte einen fork compiliiert, mittlerweile scheint es in Tasmota vonhause aus drin zu sein.

"Gutes" Wlan ist natürlich essentiell, wobei Fritzbox nicht "gut" ist.

Viele Grüße Gisbert

Auch wenn das Thema schon etwas älter ist, möchte ich kurz eine Rückmeldung geben. Nachdem ich die Probleme mit ESPEasy mega auch mit den jeweils aktuellen Images und verschiedenen Konfigurationen nicht in den Griff bekommen habe, bin ich Gisberts Vorschlag gefolgt und auf Tasmota umgestiegen. Hardwareaufbau und wlan Infrastruktur ist komplett gleich geblieben. Seit diesem Umstieg hatte ich keinen einzigen Aussetzer mehr und das System läuft unglaublich stabil, mittlerweile seit mehreren Worten.
Vielen Dank nochmal für den Hinweis, Gisbert!!

Gisbert

Hallo aw,

schön, dass du dieses Projekt umsetzen konntest.
Im Testaufbau lief es bei mir ebenfalls gut, in der Praxis gab es dann doch immer wieder Probleme - und letztlich war mir der Wechsel alle paar Wochen dann zu lästig (ausbauen, alten Akku raus, neuen Akku rein, alten Akuu aufladen). Ich bin dann auf die klassische Versorgung mit 230V und Trafo umgestiegen.
Es gibt wirklich stromsparende Microcontroller wie den attiny, aber da muss man sich zuerst sehr tief einarbeiten.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY