esp32 tasmota deepsleep wakeup

Begonnen von no_Legend, 30 Januar 2023, 14:51:52

Vorheriges Thema - Nächstes Thema

no_Legend

Hallo Zusammen,

hat jemand von euch zufällig Erfahrung mit ESP32 Tasmota und Deep Sleep?

Ich würde gerne eine Lolin D32 mit Akku dazu verwenden, drei Reed Kontakte einzulesen.
Damit das ganze auch über den Akku länger hält, wollte ich den DeepSleep des ESP32 nutzen.
Da ich nach dem Wakeup und einwählen ins WLAN gerne den Status per MQTT an FHEM übertragen wollte, kam mir Tasmota da zu in den Sinn.

Ich hab dazu leider per google nicht wirklich etwas gefunden.
Es gibt wohl einen Eintrag bei Tasmota in Github, in Bezug auf die Berry Lanuage und ULP.

Hat hier schon jemand Erfahrungen mit gesammelt?

Danke und Grüße Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

Torxgewinde

#1
Hi,
Tasmota kann bisher per Timer aus dem Deepsleep aufwachen. Per GPIO oder ULP ist es IMHO noch nicht in Tasmota ohne selbst zu kompilieren gelöst. Doku dazu findet man dort: https://tasmota.github.io/docs/DeepSleep/ Auch durchläuft Tasmota eine etwas längere Startsequenz wenn es aus dem Deepsleep aufwacht und belastet damit die Batterie. Zur Zeit ist Deepsleep in Tasmota dafür geeignet einen Sensor wie z.B. für Temperatur zyklisch auszulesen. Interrupts aus dem Deepsleep kann es (noch?) nicht. die Frage ist: brauchst du die Reedschalter als Interrupt, oder reicht es diese alle paar Minuten zyklisch auszulesen? Zyklisch auslesen müsste mit Tasmota so gehen, aufwecken durch Pegeländerung eher nicht so...

Fazit, ich habe es mit Arduino selbst gelöst:
Ich habe einen Reed-Schalter an einem ESP32 und das ganze läuft vom Akku einige Wochen bis Monate. Das Projekt ist bei Github: https://github.com/Torxgewinde/Firebeetle-2-ESP32-E --> Firebeetle_Gasmeter.ino
Speziell im Issue #4 ist praktisch der Werdegang nachzuvollziehen: https://github.com/Torxgewinde/Firebeetle-2-ESP32-E/issues/4
In FHEM ist der Reedschalter als Gaszähler eingebunden: https://forum.fhem.de/index.php/topic,131451.0.html

Die Lolin D32 haben einen Spannungsregeler (LDO), die nicht stromsparend sind - das heißt durch programmieren alleine kann man die Hardware nicht sinnvoll mit Batterien nutzen. Der Lolin D32 braucht ca. 230 µA im Deepsleep von Batterie, der Firebeetle 2 hingegen ca. 12 µA (Quelle: https://docs.google.com/spreadsheets/d/1Mu-bNwpnkiNUiM7f2dx8-gPnIAFMibsC2hMlWhIHbPQ/edit#gid=0 und https://lucidar.me/en/esp32/power-consumption-of-esp32-firebeetle-dfr0654/)

DasQ

Darf ich fragen, warum du dann kein 8266 nutzt? Der kann ordentliches deepsleep.

Gern auch auf fertig kompilierten binarys wie espeasy.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Torxgewinde

#3
Ich nutze sowohl ESP32 (seit ca. 4 Jahren, Beispiel: https://www.reddit.com/r/esp32/comments/gc5mam/irrigation_controller/, https://github.com/Torxgewinde/Irrigation_Controller) als auch ESP8266 (seit ca. 6-7 Jahren, Beispiel von damals: https://www.reddit.com/r/esp8266/comments/5urb2n/an_alternative_firmware_for_lyt8266/, https://github.com/Torxgewinde/LYT-SCRIPTED).

Der ESP32 gefällt mir besser als der ESP8266 weil er:

Die größere Ressourcen (RAM, CPU) braucht man, wenn man TLS z.B. mit MQTT auch im LAN nutzen möchte. Da gerät ein ESP8266 regelmäßig an seine Grenzen. Selber kompilieren können und die Sourcen zu haben, hilft dabei die Geräte Jahrzehnte lang verwenden zu können, solche Zeiträume sind bei Hausautomation IMHO nicht selten.

Mit ESP8266 ist die Auswahl an "hackbaren" Geräten mit Gehäuse und Prüfzeichen (CE, TÜV, UL) größer. Solche Geräte mit ESP8266 kann man weit über die Zeitdauer, die der Hersteller Updates liefern wollte, unterstützen bzw. selbst patchen und deswegen mag ich den Controller auch. Mein Eindruck ist allerdings, dass auch diese Phase sich langsam wieder dem Ende neigt und nun wieder das umflashen seltener wird, außer man kauft bewusst ein.

Back to topic: Schreib' doch mal genauer wie man das mit ESPeasy machen könnte. In der Doku (= https://espeasy.readthedocs.io/en/latest/Config/Config.html#sleep-mode oder https://emariete.com/en/espeasy-deep-sleep-esp8266-low-consumption/) steht auch nur wie man mit ESPeasy per Timer aufwacht, oder den RST Pin zieht. Das wäre genau wie bei Tasmota und GPIO-Wakeup-Pins finde ich dort nicht.

DasQ

Der ESP32 gefällt mir schon auch besser, aber oft ist er einfach nur überdimensioniert.

Um ein (3) Kontakte abzufragen, brauch ich kein Bluetooth oder mehr als ein zwei gpios.

Für echtes lowpowercurrent deepsleep muß man an die Hardware und Bauteile auslöten. So hab ich nen wemos auf 8uA gebracht.

Allein die ungenutzten Bauteile auf solchen entwicklerboards braucht den bärenteil Strom.

Jetzt müsste man genauer wissen wie fit ist der te und traut er sich das löten zu?
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 es dann nicht einfacher, einen "nackten *)" esp8266 oder 32 Aufzurüsten, als ein Entwicklerboard abzurüsten?

*)
z.B. https://www.amazon.de/ZHITING-ESP8266-Wireless-Transceiver-Development/dp/B085B1XDY3
Gibt auch genug bei eBay, Alibaba und co.
- 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

Im Grunde schon. Aber preislich ist ein kastrierter wemos oder nodemcu auch jetzt kein Beinbruch.

Mal davon abgesehen, das man ja eh wieder ne Platine braucht um des halbwechs ordentlich anzuschließen.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org