Bilderstream modularisieren

[ProfZiebart]

Ich arbeite an einer ähnlichen Lösung, möchte dafür aber MagicMirror als Basis nehmen. Das ist sehr leicht konfigurierbar und mit Hilfe von Puppeteer kann ich per Skript automatisiert das MM-Bild als png wegspeichern.
Könnte man dieses Projekt hier irgendwie abspecken, damit ich nur den "Kanal" also den Stream des pngs. vom Server zum ESP32 alleine nutzen kann?
Der Rest läuft ja schon auf dem Raspi.
Auch bin ich mir nicht sicher, ob ich das irgendwie OHNE basecamp hinbekommen kann, welches ja nicht mehr supported wird.

[jdede]

Im Prinzip schon. Die Umwandlung in das Rohdatenformat geschieht in der index.php:

DoorsignEPD/server/index.php

Line 134 in ee190f3

function rawImage($im, $hasRed) {

Diese Funktion müsste man dann entsprechend umschreiben. Der Code auf dem ESP schreibt diese Daten dann Pixelweise auf das Display:

DoorsignEPD/esp32/doorsignEPD/doorsignEPD.ino

Line 181 in ee190f3

void drawPixels(char *data, size_t len, boolean start){

Der ganze Code ist schon etwas in die Jahre gekommen und müsste überarbeitet werden. So implementiert der Arduino-Code einen einfachen HTTP-Client. Neben den Wechsel auf ein anderes Framework zur Konfiguration würde ich persönlich dies ebenfalls anpassen wollen.

Auf Grund des Alters des gesamten Codes und den zwischenzeitlichen Entwicklungen würde ich den Code für den ESP32 komplett neu schreiben -- wahrscheinlich in Python für microPython. Hier müssten alle benötigten Funktionen schon verfügbar sein und der Code deutlich übersichtlicher werden.

Leider fehlt mir jedoch die Zeit für dieses Projekt.

[ProfZiebart]

Hallo Herr Dede, danke für die Antwort. Mir läuft auch irgendwie die Zeit durch die Finger, ich will es aber demnächst mal angehen. Dafür möchte ich die Schachtelung auf der Serverseite reduzieren. Die Idee wäre, vom ESP aus per http ein Bild anzufordern und per Touch-Pin dann das nächste, so dass man ggf. durch mehrere Bilder schalten kann. Was auf den Bildern ist, darum soll sich der Raspi kümmern, bei mir wären das verschiedene Kalender die ich per puppeteer aus MagicMirror erzeuge. Der Server würde dabei überwachen auf welchem Bild ich gerade stehe und dann das nächste rüberschicken, so brauche ich bei einem weiteren Bild nicht den ESP neu flashen. Micropython ist weit entfernt auf meiner Liste, ich würde das Ganze in der ArduinoIDE umsetzen wollen, ggf. mit einem HTTPS Client. Dann kann das eigentlich auf der ESP Seite nicht so superkomplex werden. ( ESP wacht durch Touch oder per Timer auf, geht ins WLAN, fragt Seite an, bekommt Bitstream, schreibt Bitstream in Bild, meldet OK zurück, um Serverzeiger weiterzusetzen, geht wieder aus. Zugriffe per Watchdog absichern dass er sich nicht aufhängt. Alles andere läuft auf der Serverseite. Dort cycled der Server durch mehrere Bilder, die irgendwie dort erzeugt werden könnten.) Ich hatte zunächst überlegt auf dem ESP das Bild in den Bitstream zu konvertieren (gibt dafür ja schon Lösungen) aber warum Akkulaufzeit verschwenden? Gibt es denn etwas AUßER der Umstellung auf Micropython die Sie mal angehen wollten? Ggf. kann ich ja schon versuchen das einzustricken. Gruß Jan R. ZIebart Von: Jens Dede ***@***.***> Gesendet: Sonntag, 19. Dezember 2021 21:36 An: jamct/DoorsignEPD ***@***.***> Cc: Ziebart, Jan Robert ***@***.***>; Author ***@***.***> Betreff: Re: [jamct/DoorsignEPD] Bilderstream modularisieren (Issue #40) Im Prinzip schon. Die Umwandlung in das Rohdatenformat geschieht in der index.php: https://github.com/jamct/DoorsignEPD/blob/ee190f3d86678edcfcb893be88ebd08be913d0a8/server/index.php#L134 Diese Funktion müsste man dann entsprechend umschreiben. Der Code auf dem ESP schreibt diese Daten dann Pixelweise auf das Display: https://github.com/jamct/DoorsignEPD/blob/ee190f3d86678edcfcb893be88ebd08be913d0a8/esp32/doorsignEPD/doorsignEPD.ino#L181 Der ganze Code ist schon etwas in die Jahre gekommen und müsste überarbeitet werden. So implementiert der Arduino-Code einen einfachen HTTP-Client. Neben den Wechsel auf ein anderes Framework zur Konfiguration würde ich persönlich dies ebenfalls anpassen wollen. Auf Grund des Alters des gesamten Codes und den zwischenzeitlichen Entwicklungen würde ich den Code für den ESP32 komplett neu schreiben -- wahrscheinlich in Python für microPython. Hier müssten alle benötigten Funktionen schon verfügbar sein und der Code deutlich übersichtlicher werden. Leider fehlt mir jedoch die Zeit für dieses Projekt. — Reply to this email directly, view it on GitHub <#40 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO3HFYXDLXEBM73YJ2ECT33URY64TANCNFSM5KL3L7JA> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AO3HFYURRG7CSENEUKFC7TLURY64TA5CNFSM5KL3L7JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHNZ7ZMI.gif> Message ID: ***@***.*** ***@***.***> >

[jdede]

Klingt logisch. Auf der Serverseite wollte ich so etwas mal via Flask oder Django implementieren. Dann gäb es entsprechende URLs für verschiedene Bilderrahmen. Würde einen Token für jeden Bilderrahmen nutzen, dann kann man die Serverseite noch ein wenig erweitern. Die URLs müssten dann entsprechend logisch aufgebaut sein. Angenommen es gibt 4 Bilder, würde es wie folgt bauen:

• http://127.0.0.1/<TOKEN>/1 1. Bild
• http://127.0.0.1/<TOKEN>/1/next 302er Redirect auf - http://127.0.0.1/<TOKEN>/2
• http://127.0.0.1/<TOKEN>/1/prev 302er Redirect auf - http://127.0.0.1/<TOKEN>/4
• http://127.0.0.1/<TOKEN>/4/prev 302er Redirect auf - http://127.0.0.1/<TOKEN>/3
• http://127.0.0.1/<TOKEN>/4/next 302er Redirect auf - http://127.0.0.1/<TOKEN>/1

Dies hätte den Vorteil, dass der Server stateless wäre und kein Zeiger umgebogen werden muss. So könnte man auch ganz einfach einen Sprung z.B. auf die 1. Seite realisieren.

Mit DeepSleep und Buttons macht Arduino mehr Sinn. Die Python-VM benötigt standardmäßig 3-5 Sekunden zum Starten. Sorgt für eine schlechtere Usability und lässt sich nur mit Tricks umgehen.
Bei Arduino muss man dafür ein wenig mehr Hirnschmalz in den Verbindungsaufbau sowie die Requests und deren Fehlerbehandlung stecken.

Bei den Arduino-Libs bin ich nun nicht so ganz auf dem Laufenden. Aber eine HTTP(S)-Bib, die auch Redirects unterstützt sollte inzwischen zu finden sein. Notfalls kann man das auch noch mal selbst implementieren. Aber so hätte man eine saubere Lösung, die kaum Intelligenz auf dem ESP benötigt.

Weitere offene Punkte fallen mir derzeit nicht wirklich ein. Nur das Allgemeine:

• Code modularisieren
• Bibliotheken aktualisieren
• Config auslagern
• Das manuelle Parsen des Datenstreams besser implementieren / in eine Bibliothek packen

Ach ja, es wäre schön, den Code als saubere State Machine zu schreiben. Das wäre deutlich schöner und einfacher zu lesen...

Soweit meine Kommentare. Viel Erfolg! :-)

[ProfZiebart]

Hallo Herr Dede, habe das mal ausgetestet. Geht. Ich kriege den ESP soweit, dass er den Redirect erkennt und die neue URL rausparst (das leider mit String-Operationen, was eigentlich unelegant ist, aber besser kriege ich es nicht hin) und dann im SPIFFS zwischenspeichert. Ihre Idee mit dem Redirect ist cool. Allerdings werde ich noch eine weitere Variante reinbauen, wo ich es ermögliche eine HTML zu schreiben in der der Redirect als Schlüsselwort vorkommt. (Wenn BODY.Substring „Redirect“ = TRUE, dann parse als wäre 200 302.) Das hätte die Möglichkeit, dass ich „Ketten“ von Bildern aufbauen kann ohne an der Serverconfig rumzuspielen. Also ein „Redirect“ für arme Leute. Wenn man dann gedanklich next und prev in A und B umstellt, könnte man die alten Text-Adventures auf dem Ding mit 2 Tasten spielen… ;) Die HTTPClient.h kann zwar Redirects folgen, ich will aber die neue URL Zwischenspeichern, damit ich weiß auf welcher Seite ich aktuell bin. Gruß Ziebart Von: Jens Dede ***@***.***> Gesendet: Montag, 10. Januar 2022 18:00 An: jamct/DoorsignEPD ***@***.***> Cc: Ziebart, Jan Robert ***@***.***>; Author ***@***.***> Betreff: Re: [jamct/DoorsignEPD] Bilderstream modularisieren (Issue #40) Klingt logisch. Auf der Serverseite wollte ich so etwas mal via Flask oder Django implementieren. Dann gäb es entsprechende URLs für verschiedene Bilderrahmen. Würde einen Token für jeden Bilderrahmen nutzen, dann kann man die Serverseite noch ein wenig erweitern. Die URLs müssten dann entsprechend logisch aufgebaut sein. Angenommen es gibt 4 Bilder, würde es wie folgt bauen: * http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/1> <TOKEN>/1 1. Bild * http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/1/next> <TOKEN>/1/next 302er Redirect auf - http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/2> <TOKEN>/2 * http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/1/prev> <TOKEN>/1/prev 302er Redirect auf - http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/4> <TOKEN>/4 * http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/4/prev> <TOKEN>/4/prev 302er Redirect auf - http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/3> <TOKEN>/3 * http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/4/next> <TOKEN>/4/next 302er Redirect auf - http://127.0.0.1/ <http://127.0.0.1/%3cTOKEN%3e/1> <TOKEN>/1 Dies hätte den Vorteil, dass der Server stateless wäre und kein Zeiger umgebogen werden muss. So könnte man auch ganz einfach einen Sprung z.B. auf die 1. Seite realisieren. Mit DeepSleep und Buttons macht Arduino mehr Sinn. Die Python-VM benötigt standardmäßig 3-5 Sekunden zum Starten. Sorgt für eine schlechtere Usability und lässt sich nur mit Tricks umgehen. Bei Arduino muss man dafür ein wenig mehr Hirnschmalz in den Verbindungsaufbau sowie die Requests und deren Fehlerbehandlung stecken. Bei den Arduino-Libs bin ich nun nicht so ganz auf dem Laufenden. Aber eine HTTP(S)-Bib, die auch Redirects unterstützt sollte inzwischen zu finden sein. Notfalls kann man das auch noch mal selbst implementieren. Aber so hätte man eine saubere Lösung, die kaum Intelligenz auf dem ESP benötigt. Weitere offene Punkte fallen mir derzeit nicht wirklich ein. Nur das Allgemeine: * Code modularisieren * Bibliotheken aktualisieren * Config auslagern * Das manuelle Parsen des Datenstreams besser implementieren / in eine Bibliothek packen Ach ja, es wäre schön, den Code als saubere State Machine zu schreiben. Das wäre deutlich schöner und einfacher zu lesen... Soweit meine Kommentare. Viel Erfolg! :-) — Reply to this email directly, view it on GitHub <#40 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO3HFYXOZ66FW366UKP6G33UVMGAZANCNFSM5KL3L7JA> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AO3HFYSKFPFRQJC7D4CGDPLUVMGAZA5CNFSM5KL3L7JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHQTBWRI.gif> Message ID: ***@***.*** ***@***.***> >