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

[eki]

Hallo zusammen,

ich habe mich jetzt auch mal an ein eigenes Modul gewagt. Es steuert EInk Anzeigeelemente (z. B. https://www.waveshare.com/wiki/2.9inch_e-Paper_Module_(C)) von Waveshare über das ESP8266 Treiber Modul https://www.waveshare.com/wiki/E-Paper_ESP8266_Driver_Board der gleichen Firma an, und kann sowohl Bilder, als auch FHEM readings als Text auf diesen Devices darstellen.

Voraussetzungen: siehe Commandref zum Modul.

Features:

• Direkte Anbindung über die IP Adresse des Treiber Moduls
• Unterstützung von Displays verschiedener Größen, siehe https://www.waveshare.com/wiki/2.9inch_e-Paper_Module_(C)
• Nutzung von Bildern als Templates
• Hinzufügen von Texten über die Template Bilder entweder direkt oder aus FHEM readings
• Updates des Displays entweder Eventgetriggert über Änderung von Readings oder regelmäßig mit interval paramter
• Umrechnung des Bildes mit verschiedenen Varianten (farbe/monochrom, level/dithering) um möglichst gute Darstellung auf dem e-Paper zu erhalten
• ... siehe Commandref zum Modul

Das Modul ist angehängt und aktuell in einem Beta Status würde ich sagen. Ich habe selbst nur eine variante des ePapers und kann also damit testen. Wäre also interessiert, wenn jemand solche Devices hat und als Tester mitmachen könnte.
Natürlich wäre ich auch an Tipps von erfahrenen Modulentwicklern interessiert.

Edit 4.11.2019:
Neue version
Achtung, Name ist geändert, bestehende Devices müssen mit neuem Namen neu definiert werden)
Zusätzliche Features:

• Neben Texten können jetzt auch Icons dargestellt werden. Es können sowohl Icons aus Readings anderer Devices (z.B. die on/off Lampensymbole als FHEM Icons oder die Wetter Icons z.B. aus den PROPLANTA Wettermodul Readings) als auch statisch alle fhem Icons sowie auch Icons aus dem Web (per URL anzugeben) verwendet werden (set <dev> addicon bzw. set <dev> iconreading)
• Unterstützung von SVG Icons
• Es wird nebem dem ESP8266 board auch das ESP32 board unterstützt (daher die Namensänderung)
• Angabe des Unterordners im Dateisystem als Basis für temporäre Dateien (bei der Definition des Devices, siehe Commandref)
• Fehlerkorrekturen

Edit 25.11.2019:
Neue version
Zusätzliche Features:

• Die Konvertierung find jezt "non-blocking" im Hintergrund statt, FHEM bleibt damit bedienbar
• Es gibt ein neues Attribut, über das alternativ die Objekte auf dem Display definiert werden können
• Readings können formatiert werden (z.B. mit Einheit angefügt etc.)
• Positionen (x,y) können jetzt auch als left/mid/right/top/bottom angegeben werden. Wenn hinter left/mid/right/top/bottom noch eine Zahl steht, so wird ein entsprechender Abstand vom Rand bzw. der Mitte eingehalten

[reibuehl]

Das hört sich ja spannend an. Könntest Du mal ein paar Bilder posten, wie das dann aussieht?

[eki]

Hier mal Bilder, wie das aussieht. Die rohen Displays gibt es in verschiedene Größen zu kaufen (ab 1.5 Zoll so für 5 Euro bis ca. 7.5 Zoll Diagonale für 45 Euro z.B. bei Alibaba). Der Treiber (ca. 15 Euro) basiert auf einem ESP8266, der über Arduiono Softwarepakete konfiguriert wird und dann über WLAN von FHEM aus erreichbar ist. Man kann die Displays also dann irgendwo verbauen, und über USB entweder aus einer Batterie oder per Stromanschluss mit Strom versorgen.
Anwendungsbeispiele sind jegliche Art von Anzeigen, die sich nicht sehr häufig ändern (also keine Filme oder so etwas) und die wenig Strom brauchen sollen. Also z.B. als variables Türklingelschild oder Türschild oder eben als Statusanzeige für FHEM irgendwo.

[reibuehl]

Sorry, ich meinte wie eine Ausgabe mit Deinem Modul aussieht... ich hab nämlich hier schon ein paar von den Displays liegen :-)

[eki]

Na das ist ja weitestgehend variabel (wie gesagt, auf Basis eines Bildes auf dem alles drauf sein kann und mit beliebigen Texten and beliebiger Stelle mit beliebigem TTF Font und beliebiger Farbe und beliebiger Rotation). Ich werde demnächst mal Beispiele posten.
Darüber hinaus kannst Du im Modul Dir auch immer anschauen, wie das Bild aussehen wird. Das Blid, das an das Display übertragen wird, wird als Reading im Modul angezeigt wenn man "set convert" macht (siehe angehängter Snapshot).

[andies]

was ist denn der Unterschied dieser Displays zu den Nextion-Displays?

[eki]

Von Nextion kenne ich nur LCDs.

Der Hauptunterschied zwischen ePaper und LCD ist, dass das ePaper auch ohne Storm wochenlang das Bild anzeigt. Der Treiber braucht natürlich etwas Strom, geht aber in einen deep sleep Modus wenn er nicht gebraucht wird. Damit lassen sich relativ gut Displays mit Batterien irgendwo abgesetzt aufbauen. Dafür dauert das Ändern eine gewisse Zeit, somit macht das nur Sinn wenn man etwas anzeigen will, das Sicht nicht zu oft ändert.

[max333]

Ich habe dein Modul ausprobiert, aber leider startet mein ESP32 bei jedem upload neu. Brauche ich da eine andere Firmware für den ESP32? Als display habe ich das 7.5inch_e-Paper_HAT_(B).

[eki]

Ich habe bisher nur mit dem ESP8266 getestet (den ESP32 habe ich nicht). Ich müsste mir mal anschauen, was da die Unterschiede sind. Ich melde mich wieder.

[eki]

Ich habe dein Modul ausprobiert, aber leider startet mein ESP32 bei jedem upload neu. Brauche ich da eine andere Firmware für den ESP32? Als display habe ich das 7.5inch_e-Paper_HAT_(B).

Beim ESP32 läuft die Kommunikation etwas anders, das müsste ich anpassen (dann würde ich auch den Namen von ESP8266EInk auf ESPEInk ändern). Allerdings habe ich, wie gesagt, kein ESP32 board, Du müsstest mir beim Testen also ein bisschen helfen (wird sicher einige Male hin und her gehen, und ein bisschen Aufwand auch für Dich).

[max333]

Klar ich helfe doch gern 

Mit GxEPD experimentiere ich auch noch, aber da bekomme ich den ESP32 von Waveshare nicht zum laufen.

[eki]

So, hier wäre mal eine Version, die neben diversen anderen Verbesserungen (z.B. Darstellung von beliebigen Icons, auch auf Basis von Readings, jede Menge Fehlerkorrekturen und Verbesserungen, ...) auch ein erster Versuch für das ESP32 Board ist.
Es gibt dazu ein Attribut boardtype, welches standardmäßig auf ESP8266 steht, das man aber auf ESP32 setzen kann. Dann wird der Uploadmechanismus entsprechend angepasst. Wie gesagt, ich konnte nicht mit der echten HW testen, daher nicht enttäuscht sein, wenn es nicht auf Anhieb funktioniert 
Noch ein Beispiel wie das Ergebnis aussehen kann.

[max333]

Vielen Dank für das Update.

Wenn ich in Paint eine PNG-Datei erstelle, hängt sich der ESP32 auf. Mit Corel erstellte lassen sich anzeigen.

[eki]

Verstehe ich das richtig, die Daten über ESP32 auf's Display schieben klappt auf Anhieb (zumindest mit den "guten" png Dateien??

Der zweite Teil wundert mich. Kannst Du mir mal Beispiele der funkionierenden und nicht funktionierenden png Dateien schicken, und auch Deine Device Definition (list <name> in FHEM).

[max333]

Den Fehler mit der PNG-Datei von Paint kann ich leider nicht reproduzieren, da ich die "fehlerhafte" mit der von Corel überschrieben habe und glücklich war, dass es jetzt funktioniert.

Hilfreich wären noch paar Beispiele, wie man dynamische Inhalte darstellen kann.