Müllabholungs-Display mit Batteriebetrieb?

[schmadde]

Ich bin jetzt nicht unbedingt ganz blutinger Anfänger in FHEM, habe mich damit aber bisher nur so viel damit beschäftigt, bis ich zum laufen bekommen habe, was ich brauche. Jetzt bräuchte ich einen Denkanstoß wie ich folgendes am einfachsten implementiert bekomme.

Ich möchte neben die Haustüre ein kleines Display anbringen, auf dem ne Mülltonne abgebildet wird mit Text, welche Tonne und wann sie rausgestellt werden soll (für den aktuellen und den darauffolgenden Tag). Das Abfall Modul habe ich bereits entsprechend konfiguriert und auf dem Web-Interface sind die entsprechenden Infos da.

Das Display soll per WLAN angebunden werden und per Akku betrieben werden. Da ich nicht ständig den Akku laden will und WLAN+Display viel Strom brauchen dachte ich an ein E-Paper Display und seltenes Aufwachen - es reicht ja, wenn die Infos 1 oder 2 mal am Tag updated werden.

Ich habe beim stöbern gesehen, dass man wohl irgendwie mit esphome eine art externes Display anbinden kann - ein ESP mit epaper wäre sogar vorhanden, ich weiss nur nicht so recht, wie das mit dem Stromverbrauch aussieht. Gibts da Erfahrungswerte? Und wo finde ich am besten Infos, was da wie genau eingerichtet wird?

Am liebsten würde ich ja einen Raspberry Pi Pico nehmen und selbst ein kleines Programm für die Anzeige schreiben - kann man bestimmte Werte einfach an einen Web- (oder Telnet-) Client exposen?

[eisman]

hi,

ESPEInk vieleicht hilfts

gruss

[rabehd]

Ob man ein epaper bei runtergefahrenem ESP auch nutzen kann, keine Ahnung.

Der ESP kann regelmäßig oder gesteuert aufwachen, per MQTT die Infos holen und die Anzeige aktualisieren.

[eisman]

hi,

bei meinen ink blieb der Display länger als 1 Woche ohne Strom sichtbar

gruss

[JoWiemann]

Ein E-Ink-Display, auch bekannt als elektronisches Papier, funktioniert durch das Anordnen von kleinen, elektrisch geladenen Partikeln in Mikrokapseln, die zwischen zwei Elektroden auf dem Display angeordnet sind. Diese Partikel sind entweder weiß oder schwarz (mittlerweile auch farbig) und werden durch ein elektrisches Feld entweder nach oben (weiß) oder nach unten (schwarz) bewegt, wodurch ein Bild oder Text dargestellt wird. Da die Partikel nicht mehr bewegt werden müssen, sobald sie in ihrer Position sind, benötigt das Display nur Energie, um das Bild zu aktualisieren, was es extrem stromsparend macht, da es im Ruhezustand keinerlei Energie benötigt.

Grüße Jörg

[rabehd]

da es im Ruhezustand keinerlei Energie benötigt.

Da wollte ich nicht mit Halbwissen unterwegs sein.

[schmadde]

Ok also der beste Weg wäre via MQTT? Welche Client Software empfiehlt sich für den ESP (die grafische Aufbereitung und das Schlafen für mehrere Stunden unterstützt?

[Guybrush]

die "Grafik" machst du da über passende Schriftarten, die Symbole statt Buchstaben etc haben. Das Ganze ist aber echt etwas komplex als Anfangsprojekt. Grundsätzlichmkannst du aber mit einem ESP32 und eInk Paper genau das machen was du dir wünscht. Der Stromverbrauch im Deepsleep liegt bei einigen Boards bei nur 50 µA. Das reicht bei einem flachen 1000mAh Akku für Jahre standby. Entscheidend ist da also eher wieviel Energie du fürs updaten benötigst, was schnell 200 mA zieht.

ich hab mir zb Feuchtigkeitsmesser gebaut mit 3000 mAh Akkus. Die hab ich vor ca. 2 Jahren installiert und haben immer noch Akku Läuft da auch alles über deepsleep und mqtt als Kommunikationsschnittstelle. Die sind aber auch nur alle paar Stunden für 1 sec im Betrieb. Ein eInk Paper kann je nach Hersteller auch mal 30 Sekunden brauchen bis alles aktualisiert ist. Vielleicht fängst du auch erstmal mit kleinen Projekten an zum lernen. also irgendeinen Sensor auslesen und per matt an fhem übermitteln.

[JoWiemann]

Hallo,

ich würde hier einen zweiten ESP als ESP-NOW Broker einsetzen. ESP-NOW verbraucht viel weniger Strom als MQTT inkl. WLAN. Allein das einloggen per WLAN ist schon sehr Strom intensiv. Für ESP-NOW gibt es einige Beispiele mit deep sleep.

Grüße Jörg

[schmadde]

Ich habe mich ein bisschen eingelesen und soweit ich es verstanden habe, ist MQTT ein push-Protokoll, das auf einer persistenten TCP-Verbindung basiert - wie funktioniert das, wenn der ESP blos 1-2x am Tag aufwacht? Ist das noch das richtige? Ansonsten klingt es gut. Am liebsten hätte ich irgendwas, bei dem man 1-2 mal am Tag den Status abholt und daraus irgendeine Darstellung macht. Falls der Akku dennoch monatelang durchhält und es einfacher zu integrieren ist, nehme ich auch öftere updates. Brauchen tu ichs aber nur 1x am Tag.


ESP-Now klingt interessant, aber irgendwie muss ich ja zum FHEM kommen, ein weiterer ESP nützt mir hier doch nix?

[JoWiemann]

ESP-Now klingt interessant, aber irgendwie muss ich ja zum FHEM kommen, ein weiterer ESP nützt mir hier doch nix?

Der zweite ESP ist die ESP-NOW MQTT Bridge zu Fhem.

Grüße Jörg

[Guybrush]

wenn der esp32 die meiste zeit im deep sleep hängt, dann ist auch wlan egal. entscheidend ist insoweit viel mehr wie lange der im betrieb sein muss.

wenn der z.b. 2x30sek im betrieb ist, dann zieht das bei 200 mA 200/60=3,3mAh. Das sind im Jahr 1200 mAh. Hinzu kommen noch ca 440 mAh für den Rest der Zeit im deep sleep. da würde also ein 2500 mAh Akku mehr als ein Jahr reichen - trotz wlan.

Über Alternativen zu wlan kann man sich Gedanken machen wenn du winzige Akkus nur verwenden kannst. So ein 3000 mAh Akku ist kleiner als eine Streichholzschachtel..

[tobi01001]

Ich habe mich ein bisschen eingelesen und soweit ich es verstanden habe, ist MQTT ein push-Protokoll, das auf einer persistenten TCP-Verbindung basiert - wie funktioniert das, wenn der ESP blos 1-2x am Tag aufwacht? Ist das noch das richtige? Ansonsten klingt es gut. Am liebsten hätte ich irgendwas, bei dem man 1-2 mal am Tag den Status abholt und daraus irgendeine Darstellung macht. Falls der Akku dennoch monatelang durchhält und es einfacher zu integrieren ist, nehme ich auch öftere updates. Brauchen tu ichs aber nur 1x am Tag.


ESP-Now klingt interessant, aber irgendwie muss ich ja zum FHEM kommen, ein weiterer ESP nützt mir hier doch nix?

Ich habe mir batteriebetriebene Temperatur/Feuchtesensoren für Keller und  Getränkekühlschrankl gebastelt (ESP32 mit DHT22). Mit einen Aktualisierungsinterval was klein genug ist, halten die ewig.... Die Werte werden - sofern erforderlich (d.h. signifikante Änderung) zu fhem via einfacher Netzwerk-Verbindung gesendet. Ansonsten schläft das Ding direkt wieder. Kommunikation ohne einen mqqt overhead. Das was gesendet wird, ruft eine myUtils-Funktion aufgerufen, die das ganze berarbeitet... (sie unten als Beispiel) - aus security Gesichtspunkten ist das allerdings mehr als fragwürdig


Aber: Zumindest bei uns wird der Abfallkalender einmal jährlich aktualisiert und verteilt. Damit würde ich vll. einmal im Monat ein OTA anstoßen, die RTC aktualisieren und ansonsten die Daten entweder hart kodiert oder im "Filesystem" als JSON abgelegt direkt auf dem ESP ablegen. Dann kann er bis zum nächsten Zustandswechsel schlafen. Wäre bei deiner Spezifikation immernoch einmal am Tag, aber ohne WiFi...

Gruß,
Tobias

Code Auswählen Erweitern

...
while(!server_connected && server_retry--)
    {
      client = new WiFiClient();
      server_connected = client->connect(host, TelNetPort);
      if(!server_connected)
      {
        client->stop();
        delete client;
      }
      delay(5);
    }
...

String payload = "{handleTelnet(\"TH_Sens_" + String(chip_crc) + "\", \"minUpdateCount "  + String(sendMinCounter) +
...

 // This will send the request to the server
    client->print(payload);
    client->print("exit\r\n");
    client->flush();
    client->stop();
    delete client;

    if(shouldCheckforOTA)
    {
      checkForUpdates();
    }

    goto_sleep(SENSOR_READ_INTERVAL, SR_SEND_DATA);


[Prof. Dr. Peter Henning]

Ich habe mich ein bisschen eingelesen und soweit ich es verstanden habe, ist MQTT ein push-Protokoll, das auf einer persistenten TCP-Verbindung basiert

Das stimmt so nicht.

https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/

LG

pah

[Guybrush]

ich halte das auch nicht für sinnvoll die abfalltermine hard coded per ota update auf dem esp32 vorzuhalten. der sollte nur die darstellung machen und auf ein mqtt publish lauschen. die logik hälst du besser in fhem und steuerst das über at/notify, die dann ein mqtt publish anstoßen und die darzustellenden werte für den esp32 schreiben.