Anzeige von PNG-Bitmaps aus Grafana auf einem e-Paper Display

Ja der ESP muß das können, hab leider nur kein 1:1 Beispiel dazu finden können wie man mit den Bibliotheken ein Bild per HTTP abholt, umwandelt und dann per GxEPD2 aufs S./W Display schickt.

Werde wohl schrittweise ran gehen und es erstmal als BMP über eine kostenfreie Convert API holen.

Wahrscheinlich muß ich das Bild noch in S/W oder besser noch in Graustufen umgewandelt werden.
Dann schauen die Schriftkanten auch nicht mehr so ausgefranst aus.

Wenn das klappt erst direkt und mich mit den Decoder Libs vertraut machen. Es ist ein etwas holpriger weg, aber ich bin auch kein Programmierer, und lerne jeden Tag neu dazu. Habe leider die Tage wenig Zeit, es wird also etwas dauern.

Hi!

Das mit dem Bitmap mag auf den ersten Blick vielleicht wie ein leichter Weg erscheinen, trägt aber an verschiedenen Stellen ordentlich auf hinsichtlich Programmieraufwand und Ressourcenverbrauch.

Man muss wirklich viel frickeln und einige Umwege gehen und selbst dann ist das Ergebnis oft nicht zufriedenstellend.

Auch wenn es anstrengender erscheint, würde ich empfehlen, eher die “native” Schiene weiterzuverfolgen, Daten diskret abzufragen und erst auf dem Gerät selbst zu rendern. Hintenraus ist es in Summe dann doch viel flexibler und wir werden wahrscheinlich langfristig mehr davon haben und portabler unterwegs sein.

Ich verstehe aber, dass es als Fingerübung interessant ist, auch die Bitmap-Schiene zu versuchen und bin gespannt, ob das klappt. Viel Erfolg dabei!

Viele Grüße,
Andreas.

Genau, selbst Rendern ist der Plan.
Ich will das nur in kleinen Schritten erschließen. Sind aktuell für mich zu viele unbekannte Stellen drin.
Hole ich die Daten so ab, das der Decoder was damit anfangen kann? Wie übergebe ich dem Decoder die Daten. Kommt GxEPD mit dem Format der Decodierten Daten überhaupt klar und kann das auch das Display so darstellen.
Hab bedenken, das ich mit meinem begrenzten wissen nachher die Stelle nicht finde, wo es hackt. Die Zwischenschritte kann ich ja schlecht Kontrollieren.

1 Like

Absolut verständlich, mir erginge es ähnlich. Falls sich wirklich jemand daran versuchen will, könnte folgendes als Starthilfe dienen:

Aber selbst das hat noch viele Lücken und Unwägbarkeiten, genau wie Du sie benannt hast, @MKO.

Genau, da weiß man was man hat. Danke!

1 Like

Wir haben halt viele, viele todos, wenn wir das nachbauen wollen, was eigentlich schon da ist

  • z.B. die schönen icons, die @wtf für die Kurzübersicht rausgesucht / erstellt hat
  • die ganze Logik der Berechnung, z.B. kg-Differenz für eine Woche, einen Tag, drei Tage, was man eben haben möchte
  • den Zustand Schwarm ja / Schwarm nein, Niederschlag schlecht / gut für Flugwetter usw.

nur was in dem kleinen panel links drinsteckt können wir mit vertretbarem Aufwand vermutlich nicht nachbauen.

Daher die Idee mit rendern lassen extern und dann nur die Anzeige auf dem e-Paper.

Noch einfacher wäre es statt des e-Papers ein normales kleines TFT zu nehmen und dort eine angepasste (HTML-)Seite von swarm.hiveeyes anzuzeigen wenn das Display irgendwo steht wo Strom ist.

A post was merged into an existing topic: Anzeige der Daten auf einem Kiosk-Display mit RaspberryPi und Grafana

Hi Clemens,

Das stimmt – das wäre ne Menge Holz.

Praktisch wäre es auf jeden Fall. Ich finde es auf jeden Fall sinnvoll. Es ist nur leider mit einigen zusätzlichen Unwägbarkeiten verbunden im Vergleich dazu, was wir nun bei Anzeige der Daten auf einem e-Paper Display - #50 by MKO auf Basis des 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 haben.

Vielleicht bestellst Du Dir im Herbst auch mal ein solches Waveshare Modul und wir verfolgen die Idee auf Basis des Schnipsels bei Unfinished spike to load PNG via HTTP and display on e-Paper display with ESP32 · GitHub weiter?

Vielleicht können wir auch @Stefan und @Oliver dafür begeistern, dabei mitzuhelfen.

Viele Grüße,
Andreas.

Es liegen schon eine Zeit welche hier, ich hatte damals – mangels besseren Wissens – leider nur die raw panels bestellt und der controller fehlt jetzt noch! ;-)

Ick versteh Euch nicht ganz. Wo ist das Problem, wenn Ihr schon bereit seid die Daten von Außen zu laden und nicht noch lokal vorzuhalten? Die Queries sind ja schon da. Ok, in der Tat, der Auswertungsteil (Icons/Farben in Abhängigkeit von Grenzwerten) muss wiedererfunden werden.

Der Einzelteil-Weg hat zumindest den Vorteil, dass auf dem Display auch zumindest lokale Ist-Werte stehen können ohne dass es Interdings hat.

Bzgl

Frag ich mich noch: Ist hier die Farb-PNG → s/w-BMP-conversion gemeint? Falls ja: Fänd ich spannend wie lang das auf nem FiPy braucht. Der hat ja schon etwas Unz. Als ich allerdings jüngst mal mit nem epaper display (auch 400x300) spielte war ich schon sehr irritiert wie lang der braucht um nen einfaches Rechteck zu malen. Ich glaub da hats nen µ Potential …

Verwendet hatte ich diese waveshare-epd libraries für µpython (Link korrigiert):

Das ist auf jeden Fall cool für low-memory. Preprocessing ist aber auf jeden Fall sinnvoll, gerade weil wir damit serverseitig flexibel skalieren und farb- und kontrastwandeln können etc. pepe.

Diese beiden hier wären also die Wunschkandidaten, ja?

Gewicht & tägliche Gewichtsdifferenz (Graph)

Übersicht: Letzte Werte (Boom Table)

Mit dem WiPy hatte ich es aber auch schon in Betrieb aber da war alles Schleppender.
Aktuell verwenden ich C auf dem ESP32. Da scheint es wesentlich potenter. Kann aber auch von der Libary her kommen.

Hier Mal ein kleines Video davon Reset wird ungefähr in sec 3-4 gedrückt. (Kurz bevor ich wieder auf Display schwenke)
In der Zeit wird erledigt:

  • Hochfahren
  • WiFi verbindung
  • 4 http requests (2x Open Weather Map, 1x swarm.hiveeyes, 1x Apicast)
  • Datenaufbereitung und Zeichnen des Bildschirms (incl resizing Icons usw.)
  • Aktualisierung Bildschrm
3 Likes

Ja, und wenn wir dann doch was ändern, an Grenzwerten, icons, Bezeichnungen und man das synchron haben möchte, müsste man das in Grafana und auf dem Anzeigegerät ändern. In Grafana ist das deutlich einfacher und schneller mit einer grafischen UI.

Ja, das wäre ein Argument! Und dass es ggf. besser ausschaut wenn ich die rendering-Ergebnisse oben anschaue.

Die displays sind recht wählerisch was die PNGs angeht, man kann nicht einfach irgendein PNG reinstecken, wenn ichs richtig verstanden habe.

  • PNG to s/w oder 3 Farben (für die s/w rot oder s/w gelb Displays), keine Ahnung, ob die mit Graustufen genügsamer sind und mehr fressen
  • dann was für die alten Arduino-C-libs noch nötig war konvertierung in inline byte-array wie in post 9 oben beschrieben.

In den Forks von GitHub - mcauser/micropython-waveshare-epaper: MicroPython drivers for Waveshare e-paper modules hatte ich kürzlich jene Commits entdeckt:

Leider erkennt man im Diff des ersten Commits kaum etwas, weil viel Whitespace-/Newline-Noise dabei ist ;[.

Analyse Graph

300x200 geht gerade noch

image image

https://swarm.hiveeyes.org/grafana/render/d-solo/start/welcome?orgId=2&panelId=9&from=1555547678893&to=1557998019523&var-beekeeper=All&var-COMMON_CDC_NAME=Berlin-Tegel&var-COMMON_MOSMIX_NAME=BERLIN-TEGEL&var-STATION=Berlin-Tegel&var-sensors=default_1_sensors&theme=light&width=300&height=200&tz=Europe%2FBerlin

130x100 geht in die Hose

image image

https://swarm.hiveeyes.org/grafana/render/d-solo/start/welcome?orgId=2&panelId=9&from=1555547678893&to=1557998019523&var-beekeeper=All&var-COMMON_CDC_NAME=Berlin-Tegel&var-COMMON_MOSMIX_NAME=BERLIN-TEGEL&var-STATION=Berlin-Tegel&var-sensors=default_1_sensors&theme=light&width=130&height=100&tz=Europe%2FBerlin

Gedanken

Ein Drittel der Displaybreite – also ein Panel im aktuellen Layout – hat mit dem 4.2’’ e-Paper eine Breite von ~130 Pixeln.

image

Fazit

Im Vollbild könnte man den Graphen also gut anzeigen. Klein komprimiert wird nicht klappen – das müssten wir wohl manuell rendern.

Analyse Boom Table

200x350

image image

https://swarm.hiveeyes.org/grafana/render/d-solo/OvnLNPqiz/statista-stockubersicht-and-bienenwetter-testvolk-zk-u?panelId=23&orgId=2&from=1546297200000&to=1577833199999&var-beekeeper=hiveeyes_open_hive_test_statista&var-sensors=All&var-COMMON_CDC_NAME=Berlin-Tegel&var-COMMON_MOSMIX_NAME=BERLIN-TEGEL&var-STATION=Berlin-Tegel&theme=light&width=200&height=350&tz=Europe%2FBerlin

Dieses Ausgabeformat nennt sich auch X BitMap (XBM) aka. “XBM – X Windows system bitmap, black and white only”, siehe X BitMap - Wikipedia.

Hier im Artikel wird beschrieben, dass auch GIMP dieses Format erzeugen kann.

Im obigen Artikel wird auch der Image Converter genannt – ebenfalls ein Online-Werkzeug.

Habe gestern Nacht Mal angefangen zu experimentieren und Div. BMP per Http und Https in einen Buffer zu laden und aus dem Buffer wieder anzuzeigen.
Habe dafür das WiFi Beispiel von GxEPD2 genommen.


Ein skalieren der Bilder sowie Umgang mit Farbe sowie Graustufen Bildern scheint auch zu klappen.
Die Ausgabe auf dem Display war allerdings nur SW und nicht Graustufen dafür aber wie gewohnt recht flüssig.
Als nächster Schritt steht jetzt das Laden eines PNG an. Da in dem Beispiel auch der Header des Bildes gelesen und Analysiert wird wird denke ich, das da die ersten Probleme auftauchen könnten.

Dann fehlt nur noch die Decodierung vor der eigentlichen Anzeige, das wenn die Treiber keine Probleme machen klappen sollte.

Die BMP lade und Anzeige Funktion lasse ich aber drin, man weiß ja nie ob jemand das nicht doch mal brauchen könnte. Zusätzliche Libarys werden dafür eh nicht gebraucht.

2 Likes

Durch das Antialiasing des Bildes ist es evtl. Sogar ratsam das Bild etwas größer zu laden, in SW umzuwandeln und dann erst zu verkleinern so wirken die Kanten evtl. schärfer.

Müssten wir auf alle Fälle dann ausprobieren wenn es funktioniert. Also erstmal bitte nichts an den Pannels ändern, könnte sein, das das kontraproduktiv ist.

1 Like

Ich fass nix an, nur der Hinweis: Man kann in dem Boom-table-plugin auch sehr fein mit der Schriftgröße rumspielen. (In den Einstellung einjeden “Patterns” janz unten.)

1 Like

Folgendes kleines Werkzeug kann uns u.U. weiterhelfen, welches auf der Python Imaging Library Pillow basiert:

XBM output

imagecast \
  --uri="https://unsplash.com/photos/WvdKljW55rM/download?force=true" \
  --monochrome=80 --crop=850,1925,-950,-900 --width=320 --format=xbm

Studie: Graph

# Define URI to image
export IMAGE='https://swarm.hiveeyes.org/grafana/render/d-solo/start/welcome?orgId=2&panelId=9&from=1555547678893&to=1557998019523&var-beekeeper=All&var-COMMON_CDC_NAME=Berlin-Tegel&var-COMMON_MOSMIX_NAME=BERLIN-TEGEL&var-STATION=Berlin-Tegel&var-sensors=default_1_sensors&theme=light&width=400&height=300&tz=Europe%2FBerlin'
# Convert image to monochrome, also slightly crop and resize
imagecast --uri="$IMAGE" --monochrome=200 --crop=40,50,-50,-40 --width=200 --display

image

# Try grayscale
imagecast --uri="$IMAGE" --grayscale --crop=40,50,-50,-40 --width=200 --display

image

Studie: Boom table

# Define URI to image
export IMAGE='https://swarm.hiveeyes.org/grafana/render/d-solo/OvnLNPqiz/statista-stockubersicht-and-bienenwetter-testvolk-zk-u?panelId=23&orgId=2&from=1546297200000&to=1577833199999&var-beekeeper=hiveeyes_open_hive_test_statista&var-sensors=All&var-COMMON_CDC_NAME=Berlin-Tegel&var-COMMON_MOSMIX_NAME=BERLIN-TEGEL&var-STATION=Berlin-Tegel&theme=light&width=200&height=350&tz=Europe%2FBerlin'

# Same procedure.
imagecast --uri="$IMAGE" --monochrome=200 --crop=20,40,-20,-40 --display

image

1 Like