Anzeige der Daten auf einem e-Paper Display

Entwicklung / Development Benutzerschnittstelle / User interface / API
18

Bin jetzt am Wochenende entlich mal ein Stückchen weiter gekommen.
Das Display funktioniert mit Arduino-C auf einem ESP32 echt flott (1-2sek).
Die Abfrage und Anzeige der Daten von openweathermap.org läuft auch einwandfrei.

19

Wahnsinn, was der Python-Treiber vs. C da an Geschwindigkeit macht!

20

8 posts were merged into an existing topic: Erschließung der HTTP-Datenexportschnittstelle via Arduino

21

Drüben bei Erschließung der HTTP-Datenexportschnittstelle via Arduino haben wir einen Ausflug gemacht, wie die HTTP-Datenexportschnittstelle von Arduino for ESP32 aus angesprochen werden kann, um eine Anpassung auf Basis von GitHub - G6EJD/ESP32-e-Paper-Weather-Display: An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground and displays the weather zu realisieren.

22

Während der o.g. Arbeiten habe ich bei Erschließung der HTTP-Datenexportschnittstelle via Arduino gemerkt, dass es ungünstig ist, dass die ds18b20 vor der Übertragung zu swarm.hiveeyes.org nicht gemapt werden.

Gerade, wenn ich mehrere Sensor-Beuten mit dem Display überwachen möchte, muß ich alle ID’s überall übertragen. Es graut mir schon davor, wenn mal ein DS18b20 ausgetauscht werden muß.

23

+1 _______

24

Deshalb werden ja bei Hiverize/Fipy die ID’s nur in user_settings.json gespeichert und nicht übertragen.
In den Daten tauchen nur t_i_1 bis 5 und t_o auf.

25

@didilamken stimmt, von dort kenne ich das ja auch so.

@clemens, @all wo wir schon bei den Temperatursensoren und deren Anzeige sind.
Macht es Sinn, einen Median der inneren DS1820 zu bilden und auch die Abweichung der letzten Stunde auszugeben(Schwarmalarm?)?
Eine Auflistung aller Sensoren macht das ganze finde ich recht unübersichtlich, gerade wenn man mehrere Beuten anzeigen möchte.
Man könnte auch über der Zahl dann noch noch einen Pfeil zeichnen, der anzeigt, ob sie eher links,rechts oder Mittig sitzen.

26

Hi Michael,

I hear you. Ja, wir sollten das gerade in diesem Kontext auch unbedingt so gestalten wie hier:

@tonke hat ebensolche Wünsche und wir haben während der letzten Releases bereits daran gearbeitet, entsprechende Funktionalität nicht “out-of-band” zu realisieren, sondern die Möglichkeit zu schaffen, die Telemetriefeldnamen bereits in den entsprechenden Konfigurationsabschnitten der Sensoren selbst definieren zu können.

Viele Grüße,
Andreas.

1 Like
27

Hmm, Median / Mittelwert würde ich nicht machen, das sagt dann nix mehr aus. Ich würde mir einfach den mittleren nehmen und dessen Daten anzeigen, die anderen verwerfen. Oder man nimmt den Maximalwert von allen. Schwarm wäre so ab 35,8 °C

28

Ist es für die Messdatenauswertung wichtig zu wissen, dass der BME280 am I2C-Bus0 mit der Adresse 0x77 betrieben wird? Oder ist das nur unnötiger Datenballast?

29

@MKO: Ich habe das o.g. Repository nach GitHub - hiveeyes/ESP32-e-Paper-Display: Display data from Weather Underground and Hiveeyes on an ESP32 and 2.9", 4.2" or 7.5" ePaper Display geforked und einen Branch “hiveeyes” angelegt. Vielen Dank schon im Voraus fürs Bestücken mit unseren Errungenschaften aus Erschließung der HTTP-Datenexportschnittstelle via Arduino und dem weiteren Entwicklungsverlauf!

30

Das liegt daran, das die Terkin Firmware nach oben offen ausgelegt ist. Theoretisch kann man beliebig viele BME280 anschließen. Praktisch wird das aber wieder durch die BME begrenzt, die nur auf 2 Adressen eingestellt werden können. Beim i2C verhält sich das ähnlich es sind auch auf dem FiPy zwei möglich.
Testweise Angeschlossen hatte ich schon 2 x BME, 10 DS18b20 und 2 x HX711, welches einen vollen Sensor-Betrieb von 2 Beuten mit nur einem Fipy + bedeuten würde.
Theoretisch geht noch einiges mehr. I2C Multiplexer + B Kanäle der ADC (beim HX711 wohl lieber nicht) z.B.

Man braucht also nicht mehr lange Programmieren, wenn man neue Ideen hat. Anschließen Konfig Ändern und fertig.

1 Like
31

David aka G6EJD hat dazu auch einige YT-Videos ins Netz gestellt:
https://www.youtube.com/results?search_query=G6EJD+e-paper

32

Hast du das s/w-Display oder ein dreifarbiges? Du hattest hier irgendwo mal ein Foto mit einem 3-farbigen Display gepostet, daher die Frage! Gerade für die Graphen fände ich die dritte Farbe prima!

Könnte das framework von David / G6EJD auch drei Farben?

33

Ich habe derzeit nur das Schwarz Weiße 4.2 von Waveshare. Der Grund ist hauptsachlich eine kurze Aktualisierungszeit und die möglichkeit von Partial Update. Anstatt Farbe kann es aber auch aber auch Graustufen.

Ein 3 Farben Display braucht doppelt so viel Speicher/rechenzeit im ESP , doppelt so viel Zeit/Daten per SPI und gut 3Mal so lange zum Aktualisieren.
Und aktive Zeit ist leider auch Batterieverbrauch, welche sich auch durch häufigeres Laden/Batteriewechsel bemerkbar machen würde. Derzeit hoffe ich, das wir bei ca. 200 - 300 Tagen Laufzeit mit einer Akku Ladung landen.

Die verwendete Libary fur die Displays GitHub - ZinggJM/GxEPD2: Arduino Display Library for SPI E-Paper Displays kann aber auch 3 Fabige Displays.

Eine Kurze Aktualiesierunszeit und Datenübertragung zum Display ist für mich aber aktuell fast wichtiger als Farbe, da ich auch ein paar Buttons mit Interupt einbauen möchte.

Von der Idee her: Ich möchte ich eine Kurzform der wichtigsten Daten des Wetters und meherer Beuten in der Standartansicht anzeigen lassen, die dann auch per Wakeup über einen Button-interupt umgeschaltet werden können, um eine größere Ansicht der einzelnen Beuten zu erhalten.
Also ein Button zum manuellen Aktualiesieren (=Reset) und je einen weiteren für die Detailansicht der einzelnen Beuten.

Der relativ günstige Preis für diese größe des E-Papers (ca 35€ m. Controler und Versand aus DE) hat aber auch eine Rolle gespielt.

Mit einem Waveshare 15823 e-Paper ESP32 Driver Board
 ca15€ + Solo-Display ohne Controler für ca. 22€ hätte man auch noch eine minimal kostengünstigere Variante, ohne groß Kabelsalat und Löten.

35

War mir nicht klar, dass der Unterschied so heftig ist. Selbst bei einem kleinen 3-Farben Display dauer es fast eine halbe Minute (Video ab 7:42):

Hier, mit em großen Display, dauert es unglaubliche 55 Sekunden bis das neue Bild aufgebaut ist: (ab 12:58)

Hier im Vergleich ein 2-Faben Display mit ca. 4 Sekunden update-Zeit (ab 14:48)

36

Ja der ist echt heftig. Der Treiber macht aber schon extrem viel aus.
Das im Video gezeigte Flackern braucht das Display, um Leinenhaft ausgedruckt, die Elektrische Ladung in den einzelnen Bildpunkten anzugleichen. Wenn dieses nicht oder nicht intensiv genug gemacht wird bleiben Teil-Ladungen von der letzten Anzeige erhalten. Die sich dann als Schatten bemerkbar machen.
Ein 3 Farbiges e-Paper sind theoretisch 2 eigenständige Anzeigen in einem. Diese werden nicht parallel sondern nacheinander Aktualisiert. Daher dauert es mindestens doppelt so lange.

Eine reale Chance später auch Farbe ins Spiel zu bekommen haben wir allerdings dennoch. Von der verwendete Display Libary meine ich eine evtl. kompatible für “normale” Displays gesehen zu haben. Der Nachteil wär dann aber, das man an eine feste Spannungquelle gebunden wär, oder ständig aufladen müsste.
Also eher was für den Schreibtisch oder ein Regal mit Steckdose, wo ein zusätzliches Stromkabel nicht stört.
Ich will es frei an der Wand im Flur/Gaderobe hängen, oder auch Mal einem interessierten Besucher in die Hand geben.

Ein komplettes Aktualisieren inkl. Hochfahren, Wlan, Zeitsync, 2x API-OpenWeathermap, 1x Http-Hiveeye , Datenaufbereitung und Displayanzeige dauert Aktuell übrigens ab Reset 5-6 Sekunden. Was ich zugegeben recht Flott finde, für das was getan wird und das Flackern von nicht einmal einer Sec. Zeigt einem dann auch noch zusätzlich, das das die Daten Frisch sind.

Gestern bin ich leider nur minimal weiter gekommen. Das Auslesen der Json stoppt jetzt nach dem letzten Datensatz und ich bin mit einem Configfile für Hiveeyes angefangen.
Auf GitHub - hiveeyes/hiveeyes-epaper-display: Display data from Hiveeyes and Weather Underground on an ESP32 and 4.2" ePaper Display werde ich es leider erst am Wochenende Mergen können. Die geforderte Verzeichnisstruktur von der Arduino-IDE und die des Forks unterscheiden sich schon extrem. Werde wohl auf CodeBlocks oder Visual Studio Code oder WSL inkl. Makefile umbauen müssen.

1 Like
38

Hi Michael,

alles neu macht der Mai – hierzu ein paar Updates von meiner Seite.

Repository

Stattdessen habe ich nun ein eigenes Repository angelegt und mit einer Build-Umgebung auf Basis von PlatformIO ausgestattet. So kannst Du wunderbar mit mehreren Dateien im Editor Deiner Wahl arbeiten. Ich hoffe das klappt auch mit WSL.

https://github.com/hiveeyes/hiveeyes-epaper-display

Abhängigkeiten

Der Code im Repository GitHub - G6EJD/ESP32-e-Paper-Weather-Display: An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground data via their API and then displays the weather ist ja eigentlich eine Bibliothek und wurde nun neben den anderen Abhängigkeiten auch entsprechend eingebunden.

HTTP-Client für Hiveeyes Datenexportschnittstelle

Diese Schnipsel wurden nun auch bereits hinzugefügt, siehe lib/hiveeyes.

Konfigurationsdatei

Die gibt es nun ebenfalls bereits im Repository:

Anleitung

git clone git@github.com:hiveeyes/hiveeyes-epaper-display.git
cd hiveeyes-epaper-display
make

Ich hoffe das hilft Dir ordentlich weiter. Happy hacking!

Viele Grüße,
Andreas.

1 Like
40

Backlog

Diese beiden Dinge müssten noch erledigt werden, damit das Gesamtsystem bestehend aus “Datenlogger -> DAQ-Backend -> Anzeige-Panel” robuster und wartungsärmer wird.

Wenn Euch weitere Details dazu einfallen, freuen wir uns über entsprechende Rückmeldungen.