Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)

Begonnen von eki, 02 Oktober 2019, 10:24:53

Vorheriges Thema - Nächstes Thema

eki

Du schreibst oben, dass Du das 7.5 V2 rot/schwarz/weiß ePaper hast. Als Device hast Du aber das ohne V2 gewählt. Das habe ich irgendwann mal nachgepflegt, ist aber im ,,offiziellen" Release drin.

Jojocra

Ah ja, danke. Ich habe das "normale" ohne V2. Also die Konfiguration müsste richtig sein.
Ich versuche es mal mit einer neuen Raspberry pi Installation. Ich habe irgendwann mal manuell von jessie auf strech und dann auf buster geupgraded. Wahrscheinlich ist mal alles neumachen dran.
Ich melde mich, sollte das das Problem lösen oder es noch bestehen.

appi

Hallo
bei mir läuft es nun auch endlich   :) ...... mit dem neuesten Waveshare Loader auf einem ESP32 Wemos Lite.
Frage: Ich arbeite auf einem Readonly Filesystem und würde gerne das Source PNG und das Result PNG auf eine USB Stich gemountet lagern.
Den Pfad für die Source kann ich definieren, allerdings würde ich auch gerne die Destination des Result.png als Attr definieren.  Wäre das möglich?

Danke für das super Modul und Gruss
Remo

eki

Du kannst als Parameter nach dem Namen des Picturefiles noch den Namen eines Subfolders angeben (unterhalb de FHEM Verzeichnisses und bisher nur beim Define und nicht als Attribut). Wenn das auf einen USB Share laufen soll müsstest Du dann einen Link in den FHEM Ordner legen und den als Subfolder angeben.
Ich könnte das aber auch noch als Attribut in der nächsten Version vorsehen, denke ich.

appi

danke, werde ich probieren.
Was mir auch noch aufgefallen ist, nach einem Fhem restart ( z.B. shutdown restart ), bekomme ich den Fehler: define Ink_Display ESPEInk www/images/Ink_Display/remo10.png: ESPEInk: Invalid filename www/images/Ink_Display/remo10.png. Must point to a readable file

Das File wird tatsächlich gelöscht, verstehe ich nicht. Wenn ich das File wieder an den obigen Pfad kopiere kann ich mit einem rereadcfg mein ESPInk Device wieder benutzen.

eki

Das Verzeichnis images/<EInkName> ist eigentlich als temporäres Verzeichnis gedacht (wird, falls es nicht exisitiert, vom Modul angelegt). Dort sollten eigentlich nur die temporären Dateien liegen und diese werden beim Beenden (z.B. beim Löschen des Devices) gelöscht (ob das auch beim Shutdown passiert, muss ich noch mal schauen). Dein Template Bild sollte also möglichst woanders liegen (und beim Anlegen mit "define..." auch mit einem anderen Pfad als der vorher beschriebene Verzeichnisname festgelegt werden.

mi.ke

FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

arthur_dent_2015

Zitat von: eki am 24 März 2020, 13:02:09
Was man machen müsste (zumindest) wäre, einen Webserver auf den Arduino bringen, der Bilder entgegen nimmt und dann auf das Display schiebt. Falls das vorhanden wäre, könnte ich das sicher auch in das FHEM Modul mit einbauen.

Ein example für einen Webserver ist jetzt vorhanden: https://github.com/e-radionicacom/Inkplate-6-Arduino-library/blob/master/examples/2.%20Advanced%20Inkplate%20Features/9-Inkplate_Web_Server
Kannst Du Dir ja mal ansehen und gucken ob Du das irgendwie in Dein Modul integrieren kannst.
Meins ist heute angekommen, macht nen guten Eindruck, und soll jetzt asap seinen Dienst in Fhem aufnehmen ;)

Danke & Gruß
Arthur

viegener

Zitat von: arthur_dent_2015 am 24 August 2020, 14:49:22
Ein example für einen Webserver ist jetzt vorhanden: https://github.com/e-radionicacom/Inkplate-6-Arduino-library/blob/master/examples/2.%20Advanced%20Inkplate%20Features/9-Inkplate_Web_Server
Kannst Du Dir ja mal ansehen und gucken ob Du das irgendwie in Dein Modul integrieren kannst.
Meins ist heute angekommen, macht nen guten Eindruck, und soll jetzt asap seinen Dienst in Fhem aufnehmen ;)

Danke & Gruß
Arthur

Nun ja der Webserver ist ja recht rudimentär. ich denke was eki meinte ist ein WebServer, der das gesamte Bild entgegennimmt wie bei waveshare und dann auf das Display bringt.

Generell ist auch das machbar, denn auch der Code für das Waveshare ist ja Arduino-Code und in beiden Fällen werkelt ein ESP32 (oder ESP8266) - Generell erscheint mir das inkplate sogar besser geeignet, denn das Rendering der Seite in FHEM ist schon relativ aufwändig und erzeugt erhebliche Last (und freezes bei mir).

In einem ersten Schritt müsste also der Code des Waveshare-Webservers auf den Inkplate portiert werden und die Ansteuerung für das Display mit den Daten auf die Inkplate library verändert werden.
Generell kein zu kompliziertes Unterfangen, allerdings muss man dafür auch ein inkplate display haben...


Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Jendaw

Zitat von: viegener am 24 August 2020, 15:04:50
Generell erscheint mir das inkplate sogar besser geeignet, denn das Rendering der Seite in FHEM ist schon relativ aufwändig und erzeugt erhebliche Last (und freezes bei mir).
Wenn das Display das Rendering durchführen soll, dann muss jeder die (ESP-)Firmware seinen Wünschen anpassen. Es muss ja jede Form einzeln gezeichnet werden. Oder wie meinst du das?
Mein Vorschlag wäre, das Rendering weiterhin in FHEM durchzuführen und mit der Inkplate-Lib nur als Vollbild darzustellen. Würde dir aber nicht helfen.

VG
FHEM/RaspberryMatic @RaspPi + nanoCUL 433 + Signalduino 433 + JeeLink-Clone + CC2531 + Slaesh-Stick
IT Funkschalter, HE-Sensoren, TX 29 DTH-IT, HMIP, HM-Wired, zigbee2mqtt
ESPEInk + waveshare 7.5inch_e-Paper_HAT_(B) + ESP8266 (Firmware von https://github.com/Yattien)

arthur_dent_2015

Zitat von: Jendaw am 24 August 2020, 15:20:54
Mein Vorschlag wäre, das Rendering weiterhin in FHEM durchzuführen und mit der Inkplate-Lib nur als Vollbild darzustellen. Würde dir aber nicht helfen.
Käme auf nen Versuch an, mein Raspi 4 mit 8GB sollte da nicht so das Problem haben, denke ich. Da ich wohl der Einzige mit Inkplate hier bin wird sich niemand hinsetzen und nen kompletten Webserver dafür entwickeln oder portieren, selbst wenn ich meins für die Entwicklung zur Verfügung stellen würde :(  Aber vielleicht bestellt ja noch der eine oder andere und die Nachfrage steigt. Die Dinger sind ja jetzt real verfügbar. Meins hat 3 Tage aus Texas zu mir gebraucht ;)

Gruß
Arthur

jowe

Ich habe auch ein inkplate und wäre begeistert, es für fhem nutzen zu können!

viegener

Zitat von: arthur_dent_2015 am 24 August 2020, 15:48:09
Käme auf nen Versuch an, mein Raspi 4 mit 8GB sollte da nicht so das Problem haben, denke ich. Da ich wohl der Einzige mit Inkplate hier bin wird sich niemand hinsetzen und nen kompletten Webserver dafür entwickeln oder portieren, selbst wenn ich meins für die Entwicklung zur Verfügung stellen würde :(  Aber vielleicht bestellt ja noch der eine oder andere und die Nachfrage steigt. Die Dinger sind ja jetzt real verfügbar. Meins hat 3 Tage aus Texas zu mir gebraucht ;)

Gruß
Arthur

Der begrenzende Faktor ist nicht die generelle Kapazität des Rechners, sondern das FHEM im Grundsatz ein einzelner Prozess ist. Damit gilt für das Modul in der jetzigen Form, dass alle anderen Dinge warten müssen (auch die Bearbeitung von Events und Schaltbefehlen). Es müsste entweder das Modul die Erzeugung in einen separaten Prozess (Blocking call) auslagern oder eben auf das Displaymodul.

Mein Punkt ist, dass
1) Unterschiedliche Displays auch unterschiedliche Ansteuerungen haben
2) Ein ESP-32 mit 2 Kernen sich sowieso eher langweilt
3) Eine lokale Erzeugung zwar eine komplexere Übergabe erfordert aber auch mehr Möglichkeiten schafft auch andere Dinge anzuzeigen (und häufiger) - Beispiel Uhrzeit, Status des ESP32, ...

Ich habe ja siehe früheren Beitrag die Umwandlung schonmal umgebaut, so dass sie deutlich weniger Zeit in Anspruch nimmt aber bei einem grossen Display (7,5 '' waveshare) dauert es immer noch regelmässig über 1 Sek und das Inkplate hat sogar deutlich mehr Pixel...

Vielleicht muss ich mir so ein Ding bestellen, ab 90€ ist ja eigentlich kein Schnäppchen wenn man berücksichtigt, dass das Display ja recycltet ist....



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Jendaw

Zitat von: viegener am 24 August 2020, 17:34:35
Der begrenzende Faktor ist nicht die generelle Kapazität des Rechners, sondern das FHEM im Grundsatz ein einzelner Prozess ist. Damit gilt für das Modul in der jetzigen Form, dass alle anderen Dinge warten müssen (auch die Bearbeitung von Events und Schaltbefehlen). Es müsste entweder das Modul die Erzeugung in einen separaten Prozess (Blocking call) auslagern oder eben auf das Displaymodul.

Mein Punkt ist, dass
1) Unterschiedliche Displays auch unterschiedliche Ansteuerungen haben
2) Ein ESP-32 mit 2 Kernen sich sowieso eher langweilt
3) Eine lokale Erzeugung zwar eine komplexere Übergabe erfordert aber auch mehr Möglichkeiten schafft auch andere Dinge anzuzeigen (und häufiger) - Beispiel Uhrzeit, Status des ESP32, ...

Ich habe ja siehe früheren Beitrag die Umwandlung schonmal umgebaut, so dass sie deutlich weniger Zeit in Anspruch nimmt aber bei einem grossen Display (7,5 '' waveshare) dauert es immer noch regelmässig über 1 Sek und das Inkplate hat sogar deutlich mehr Pixel...
Ich verstehe deinen Punkt. Und genau bei der komplexeren Übergabe sehe ich das Problem, dass es für die meisten Anwender nicht mehr händelbar ist. Möglicherweise könnte man die Werteübergabe noch mit JSON kapseln. Wenn man dann jedoch mit (Wetter)Icons usw. hantiert, wird es mMn unnötig kompliziert.
Je nachdem, wo FHEM läuft, könnte man einen separaten Prozess (/Thread) für die Umwandlung vorsehen, wie du vorgeschlagen hast. Wenn ein Blocking Call das ist, was der Name suggeriert, würde er nicht helfen, da FHEM dann auch warten muss, oder? Ich für meinen Teil finde ESPEInk, aufgrund seiner Einfachheit mit dem Rendern in FHEM, bestechend.
Btw. mit einer angepassten ESP32-Firmware kann sich der ESP auch schlafen legen und wird per MQTT auf neue Daten aufmerksam gemacht.

VG
FHEM/RaspberryMatic @RaspPi + nanoCUL 433 + Signalduino 433 + JeeLink-Clone + CC2531 + Slaesh-Stick
IT Funkschalter, HE-Sensoren, TX 29 DTH-IT, HMIP, HM-Wired, zigbee2mqtt
ESPEInk + waveshare 7.5inch_e-Paper_HAT_(B) + ESP8266 (Firmware von https://github.com/Yattien)

arthur_dent_2015

Zitat von: viegener am 24 August 2020, 17:34:35
Der begrenzende Faktor ist nicht die generelle Kapazität des Rechners, sondern das FHEM im Grundsatz ein einzelner Prozess ist. Damit gilt für das Modul in der jetzigen Form, dass alle anderen Dinge warten müssen (auch die Bearbeitung von Events und Schaltbefehlen). Es müsste entweder das Modul die Erzeugung in einen separaten Prozess (Blocking call) auslagern oder eben auf das Displaymodul.

Mein Punkt ist, dass
1) Unterschiedliche Displays auch unterschiedliche Ansteuerungen haben
2) Ein ESP-32 mit 2 Kernen sich sowieso eher langweilt
3) Eine lokale Erzeugung zwar eine komplexere Übergabe erfordert aber auch mehr Möglichkeiten schafft auch andere Dinge anzuzeigen (und häufiger) - Beispiel Uhrzeit, Status des ESP32, ...

Ich habe ja siehe früheren Beitrag die Umwandlung schonmal umgebaut, so dass sie deutlich weniger Zeit in Anspruch nimmt aber bei einem grossen Display (7,5 '' waveshare) dauert es immer noch regelmässig über 1 Sek und das Inkplate hat sogar deutlich mehr Pixel...

Vielleicht muss ich mir so ein Ding bestellen, ab 90€ ist ja eigentlich kein Schnäppchen wenn man berücksichtigt, dass das Display ja recycltet ist....
Das Modul müsste auf Blocking Call umgeschrieben werden. Ein Raspi 4 mit RAM > 1GB sollte damit dann locker umgehen können.
Deine 3 Punkte unterschreibe ich. Ich denke aber dass dann ein eigenes Modul für das Inkplate her müsste. Mehrere Displays mit einem Modul ansteuern, der Code dürfte schnell unübersichtlich werden. Leider ist die Dokumentation für das Inkplate noch unvollständig https://inkplate.readthedocs.io/en/latest/index.html
Ja, für €129 (inkl. Rahmen und Porto) bekommst Du 3 Waveshare mit ähnlichen Eigenschaften, aber eben kein Kindle ;) , keine Elektronik für die Ansteuerung und keinen ESPxxxx. Außerdem bewahrt man damit einige vor der Verschrottung :)

Zitat von: Jendaw am 24 August 2020, 17:59:37
Ich verstehe deinen Punkt. Und genau bei der komplexeren Übergabe sehe ich das Problem, dass es für die meisten Anwender nicht mehr händelbar ist. Möglicherweise könnte man die Werteübergabe noch mit JSON kapseln. Wenn man dann jedoch mit (Wetter)Icons usw. hantiert, wird es mMn unnötig kompliziert.
Je nachdem, wo FHEM läuft, könnte man einen separaten Prozess (/Thread) für die Umwandlung vorsehen, wie du vorgeschlagen hast. Wenn ein Blocking Call das ist, was der Name suggeriert, würde er nicht helfen, da FHEM dann auch warten muss, oder? Ich für meinen Teil finde ESPEInk, aufgrund seiner Einfachheit mit dem Rendern in FHEM, bestechend.
Btw. mit einer angepassten ESP32-Firmware kann sich der ESP auch schlafen legen und wird per MQTT auf neue Daten aufmerksam gemacht.

VG
Ein Blocking Call macht genau das Gegenteil von dem was der Name suggeriert (wenn ich das richtig verstanden habe) siehe https://wiki.fhem.de/wiki/Blocking_Call.
Das Inkplate kann wohl Web Seiten out of the box darstellen, aber dann langweilt sich der ESP. Wie viegener schon geschrieben hat, die Möglichkeiten, die sich damit auftun, wären viel größer :)
Da wir jetzt schon 2 Interssenten sind, sollten wir vielleicht einen eigenen Thread für das Inkplate aufmachen??? Vielleicht outen sich dann noch mehr Inkplate Besitzer...