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!
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.
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.
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?
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:
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.
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.
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.
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.)
# 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
# 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
Als bi-level bitmap aka. MONO:raw hat dieser Eumel dann nur noch eine Größe von 1496 Bytes und könnte ohne Dekodierung direkt in den Framebuffer geladen werden.
Das entsprechende PNG ist sogar nur 429 Bytes klein.
Die Achsenbeschriftungen habe ich bewusst weggeschnitten, weil der Text die extreme Skalierung bestimmt nur wenig ansehnlich überlebt hätte. Bei der entsprechenden e-Paper Bibliothek sind optimierte Fonts für eine deutlich bessere Textausgabe dabei, so dass man damit vielleicht wieder eine Legende anbauen könnte, die zumindest über den dargestellten Zeitraum informiert.
[edit] Mit einer Breite von 400 px ist die Achsenbeschriftung noch lesbar:
