FHEM Forum

FHEM - Hausautomations-Systeme => Sonstige Systeme => Thema gestartet von: eki am 02 Oktober 2019, 10:24:53

Titel: Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 Oktober 2019, 10:24:53
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) (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 (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:

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:

Edit 25.11.2019:
Neue version
Zusätzliche Features:
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: reibuehl am 02 Oktober 2019, 12:26:47
Das hört sich ja spannend an. Könntest Du mal ein paar Bilder posten, wie das dann aussieht?
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 02 Oktober 2019, 12:43:31
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: reibuehl am 02 Oktober 2019, 12:53:34
Sorry, ich meinte wie eine Ausgabe mit Deinem Modul aussieht... ich hab nämlich hier schon ein paar von den Displays liegen :-)
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 02 Oktober 2019, 13:22:22
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).
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: andies am 02 Oktober 2019, 21:53:34
was ist denn der Unterschied dieser Displays zu den Nextion-Displays?
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 02 Oktober 2019, 22:18:55
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: max333 am 08 Oktober 2019, 20:48:45
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).
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 09 Oktober 2019, 09:25:49
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 10 Oktober 2019, 15:55:13
Zitat
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).
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: max333 am 10 Oktober 2019, 19:45:45
Klar ich helfe doch gern  :)

Mit GxEPD experimentiere ich auch noch, aber da bekomme ich den ESP32 von Waveshare nicht zum laufen.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 29 Oktober 2019, 13:46:37
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: max333 am 30 Oktober 2019, 18:29:38
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 31 Oktober 2019, 09:43:10
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).
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: max333 am 02 November 2019, 12:21:20
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.
Titel: Antw:Neues Modul: ESP8266EInk für e-Paper Displays
Beitrag von: eki am 04 November 2019, 10:03:30
Na gut, falls es weitere Infos aus dem Betrieb gibt, lass es mich wissen. Ich werde die Version also jetzt mal so im ersten Post "freigeben".

Als Beispiel für dynamische Inhalte siehe die Definition der Wetteranzeige für das 2.9 Inch Display:
defmod testInk ESPEInk /opt/fhem/www/images/test_fhem.png

attr testInk convertmode dithering
attr testInk devicetype 2.9inch_e-Paper_Module_(C)

set testInk addtext Wettervorhersage#10#100#12#0#FFFFFF#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk textreading AgroWeather:fc0_date#10#10#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk iconreading AgroWeather:fc0_weatherDayIcon#170#0#90
set testInk addicon thermometer-full#10#30#25
set testInk addicon thermometer-empty#10#60#25
set testInk textreading AgroWeather:fc0_tempMax#35#32#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk textreading AgroWeather:fc0_tempMin#35#64#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addtext °C#55#32#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addtext °C#55#64#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addicon tint#90#32#23
set testInk textreading AgroWeather:humidity#115#32#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addtext %#150#32#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addicon umbrella#90#64#23
set testInk textreading AgroWeather:fc0_chOfRainDay#115#64#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
set testInk addtext %#150#64#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 16 November 2019, 14:17:44
Hab gestern endlich das ESP8266-Treiberboard und ein 7,5"-Waveshare-Display (Gelb/Schwarz/Weiß) bekommen.

Mal die Software auf den ESP geladen und dein Modul installiert.

Jetzt hab ich aber immer folgendes Problem (Egal, ob vom Modul aus oder von der Weboberfläche).
EINMAL kann ich das Display aktualisieren, danach reagiert der ESP nicht mehr. Also auch die Webseite kann nicht mehr geladen werden und läuft in ein Timeout.

Kennt das Problem jemand? Ideen/Lösungsansätze dazu?

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 16 November 2019, 19:50:34
Also, ich habe das Thema jetzt so gelöst, dass ich im Sourcecode nach jedem Bild-Upload einfach mal den ESP resette. Funktioniert soweit.

Nach ein paar Stunden herumexperimentieren mit dem Modul hier mal ein paar Änderungswünsche / Verbesserungsvorschläge:
1) "set convert" nach Möglichkeit im Hintergrund ausführen. Die Umwandlung dauert auf meinem Cubietruck (der ansonsten recht performant ist) ca. 20-30 Sekunden, in dieser Zeit blockiert FHEM komplett.
2) Statt "set textreading" etc. würde ich EIN Attribut mit :textlong machen, in dem die ganzen Defs sind.
     Bei Änderung des Attributs einfach die Readings neu erstellen. Würde Änderungen immens erleichtern, gerade in der Experimentierphase.
     Ausserdem wären dann die ganzen UserReadings 1-x, 1-y etc. unnötig.
3) Möglichkeit, Texte links/zentriert/rechtsbündig anzuordnen.

Kommen sicher noch einige Vorschläge, falls gewünscht.

Vorerst wären mal 1) und 2) wichtig :)

lg, Stefan

Edit: Noch was ist mir grade aufgefallen:
Ich hab ein Farbdisplay. FHEM speichert die Attribute in alphabetischer Reihenfolge.
Somit bekomm ich beim starten einen Fehler, weil "colormode color" VOR dem Boardtype gesetzt wird.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Laffer72 am 16 November 2019, 21:18:24
Hallo Eki,

tolle Idee. Scheitere aber leider schon bei der Definition. Kann Modul nicht laden.

Wenn ich  ein Reload des Moduls mache kommt folgende Meldung:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/89_ESPEInk.pm line 8.
BEGIN failed--compilation aborted at ./FHEM/89_ESPEInk.pm line 8.

Php-gd hab ich schon installiert. Muss ich noch was installieren?

Danke schonmal für die Mühe

Reinhard
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 16 November 2019, 21:20:56
sudo apt-get install libgd-perl
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Laffer72 am 16 November 2019, 21:34:11
Danke, jetzt klappt die Definition.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 18 November 2019, 08:51:30
Also, ich habe das Thema jetzt so gelöst, dass ich im Sourcecode nach jedem Bild-Upload einfach mal den ESP resette. Funktioniert soweit.

Nach ein paar Stunden herumexperimentieren mit dem Modul hier mal ein paar Änderungswünsche / Verbesserungsvorschläge:
1) "set convert" nach Möglichkeit im Hintergrund ausführen. Die Umwandlung dauert auf meinem Cubietruck (der ansonsten recht performant ist) ca. 20-30 Sekunden, in dieser Zeit blockiert FHEM komplett.
2) Statt "set textreading" etc. würde ich EIN Attribut mit :textlong machen, in dem die ganzen Defs sind.
     Bei Änderung des Attributs einfach die Readings neu erstellen. Würde Änderungen immens erleichtern, gerade in der Experimentierphase.
     Ausserdem wären dann die ganzen UserReadings 1-x, 1-y etc. unnötig.
3) Möglichkeit, Texte links/zentriert/rechtsbündig anzuordnen.

Kommen sicher noch einige Vorschläge, falls gewünscht.

Vorerst wären mal 1) und 2) wichtig :)

lg, Stefan

Edit: Noch was ist mir grade aufgefallen:
Ich hab ein Farbdisplay. FHEM speichert die Attribute in alphabetischer Reihenfolge.
Somit bekomm ich beim starten einen Fehler, weil "colormode color" VOR dem Boardtype gesetzt wird.

Kannst Du mal Deine Änderung in Source Code hier posten, dann würde ich das mit übernehmen und alle könnten profitieren  ;).

Zu 1) Das ist leicht gesagt. Dazu fällt mir aktuell nur ein, die Konvertierung in ein extra script auszulagern und dann per "system" Kommando aufzurufen (das wäre eine ziemlich große Änderung) oder ein fork (damit habe ich aber keine Erfahrung). Oder hast Du eine andere Idee wie das gehen soll (bin leider auch nicht so der Perl Guru)?
Zu 2) Lässt sich machen, würde ich aber nur als zusätzliche Möglichkeit zur Definition vorsehen und trotzdem die readings belassen. Ansonsten müsste ich das ganze Modul mehr oder weniger neu machen.
Zu 3) Das ist wahrscheinlich der Einfachste von den 3 Wünschen (ist ja wie bei Kinderüberraschung  ;) ). Mache ich bei Gelegenheit.

Ergänzung zu 1). Habe gerade gesehen, dass es da etwas in FHEM gibt (Blocking Modul). Muss ich mir mal genauer anschauen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 18 November 2019, 18:14:21
Hi Eki,

also, zum Thema SourceCode beim ESP. Da hab ich direkt in dem Waveshare-Treiber ein ESP.restart eingefügt:
void EPD_Show()
{
  Serial.println("SHOW");
  // Show results and Sleep
  EPD_dispMass[EPD_dispIndex].show();
  server.send(200, "text/plain", "Show ok\r\n");
  Serial.println("Back from SHOW");
  ESP.restart();
}

Ist also leider nichts, was du im Modul übernehmen könntest.
Eigentlich bin ich absolut gegen solche Holzhammer-Methoden, genauso wie gegen irgendwelche regelmäßigen Reboots von Pi's oder so. Da gehört die Ursache selbst gelöst, nicht das Problem.
Aber aktuell hab ich einfach keine Zeit, mich damit weiter zu beschäftigen.

Zu 1):
Stichwort Non-Blocking-Modul, ja genau. Hab zwar selbst noch nciht damit gearbeitet, ist aber schon ziemlich verbreitet, sollte also problemlos zum laufen zu bekommen sein.

Zu 2) Wenn du die Readings lässt, brauchst du ja nur zusätzlich in der AttrFn auf ein Attribut lauschen, und bei dessen Änderung halt immer die Readings löschen und neu anlegen.
Ist halt einfach vom Bearbeiten her leichter. Ausserdem gilt ja immer der Grundtenor "Attribute gehören den Usern!" :)
Und es ist halt einfacher, EIN Attribut zu ändern, als zig einzelne, um zB Einen Text anders zu formatieren oder so.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 19 November 2019, 08:10:38
Zu 1) läuft bei mir schon war tatsächlich nicht schwer. Wenn ich es ein bisschen getestet habe, füge ich es an.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 19 November 2019, 08:40:06
Guten Morgen,

noch einen Vorschlag/Wunsch: ein x-format-Eintrag, um Readings zu formatieren. Im Idealfall mit "eval" ausgewertet, um auch Perl-Code ausführen zu können.
So wie beim FReplacer das "RepxxExpr".

attr fr_EInk Rep03Expr {sprintf("%.1f°C",ReadingsVal("Temp_Aussen","statTemperatureDayMin",0))}
lg, Stefan

Edit: Oder vlt. ganz einfach: Das x-def-Reading mit RegEx auswerten....Wenn in {} eingeschlossen, ists ein Perl-Ausdruck, also mit "eval" behandeln....Andernfalls ists ein Device:Readings-Name, also wie bisher auswerten.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 19 November 2019, 12:52:05
Zu 2) hätte ich einen Vorschlag. Es gibt ja schon die Readings, die die gesamte Definition enthalten (habe ich dafür angelegt, die Attributbasierten Änderungen zurück zu nehmen, wenn man die Attribute wieder löscht (dann wird das Ganze wieder auf die Startdefinition gesetzt).
Wenn ich nun ein Attribut vorsehen würde das genau diese x-def Werte setzt, wäre das dann entsprechend das, was Du Dir dachtest?

Edit: Ich habe jetzt mal eine Version zum testen angehängt. Kann 1) und 2). Für 2) gibt es ein Attribut "definition" in dem Zeilenweise mit genau der gleichen Syntax wie bei den anderen defs (siehe x-def) Objekte definiert werden können, die dann zusätzlich zu denen, die es bisher gab, dargestellt werden.

Beispiel:
addicon#icoTemp#190#100#12#0#FFFFFF
addtext#Hallo#210#100#12#0#FFFFFF#giant
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 20 November 2019, 20:10:03
Zitat
Ich habe jetzt mal eine Version zum testen angehängt. Kann 1) und 2). Für 2) gibt es ein Attribut "definition" in dem Zeilenweise mit genau der gleichen Syntax wie bei den anderen defs (siehe x-def) Objekte definiert werden können, die dann zusätzlich zu denen, die es bisher gab, dargestellt werden.

Cool, genau so war's gemeint :)

lg, Stefan

PS: Empfehlung: Ersetze das Modul im ersten Post, statt die neuere Version in dem Beitrag hier drüber zu posten.
Wenn mal jemand das Modul runterladen will, hat er so immer die aktuellste Version, statt den ganzen Thread durchsuchen zu müssen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 20 November 2019, 21:39:53
Also, irgendwie klappt das noch nicht, oder ich mach was falsch.

Neues Modul geladen, reload gemacht (Convert im Hintergrund funktioniert)
Die alten Readings alle gelöscht, dann ein
attr EInk definition textreading#Weather2:current_date_time#100#29#12#0#DDFF00#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
iconreading#Weather2:fc1_icon#130#235#90\
textreading#Weather2:HeuteMax#95#247#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Weather2:HeuteMin#35#247#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Weather2:fc1_condition#35#320#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Temp_Aussen:TempText#80#85#28#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Temp_Aussen:statTemperatureDayMin#75#150#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Temp_Aussen:statTemperatureDayMax#75#165#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myAstro:MoonPhaseS#190#180#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myAstro:SunRise#240#150#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myAstro:SunSet#240#165#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myAstro:MoonRise#320#150#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myAstro:MoonSet#320#165#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addicon#weather_moon_phases_3_half#290#150#25\
addicon#weather_sun#210#150#25#0#DDFF00\
textreading#myLuftdaten:pressure#180#120#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
hinzugefügt.

Danach ein Convert angestossen.
Ergebnis siehe Bild. :(
Die Icons werden geladen, aber die textreadings nicht richtig umgewandelt.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 21 November 2019, 00:02:57
ups, ich habe bisher nur addicon und addtext eingebaut. Neue Version folgt und wenn die einigermaßen stabil ist und ich die anderen Sachen auch noch drin habe, ersetze ich natürlich auch den Link im ersten Post.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 22 November 2019, 17:14:37
Angehängte Version müsste jetzt eigentlich auch mit "textreading" und "iconreading" gehen.
Darüber hinaus habe ich die Möglichkeit eingebaut, dass man bei den event basierten Objekten auch ein Format angeben kann (eval auf einen vom Nutzer eingegebenen Text gefällt mir nicht so, das macht jede Menge Türen für komische Dinge auf und ich habe keine Lust da 1000 Prüfungen einzubauen). Man kann jetzt normale Formatierungen wie bei sprintf in "{}" nach dem Reading eingeben also z.B.

textreading#AgroWeather:fc0_tempMax{%.1f °C}#35#32#14#0#000000#C:\Windows\Fonts\arial.ttf

Das mit rechtsbündig/zentriert etc. ist etwas tricky (weil man bei nichtproportionalen Fonts erst mal heraus bekommen muss, wie lang der Text wird, da muss ich noch forschen) und kommt später.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 22 November 2019, 21:05:54
Yup, funktioniert.

Zum Thema
Zitat
eval auf einen vom Nutzer eingegebenen Text gefällt mir nicht so, das macht jede Menge Türen für komische Dinge auf und ich habe keine Lust da 1000 Prüfungen einzubauen).
Prüfungen brauchst keine.....Entweder es wird ein korrekter Text zurückgegeben, oder ein fehler....Fehler kann man ja anzeigen lassen.
Ist aber nicht so tragisch, ich löse das halt weiterhin mit Userreadings im Quell-Device :)

Was mir noch aufgefallen ist: Das "disable"-Attribut wertest du nicht aus, oder? gg

Jetzt muss ich nur noch herausfinden, wie ich meinen SVG-Kalender halbwegs hinbekomme, ohne dass er gedithert wird.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 23 November 2019, 14:21:22
Zitat
Prüfungen brauchst keine.....Entweder es wird ein korrekter Text zurückgegeben, oder ein fehler....Fehler kann man ja anzeigen lassen.
Ist aber nicht so tragisch, ich löse das halt weiterhin mit Userreadings im Quell-Device
Ich hatte eher an so Ausdrücke wie eval „system 'rm -r /'“ gedacht  ;). Mit der Nutzung der Format Funktion in {} müsste ja auch einiges gehen.

Disable werte ich schon aus. Der Timer für‘s automatische Aktualisieren wird gestoppt und die Events werden nicht mehr berücksichtigt.

Um dithering zu umgehen, solltest Du genau die Farben im Kalender haben, die das Device originär kann. Das sind in Deinem Fall folgende:
[0,0,0],[255,255,255],[220,180,0]
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 23 November 2019, 15:06:54
Zitat
Ich hatte eher an so Ausdrücke wie eval „system 'rm -r /'“ gedacht
Dazu bräuchte ich dein Modul nicht zu definen.......Das kann ich direkt in der Eingabezeile mittels "system 'rm -r /"  :P

Zitat
Mit der Nutzung der Format Funktion in {} müsste ja auch einiges gehen.
Einiges schon, aber zB die große Temp/Hum-Anzeige nicht, das sind ja zwei readings (wie gesagt, ist aber egal, hab eh das UserReading dafür)

Zitat
Disable werte ich schon aus.
Hmm, hab das EInk-Device mit attr disable 1 versehen, es aktualisiert aber trotzdem weiterhin das Vorschau-Bild und sendet es auch ans Display.
Grad eben letzter Eintrag im Log:
Zitat
2019.11.23 14:39:45 3: EInk: sending HTTP request to http://192.168.1.235/EPDu_ with data:
obwohl es seit 2 Tagen auf disabled steht.

Thema dithering: Ansich habe ich in dem SVG nur 0xffffff und 0x000000 in verwendung (ausser dem gelben Quadrat, welches den aktuellen Tag markiert.
Trotzdem sind die Linien teilweise mehr gelb als schwarz.
Muss ich mal schaun, evtl. eine Skalierungssache?

Schönes WE noch,

Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Laffer72 am 24 November 2019, 09:13:08
Hallo,

vielen Dank für das Modul, funktioniert soweit sehr gut.

Wenn ich Intervall auf 0 setzte aktualisiert er dann nur bei Änderung eines Readings?

Irgendwie krieg ich das mit den Icons noch nicht richtig zum Laufen. Ich bekommen nur Icons in png-Format angezeigt. Die svg-Icons werden mir nicht angezeigt. (Icons in opt/fhem/www/images/fhemSVG)

Wie kriegt Ihr die aktuelle Uhrzeit (also die Erstellungszeit der Grafik) in das Bild. Ich habe es mit einem UserReading mit strftime probiert, da wurde jede Minute das Bild convertiert und ein upload gestartet. Mit addtext funktioniert ja kein perl, wenn ich das richtig mitbekommen habe.

Viele Grüße und danke schonmal für die Antworten

Reinhard
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 25 November 2019, 09:25:14
Ja, wenn interval auf 0 steht, dann wird bei jeder Änderung eines der Readings, die an der Ausgabe beteiligt sind, ein "convert" und danach ein "upload" gemacht.

SVG Icons funktionieren nur, wenn Du, wie in der Commandref angegeben, https://metacpan.org/pod/XML::LibRSVG (https://metacpan.org/pod/XML::LibRSVG) installiert hast.

Wenn Du für die Erstellungszeit ein userReading des ESPEInk devices selbst nimmst und das Interval auf 0 setzt, wird aus meiner Sicht so eine Art Endlosschleife generiert, weil das userReading selbst ja auch wieder ein update triggert.
Am besten wäre es, aus meiner Sicht, die Uhrzeit aus den Readings des Devices zu nehmen, welches die Daten liefert.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 25 November 2019, 16:44:01
Ich habe im ersten Beitrag oben jetzt eine neue Version angehängt, die auch die Positionierung per left/mid/right/top/bottom kann.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 08 Dezember 2019, 16:54:24
Danke für diese tolle Modul für FHEM. Als ich zum ersten Mal davon gelesen habe, hat es mich gleich so begeistert, dass ich mir ein e-paper Display besorgte. Es ist ein 7.5inch_e-Paper_HAT_(B) geworden (also mit Rot als 3. Farbe).

Ich habe damit 2 Probleme:



edit: Fehlermeldungen im LOG:
libpng warning: iCCP: known incorrect sRGB profile
2019.12.08 16:34:13 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1037.
2019.12.08 16:46:12 1: einkDiplay01: problems with communication to device, max retries (3) reached

Devicedefintion:
defmod einkDiplay01 ESPEInk /opt/fhem/www/images/test_SWBalken.png
attr einkDiplay01 boardtype ESP8266
attr einkDiplay01 colormode color
attr einkDiplay01 convertmode dithering
attr einkDiplay01 definition attr einkDiplay01 definition \
addtext#Haussteuerung Augasse 5#100#10#24#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetter:current_date_time#200#45#18#0#FFFFFF#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Wetter heute#10#80#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetter:fc1_condition#10#100#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#aktuelle Temperatur °C#10#120#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetterstation:temperature#210#120#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Luftfeuchte %#10#140#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetterstation:humidity#210#140#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Tageshoch °C#10#160#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetter:fc1_high_c#210#160#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#(Tagestief  Ozon °C)#10#180#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetter:fc1_ozone#210#180#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Wind km/h#10#200#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Wetterstation:windSpeed#210#200#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Wettervorschau#10#225#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
iconreading#Wetter:fc2_icon#25#235#50#0#FF1000\
iconreading#Wetter:fc3_icon#120#235#50#0#FF1000\
iconreading#Wetter:fc4_icon#210#235#50#0#FF1000\
addtext#Regen %#5#295#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Hoch °C#5#315#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Tief °C#5#335#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#myProPlanta:fc2_chOfRain12#66#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc2_high_c#66#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc2_low_c#66#335#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
\
textreading#myProPlanta:fc3_chOfRain12#145#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc3_high_c#145#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc3_low_c#145#335#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
\
textreading#myProPlanta:fc4_chOfRain12#240#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc4_high_c#240#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
textreading#Wetter:fc4_low_c#240#335#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#  morgen         übermorgen          3.Tag#20#350#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Energie#315#80#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Photovoltaik kWh#315#100#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#Solar:Daily.Energy#500#100#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Stromverbrauch#315#120#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Gasverbrauch m³#315#140#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#c_Gaszaehler:verbrTagM#500#140#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
\
addtext#Status im Haus#315#200#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
addtext#Eingangstuer#315#220#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#NUKIDevice353363333:state#500#220#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#AV-Anlage heute kW#315#240#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#wzavplf:statEnergyDay_kWh#500#240#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Buecherregal W#315#260#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#wzbuecherregal:power#500#260#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#LAN heute kW#315#280#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#fb_stromazpc:statEnergyDay_kWh#500#280#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#Linux heute kW#315#300#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#azklinuxpc:statEnergyDay_kWh#500#300#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf\
addtext#USB-Lader W#315#320#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
textreading#c_zSchaltpower:power#500#320#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
attr einkDiplay01 devicetype 7.5inch_e-Paper_HAT_(B)
attr einkDiplay01 group Device
attr einkDiplay01 interval 7200
attr einkDiplay01 picturefile /opt/fhem/www/images/test_SWBalkenStrich.png
attr einkDiplay01 room System
attr einkDiplay01 scale2fit 1
attr einkDiplay01 url 10.0.0.130
attr einkDiplay01 verbose 1

setstate einkDiplay01 Successfully uploaded image to device
setstate einkDiplay01 2019-12-08 16:34:24 result_picture <html><img src=/fhem/images/einkDiplay01/result.png?dummy=610050.586037545></img><div>/fhem/images/einkDiplay01/result.png</div></html>
setstate einkDiplay01 2019-12-08 10:06:54 source_picture <html><img src=/fhem/images/einkDiplay01/test_SWBalkenStrich.png?dummy=690635.125798369></img><div>/fhem/images/einkDiplay01/test_SWBalkenStrich.png</div></html>
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 09 Dezember 2019, 10:52:49
Könntest Du bitte noch Dein Basisbild (test_SWBalken.png) posten. Dann kann ich das bei mir besser nachstellen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 09 Dezember 2019, 11:01:51
Natürlich (logo inzwischen eingefügt). Und großen Dank für Deine Hilfsbereitschaft bei diesem tollen Modul !!
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 09 Dezember 2019, 13:29:06
Hier habe ich mal eine neue Version, die den Fehler mit den 0en nicht mehr haben sollte. Das 2. Problem kann ich nicht nachvollziehen (ich kann allerdings nur die Daten vergleichen, die per HTTP an das Device geschickt werden und die sind identisch in der Oberfläche von Waveshare und bei meinem Modul).
max333 einige Beiträge weiter oben, hat ja das gleiche Display wie Du und er scheint es ja hinbekommen zu haben, er benutzt allerdings das ESP32 und nicht ESP8266, wie Du.
Icininger hat eine Modifikation im Treiber gemacht (reset). Vielleicht hilft das ja?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 09 Dezember 2019, 16:24:09
Vielen Dank !!

Mit der Installation meines perl-gd unter Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-71-generic x86_64) scheint etwas nicht zu stimmen. Ich sehe Fehler bedingt durch (ein altes?) GD.so -  ich mache gerade ein update des gesamten cpan. Ein install von GD::SVG schlug zuerst fehl.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 09 Dezember 2019, 21:34:52
Mal eine kleine Info:

In Vorbereitung auf einen evtl. Akku-Betrieb habe ich die Software von meinem ESP32 jetzt dahingehend verändert, dass der ESP nach einem empfangenen Bild in den Deep-Sleep geht, und nach (aktuell 10 Minuten) wieder aufwacht.
Danach wartet er einfach auf das nächste Bild und geht wieder pennen.
Zusätzlich habe ich noch einen MQTT-Client eingebaut, der ein "online" sendet, bzw. als LWT halt "offline".
Somit könnte ich jetzt sogar die Bildübertragung direkt anstoßen und wäre nicht auf ein Intervall-Attribut angewiesen.

Ich teste das mal ein paar Tage, dann kann ich gern die Software hier zur Verfügung stellen.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 10 Dezember 2019, 08:03:40
Das hört sich interessant an. Das müsste dann ja auch für den ESP8266 übertragbar sein oder?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 10 Dezember 2019, 09:46:01
Zitat
Das müsste dann ja auch für den ESP8266 übertragbar sein oder
Leider nicht, weil der 8266 keine eingebaute RTC hat, welche für den Aufwach-Vorgang benötigt wird.
Der 8266 ist auf einen externen Interrupt angewiesen, um wieder aktiv zu werden.

Aber in diesem Zusammenhang noch eine neue und eine alte Bitte:
"Alt": Bei einem FHEM-Restart wird immer noch das colormode-Attribut gelöscht, weil es (alphabetisch, in der config) VOR dem devicetype kommt.
Und somit hab ich die Meldung
Zitat
Invalid argument color to colormode. Device does not support color mode.

Neu: Vielleicht beim "interval"-Attribut eine 0 akzeptieren, um das automatische updaten ganz auszuschalten. Aktuell hab ichs halt auf 100000 gestellt, weil ich den Update-Prozess ja manuell anstoße.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 11 Dezember 2019, 09:36:27
Zitat
"Alt": Bei einem FHEM-Restart wird immer noch das colormode-Attribut gelöscht, weil es (alphabetisch, in der config) VOR dem devicetype kommt.
Und somit hab ich die Meldung
Zitat

    Invalid argument color to colormode. Device does not support color mode.


Neu: Vielleicht beim "interval"-Attribut eine 0 akzeptieren, um das automatische updaten ganz auszuschalten. Aktuell hab ichs halt auf 100000 gestellt, weil ich den Update-Prozess ja manuell anstoße.

Zu Alt: Ich habe noch keine schlaue Möglichkeit gefunden, das zu vermeiden, bin aber dran.
Zu Neu: Die 0 ist ja schon reserviert (dann wird automatisch ein Update und Upload gemacht, wenn sich etwas an irgend einem der Readings, die zum Bild beitragen, ändert). Du kannst den Wert aber auf -1 setzen, dann sollte eigentlich auch in der aktuellen Version schon nichts mehr automatisch passieren.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 11 Dezember 2019, 16:55:29
Zitat
Ich habe noch keine schlaue Möglichkeit gefunden, das zu vermeiden, bin aber dran.
Ganz einfach:

In der xx_set-Routine auf "Global:initialized" prüfen......Solange das false ist, ist FHEM noch nicht richtig hochgefahren, also liegt die Vermutung nahe, dass das "set" vielleicht gültig sein könnte :)

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 12 Dezember 2019, 11:28:53
@ eki:
Nachdem ich auf meiner Hauptinstanz von Fhem noch immer Probleme herrschen (Can't locate object method "newFromPng" via package "GD::Image" at ./FHEM/89_ESPEInk.pm line 1295 - obwohl libgd3 und GD istalliert sind), habe ich schnell einen Raspi4 aufgesetzt, FHEM und die libraries installiert. Über FHEM2FHEM mit der Hauptinstanz verbunden und die einzelnen clone devices angelegt.

Anfangs sah es genau so wirr aus, dann habe ich am Raspi4 im ePaper-Device von "7.5inch_e-Paper_HAT_(B)" auf "7.5inch_e-Paper_HAT_(C)" umgestellt --> alles ok und wird korrekt dargestellt. Sogar die gelbe Farbe wird in rot umgewandelt. Für mich jetzt alles bestens, nochmal danke für das tolle Modul.

@Icinger:
Akkubetrieb des e-paper-Displays schwebt mir auch vor. Ich habe an einen "dicken" Bilderrahmen gedacht und hinter dem Display noch eine dünne Powerbank wie das hier: https://www.amazon.de/dp/B073FJ9X2J/?coliid=I10YWJBYXDODAD&colid=34S3O002OOO4K&psc=1&ref_=lv_ov_lig_dp_it (https://www.amazon.de/dp/B073FJ9X2J/?coliid=I10YWJBYXDODAD&colid=34S3O002OOO4K&psc=1&ref_=lv_ov_lig_dp_it)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 12 Dezember 2019, 15:50:55
Zitat
Ganz einfach:

In der xx_set-Routine auf "Global:initialized" prüfen......Solange das false ist, ist FHEM noch nicht richtig hochgefahren, also liegt die Vermutung nahe, dass das "set" vielleicht gültig sein könnte :)

Na ja, so ganz einfach ist es dann doch nicht gewesen (lag aber eher daran, zu verstehen, was die Funktion notifyRegexpChanged macht bzw. nicht macht) und außerdem erlaubt das dann halt fehlerhafte Settings wenn einer im Configfile rumeditiert und dabei inkonsistente Settings macht. Aber wie sagt Olaf Schubert immer "... ich kann mich nicht um alles kümmern".
In der anghängten Version sollten jetzt also Settings mit colormode color beim Starten auch funktionieren. Außerdem laufen jetzt auch nur noch die Notifies auf, die auch wirklich gebraucht werden, was hoffentlich auch die CPU schont.

Bitte gern mal testen und Rückmeldung geben, dann aktualisiere ich die Version auch im ersten Beitrag oben wieder.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 12 Dezember 2019, 18:03:25
Nach 4x shutdown+restart ist jedesmal das Device verschwunden.

Möglicherweise weil es (bei mir) das source PICTUREFILE im Pfad ...www/images/(Device-)NAME/image.ext gelöscht hat. Image zurückkopiert, edit fhem.cfg, save und das Device ist wieder da.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 13 Dezember 2019, 07:13:44
Achja, noch ein Vorschlag/Bitte:

Soweit ich das im Code gesehen habe, bezieht sich left/right/center usw ja nur auf den Bildschirmrand, oder?
Also right ist ganz rechtsbündig.

Schön wäre es, einen Text an einer bestimmten x/y-Position rechtsbündig zu haben.

zB die Positionen mit
Zitat
textreading#myAstro:SunSet#240#>165#12#0#000000
textreading#myAstro:MoonRise#320#|150#12#0#000000
angeben. Also > für rechts, | für mittig....Linksbündig ist eigentlich unnötig, weil ja eh Standard.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 13 Dezember 2019, 17:09:51
Ist ja kurz vor Weihnachten :), Wunsch erfüllt (siehe Anhang).

Wenn jetzt in der x Position ein > enthalten ist, dann ist der Bezugspunkt rechts (>300 bedeutet der Text/ das Icon hört bei 300 pixeln auf) wenn ein | enthalten ist dann ist der Bezugspunkt die Mitte (|300 bedeutet die Mitte des Textes/Icons liegt bei 300 pixeln). Gleiches gilt für die y Position > bedeutet hier dass der Bezugspunkt oben ist | entsprechend wieder in der Mitte (< geht auch ist aber das Gleiche als wenn nichts da steht).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 14 Dezember 2019, 07:50:24
Coole Sache, danke.

Funktioniert einwandfrei :)

lg und schönes Wochenende,

Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 16 Dezember 2019, 10:47:44
Das Flex-Display "2.9inch e-Paper HAT (D)" ist beim devicetype nicht vorhanden und wird nach Auswahl von 2.9inch_e-Paper_Module, 2.9inch_e-Paper_Module_(B) oder 2.9inch_e-Paper_Module_(C) auch nicht richtig upgeloaded. Nur schwarzes Display obwohl die Konvertierung funktioniert. Zu diesem Display auch eine Bitte (alles ohne jede Eile): den Text um 90° rechts rotieren ermöglichen.

2019.12.16 10:08:30 3: eDisplayFlex: sending HTTP request to http://10.0.0.133/EPD with data: ja
2019.12.16 10:08:40 3: eDisplayFlex: problems with communication to device, trying once more (1 of 3 done)
2019.12.16 10:08:50 3: eDisplayFlex: problems with communication to device, trying once more (2 of 3 done)
2019.12.16 10:09:00 3: eDisplayFlex: problems with communication to device, trying once more (3 of 3 done)
2019.12.16 10:09:10 1: eDisplayFlex: problems with communication to device, max retries (3) reached
2019.12.16 10:09:14 3: eDisplayFlex: sending HTTP request to http://10.0.0.133/EPD with data: ka
2019.12.16 10:09:24 3: eDisplayFlex: problems with communication to device, trying once more (1 of 3 done)
2019.12.16 10:09:34 3: eDisplayFlex: problems with communication to device, trying once more (2 of 3 done)
2019.12.16 10:09:44 3: eDisplayFlex: problems with communication to device, trying once more (3 of 3 done)
2019.12.16 10:09:52 3: eDisplayFlex: sending HTTP request to http://10.0.0.133/EPD with data: la
2019.12.16 10:09:54 3: eDisplayFlex: problems with communication to device, trying once more (1 of 3 done)
2019.12.16 10:10:02 3: eDisplayFlex: problems with communication to device, trying once more (2 of 3 done)
2019.12.16 10:10:04 3: eDisplayFlex: problems with communication to device, trying once more (3 of 3 done)
2019.12.16 10:10:12 1: eDisplayFlex: problems with communication to device, max retries (3) reached
2019.12.16 10:10:14 1: eDisplayFlex: problems with communication to device, max retries (3) reached
2019.12.16 10:40:14 4: Start forked process to convert output picture
2019.12.16 10:40:14 4: File /opt/fhem/www/images/296x128.jpg opened, sizes is 128 x 296
2019.12.16 10:40:16 4: Finished conversion in background
2019.12.16 10:40:33 3: eDisplayFlex: sending HTTP request to http://10.0.0.133/EPD with data: ka
2019.12.16 10:40:43 3: eDisplayFlex: problems with communication to device, trying once more (1 of 3 done)

Direktupload über die Weboberfläche des ESP 8266 funktioniert.

edit: Durchgestrichenes existiert ja bereits im tollen Modul (RTFM für mich)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 16 Dezember 2019, 16:42:28
Das schwarz-weiße Display "7.5inch_e-Paper_HAT" wird mit der Auswahl von "7.5inch_e-Paper_HAT_(C)" korrekt dargestellt. Weiters empfiehlt es sich dafür schon aus dem zugrundeliegenden Picturefile die Farben zu entfernen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 17 Dezember 2019, 11:01:53
Ich habe gesehen, dass es eine Neue Version der Waveshare Web Applikation gibt, da ist jetzt das 2.9 D Display enthalten, kann ich also einbauen, etwas Geduld.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 17 Dezember 2019, 11:33:04
Danke. Lass Dir Zeit. Das 2.9-D-Display richte ich erst nach Weihnachten ein, ich hatte vorerst nur rumprobiert.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 31 Dezember 2019, 05:33:46
Guten Morgen,

mein Display läuft jetzt schon einige Zeit superstabil.
Grad vorhin wäre mir noch ein nettes Gimmick dazu eingefallen, allerdings bräuchte es dazu evtl. eine Änderung im Modul: Mehrzeiligen Text.
Ich würde gerne ein "Zitat des Tages" anzeigen. Das könnte zB vom fortune-Kommando (https://wiki.ubuntuusers.de/fortune/ (https://wiki.ubuntuusers.de/fortune/)) kommen, oder evtl. auch per HTTPMOD von irgendeiner Website.

Leider unterstützt GD ja keine NewLines, daher müsste das im Modul selbst umgesetzt werden.

Gibts da evtl. auch eine Möglichkeit, das zu implementieren? Sonst mach ich das nur hier in meinem lokalen Modul.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 03 Januar 2020, 15:16:01
Hallo Stefan,

mein Display läuft jetzt schon einige Zeit superstabil.

Würdest du deine ESP32-Sourcen hier zur Verfügung stellen?

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 07 Januar 2020, 11:33:32
Guten Morgen,

mein Display läuft jetzt schon einige Zeit superstabil.
Grad vorhin wäre mir noch ein nettes Gimmick dazu eingefallen, allerdings bräuchte es dazu evtl. eine Änderung im Modul: Mehrzeiligen Text.
Ich würde gerne ein "Zitat des Tages" anzeigen. Das könnte zB vom fortune-Kommando (https://wiki.ubuntuusers.de/fortune/ (https://wiki.ubuntuusers.de/fortune/)) kommen, oder evtl. auch per HTTPMOD von irgendeiner Website.

Leider unterstützt GD ja keine NewLines, daher müsste das im Modul selbst umgesetzt werden.

Gibts da evtl. auch eine Möglichkeit, das zu implementieren? Sonst mach ich das nur hier in meinem lokalen Modul.

lg, Stefan

Ich könnte so etwas wie eine maximale Breite für die texte einführen und dann manuell einen Zeileinumbruch machen, wenn diese Breite erreicht ist. Das würde dann Textblöcke mit "Flatterrand" erzeugen.
Eine zweite, leichter zu implementierende Möglichkeit wäre, einen special Character (also so etwas wie \n) in den Texten als Zeilenumbruch zu interpretieren und dann entsprechend im Modul die Zeilenumbrüche zu setzen.
Was wäre Deine Präferenz?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 07 Januar 2020, 15:35:15
In meinem Fall müsste ich zu (1) tendieren, da fortune die Texte mit einer fixen Breite von 80 ausgibt.
Ich hab das jetzt mit RegExen gelöst, so daß die Zeilenumbrüche entfernt werden.
Und diesen Text würd ich halt jetzt gern am Display unterbringen :)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: xs3bt am 08 Januar 2020, 17:35:47
irgendwie kann ich zu dem Modul im commandref leider nichts finden, würde es auch gerne testen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 09 Januar 2020, 13:44:30
irgendwie kann ich zu dem Modul im commandref leider nichts finden, würde es auch gerne testen.
Das ist bisher ja noch kein offizielles Tool und kommt (noch) nicht mit FHEM mit. Daher ist auch nix in der FHEM Commandref zu finden. Allerdings ist die ganze Beschreibung schon im Modul vorhanden.
Du musst einfach das .pl file im ersten Beitrag oben in Deinen FHEM Ordner kopieren und dann FHEM neu starten. Wenn Du dann ein Device dieses Typs anlegst (mit define <name> ESPEInk ...), dann kannst Du unten auf "Device specific help" klicken und siehst die ganze Beschreibung.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 09 Januar 2020, 13:55:02
In meinem Fall müsste ich zu (1) tendieren, da fortune die Texte mit einer fixen Breite von 80 ausgibt.
Ich hab das jetzt mit RegExen gelöst, so daß die Zeilenumbrüche entfernt werden.
Und diesen Text würd ich halt jetzt gern am Display unterbringen :)
Zitat
Das Flex-Display "2.9inch e-Paper HAT (D)" ist beim devicetype nicht vorhanden und wird nach Auswahl von 2.9inch_e-Paper_Module, 2.9inch_e-Paper_Module_(B) oder 2.9inch_e-Paper_Module_(C) auch nicht richtig upgeloaded. Nur schwarzes Display obwohl die Konvertierung funktioniert. Zu

Es gibt jetzt eine neue Version (erst mal nur zum Testen an diesen Beitrag angehängt). Dort sind 3 neue Devicetypes dazu gekommen, das gewünschte 2.9D und 2 neue 7.5 Zoll (V2).

Zusätzlich gibt es dort auch das gewünschte Feature mit dem Umbruch. Ich habe hier beide Varianten realisiert. Man kann entweder \n in den String einfügen dann wird an dieser Stelle umgebrochen, oder man setzt 2 zusätzliche Parameter ans Ende hinter die Font Definition (geht bei definition und auch bei set addtext oder set textreading), der erste gibt die Möglichkeit die Zeilenabstände zu variiren (zusätzlicher Wert in Pixeln zur normalen Zeilenhöhe), der zweite ist die Breite des Textblockes in Pixeln die den automatischen Umbruch bestimmt. Man kann auch beides kombinieren, dann wird bei \n im Text immer umgebrochen und darüber hinaus wenn die Breite des Textblockes überschritten würde.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 18 Januar 2020, 11:55:54
Danke !
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: bhaal am 18 Januar 2020, 20:57:47
Hallo zusammen,

Auch von meiner Seite aus vielen Dank für das Modul. Läuft bei mir bisher auch wunderbar, sogar seit einigen Tagen mit der 7.5" V2 (800 x 480px).  :)

Ich hatte jedoch beim Einrichten das Problem, dass beim nachträglichen Löschen von Einträgen alles durcheinander kommt.
Ich habe z.B. Position, Trigger und Größe mit der Nr. 8 angepasst (über attr) und dann Eintrag Nr. 7 komplett gelöscht. Dann bleiben die attr auf Nr 8, obwohl sich alles um einen Eintrag verschieben müsste. Ich hoffe das war verständlich...  :o

Ich habe also viel probiert und nachdem es jetzt soweit passt alles neu hinzugefügt. Aktueller Stand siehe Screenshot.  8)

Viele Grüße
Max
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 20 Januar 2020, 10:33:16
Kann es sein, dass die Modulsteuerung etwas durcheinander kommt wenn mehrere Displays genutzt werden? Manchmal sehe ich wieder nur wirre Zeichen darauf.

Das Modul versucht die 2 oder mehr Displays immer zur gleichen Zeit zu aktualisieren. Ich habe Intervall = 3600 eingestellt und alle Displays werden (bis auf wenige Sekunden) immer um zB XX:32 sychronsiert. Das ist mM nach die Minuten-Zahl zu der FHEM gestartet wurde. Maxretries steht bei mir auf 3. Ich würde den Uploadzeitpunkt lieber über AT steuern, um so verstreut über den Tag die Displays zu aktualisieren. Das scheitert aber mM daran, dass Intervall = 0 dann bei jedem Readingsupdate triggert (If this value is set to 0 there will be automatical updates in case a triggering device is specified (see set textreading). Otherwise 0 means no automatic updates. ). Allerdings muss ich gestehen, dass ich Intervall 0 noch ausprobiert habe. Besteht Deiner Meinung nach die Möglichkeit disable = 1 zu setzen und dann mit AT upzuloaden?

Außerdem beobachte ich, dass die Statusmeldung "Successfully uploaded image to device" lautet, obwohl ein Display gar nicht mit Stom versorgt wird, also offline ist. Stört mich aber nicht.

Anbei einmal ein Auszug aus dem Log (Verbose = 0):
2020.01.20 07:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:35 1: PERL WARNING: Argument "FF1000" isn't numeric in division (/) at ./FHEM/89_ESPEInk.pm line 1132.
2020.01.20 08:32:35 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:35 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:35 1: PERL WARNING: Argument "FF1000" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:35 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:36 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.

Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 21 Januar 2020, 10:17:40
So, ich habe jetzt disable auf 1 gestellt sowie ein DOIF gestaltet, das nur je 2-3x am Tag die Darstellung der Displays updated und belädt.  Keine wirren Zeichen mehr - ich bin zu 100% zufrieden. Mit diesem tollen Modul sowieso!

edit: und die an das Board angeschlossene Powerbank hält jetzt auch viel länger (der Upload scheint im Board viel Energie zu verbrauchen).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 22 Januar 2020, 10:41:18
Vielen Dank eki für das Modul!

Benutzt jmd. das EInk-Display auch ohne waveshare-Treibermodul, also direkt mit einem ESP32(/ESP8266)? Falls ja, würde er seine Sourcen freundlicherweise hier auch zur Verfügung stellen? Falls nicht public, zumindest als PM?

Vielen Dank im Voraus!
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 22 Januar 2020, 22:16:35
Kann es sein, dass die Modulsteuerung etwas durcheinander kommt wenn mehrere Displays genutzt werden? Manchmal sehe ich wieder nur wirre Zeichen darauf.

Das Modul versucht die 2 oder mehr Displays immer zur gleichen Zeit zu aktualisieren. Ich habe Intervall = 3600 eingestellt und alle Displays werden (bis auf wenige Sekunden) immer um zB XX:32 sychronsiert. Das ist mM nach die Minuten-Zahl zu der FHEM gestartet wurde. Maxretries steht bei mir auf 3. Ich würde den Uploadzeitpunkt lieber über AT steuern, um so verstreut über den Tag die Displays zu aktualisieren. Das scheitert aber mM daran, dass Intervall = 0 dann bei jedem Readingsupdate triggert (If this value is set to 0 there will be automatical updates in case a triggering device is specified (see set textreading). Otherwise 0 means no automatic updates. ). Allerdings muss ich gestehen, dass ich Intervall 0 noch ausprobiert habe. Besteht Deiner Meinung nach die Möglichkeit disable = 1 zu setzen und dann mit AT upzuloaden?

Außerdem beobachte ich, dass die Statusmeldung "Successfully uploaded image to device" lautet, obwohl ein Display gar nicht mit Stom versorgt wird, also offline ist. Stört mich aber nicht.

Anbei einmal ein Auszug aus dem Log (Verbose = 0):
2020.01.20 07:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:34 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.20 08:32:34 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:35 1: PERL WARNING: Argument "FF1000" isn't numeric in division (/) at ./FHEM/89_ESPEInk.pm line 1132.
2020.01.20 08:32:35 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:35 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:35 1: PERL WARNING: Argument "FF1000" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:35 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.20 08:32:36 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.20 08:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.20 08:32:36 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.

Ich könnte eine zufällig berechnete Verzögerung beim ersten Start der Timer einbauen, dann sollte es bei interval>0 die Gleichzeitigkeit unwahrscheinlicher werden. Darüber hinaus könnte man auch eine vorgebaute Verzögerung pro Device vorsehen, dann würde auch im Fall Display=0 eine Entkopplung möglich.
Grundsätzlich werde ich mir aber erst mal anschauen, warum das Modul bei mehreren Devices durcheinander kommt. Das müsste auch trotz mehrerer Devices parallel gehen.


Ich hatte jedoch beim Einrichten das Problem, dass beim nachträglichen Löschen von Einträgen alles durcheinander kommt.
Ich habe z.B. Position, Trigger und Größe mit der Nr. 8 angepasst (über attr) und dann Eintrag Nr. 7 komplett gelöscht. Dann bleiben die attr auf Nr 8, obwohl sich alles um einen Eintrag verschieben müsste. Ich hoffe das war verständlich...  :o

Ich habe also viel probiert und nachdem es jetzt soweit passt alles neu hinzugefügt. Aktueller Stand siehe Screenshot.  8)

Viele Grüße
Max

Kann ich nachstellen, wir repariert.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 27 Januar 2020, 18:00:39
Zitat
Kann es sein, dass die Modulsteuerung etwas durcheinander kommt wenn mehrere Displays genutzt werden? Manchmal sehe ich wieder nur wirre Zeichen darauf.

... hier nun mal eine Testversion, die dieses Problem hoffentlich beseitigt. Lag daran, dass ich in den non blocking Callbacks nicht zwischen den startenden Aufrufen unterschieden habe und dadurch alles durcheinander kam.
Ich kann das leider nicht richtig testen, weil ich nur ein Board habe, also intensiv ausprobieren und Bescheid geben.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 28 Januar 2020, 10:56:33
verbose = 4
2020.01.28 10:46:31 4: Start forked process to convert output picture
2020.01.28 10:46:31 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.28 10:46:31 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.01.28 10:46:31 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1135.
2020.01.28 10:46:31 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.28 10:46:33 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1123.
2020.01.28 10:46:33 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1143.
2020.01.28 10:46:33 4: File /opt/fhem/www/images/test_SWBalkenStrichLogo.png opened, sizes is 640 x 384
2020.01.28 10:46:49 4: Finished conversion in background
2020.01.28 10:47:01 3: einkDisplaySW: sending HTTP request to http://10.0.0.133/EPD with data: fb
2020.01.28 10:47:01 3: einkDisplaySW: problems with communication to device, trying once more (1 of 3 done)
2020.01.28 10:47:01 3: einkDisplaySW: problems with communication to device, trying once more (2 of 3 done)
2020.01.28 10:47:01 3: einkDisplaySW: problems with communication to device, trying once more (3 of 3 done)
2020.01.28 10:47:01 1: einkDisplaySW: problems with communication to device, max retries (3) reached

Die Displays sind definitiv im Netzwerk erreichbar (Weboberfläche des ESP8266). Es ist kein Upload möglich.

PS: Sorry, aber in den nächsten 2.5 Wochen kann ich leider nicht testen (Auslandsurlaub).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 28 Januar 2020, 15:38:34
Da war ich wohl doch zu schnell  :-[

Hier noch mal eine neue Version. Bitte noch mal testen (nach dem Urlaub, viel Spaß).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 07 Februar 2020, 09:23:06
Hallo,

ich habe ein 7.5B (die erste Version mit 640x384, id=20), angebunden an ein ESP32 (nicht das waveshare-Modul).
Dabei ist mir folgendes aufgefallen, was zum Betrieb geändert werden sollte:

- $cparams->{url} = 'http://'.ESPEInk_GetSetting($name,"url").'/'.$cparams->{command};
+ $cparams->{url} = 'http://'.ESPEInk_GetSetting($name,"url").'/'.$params->{command};


VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 09 Februar 2020, 19:24:49
Hallo zusammen,

ich hatte etwas Zeit um mein ESP32-Driver-Board und ein 1.54"B Modul zu testen.
Nach anfänglichen Problemen habe ich nun zum ersten mal etwas angezeigt bekommen  ;D

So ganz zufrieden bin ich nicht.

Ich musste beim flashen den Boot-Knopf drücken. Im Schaltplan sieht man aber das dies doch "eigentlich" durch den COM-Port gesteuert werden sollte (wie das auch bei NodeMCU für den ESP8266 der Fall ist).

Weiter bin ich auch etwas unschlüssig ob WaveShare in ihrem Demo-Code ein Fehler haben oder ob das egal ist wie das geschrieben wird.

Was ich meine sind die "*" bei ssid und password.
Original im Source:
/* SSID and password of your WiFi net ----------------------------------------*/
const char *ssid = "FB6490"; //"your ssid";
const char *password = "Blallla";   //"your password";

Das Internet sagt aber das es so zu schreiben ist:
/* SSID and password of your WiFi net ----------------------------------------*/
const char* ssid = "FB6490"; //"your ssid";
const char* password = "Blallla";   //"your password";

Schön wäre es natürlich wenn man auch noch etwas an FHEM senden könnte, z.B. Tastendrücke.
Hat das schon jemand umgesetzt?


Danke schon mal fürs Modul und die Idee :=)

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 09 Februar 2020, 20:42:35
Hallo zusammen,

bei mir funktioniert das nicht stabil. Ich muss dauernd den EN-Knopf betätigen das ich die Web-Oberfläche wieder erreiche.
Wenn ich das doch richtig gelesen habe wird als Betriebs-Software die Demo von WaveShare benutzt?

Bisher habe ich es nicht geschafft ein Bild von FHEM zu übertragen.

Meine Einstellungen:
defmod myEInk ESPEInk /opt/fhem/www/images/200x200.png
attr myEInk userattr 1-angle 1-blockwidth 1-color:colorpicker,RGB 1-font 1-linegap 1-size 1-text 1-trigger 1-x 1-y 2-angle 2-blockwidth 2-color:colorpicker,RGB 2-font 2-linegap 2-size 2-text 2-trigger 2-x 2-y 3-angle 3-blockwidth 3-color:colorpicker,RGB 3-font 3-linegap 3-size 3-text 3-trigger 3-x 3-y
attr myEInk boardtype ESP32
attr myEInk colormode color
attr myEInk convertmode level
attr myEInk devicetype 1.54inch_e-Paper_Module_(B)
attr myEInk interval 0
attr myEInk picturefile /opt/fhem/www/images/200x200.png
attr myEInk url 192.168.178.63
attr myEInk verbose 1

setstate myEInk Finished conversion in background
setstate myEInk 2020-02-09 20:19:21 1-angle 0
setstate myEInk 2020-02-09 20:19:21 1-blockwidth 0
setstate myEInk 2020-02-09 20:19:21 1-color 000000
setstate myEInk 2020-02-09 20:19:21 1-def addtext#Bla
setstate myEInk 2020-02-09 20:19:21 1-font medium
setstate myEInk 2020-02-09 20:19:21 1-isIcon 0
setstate myEInk 2020-02-09 20:19:21 1-linegap 0
setstate myEInk 2020-02-09 20:19:21 1-size 10
setstate myEInk 2020-02-09 20:19:21 1-text Bla
setstate myEInk 2020-02-09 20:19:21 1-x 0
setstate myEInk 2020-02-09 20:19:21 1-y 0
setstate myEInk 2020-02-09 20:19:44 2-angle 0
setstate myEInk 2020-02-09 20:19:44 2-blockwidth 0
setstate myEInk 2020-02-09 20:19:44 2-color 000000
setstate myEInk 2020-02-09 20:19:44 2-def addtext#bla
setstate myEInk 2020-02-09 20:19:44 2-font medium
setstate myEInk 2020-02-09 20:19:44 2-isIcon 0
setstate myEInk 2020-02-09 20:19:44 2-linegap 0
setstate myEInk 2020-02-09 20:19:44 2-size 10
setstate myEInk 2020-02-09 20:19:44 2-text bla
setstate myEInk 2020-02-09 20:19:44 2-x 0
setstate myEInk 2020-02-09 20:19:44 2-y 0
setstate myEInk 2020-02-09 20:25:42 3-angle 0
setstate myEInk 2020-02-09 20:25:42 3-blockwidth 0
setstate myEInk 2020-02-09 20:25:42 3-color 000000
setstate myEInk 2020-02-09 20:25:42 3-def addtext#blblblblblblblbl
setstate myEInk 2020-02-09 20:25:42 3-font medium
setstate myEInk 2020-02-09 20:25:42 3-isIcon 0
setstate myEInk 2020-02-09 20:25:42 3-linegap 0
setstate myEInk 2020-02-09 20:25:42 3-size 10
setstate myEInk 2020-02-09 20:25:42 3-text blblblblblblblbl
setstate myEInk 2020-02-09 20:25:42 3-x 0
setstate myEInk 2020-02-09 20:25:42 3-y 0
setstate myEInk 2020-02-09 20:25:42 deftexts 3
setstate myEInk 2020-02-09 20:25:49 result_picture <html><img src=/fhem/images/myEInk/result.png?dummy=950048.774690121></img><div>/fhem/images/myEInk/result.png</div></html>
setstate myEInk 2020-02-09 19:48:02 source_picture <html><img src=/fhem/images/myEInk/200x200.png?dummy=583153.879619569></img><div>/fhem/images/myEInk/200x200.png</div></html>

Funktioniert das bei irgend jemand stabil mit dem ESP32--Driver-Board?

Wenn ich im Web-Interface des ESP ein paar mal etwas schicke ist dieser dann nicht mehr erreichbar.
Beim dritten mal hochladen über die ESP32-Web-Seite bleibt die Anzeige bei 2.5% stehen und das wars.
Liegt das eventl. an der zu kurzen Update-Zeit?

@Icinger, willst Du dein Code eventl. hier zur Verfügung stellen?

Danke,

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 10 Februar 2020, 08:33:28
Hallo Gerd,

Weiter bin ich auch etwas unschlüssig ob WaveShare in ihrem Demo-Code ein Fehler haben oder ob das egal ist wie das geschrieben wird.

Was ich meine sind die "*" bei ssid und password.
Original im Source:
/* SSID and password of your WiFi net ----------------------------------------*/
const char *ssid = "FB6490"; //"your ssid";
const char *password = "Blallla";   //"your password";

Das Internet sagt aber das es so zu schreiben ist:
/* SSID and password of your WiFi net ----------------------------------------*/
const char* ssid = "FB6490"; //"your ssid";
const char* password = "Blallla";   //"your password";

Das ist gleichbedeutend uns spielt keine Rolle. Bei mir funktioniert der Democode auch soweit auf einem "normalen" ESP32.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 10 Februar 2020, 17:12:22
Hallo,

ich habe ein 7.5B (die erste Version mit 640x384, id=20), angebunden an ein ESP32 (nicht das waveshare-Modul).
Dabei ist mir folgendes aufgefallen, was zum Betrieb geändert werden sollte:

  • mein URL-Parameter muss "EPDu_" lauten (statt "EPDa_")
  • in Zeile 1852 (letzte Version) befindet sich ein Bug (?) bei der Übertragung, die Parameter werden nicht mitgegeben
- $cparams->{url} = 'http://'.ESPEInk_GetSetting($name,"url").'/'.$cparams->{command};
+ $cparams->{url} = 'http://'.ESPEInk_GetSetting($name,"url").'/'.$params->{command};
  • Beachtung der Refreshtime, das 7.5B hat bspw. 31s, wenn zwischenzeitlich ein erneutes Update kommt, dann ist es nicht mehr ansprechbar (siehe Refreshtimings bei https://diyprojects.io/test-waveshare-epaper-eink-2-7-spi-screen-raspberry-pi-python/ (https://diyprojects.io/test-waveshare-epaper-eink-2-7-spi-screen-raspberry-pi-python/), hier sollte kein Update durchgeführt werden, wenn das letzte noch innerhalb des Refreshzeitraums liegt
  • auch mein ESP32 bleibt nach dem ersten Update stehen, ich habe aber auch den Workaround mit ESP.restart()eingebaut. Mittelfristig werde ich vermutlich auch einen MQTT-Client einbauen
  • die Farbangabe bei iconreading wird bei mir nicht beachtet - es ist nach dem Konvertieren immer schwarz


VG

Hier mal eine Version, die Deine Wünsche erfüllen sollte, bitte ausgiebig testen.
- Statt einer "refresh Time" warte ich jetzt, bis ein aktueller Upload fertig ist und erlaube dann erst wieder einen Neuen.
- Warum die ESP32 Devices nach dem Update stehen bleiben, ist mir ein Rätsel und kann ich, weil ich keinen ESP32 habe, auch nicht nachvollziehen.
- Die Icons berücksichtigen jetzt die Farbe und zwar folgendermaßen: Wenn keine Farbe gegeben ist, bleibt das Original erhalten (mit allen Farben), wenn eine Farbe gegeben ist, werden alle Pixel, die nicht weiß sind, auf diese Farbe gesetzt.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 10 Februar 2020, 17:54:58
Hi,

anbei mal mein ESP32-Code.

Änderungen gegenüber dem "normalen" Sketch:

srvr.h
 -) ssid und password ändern
 -) myIP ändern (bei mir eine fixe IP)
ggf das Topic anpassen:
 -) mqTopic

Loader_esp32wf
 -) mqtt_server ändern
 -) TIME_TO_SLEEP ändern (die Zeit, wie lange der ESP schlafen soll)

lg, Stefan
 
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 10 Februar 2020, 18:03:39
Hallo ihr zusammen

Danke für die Infos.
Mal schauen wann ich motiviert bin. Die Nacht war hier etwas laut   :o

Melde mich wieder

Gruß Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 10 Februar 2020, 22:13:11
Hier mal eine Version, die Deine Wünsche erfüllen sollte, bitte ausgiebig testen.

Vielen Dank!

Zitat
- Statt einer "refresh Time" warte ich jetzt, bis ein aktueller Upload fertig ist und erlaube dann erst wieder einen Neuen.

Das sollte auch genügen. Das SHOW kehrt nach meinen Beobachtungen der seriellen ESP32-Konsole erst zurück, wenn der Inhalt dargestellt wurde. Bis jetzt hilft diese Änderung - ich werde das weiter beobachten :)

Zitat
- Warum die ESP32 Devices nach dem Update stehen bleiben, ist mir ein Rätsel und kann ich, weil ich keinen ESP32 habe, auch nicht nachvollziehen.

Im ESP32-Code wird nach dem Show die Verbindung erst geflusht und dann ein HTTP200 mit einem "Ok!"-Text gesendet, wird diese Seite abgeholt? Mir scheint, als wäre das die Ursache für die stehen bleibenden ESP32 - wenn ich das im Treiber auskommentiere, bleibt der ESP32 nicht mehr "stehen" (Originaltreiber, ohne ESP.reset()).
client.flush();
client.print("HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n");
client.print("Ok!");
client.print("\r\n");

Zitat
- Die Icons berücksichtigen jetzt die Farbe und zwar folgendermaßen: Wenn keine Farbe gegeben ist, bleibt das Original erhalten (mit allen Farben), wenn eine Farbe gegeben ist, werden alle Pixel, die nicht weiß sind, auf diese Farbe gesetzt.

Sollten nicht eher alle weißen Pixel auf die angegebene Farbe gesetzt werden oder verstehe ich das falsch? Ich verwende für offene Fenster das icon "rc_dot", welches einen schwarzen Kreis im Hintergrundbild überdeckt, wenn gesetzt.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 11 Februar 2020, 08:21:31
Zitat
Im ESP32-Code wird nach dem Show die Verbindung erst geflusht und dann ein HTTP200 mit einem "Ok!"-Text gesendet, wird diese Seite abgeholt? Mir scheint, als wäre das die Ursache für die stehen bleibenden ESP32 - wenn ich das im Treiber auskommentiere, bleibt der ESP32 nicht mehr "stehen" (Originaltreiber, ohne ESP.reset()).
Code: [Auswählen]

Abgeholt wird da nichts mehr, wartet Dein ESP32 denn auf eine Antwort?

Zitat
Sollten nicht eher alle weißen Pixel auf die angegebene Farbe gesetzt werden oder verstehe ich das falsch? Ich verwende für offene Fenster das icon "rc_dot", welches einen schwarzen Kreis im Hintergrundbild überdeckt, wenn gesetzt.

Das ist genau so ein bisschen das Problem. Ich bin davon ausgegangen, dass die weißen Pixel eher der Hintergrund sind und alle nicht weißen (hintergrund) Pixel damit zu ändern sind. Damit muss ich, denke ich, noch ein bisschen rumexperimentieren.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 11 Februar 2020, 08:43:35
Abgeholt wird da nichts mehr, wartet Dein ESP32 denn auf eine Antwort?

Antwort nicht, aber scheinbar, dass es abgeholt wird. Ansonsten kommt er nicht aus der Serverloop raus. Das Problem werden jedoch auch die waveshare-ESP32 haben, da sie die selbe Firmware haben. Unterschied zu meinem Board ist lediglich, dass ich die Verdrahtung selbst vornehmen muss, beim waveshare-ESP32 muss man nur die Flachbandleitung draufstecken.

Zitat
Das ist genau so ein bisschen das Problem. Ich bin davon ausgegangen, dass die weißen Pixel eher der Hintergrund sind und alle nicht weißen (hintergrund) Pixel damit zu ändern sind. Damit muss ich, denke ich, noch ein bisschen rumexperimentieren.

Da kenne ich mich leider nicht aus. Ursprünglich ist das eine svg-Grafik im RGB-Farbraum, wo es nur schwarz gibt, der Hintergrund ist transparent. Möglicherweise wird das von der UI je nach FHEM-Style umgewandelt, bevor du es nutzt? Mein Workaround sieht derzeit so aus, dass ich eine Grafik (png) über meinen Hintergrund lege - mit deiner Änderung, dass die Farbe, falls nicht angegeben, nicht geändert wird, sollte es passen - muss ich jedoch noch testen.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 11 Februar 2020, 13:33:18
Was passiert denn, wenn Du statt über FHEM das ESP32 über den Browser ansprichst? Blockiert das ESP32 dann auch? Falls nicht, wäre es gut, wenn Du mal mit dem Browser Entwicklungswerkzeug mir den Mitschnitt der Kommunikation für diesen Fall (ESP32 <-> Browser direkt) hier postest.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 11 Februar 2020, 14:14:29
Was passiert denn, wenn Du statt über FHEM das ESP32 über den Browser ansprichst? Blockiert das ESP32 dann auch?
Nein, da geht es. Erst, wenn ich zwischendurch per FHEM uploade, geht die ESP32-Webseite auch nicht mehr.

Zitat
Falls nicht, wäre es gut, wenn Du mal mit dem Browser Entwicklungswerkzeug mir den Mitschnitt der Kommunikation für diesen Fall (ESP32 <-> Browser direkt) hier postest.
Die XHR/AJAX-Kommunikation sehe ich nicht direkt im Mitschnitt (FF), ich hoffe, er bringt dir dennoch etwas, siehe Anhang.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 11 Februar 2020, 14:44:03
Da drin ist leider auch nicht mehr zu sehen als das, was ich schon kenne. Die letzte Kommunikation ist das SHOW_ von der Browser Seite, danach sehe ich nichts mehr.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 11 Februar 2020, 17:00:12
Da drin ist leider auch nicht mehr zu sehen als das, was ich schon kenne. Die letzte Kommunikation ist das SHOW_ von der Browser Seite, danach sehe ich nichts mehr.

Ich hab das noch einmal verglichen: die Webseite verwendet scheinbar ein synchrones SHOW, das FHEM-Modul ein asynchrones mit einem (für mein waveshare-Modul) zu kurzem Timeout - der Client ist somit gar nicht mehr da, um das "Ok!" vom Server zu empfangen. Ich habe es testweise auf 35s gestellt - damit geht es (wenn ich jetzt mit den Softwareständen nicht durcheinander gekommen bin).

edit
Die Timeout-Änderung allein reicht nicht, der ESP ist über Nacht hängen geblieben.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 12 Februar 2020, 08:25:49
Ich könnte den HTTP timeout als parameter einbauen, dann kann man das anpassen. Siehst Du das als Lösung des Problems?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 12 Februar 2020, 08:33:40
Ich könnte den HTTP timeout als parameter einbauen, dann kann man das anpassen. Siehst Du das als Lösung des Problems?

Bin mir nicht sicher, ob das wirklich das Problem löst. Ich würde daher noch mal die Original-waveshare-Firmware und den letzten Modulstand+Timeoutänderung aufspielen und tagsüber laufen lassen.
Wird bei der Ermittlung, ob noch ein Upload läuft das SHOW mitgezählt oder ist das nur das LOAD?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 12 Februar 2020, 08:39:08
Aktuell wird nach dem Abschicken des SHOW_ der nächste Upload wieder freigegeben. Ich könnte natürlich auf die Antwort auf das SCHOW_ warten (natürlich auch hier mit Timeout) und erst dann wieder freigeben.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 12 Februar 2020, 08:49:16
Aktuell wird nach dem Abschicken des SHOW_ der nächste Upload wieder freigegeben. Ich könnte natürlich auf die Antwort auf das SCHOW_ warten (natürlich auch hier mit Timeout) und erst dann wieder freigeben.

IMO würde das helfen, da die Serverloop erst verlassen wird, wenn das SHOW "durch" ist. Es würde ggf. auch das Problem lösen, dass die Anzeige nicht sauber ist (wenn während des SHOW bereits neue Daten angeliefert werden).

Das erhöhte Timeout habe ich eben noch mal mit der Orig-Firmware manuell getestet - das sieht soweit gut aus. Ich konnte ein paar Uploads hintereinander absetzen und lt. ESP-Konsole wird die Serverloop auch immer verlassen  :D
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 12 Februar 2020, 09:39:21
Dann mal mit dieser Version testen (würde ich bei positivem Feedback dann auch im ersten Beitrag hier mal "freigeben".
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 12 Februar 2020, 09:54:13
Dann mal mit dieser Version testen (würde ich bei positivem Feedback dann auch im ersten Beitrag hier mal "freigeben".

Sieht sehr gut aus, gute Arbeit! :)
Durchgeführte Tests:
-mehrere Uploads hintereinander: ok, Server bleibt nicht mehr stehen (timeout-Attr auf 50s für das 7.5 gestellt)
-Upload, während noch ein anderer Upload stattfindet: ok, es wird die Meldung "Upload of image currently running, try again later" ausgegeben und der aktuelle Upload wird nicht gestört - erfolgt der Upload automatisch oder wird dieser abgebrochen?
-Konvertierung: ich erhalte u.a. Warnungen, liegt das ggf. an meiner Konfiguration?
PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1124.
PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1125.
PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1137.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 12 Februar 2020, 10:06:30
Gut,
Ein upload wird, wenn gerade schon einer läuft, nicht automatisch angestoßen (könnte man natürlich auch noch einbauen).
Die Warnungen sind meiner Schlamperei geschuldet (ich muss mal alle nicht im Code initialisierten Variablen suchen  :-[), sind aber nicht kritisch,
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 12 Februar 2020, 12:30:05
Der ESP32-Webserver scheint sich auch zu verhaspeln, wenn unmittelbar nach einem Upload ein neuer Upload kommt. In dem Fall liegen nur 3ms dazwischen:

[12:07:48:022] <<<LOAD>>>␍␊
[12:07:48:062] <<<␍␊
[12:08:21:465] SHOW>>>␍␊
[12:08:21:468] <<<␍␊
[12:08:21:469] EPD␍␊
[12:08:21:469] EPD 7.5 inch b

Könnte da bei einem erneuten Update eine Verzögerung (1s?) helfen?

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 12 Februar 2020, 22:27:44
Hallo zusammen,

heute etwas Zeit gefunden zum probieren.

Ich konnte mit ekis letzten Update des Moduls nun tatsächlich ein Bild an den ESP32 schicken!

@Icinger
Aber ersteinmal die alte IDE 1.8.10 löschen müssen. Gab irgend welches gemecker wegen doppelten Wifi.h.
Habt ihr die Fehlermeldungen auch?
In file included from sketch\srvr.h:19:0,

                 from E:\Daten\CFG\ePaper_ESP32\Loader_esp32wf\Loader_esp32wf.ino:24:

sketch\epd.h:35:0: warning: "LOW" redefined

 #define LOW             0

 ^

In file included from E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/esp32-hal.h:53:0,

                 from E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/Arduino.h:35,

                 from sketch\Loader_esp32wf.ino.cpp:1:

E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/esp32-hal-gpio.h:29:0: note: this is the location of the previous definition

 #define LOW               0x0

 ^

In file included from sketch\srvr.h:19:0,

                 from E:\Daten\CFG\ePaper_ESP32\Loader_esp32wf\Loader_esp32wf.ino:24:

sketch\epd.h:36:0: warning: "HIGH" redefined

 #define HIGH            1

 ^

In file included from E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/esp32-hal.h:53:0,

                 from E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/Arduino.h:35,

                 from sketch\Loader_esp32wf.ino.cpp:1:

E:\Tools\Arduino_1_8_11\hardware\espressif\esp32\cores\esp32/esp32-hal-gpio.h:30:0: note: this is the location of the previous definition

 #define HIGH              0x1

 ^

In file included from sketch\srvr.h:19:0,

                 from E:\Daten\CFG\ePaper_ESP32\Loader_esp32wf\Loader_esp32wf.ino:24:

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

 };

 ^

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

sketch\epd.h:532:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

In file included from E:\Daten\CFG\ePaper_ESP32\Loader_esp32wf\Loader_esp32wf.ino:24:0:

sketch\srvr.h: In function 'bool Srvr__loop()':

sketch\srvr.h:141:65: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 11, "/styles.css"))

                                                                 ^

sketch\srvr.h:142:58: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

                 return Srvr__file(client, 0, "styles.css");

                                                          ^

sketch\srvr.h:144:65: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 11, "/scriptA.js"))

                                                                 ^

sketch\srvr.h:145:58: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

                 return Srvr__file(client, 1, "scriptA.js");

                                                          ^

sketch\srvr.h:147:65: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 11, "/scriptB.js"))

                                                                 ^

sketch\srvr.h:148:58: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

                 return Srvr__file(client, 2, "scriptB.js");

                                                          ^

sketch\srvr.h:150:65: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 11, "/scriptC.js"))

                                                                 ^

sketch\srvr.h:151:58: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

                 return Srvr__file(client, 3, "scriptC.js");

                                                          ^

sketch\srvr.h:153:65: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 11, "/scriptD.js"))

                                                                 ^

sketch\srvr.h:154:58: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

                 return Srvr__file(client, 4, "scriptD.js");

                                                          ^

sketch\srvr.h:164:56: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 4, "EPD"))

                                                        ^

sketch\srvr.h:180:57: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 4, "LOAD"))

                                                         ^

sketch\srvr.h:193:57: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 4, "NEXT"))

                                                         ^

sketch\srvr.h:220:57: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

             if (Buff__signature(Buff__bufInd - 4, "SHOW"))

                                                         ^

Der Sketch verwendet 764896 Bytes (58%) des Programmspeicherplatzes. Das Maximum sind 1310720 Bytes.
Globale Variablen verwenden 42868 Bytes (13%) des dynamischen Speichers, 284812 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.

Welche MQTT-Libs werden den von Dir vorausgesetzt? Es scheint da ja eine grosse Auswahl an gleichen benannten Libs zu geben.
Das ist blöd wenn man nicht weis welche das sein soll.

Kann man den DeepSleep einfach zum Testen ausschalten? Hab das nur kurz testen können.

MQTT2-Server mit drei Tasmota und Aquara-Sensoren hab ich hier laufen, aber mehr noch nicht gemacht;)

Danke schon mal, scheint ja stabiler zu werden.

Nachtrag: Der ESP32 findet nach dem Aufwecken den AP nicht. Erst wenn ich den EN-Taster drücke gibt es eine Verbindung. Das Problem haben meine 9 ESP8266 nicht.
 
Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 13 Februar 2020, 18:37:29
@Icinger

Benötigt der von dir verwendete Deepsleep ein GPIO um aufzuwecken?
Wie ich im Internet gelesen habe gibt es drei Möglichkeiten.

Gruß Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Icinger am 13 Februar 2020, 20:33:30
@Maista: Nein, wird kein GPIO benötigt, der ESP32 hat eine interne RTC.

lg, Stefan
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 14 Februar 2020, 09:06:47
Aber ersteinmal die alte IDE 1.8.10 löschen müssen. Gab irgend welches gemecker wegen doppelten Wifi.h.
Habt ihr die Fehlermeldungen auch?
Bei mir kompiliert der aktuelle waveshare-Code ohne Probleme. Der Code von Stefan scheint zwar eine ältere Version zu sein, sollte aber auch nicht zu diesen Problemen führen. Die Fehlermeldungen deuten eher darauf hin, dass etwas mit deinen Include-Pfaden nicht passt (doppelt, einmal in Tools und einmal lokal im Projekt).

Zitat
Welche MQTT-Libs werden den von Dir vorausgesetzt? Es scheint da ja eine grosse Auswahl an gleichen benannten Libs zu geben.
Das scheint mir, lt. eingebundenem Header der PubSubClient zu sein.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 14 Februar 2020, 11:19:01
Hallo,

ich verfolge eure Diskussion und die Lösung seit einiger Zeit. ich konnte die ESP32 Version erfolgreich kompelieren und mit dem Netzwerk verbinden. Webservice ist erreichbar und ich könnte die Images zum Display schicken,
Soweit so gut aber ich weiss nicht wie ich das Display mit dem ESP verbinden soll bzw. wie ich die Einstellungen konfigurieren soll , das Display arbeitet nicht. Ich gehe davon aus , dass ich ihm falsch verkabelt habe.. Ich habe ein ePaper 2.13 Shield im Einsatz -->https://www.wemos.cc/en/latest/d1_mini_shiled/epd_2_13.html?spm=a2g0o.detail.1000023.1.294d19b6ntvUpZ. Meine Test mit dem GxEPD_Example haben tadellos funktioniert, das Display arbeitet.
Kann mir einer von euch weiterhelfen? Vielleicht verstehe ich da etwas falsch und bin auf dem falschen Dampfer.

VG
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 14 Februar 2020, 12:03:06
Soweit so gut aber ich weiss nicht wie ich das Display mit dem ESP verbinden soll bzw. wie ich die Einstellungen konfigurieren soll , das Display arbeitet nicht. Ich gehe davon aus , dass ich ihm falsch verkabelt habe.. Ich habe ein ePaper 2.13 Shield im Einsatz -->https://www.wemos.cc/en/latest/d1_mini_shiled/epd_2_13.html?spm=a2g0o.detail.1000023.1.294d19b6ntvUpZ.

Der waveshare-ESP32-Treiber verwendet die u.a. Pins (epd.h):
/* SPI pin definition --------------------------------------------------------*/
#define PIN_SPI_SCK  13
#define PIN_SPI_DIN  14
#define PIN_SPI_CS   15
#define PIN_SPI_BUSY 25//19
#define PIN_SPI_RST  26//21
#define PIN_SPI_DC   27//22

*edit* Noch ein Hinweis: es gibt verschiedene ESP32-Ausführungen, mit unterschiedlicher Pin-Anzahl - hier muss man aufpassen, dass man die korrekte Zuordnung vornimmt.

hth
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 14 Februar 2020, 13:08:12
Der waveshare-ESP32-Treiber verwendet die u.a. Pins (epd.h):
/* SPI pin definition --------------------------------------------------------*/
#define PIN_SPI_SCK  13
#define PIN_SPI_DIN  14
#define PIN_SPI_CS   15
#define PIN_SPI_BUSY 25//19
#define PIN_SPI_RST  26//21
#define PIN_SPI_DC   27//22

*edit* Noch ein Hinweis: es gibt verschiedene ESP32-Ausführungen, mit unterschiedlicher Pin-Anzahl - hier muss man aufpassen, dass man die korrekte Zuordnung vornimmt.

hth
Danke für die schnelle Antwort. Großartig
Wie es aussieht habe ich richtig gedacht. Ich habe die Pins entsprechend geschaltet SCK-->G14 usw.). Was mir nicht klar ist, was haben die zwei shlashes zu bedeuten? (#define PIN_SPI_RST  26//21) entweder oder?
Mit den verschiedenen Ausführung der ESP's habe ich es nicht berücksichtigt. Ich habe einen von AZDelivery ESP32 NodeMCU (https://www.amazon.de/dp/B071P98VTG/ref=cm_sw_r_em_apa_i_EXOrEbP293NJD)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 14 Februar 2020, 13:11:15
Was mir nicht klar ist, was haben die zwei shlashes zu bedeuten? (#define PIN_SPI_RST  26//21) entweder oder?
Der Doppelslash ist nur eine Kommentareinleitung im Quelltext, vermutlich hat der waveshare-Programmierer den Code auch für andere Module (ESP9266?) benutzt. Alles was in der Zeile dahinter steht, ist irrelevant.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 14 Februar 2020, 13:37:29
Alles klar, danke dir. Vielleicht habe ich mich bei der Verkabelung irgendwo vertan.

VG
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 14 Februar 2020, 19:17:28
@Jendaw

Danke für die Info. Muss ich mir am Samstag anschauen.
Als ich die 1.8.10 installiert hatte kamen die Doppel Meldungen aber eindeutiger.

Und bei euch kommen gar keine Meldungen ? :-[
Vielleicht muss ich nur das Verzeichnis im User löschen.
Da schreibt die IDE auch Zeugs hin.

Bis dann

Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 16 Februar 2020, 14:17:18
Alles klar, danke dir. Vielleicht habe ich mich bei der Verkabelung irgendwo vertan.

VG
Peter

Hi,

Nach dem ich die PIN Belegung geändert habe funktioniert mein Display. :)

@Jendaw: Danke dir nochmal.

Ich habe jetzt allerdings ein anderes Problem. Ich habe im Gimp eine png Datei mit 122x250 Pixel erstellt. Die Vorlage hat nur einen weißen Hintergrund.
Wenn das espink Modul diese überträgt, zeigt das Display 6 Schwarze Balken bzw. Striche--> Siehe Bild. Die Feuchtigkeit mit Text, das ich mitsende wird angezeigt. Was mache ich hier falsch? Ich vermute, dass die png Vorlage das Problem verursacht.

VG
Peter

Internals:
   BOARDTYPE  ESP8266
   COLORMODE  monochrome
   CONVERTMODE level
   DEF        /opt/fhem/images/122x250.png 192.168.8.41 monochrome level
   DEVICETYPE 1.54inch_e-Paper_Module
   FUUID      5e483f6c-f33f-0de6-0759-eaabdf747c202e1d
   INTERVAL   level
   NAME       myEInk
   NOTIFYDEV  global,Sensor_Aussen,myEInk
   NR         863
   NTFY_ORDER 50-myEInk
   PICTUREFILE /opt/fhem/images/122x250.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL       
   OLDREADINGS:
   READINGS:
     2020-02-16 13:35:00   1-angle         0
     2020-02-16 12:57:49   1-blockwidth    2
     2020-02-16 12:57:09   1-color         000000
     2020-02-16 12:57:08   1-def           addtext#Feuchte:#30#100#70#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
     2020-02-16 12:57:09   1-font          medium
     2020-02-16 12:57:08   1-isIcon        0
     2020-02-16 12:57:09   1-linegap       0
     2020-02-16 13:23:03   1-size          30
     2020-02-16 12:57:08   1-text          Feuchte:
     2020-02-16 13:50:08   1-x             50
     2020-02-16 13:19:02   1-y             90
     2020-02-16 13:36:48   2-angle         0
     2020-02-16 13:36:11   2-blockwidth    0
     2020-02-16 13:36:11   2-color         000000
     2020-02-16 13:36:11   2-def           textreading#Sensor_Aussen:humidity#2#55#300#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
     2020-02-16 13:36:11   2-font          medium
     2020-02-16 13:36:11   2-isIcon        0
     2020-02-16 13:36:11   2-linegap       0
     2020-02-16 13:36:11   2-size          300
     2020-02-16 13:57:58   2-text          62
     2020-02-16 13:36:11   2-trigger       Sensor_Aussen:humidity
     2020-02-16 13:49:05   2-x             103
     2020-02-16 13:50:40   2-y             85
     2020-02-16 13:36:11   deftexts        2
     2020-02-16 14:00:45   result_picture  <html><img src=/fhem/images/myEInk/result.png?dummy=724001.441024424></img><div>/fhem/images/myEInk/result.png</div></html>
     2020-02-16 14:00:40   source_picture  <html><img src=/fhem/images/myEInk/122x250.png?dummy=713277.999786399></img><div>/fhem/images/myEInk/122x250.png</div></html>
   helper:
Attributes:
   1-angle    0
   1-blockwidth 2
   1-size     30
   1-x        50
   1-y        90
   2-angle    0
   2-x        103
   2-y        85
   boardtype  ESP32
   colormode  monochrome
   convertmode level
   devicetype 2.13inch_e-Paper_HAT
   interval   30
   placement  top-left
   room       ESPEasy
   scale2fit  0
   url        192.168.8.41
   userattr   1-angle 1-blockwidth 1-color:colorpicker,RGB 1-font 1-linegap 1-size 1-text 1-trigger 1-x 1-y 2-angle 2-blockwidth 2-color:colorpicker,RGB 2-font 2-linegap 2-size 2-text 2-trigger 2-x 2-y
   verbose    1
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 16 Februar 2020, 16:02:19
letztes PM geladen, bei mir sehen die Icons unvollständig aus (siehe Bild).

und ich erhalte "Error uploading image to device, max retries (3) reached", verbose=4:
2020.02.16 15:49:44 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: eb
2020.02.16 15:49:48 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.16 15:50:05 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.16 15:50:06 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.16 15:50:06 1: einkDiplay01: problems with communication to device, max retries (3) reached
2020.02.16 15:52:24 4: Start forked process to convert output picture
2020.02.16 15:52:24 1: PERL WARNING: Use of uninitialized value $linegap in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.02.16 15:52:24 1: PERL WARNING: Use of uninitialized value $blockwidth in int at ./FHEM/89_ESPEInk.pm line 1125.
2020.02.16 15:52:24 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 1137.
2020.02.16 15:52:24 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1145.
2020.02.16 15:52:25 1: PERL WARNING: Argument "FF1000" isn't numeric in division (/) at ./FHEM/89_ESPEInk.pm line 1134.
2020.02.16 15:52:25 1: PERL WARNING: Argument "FF1000" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.02.16 15:52:25 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1125.
2020.02.16 15:52:25 1: PERL WARNING: Argument "16.6 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1145.
2020.02.16 15:52:25 4: File /opt/fhem/www/images/test_SWBalkenStrichLogo.png opened, sizes is 640 x 384
2020.02.16 15:52:42 4: Finished conversion in background
2020.02.16 15:52:51 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: eb
2020.02.16 15:53:05 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.16 15:53:15 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.16 15:53:25 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.16 15:53:35 1: einkDiplay01: problems with communication to device, max retries (3) reached
2020.02.16 15:54:14 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: fb
2020.02.16 15:54:18 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.16 15:54:28 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.16 15:54:38 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.16 15:54:48 1: einkDiplay01: problems with communication to device, max retries (3) reached
2020.02.16 15:55:22 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: fb
2020.02.16 15:55:26 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.16 15:55:36 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.16 15:55:46 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.16 15:55:56 1: einkDiplay01: problems with communication to device, max retries (3) reached

altes PM vom 28.1.20 funktioniert (icons und upload).
 
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 17 Februar 2020, 09:37:43
Kannst Du bitte mal mit folgender Version schauen, ob der Upload jetzt klappt. Bei den Icons ist das noch nicht perfekt. Aktuell habe ich es jetzt so gemacht: Wenn Du keine Farbe setzt, dann lässt die Konversion die Icons so wie sie sind. Falls eine Farbe gesetzt ist, wird die Farbe aller Icon Pixel, die Farbwerter größer 0 enthalten, auf den gegebenen Farbwert gesetzt (das funktioniert eigentlich nur sinnvoll für 2-farbige icons, ich habe aber noch keine bessere Lösung). Also schau mal, ob Du bei den Icons Farben ungleich '000000' gesetzt hast und korrigiere das.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Ridchi1980 am 20 Februar 2020, 17:31:32
Hallo,

ich hab ein 2.13 e-Paper mit ESP8266 und ich bekomm das bild nicht draufgeladen.
Es erscheint die Meldung: Error uploading image to device, max retries (3) reached

an welcher schraube muss ich drehen?

vg Ridchi
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 21 Februar 2020, 08:47:26
ich hab ein 2.13 e-Paper mit ESP8266 und ich bekomm das bild nicht draufgeladen.
Es erscheint die Meldung: Error uploading image to device, max retries (3) reached

Nutzt du die Original-waveshare-Firmware? Wie sieht das FHEM-Log für den Vorgang aus? Klappt der direkte Upload, wenn du den ESP8266 im Browser aufrufst?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 21 Februar 2020, 10:00:23
Hallo,

ich hab ein 2.13 e-Paper mit ESP8266 und ich bekomm das bild nicht draufgeladen.
Es erscheint die Meldung: Error uploading image to device, max retries (3) reached

an welcher schraube muss ich drehen?

vg Ridchi

Um dazu etwas sagen zu können, bräuchte ich mehr Infos (FHEM device listing, Logeinträge mit verbose 4).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 21 Februar 2020, 15:51:37
Kannst Du bitte mal mit folgender Version schauen, ob der Upload jetzt klappt. Bei den Icons ist das noch nicht perfekt. Aktuell habe ich es jetzt so gemacht: Wenn Du keine Farbe setzt, dann lässt die Konversion die Icons so wie sie sind. Falls eine Farbe gesetzt ist, wird die Farbe aller Icon Pixel, die Farbwerter größer 0 enthalten, auf den gegebenen Farbwert gesetzt (das funktioniert eigentlich nur sinnvoll für 2-farbige icons, ich habe aber noch keine bessere Lösung). Also schau mal, ob Du bei den Icons Farben ungleich '000000' gesetzt hast und korrigiere das.

Da war für ESP8266 Boards leider noch ein Fehler enthalten. Bitte mit der hier angehängten Version testen, und melden, fals OK.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Ridchi1980 am 21 Februar 2020, 16:22:24
Um dazu etwas sagen zu können, bräuchte ich mehr Infos (FHEM device listing, Logeinträge mit verbose 4).
2020.02.21 16:17:22 4: Start forked process to convert output picture
2020.02.21 16:17:22 4: File /opt/fhem/www/images/2in13bc-b.png opened, sizes is 104 x 212
2020.02.21 16:17:23 4: Finished conversion in background doing automatic upload as requested
2020.02.21 16:17:23 3: Diplay01: sending HTTP request to http:///EPD with data: fa
2020.02.21 16:17:23 3: Diplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.21 16:17:23 3: Diplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.21 16:17:23 3: Diplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.21 16:17:23 1: Diplay01: problems with communication to device, max retries (3) reached
2020.02.21 16:17:33 3: Diplay01: sending HTTP request to http:///EPD with data: fa
2020.02.21 16:17:33 3: Diplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.21 16:17:33 3: Diplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.21 16:17:33 3: Diplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.21 16:17:33 1: Diplay01: problems with communication to device, max retries (3) reached

das ist der log...

oder hab ich irgendwas vergessen? Oder fehlen mir noch irgend welche Packete?

Ridchi
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 21 Februar 2020, 16:47:08
Du hast keine URL angegeben (IP Adresse des ESP8266).

So etwas wie:

attr Diplay01 url 192.168.178.xxx
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Ridchi1980 am 21 Februar 2020, 17:14:30
was für IP adresse? das Modul steckt doch ganz normal auf der Raspberry Pinleiste und wird über SPI angesprochen

https://www.waveshare.com/wiki/2.13inch_e-Paper_HAT_(D) (https://www.waveshare.com/wiki/2.13inch_e-Paper_HAT_(D))
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 21 Februar 2020, 20:23:05
Das Modul heißt ja ESPEink.
Und nicht HATEink.

Gruß Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 21 Februar 2020, 21:29:35
was für IP adresse? das Modul steckt doch ganz normal auf der Raspberry Pinleiste und wird über SPI angesprochen

https://www.waveshare.com/wiki/2.13inch_e-Paper_HAT_(D) (https://www.waveshare.com/wiki/2.13inch_e-Paper_HAT_(D))

Das Modul unterstützt leider nur die Anbindung der EInk Displays über ein ESP Modul. Das ESP ist ein Arduino kompatibler Microcontroller mit WLAN (kostet so um die 6 Euro). Wenn man auch direkt am Pi verbundene Displays unterstützen wollte, müsste man die komplette Kommunikation mit dem Device anpassen (neu machen). Ich kann mir mal überlegen, ob das machbar ist, kann aber nichts versprechen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Ridchi1980 am 22 Februar 2020, 09:20:03
ich musste zum betreibern aber auch den ESP Treiber installieren... von daher dachte ich das wär das gleiche.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 22 Februar 2020, 14:47:42
ich musste zum betreibern aber auch den ESP Treiber installieren... von daher dachte ich das wär das gleiche.

Es gibt mehrere Varianten, das Display zu betreiben:
* direkt mit einem HAT (siehe https://www.waveshare.com/wiki/E-Paper_Driver_HAT)
* WLAN via ESP8266/ESP32
* Bluetooth via ESP32

Für die HAT-Variante benötigt man keinen ESP, da die Verbindung direkt über den RPi abgewickelt wird. Dort sollten nur die Bins/Libs für WiringPi, bcm2835 und Python benötigt werden.
Ich selbst habe zwar auch die HAT-Platine, diese habe ich jedoch über einen (normalen, d.h. kein "waveshare driver board") ESP32 angeschlossen, anstatt diese auf den PI zu stecken (der wo anders wohnt als das Display).

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 22 Februar 2020, 15:51:41
Hi,

Nach dem ich die PIN Belegung geändert habe funktioniert mein Display. :)

@Jendaw: Danke dir nochmal.

Ich habe jetzt allerdings ein anderes Problem. Ich habe im Gimp eine png Datei mit 122x250 Pixel erstellt. Die Vorlage hat nur einen weißen Hintergrund.
Wenn das espink Modul diese überträgt, zeigt das Display 6 Schwarze Balken bzw. Striche--> Siehe Bild. Die Feuchtigkeit mit Text, das ich mitsende wird angezeigt. Was mache ich hier falsch? Ich vermute, dass die png Vorlage das Problem verursacht.

VG
Peter

Internals:
   BOARDTYPE  ESP8266
   COLORMODE  monochrome
   CONVERTMODE level
   DEF        /opt/fhem/images/122x250.png 192.168.8.41 monochrome level
   DEVICETYPE 1.54inch_e-Paper_Module
   FUUID      5e483f6c-f33f-0de6-0759-eaabdf747c202e1d
   INTERVAL   level
   NAME       myEInk
   NOTIFYDEV  global,Sensor_Aussen,myEInk
   NR         863
   NTFY_ORDER 50-myEInk
   PICTUREFILE /opt/fhem/images/122x250.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL       
   OLDREADINGS:
   READINGS:
     2020-02-16 13:35:00   1-angle         0
     2020-02-16 12:57:49   1-blockwidth    2
     2020-02-16 12:57:09   1-color         000000
     2020-02-16 12:57:08   1-def           addtext#Feuchte:#30#100#70#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
     2020-02-16 12:57:09   1-font          medium
     2020-02-16 12:57:08   1-isIcon        0
     2020-02-16 12:57:09   1-linegap       0
     2020-02-16 13:23:03   1-size          30
     2020-02-16 12:57:08   1-text          Feuchte:
     2020-02-16 13:50:08   1-x             50
     2020-02-16 13:19:02   1-y             90
     2020-02-16 13:36:48   2-angle         0
     2020-02-16 13:36:11   2-blockwidth    0
     2020-02-16 13:36:11   2-color         000000
     2020-02-16 13:36:11   2-def           textreading#Sensor_Aussen:humidity#2#55#300#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
     2020-02-16 13:36:11   2-font          medium
     2020-02-16 13:36:11   2-isIcon        0
     2020-02-16 13:36:11   2-linegap       0
     2020-02-16 13:36:11   2-size          300
     2020-02-16 13:57:58   2-text          62
     2020-02-16 13:36:11   2-trigger       Sensor_Aussen:humidity
     2020-02-16 13:49:05   2-x             103
     2020-02-16 13:50:40   2-y             85
     2020-02-16 13:36:11   deftexts        2
     2020-02-16 14:00:45   result_picture  <html><img src=/fhem/images/myEInk/result.png?dummy=724001.441024424></img><div>/fhem/images/myEInk/result.png</div></html>
     2020-02-16 14:00:40   source_picture  <html><img src=/fhem/images/myEInk/122x250.png?dummy=713277.999786399></img><div>/fhem/images/myEInk/122x250.png</div></html>
   helper:
Attributes:
   1-angle    0
   1-blockwidth 2
   1-size     30
   1-x        50
   1-y        90
   2-angle    0
   2-x        103
   2-y        85
   boardtype  ESP32
   colormode  monochrome
   convertmode level
   devicetype 2.13inch_e-Paper_HAT
   interval   30
   placement  top-left
   room       ESPEasy
   scale2fit  0
   url        192.168.8.41
   userattr   1-angle 1-blockwidth 1-color:colorpicker,RGB 1-font 1-linegap 1-size 1-text 1-trigger 1-x 1-y 2-angle 2-blockwidth 2-color:colorpicker,RGB 2-font 2-linegap 2-size 2-text 2-trigger 2-x 2-y
   verbose    1

Hallo zusammen,

Kann mir jemand einen Tip geben, warum ich diese komische Balken im Display habe? Es ist noch zu ergänzen, dass die Bilder die ich direkt über den Webserver hochlade, einwandfrei dargestellt werden (egal welche Auflösung).
Ich bin kein Entwickler aber ich könnte mir vorstellen, dass der ESPEInk Modul die LibRSVG Bibliothek zum konvertieren der Bilder in eine Vector Grafik nutzt.
Ich nutze den ESP32-Code vom Icinger, der uns den freundlicherweise zur Verfügung gestellt hat. Ich finde die ESPEInk Lösung scharmant und hätte gerne das in Action gesehen aber ich komme leider jetzt nicht weiter. :(

Gruß
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 23 Februar 2020, 09:08:23
An der libSVG wird es wohl nicht liegen, da in Deinen gepusteten Bildern der FHEM Anzeige ja alles OK aussieht und nur dort diese lib genutzt wird.
Da muss irgendwie etwas bei der Übertragung zum Device schief gehen. Kannst Du mal posten was das Log bei verbose 5 ausgibt.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 23 Februar 2020, 17:27:12
An der libSVG wird es wohl nicht liegen, da in Deinen gepusteten Bildern der FHEM Anzeige ja alles OK aussieht und nur dort diese lib genutzt wird.
Da muss irgendwie etwas bei der Übertragung zum Device schief gehen. Kannst Du mal posten was das Log bei verbose 5 ausgibt.

Hi,

hier das Log in Verbose 5. Sieht für mich wunderbar aus.

2020-02-23_17:20:36 myEInk 1-trigger: Sensor_Aussen:humidity
2020-02-23_17:20:36 myEInk 1-text: 87
2020-02-23_17:20:36 myEInk 1-isIcon: 0
2020-02-23_17:20:36 myEInk 1-def: textreading#Sensor_Aussen:humidity#100#50#5#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
2020-02-23_17:20:36 myEInk 1-x: 100
2020-02-23_17:20:36 myEInk 1-y: 50
2020-02-23_17:20:36 myEInk 1-size: 5
2020-02-23_17:20:36 myEInk 1-angle: 90
2020-02-23_17:20:36 myEInk 1-color: 000000
2020-02-23_17:20:36 myEInk 1-font: medium
2020-02-23_17:20:36 myEInk 1-linegap: 0
2020-02-23_17:20:36 myEInk 1-blockwidth: 0
2020-02-23_17:20:47 myEInk convert
2020-02-23_17:20:48 myEInk source_picture: <html><img src=/fhem/images/myEInk/122x250.png?dummy=73652.5993661772></img><div>/fhem/images/myEInk/122x250.png</div></html>
2020-02-23_17:20:53 myEInk result_picture: <html><img src=/fhem/images/myEInk/result.png?dummy=73652.5993661772></img><div>/fhem/images/myEInk/result.png</div></html>
2020-02-23_17:21:10 myEInk upload
2020-02-23_17:21:19 myEInk 1-text: 86

hier das Listing des Devices
Internals:
   BOARDTYPE  ESP32
   COLORMODE  monochrome
   CONVERTMODE dithering
   DEF        /opt/fhem/images/122x250.png 192.168.8.41 monochrome dithering
   DEVICETYPE 2.13inch_e-Paper_HAT
   FUUID      5e483f6c-f33f-0de6-0759-eaabdf747c202e1d
   INTERVAL   1800
   NAME       myEInk
   NOTIFYDEV  global,Sensor_Aussen,myEInk
   NR         854
   NTFY_ORDER 50-myEInk
   PICTUREFILE /opt/fhem/images/122x250.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        192.168.8.41
   OLDREADINGS:
   READINGS:
     2020-02-23 17:20:36   1-angle         90
     2020-02-23 17:20:36   1-blockwidth    0
     2020-02-23 17:20:36   1-color         000000
     2020-02-23 17:20:36   1-def           textreading#Sensor_Aussen:humidity#100#50#5#90#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf\
     2020-02-23 17:20:36   1-font          medium
     2020-02-23 17:20:36   1-isIcon        0
     2020-02-23 17:20:36   1-linegap       0
     2020-02-23 17:20:36   1-size          5
     2020-02-23 17:21:54   1-text          86
     2020-02-23 17:20:36   1-trigger       Sensor_Aussen:humidity
     2020-02-23 17:20:36   1-x             100
     2020-02-23 17:20:36   1-y             50
     2020-02-23 17:20:36   deftexts        1
     2020-02-23 17:20:53   result_picture  <html><img src=/fhem/images/myEInk/result.png?dummy=73652.5993661772></img><div>/fhem/images/myEInk/result.png</div></html>
     2020-02-23 17:06:19   source_picture  <html><img src=/fhem/images/myEInk/122x250.png?dummy=915638.801041968></img><div>/fhem/images/myEInk/122x250.png</div></html>
   helper:
Attributes:
   boardtype  ESP32
   colormode  monochrome
   convertmode dithering
   devicetype 2.13inch_e-Paper_HAT
   interval   1800
   room       ESPEasy
   url        192.168.8.41
   userattr   1-angle 1-blockwidth 1-color:colorpicker,RGB 1-font 1-linegap 1-size 1-text 1-trigger 1-x 1-y

VG
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 24 Februar 2020, 08:44:18
Ich brauche nicht das Log des Devices sondern das von FHEM.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 24 Februar 2020, 11:22:40
Ich brauche nicht das Log des Devices sondern das von FHEM.

Hi Eki,

alles klar. Habe  nach ESPEINK gefiltert, da das Fhem.log in verbose 5 sehr mächtig ist. Anbei die Datei.

Gruß
Peter

Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 24 Februar 2020, 18:53:11
Hallo zusammen,

hier mal meine Info zum Thema ESP32, EInk-Display und der DeepSleep. An den 3V3 hängt seit Anfang ein 1000uF Elko.
Als Source habe ich das Packet vom Icinger verwendet.
Ich habe hier eine FB 6490 (OG) / AP (EG) und schon diverse ESP8266 mit Tasmota und ESPEasy am laufen.
Ein ESPEasy ist Akku-Betrieben und legt sich per DeepSleep schlafen.

Der ESP32 scheint hier aber eine Zicke zu sein. Wie man in diversen Foren lesen kann hat der seine Probleme nach dem Aufwachen.
Er will sich dann einfach nicht mit dem AP verbinden. Ich habe auch die letzten Wochenenden einige Vorschläge aus den Foren
versucht. Z.B. https://github.com/espressif/arduino-esp32/issues/2501 (https://github.com/espressif/arduino-esp32/issues/2501) .
Von WLAN reseten vor und nach dem DeepSleep. Auch habe ich alle Parameter beim WLAN-Begin mit übergeben, wie
Statische IP, DNS, Gateway und Kanal-Nummer. Erst seit ich die mit angebe gibt es auch keine Fehlermeldungen beim compilieren ?!
Immer wenn ich dachte nun läuft die Gurke und ich schreibe das hier, kam Murphy um die Ecke und dreht mir eine Nase.

Dann will sich der ESP32 nicht mehr mit dem AP verbinden
Zitat
Reason: 202 - AUTH_FAIL
oder aber er hängt nach dem Start und musste geresettet werden  ::) >:(

Das Modul von eki funktioniert hingegen ohne Probleme.

Ich wollte das ganze Energie-Sparend betreiben, was bei einem EInk-Display ja auch Sinn machen würde.
Wenn meine Motivation nicht zu sehr leidet werde ich mir noch ein ESP8266 mit Stecker für die EInk bestellen.
Eventl. funktioniert der besser mit DeepSleep und der FB.

Gruss Gerd

Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 25 Februar 2020, 15:24:35
Da war für ESP8266 Boards leider noch ein Fehler enthalten. Bitte mit der hier angehängten Version testen, und melden, fals OK.

Perfekt, herzlichen Dank wieder einmal !
Upload funktioniert.

Ich habe jetzt die Farbanweisung bei den Icons entfernt (zB: iconreading#cmyProPlanta:fc2_weather12Icon#60#235#50#0#) und es ist ist so wie ich mir es vorgestellt hatte  :)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 25 Februar 2020, 16:17:21
Beim weiter ausprobieren fällt mir auf:
Ein Upload zeigt mir wiederholt "Error uploading image to device, max retries (3) reached" an, jedoch wird er fehlerfrei ausgeführt.

verbose = 4
2020.02.25 16:12:31 4: Start forked process to convert output picture
2020.02.25 16:12:31 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1148.
2020.02.25 16:12:32 1: Number of colors used: 64
2020.02.25 16:12:32 1: Number of colors used: 64
2020.02.25 16:12:33 1: Number of colors used: 64
2020.02.25 16:12:33 1: PERL WARNING: Argument "FF1000" isn't numeric in division (/) at ./FHEM/89_ESPEInk.pm line 1134.
2020.02.25 16:12:33 1: PERL WARNING: Argument "FF1000" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.02.25 16:12:33 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1125.
2020.02.25 16:12:33 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1148.
2020.02.25 16:12:33 4: File /opt/fhem/www/images/test_SWBalkenStrichLogo.png opened, sizes is 640 x 384
2020.02.25 16:12:50 4: Finished conversion in background
2020.02.25 16:12:55 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: eb
2020.02.25 16:13:11 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.02.25 16:13:21 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.02.25 16:13:31 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.02.25 16:13:41 1: einkDiplay01: problems with communication to device, max retries (3) reached

edit: nur beim 7.5inch_e-Paper_HAT_(B)
edit2: 7.5inch_e-Paper_HAT [=SW] tritt das nicht auf
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 26 Februar 2020, 08:50:59
2020.02.25 16:12:31 4: Start forked process to convert output picture
2020.02.25 16:12:31 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1148.
2020.02.25 16:12:32 1: Number of colors used: 64
2020.02.25 16:12:32 1: Number of colors used: 64
2020.02.25 16:12:33 1: Number of colors used: 64
2020.02.25 16:12:33 1: PERL WARNING: Argument "FF1000" isn't numeric in division (/) at ./FHEM/89_ESPEInk.pm line 1134.
2020.02.25 16:12:33 1: PERL WARNING: Argument "FF1000" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1124.
2020.02.25 16:12:33 1: PERL WARNING: Argument "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf" isn't numeric in int at ./FHEM/89_ESPEInk.pm line 1125.
2020.02.25 16:12:33 1: PERL WARNING: Argument "0.0 W" isn't numeric in sprintf at ./FHEM/89_ESPEInk.pm line 1148.

Unabhängig von der Übertragung: mir scheint, als wäre deine "definition" nicht iO. Es muss etwas verrutscht sein (Raute an der falschen Stelle, Font nicht gefunden etc), dann kommen solche Warnungen wie oben. In einem solchen Fall habe ich den Inhalt von "definition" in einen Texteditor geladen und dann nur die erste Hälfte konvertieren lassen. Falls da keine Warnung kam, dann die Hälfte vom Rest dazu genommen usw. ("sukzessive Approximation" :) ).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 26 Februar 2020, 09:01:39
Beim weiter ausprobieren fällt mir auf:
Ein Upload zeigt mir wiederholt "Error uploading image to device, max retries (3) reached" an, jedoch wird er fehlerfrei ausgeführt.

Ich habe mit einem 7.5inch_e-Paper_HAT_(B) keine (solchen) Probleme. Du nutzt doch auch ein ESP32, da wundert mich deine URL, die müsste imo so aussehen "http://10.0.0.130/EPDu_".

Ich nutze derzeit die unmodifizierte waveshare-Firmware vom 16.12.19 und die ESPEInk vom 21 Februar 2020 an einem "normalen" ESP32 (kein waveshare-Modul).
Mein Log:
4: Start forked process to convert output picture
1: PERL WARNING: Use of uninitialized value $usedcolors in concatenation (.) or string at ./FHEM/89_ESPEInk.pm line 1216.
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
1: Number of colors used:
4: File /opt/fhem/www/images/displayBackground.png opened, sizes is 640 x 384
4: Finished conversion in background
3: system_display: sending HTTP request to http://eink-panel/EPDu_ with data:

hth

edit: sehe grad, dass es eine neue waveshare-Firmware vom 19.02.20 gibt: https://www.waveshare.com/wiki/File:E-Paper_ESP32_Driver_Board_Code.7z
edit2: In den waveshare-Treiber sind nur Examples hinzugefügt worden, Änderungen am Treiber selbst gibt es keine.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 26 Februar 2020, 10:37:08
Zitat
Ich habe jetzt allerdings ein anderes Problem. Ich habe im Gimp eine png Datei mit 122x250 Pixel erstellt. Die Vorlage hat nur einen weißen Hintergrund.
Wenn das espink Modul diese überträgt, zeigt das Display 6 Schwarze Balken bzw. Striche--> Siehe Bild. Die Feuchtigkeit mit Text, das ich mitsende wird angezeigt. Was mache ich hier falsch? Ich vermute, dass die png Vorlage das Problem verursacht.

Kannst Du mal mit der angehängten Version schauen, ob das Problem damit beseitigt ist. Dein Display ist eines, das "Spezialbehandlung" im Code braucht, und da war noch ein Fehler.

Zitat
edit: sehe grad, dass es eine neue waveshare-Firmware vom 19.02.20 gibt: https://www.waveshare.com/wiki/File:E-Paper_ESP32_Driver_Board_Code.7z
Zumindest auf die Kommunkation mit dem Board hat diese Version keine Änderungen und damit keine Relevanz für 89_ESPEInk.pm.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 26 Februar 2020, 11:20:50
Unabhängig von der Übertragung: mir scheint, als wäre deine "definition" nicht iO. Es muss etwas verrutscht sein (Raute an der falschen Stelle, Font nicht gefunden etc), dann kommen solche Warnungen wie oben. In einem solchen Fall habe ich den Inhalt von "definition" in einen Texteditor geladen und dann nur die erste Hälfte konvertieren lassen. Falls da keine Warnung kam, dann die Hälfte vom Rest dazu genommen usw. ("sukzessive Approximation" :) ).

Danke. Ich hatte Kommentare mit "##" in der definition. Nach deren Entfernung sind diese Fehlermeldungen weg (hatten mich bisher nicht gestört).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 26 Februar 2020, 11:24:12
Ich habe mit einem 7.5inch_e-Paper_HAT_(B) keine (solchen) Probleme. Du nutzt doch auch ein ESP32, da wundert mich deine URL, die müsste imo so aussehen "http://10.0.0.130/EPDu_".

...

Nein, ist nutze hier als board die ESP8266 von Waveshare. Der ESP32 wartet noch auf seinen Einsatz.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 26 Februar 2020, 16:32:53
Danke. Ich hatte Kommentare mit "##" in der definition. Nach deren Entfernung sind diese Fehlermeldungen weg (hatten mich bisher nicht gestört).
Das wäre auch von mir ein Wunschpunkt: Kommentare in der Definition. Und die Definition vllt. ganz in eine separate Datei auslagern, bei mir ist sie schon recht groß :)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 26 Februar 2020, 19:22:27
Kommentare kann ich vorsehen, Auslagerung in eine Datei wäre auch kein großes Ding, finde ich aber dann doch ein bisschen an den Grundprinzipien von FHEM vorbei?!
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 26 Februar 2020, 19:36:50
Kannst Du mal mit der angehängten Version schauen, ob das Problem damit beseitigt ist. Dein Display ist eines, das "Spezialbehandlung" im Code braucht, und da war noch ein Fehler.
Zumindest auf die Kommunkation mit dem Board hat diese Version keine Änderungen und damit keine Relevanz für 89_ESPEInk.pm.

Hallo Eki,

It works, bin begeistert! Saubere Arbeit. Wo kann ich deine Kaffe-Kasse befüllen? habe nur einen kleinen Test heute machen können aber es sieht wirklich gut aus--> siehe Bild.

Schöne Grüße
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 26 Februar 2020, 22:23:18
Auslagerung in eine Datei wäre auch kein großes Ding, finde ich aber dann doch ein bisschen an den Grundprinzipien von FHEM vorbei?!
Vom Speicher wird es keinen großen Unterschied machen, da alle Attribute afair auch im Speicher gehalten werden. Beim Editieren ist es jedoch bereits unübersichtlich, obwohl ich viele statische Elemente im Hintergrundbild habe. Ich meine dazu auch etwas gelesen zu haben, finde es nur grad nicht. Nur diese Empfehlung:
https://forum.fhem.de/index.php/topic,87213.msg796528.html#msg796528 (https://forum.fhem.de/index.php/topic,87213.msg796528.html#msg796528)
Ist jedoch nur ein Vorschlag von mir, wird vermutlich weniger gebraucht ;)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 26 Februar 2020, 23:33:36
Ich denk mal drüber nach, wenn Rudi das vorschlägt, kann es ja nicht so falsch sein. Würde ich auf jeden Fall dann als zusätzliches Attribut “definitionFile” vorsehen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 27 Februar 2020, 08:55:52
OK, hier die Version mit einem neuen Attribut "definitionFile" in welchem man einen Filenamen angeben kann, der Definition enthält (gleiche Syntax wie bei "definition").
und mit der Möglichkeit zu Kommentaren (Zeilen in "definition" oder "definitionFile", die mit "#" (oder mit Leerzeichen und dann "#") starten).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 27 Februar 2020, 09:14:08
OK, hier die Version mit einem neuen Attribut "definitionFile" in welchem man einen Filenamen angeben kann, der Definition enthält (gleiche Syntax wie bei "definition").
und mit der Möglichkeit zu Kommentaren (Zeilen in "definition" oder "definitionFile", die mit "#" (oder mit Leerzeichen und dann "#") starten).
Bist du schnell, funktioniert perfekt, auch mit den Kommentaren! So kann ich die Config im Fullscreen-Editor von FHEM bearbeiten.

Zur Veranschaulichung hab ich mal meine Config sowie die verwendeten Bilder angehängt.

edit: zu früh gefreut: im Internal NOTIFYDEF befinden sich jetzt nur sehr wenige Devices, eine automatische Aktualisierung erfolgt auch nicht mehr.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 27 Februar 2020, 09:44:26
Sieht echt gut aus, hast Du das irgendwo an der Wand hängen?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 27 Februar 2020, 10:02:44
Sieht echt gut aus, hast Du das irgendwo an der Wand hängen?
Danke. Derzeit steht es noch auf meinem Schreibtisch, da ich noch mit der Hard- und Firmware sowie FHEM spiele (Sleepmode, MQTT). Es soll jedoch in einem Ribba-Rahmen an eine zentrale Stelle installiert werden.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 28 Februar 2020, 17:05:00
Was bedeutet die Fehlermeldung im Log:
GD Warning: one parameter to a memory allocation multiplication is negative or zero, failing operation gracefully
gdImageCreateTrueColor error at /usr/lib/arm-linux-gnueabihf/perl5/5.28/GD/Image.pm line 86.


Sie entsteht am Flex Display 2.9" am Waveshare-ESP32 bei folgendem Code sobald ich das icon um 270 grad drehe (0° = ohne Fehler):

iconreading#cmyProPlanta:fc2_weather12Icon#10#10#30#270
Starting conversion in background bleibt stehen, aber FHEM läuft normal weiter.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 28 Februar 2020, 18:00:11
Gleiche Fehlermeldung bei:
addicon#fhemicon#110#250#25#270
Werden nur icons aus /opt/fhem/www/images/default für Bildchen herangezogen? SVGs (selbst bei Pfadangabe) aus /opt/fhem/www/images/fhemSVG nicht?
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 28 Februar 2020, 19:29:08
@Jendaw
Mein ESP8266 kam gestern.
Magst du dein Code mit Deepsleep mit mir Teilen?
Dann muss ich das Rad nicht neu erfinden ;D

Danke

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 28 Februar 2020, 22:24:09
Mein ESP8266 kam gestern.
Magst du dein Code mit Deepsleep mit mir Teilen?
Da kann ich dir leider nicht weiterhelfen, ich verwende einen ESP32 v1 mit derzeit Stock-Firmware. Der ESP8266 kann afair nur per externem Interrupt wieder aufwachen. Der ESP32 kann das von selbst, da er einen separaten ULV-Chip dafür hat, der immer läuft. In anderen Projekten verwende ich dazu einen ATTiny85 mit dem ESP8266.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 29 Februar 2020, 00:03:46
Ah ok.
War der Meinung du hast den esp8266 mit Deepsleep laufen.
Mit dem Esp32 klappt bei mir leider nicht Dauerhaft.
Funktioniert das den bei dir zuverlässig?

Eventuell lässt du mir dein Code zum testen zu schicken?

Dann probiere ich das selbst mit dem esp8266. Sensor mit Deepsleep hat 2 Jahre mit einem LUA-Script funktioniert und jetzt mit Espeasy.
Muss man ja nur zwei Pins verbinden.

Gruß Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 29 Februar 2020, 23:07:54
Was bedeutet die Fehlermeldung im Log:
GD Warning: one parameter to a memory allocation multiplication is negative or zero, failing operation gracefully
gdImageCreateTrueColor error at /usr/lib/arm-linux-gnueabihf/perl5/5.28/GD/Image.pm line 86.


Sie entsteht am Flex Display 2.9" am Waveshare-ESP32 bei folgendem Code sobald ich das icon um 270 grad drehe (0° = ohne Fehler):

iconreading#cmyProPlanta:fc2_weather12Icon#10#10#30#270
Ich muss mal schauen, könnte mir aber vorstellen, dass es irgendwas mit einem Berechnungsoverflow bei genau 270 hat. Was passiert denn bei 271 oder 269?

Starting conversion in background bleibt stehen, aber FHEM läuft normal weiter.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 01 März 2020, 09:22:29
Ab 132 tritt das auf. Und ab 319 funktioniert die Rotation wieder, bis 360.

Aber mache Dir keinen Stress, ich drehe einfach das zugrunde liegende Picturefile , dann wird die Rotation wieder obsolet.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 März 2020, 08:39:13
War kein Stress, mit der angehängten Version sollte es gehen. Da sind einige andere Änderungen drin, die ich aufgrund von ein paar Tips von Rudi gemacht habe (ich werde demnächst das Modul auch als offizielles Modul freigeben), also bitte gut testen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 02 März 2020, 10:05:07
Mit dem Esp32 klappt bei mir leider nicht Dauerhaft.
Funktioniert das den bei dir zuverlässig?
Bei "dauerhaft" bin ich leider noch nicht, derzeit immer noch im Testbetrieb (am Rechner). Mein Display benötigt ein erhöhtes Timeout von min. 40s.

Zitat
Eventuell lässt du mir dein Code zum testen zu schicken?
Ich verwende noch die Originalfirmware: https://www.waveshare.com/wiki/File:E-Paper_ESP32_Driver_Board_Code.7z
Stefan hatte jedoch schon etwas in der Richtung gepostet: https://forum.fhem.de/index.php/topic,104171.msg1022935.html#msg1022935

Zitat
Dann probiere ich das selbst mit dem esp8266. Sensor mit Deepsleep hat 2 Jahre mit einem LUA-Script funktioniert und jetzt mit Espeasy.
Muss man ja nur zwei Pins verbinden.
Wie willst du das prinzipiell machen? Wann willst/musst du das Display updaten? Der ESP8266 kann nur max. ~70min schlafen, danach müsstest du etwas tun.

Ich möchte bei mir die Fenster-Status darstellen, benötige deshalb (tagsüber) lediglich einen kurzen Sleep (da würde also ein ESP8266 reichen). Nach dem Sleep würde ich per MQTT bei FHEM anfragen, ob es ein neues Bild gibt, falls nicht, geht das Display wieder schlafen. Ansonsten wird der Upload getriggert.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 02 März 2020, 10:21:04
War kein Stress, mit der angehängten Version sollte es gehen. Da sind einige andere Änderungen drin, die ich aufgrund von ein paar Tips von Rudi gemacht habe (ich werde demnächst das Modul auch als offizielles Modul freigeben), also bitte gut testen.

Nach dem Einspielen des neuen Files, einem Update von FHEM und dessen Neustart ist als erstes mein 4. definiertes Display (2.9"-Flex) verschwunden. Grund? das zugrundeliegende Picturefile ist gelöscht worden?

Die drei restlichen vorhandenen Displays sind als Added as new device gekennzeichnet. Die waren doch schon vorhanden.

Edit: ESP32
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 02 März 2020, 10:37:56
Auf meinen zwei 7.5"-Displays erfolgt kein erfolgreicher Upload.

Uploading image to device wird in FHEM nicht aktualisiert. erst nach einem manuellen Reload der Seite steht Successfully uploaded image to device

Log (verbose = 4):
2020.03.02 10:32:02 4: Start forked process to convert output picture
2020.03.02 10:32:03 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1194.
2020.03.02 10:32:04 4: File /opt/fhem/www/images/test_SWBalkenStrichLogo.png opened, sizes is 640 x 384
2020.03.02 10:32:21 4: Finished conversion in background
2020.03.02 10:32:33 3: einkDiplay01: sending HTTP request to http://10.0.0.130/ with data: eb

Edit: beide ESP8266
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 März 2020, 10:59:58
Grrr. Kannst Du bitte Deine Definitionen posten (list <devicename>).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 02 März 2020, 11:15:38
ESP32, 2.9"-Flex, funktioniert:
Internals:
   BOARDTYPE  ESP32
   CFGFN     
   COLORMODE  monochrome
   CONVERTMODE level
   DEF        /opt/fhem/www/images/eDisplayFlex/296x128.png
   DEVICETYPE 2.9inch_e-Paper_Module_(D)
   FUUID      5e5ccf94-f33f-5656-c375-c93d24b585f484b7
   INTERVAL   604800
   NAME       eDisplayFlex
   NOTIFYDEV  cmyAbfall,fp_date,fp_time,global,eDisplayFlex,cNuki
   NR         67
   NTFY_ORDER 50-eDisplayFlex
   PICTUREFILE /opt/fhem/www/images/eDisplayFlex/296x128.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        10.0.0.131
   .attraggr:
   .attrminint:
   READINGS:
     2020-03-02 10:49:33   result_picture  <html><img src=/fhem/images/eDisplayFlex/result.png?dummy=765010.967259311></img><div>/fhem/images/eDisplayFlex/result.png</div></html>
     2020-03-02 10:19:16   source_picture  <html><img src=/fhem/images/eDisplayFlex/296x128.png?dummy=232959.158082025></img><div>/fhem/images/eDisplayFlex/296x128.png</div></html>
   helper:
Attributes:
   alias      Flex Display 2.9" .131
   boardtype  ESP32
   colormode  monochrome
   convertmode level
   definition attr eDisplayFlex definition
textreading#fp_date:state#10#10#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#fp_time:state#105#10#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
addtext#LUFTGÜTE#150#9#11#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#------------------------------------------------------#1#16#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addicon#fhemicon#260#2#30#0#

addtext#PM 2.5 in µg/m³#1#25#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#12,5#150#25#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#PM 10 in µg/m³#1#40#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#Helligkeit Lux#1#55#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#UV-Index (0-3)#1#70#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext# - #1#85#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf

addtext#Eingang#1#100#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cNuki:aufzu#100#100#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Abfall#1#115#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#cmyAbfall:Anzeige#65#115#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf

   devicetype 2.9inch_e-Paper_Module_(D)
   disable    1
   group      Device
   icon       terminal
   interval   604800
   maxretries 3
   picturefile /opt/fhem/www/images/eDisplayFlex/296x128.png
   placement  top-left
   room       Displays
   scale2fit  0
   url        10.0.0.131
   verbose    0

7.5", ESP8266 convert=ok, kein Upload (Hier 7.5-B=rot, 2. Display=SW im Wesentlichen gleich):
Internals:
   BOARDTYPE  ESP8266
   COLORMODE  color
   CONVERTMODE dithering
   DEF        /opt/fhem/www/images/test_SWBalkenStrichLogo.png
   DEVICETYPE 7.5inch_e-Paper_HAT_(B)
   FUUID      5df261e7-f33f-5656-6753-33b686a9f40a4a33
   INTERVAL   604800
   NAME       einkDiplay01
   NOTIFYDEV  cwzbuecherregal,czSchaltpower,cazklinuxpc,cmyProPlanta,cWetter,czufalldummy,cfb_stromazpc,global,cSolar,cNuki,cvztemp,cnetatmow,einkDiplay01,cmyAbfall,fp_date,fp_time,cWetterstaion,cGaszaehler,cwzavplf
   NR         35
   NTFY_ORDER 50-einkDiplay01
   PICTUREFILE /opt/fhem/www/images/test_SWBalkenStrichLogo.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        10.0.0.130
   .attraggr:
   .attrminint:
   READINGS:
     2020-03-02 10:12:29   deftexts        0
     2020-03-02 10:44:15   result_picture  <html><img src=/fhem/images/einkDiplay01/result.png?dummy=19903.7965239945></img><div>/fhem/images/einkDiplay01/result.png</div></html>
     2020-03-02 10:12:29   source_picture  <html><img src=/fhem/images/einkDiplay01/test_SWBalkenStrichLogo.png?dummy=929805.819018945></img><div>/fhem/images/einkDiplay01/test_SWBalkenStrichLogo.png</div></html>
   helper:
Attributes:
   alias      rotes Display 7.5" .130
   boardtype  ESP8266
   colormode  color
   convertmode dithering
   definition attr einkDiplay01 definition
addtext#Haussteuerung#|300#10#24#0#FFFFFF#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#fp_date:state#|300#45#16#0#FFFFFF#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Aktualisierung:#530#75#8#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#fp_time:state#605#75#8#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf

addtext#Wetter heute#10#80#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc1_condition#10#100#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#aktuelle Temperatur#10#120#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cWetterstaion:temperature{%.1f °C}#|220#120#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Luftfeuchte#10#140#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cWetterstaion:humidity{%.1f %}#|220#140#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Tageshoch#10#160#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cWetter:fc1_high_c{%.1f °C}#|220#160#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Tagestief#10#180#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cWetter:fc1_low_c{%.1f °C}#|220#180#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Windgeschwindigkeit#10#200#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cWetterstaion:windSpeed{%.1f km/h}#|220#200#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

addtext#Wettervorschau#10#225#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
iconreading#cmyProPlanta:fc2_weather12Icon#60#235#50#0
iconreading#cmyProPlanta:fc3_weather12Icon#140#235#50#0
iconreading#cmyProPlanta:fc4_weather12Icon#220#235#50#0
addtext#Regen %#7#295#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#Hoch °C#7#315#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#Tief °C#7#335#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf

textreading#cmyProPlanta:fc2_chOfRain12#|90#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc2_high_c#|90#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc2_low_c#|90#336#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

textreading#cmyProPlanta:fc3_chOfRain12#|170#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc3_high_c#|170#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc3_low_c#|170#335#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

textreading#cmyProPlanta:fc4_chOfRain12#|250#295#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc4_high_c#|250#315#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
textreading#cWetter:fc4_low_c#|250#335#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#           morgen      übermorgen       3.Tag#20#360#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf

addtext#Energie heute#315#80#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Photovoltaik#315#100#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cSolar:Daily.Energy{%.1f kWh}#|530#100#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Stromverbrauch                noch nicht vorhanden#315#120#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
addtext#Gasverbrauch#315#140#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cGaszaehler:verbrTagM{%.1f M3}#|530#140#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

addtext#Status im Haus#315#160#12#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Abfall#315#180#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cmyAbfall:Anzeige#|525#180#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Eingangstuer#315#200#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cNuki:aufzu#|530#200#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Zufallslicht im WZ#315#220#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#czufalldummy:onoff#|530#220#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#AV-Anlage heute#315#240#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cwzavplf:statEnergyDay_kWh{%.1f kWh}#|530#240#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Buecherregal#315#260#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cwzbuecherregal:power{%.1f W}#|530#260#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#LAN heute#315#280#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cfb_stromazpc:statEnergyDay_kWh{%.1f kWh}#|530#280#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Linux heute#315#300#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cazklinuxpc:statEnergyDay_kWh{%.1f kWh}#|530#300#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#USB-Lader#315#320#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#czSchaltpower:power_2{%.1f W}#|530#320#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Holzhaus Grad#315#340#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cvztemp:temperature#|530#340#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
addtext#Wohnzimmer Grad#315#360#10#0#000000#/usr/share/fonts/truetype/msttcorefonts/Arial.ttf
textreading#cnetatmow:temperature#|530#360#10#0#FF1000#/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
   devicetype 7.5inch_e-Paper_HAT_(B)
   disable    1
   group      Device
   icon       terminal
   interval   604800
   maxretries 3
   picturefile /opt/fhem/www/images/test_SWBalkenStrichLogo.png
   room       Displays
   scale2fit  1
   url        10.0.0.130
   verbose    4
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 02 März 2020, 13:18:22
Bei meinem 7.5B @ESP32 funktioniert sowohl die manuelle Konvertierung als auch der Upload.
Was bei mir nicht funktioniert, ist seit dem letzten Update die automatische Konvertierung. Das Internal NOTIFYDEV ist noch immer recht leer. Sowohl mit definitionFile als auch mit definition.

Internals:
   BOARDTYPE  ESP32
   COLORMODE  color
   CONVERTMODE level
   DEF        /opt/fhem/www/images/displayBackground.png
   DEVICETYPE 7.5inch_e-Paper_HAT_(B)
   FUUID      5e0a2eed-f33f-062a-705d-d867dd93f669f529
   INTERVAL   0
   NAME       system_display
   NOTIFYDEV  system_display,global
   NR         630
   NTFY_ORDER 50-system_display
   PICTUREFILE /opt/fhem/www/images/displayBackground.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        eink-panel
   READINGS:
     2020-02-21 15:59:02   deftexts        0
     2020-03-02 13:15:49   result_picture  <html><img src=/fhem/images/system_display/result.png?dummy=485152.098152415></img><div>/fhem/images/system_display/result.png</div></html>
     2020-02-21 15:59:01   source_picture  <html><img src=/fhem/images/system_display/displayBackground.png?dummy=795515.52887224></img><div>/fhem/images/system_display/displayBackground.png</div></html>
   helper:
Attributes:
   alias      Statusanzeige
   boardtype  ESP32
   colormode  color
   convertmode level
   definition textreading#system_time:date_w#92#18#30#0#FFFFFF#/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf#0#0
textreading#system_time:date_w#91#17#30#0#FF0000#/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf#0#0

textreading#weather_sunrise_time:state#60#100#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#weather_sunset_time:state#220#100#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

textreading#weather_sensor1:temperature{% 2.1f}#40#150#32#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
addtext#°C#140#170#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#weather_sensor1:humidity#210#158#24#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
addtext#%#250#170#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

addtext#heute#35#205#12#0#FF0000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc0_Tn{% 2.f°C - }#20#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc0_Tx{% 2.f°C}#60#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc1_weekday#140#205#12#0#FF0000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc1_Tn{% 2.f°C - }#110#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc1_Tx{% 2.f°C}#150#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc2_weekday#230#205#12#0#FF0000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc2_Tn{% 2.f°C - }#200#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#system_weather:fc2_Tx{% 2.f°C}#240#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0


textreading#system_abfallAbholungen:displayText#20#270#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_heating#45#341#20#0#
iconreading#system_display_status:status_shutter#120#341#20#0#
iconreading#system_display_status:status_sunblind#190#341#20#0#

textreading#system_time:date_time#150#370#8#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

# rechte Seite

iconreading#system_display_status:status_dg_bad_dach_fenster#320#80#12#0#000000

iconreading#system_display_status:status_dg_bad_fenster#320#100#12#0#000000
textreading#HM_dg_bad_thermostat:1.ACTUAL_TEMPERATURE{% 2.1f}#520#100#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#HM_dg_bad_thermostat:1.HUMIDITY#590#100#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_dg_kizi_fenster#320#120#12#0#000000
textreading#HM_dg_kizi_thermostat:1.ACTUAL_TEMPERATURE{% 2.1f}#520#120#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#HM_dg_kizi_thermostat:1.HUMIDITY#590#120#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_HM_dg_schlaZiL_tuer#320#140#12#0#000000
iconreading#system_display_status:status_HM_dg_schlaZiR_tuer#320#160#12#0#000000
textreading#HM_dg_schlazi_hzgThermostat:1.ACTUAL_TEMPERATURE{% 2.1f}#520#160#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_eg_wizi_fenster#320#190#12#0#000000
textreading#weather_sensor3:temperature{% 2.1f}#520#190#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#weather_sensor3:humidity#590#190#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_eg_bad_fenster#320#210#12#0#000000
iconreading#system_display_status:status_eg_kueche_fenster#320#230#12#0#000000
iconreading#system_display_status:status_eg_azi_fenster#320#250#12#0#FF0000

iconreading#system_display_status:status_HM_eg_wozi_linkeTerrassen_tuer#320#270#12#0#000000
textreading#HM_eg_wozi_thermostat:1.ACTUAL_TEMPERATURE{% 2.1f}#520#270#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#HM_eg_wozi_thermostat:1.HUMIDITY#590#270#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#system_display_status:status_HM_eg_wozi_rechteTerrassen_tuer#320#290#12#0#000000

iconreading#system_display_status:status_kg_dusche_fenster#320#320#12#0#000000
textreading#weather_sensor2:temperature{% 2.1f}#520#320#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
textreading#weather_sensor2:humidity#590#320#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

   devStateIcon Starting.conversion.in.background:hm-dis-wm55@green Finished.conversion.in.background:hm-dis-wm55@yellow Uploading.image.to.device:hm-dis-wm55@red Successfully.uploaded.image.to.device:hm-dis-wm55@grey
   devicetype 7.5inch_e-Paper_HAT_(B)
   group      Global
   icon       hm-dis-wm55
   interval   0
   picturefile /opt/fhem/www/images/displayBackground.png
   room       System
   timeout    50
   url        eink-panel
   verbose    4
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 März 2020, 16:01:22
Ich denke, das Problem liegt nicht an den Displays sondern am ESP8266 setting . Ich kann aber leider aktuell kein Problem erkennen. Kannst Du mal ein log mit verbose = 5 posten?

Das Problem mit NOTIFYDEV habe ich gefunden, kommt mit der nächsten korrigierten Version.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 März 2020, 17:30:16
Ist das das komplette Log? Da scheint irgendetwas abzubrechen. Die Zahlen vorne sollten bis 245760 gehen und das letzte Kommando müsste /SHOW am Ende haben.
Bei mir gerade noch mal mit mehr oder weniger Deinen Settings ausprobiert. Geht das denn mit der vorherigen Version gut?.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 02 März 2020, 17:36:54
Ich kann das Log nur als txt-file anhängen.
Im Anschluss folgten 2 Minuten lang nur mehr Events von den devices.

Jetzt habe ich eine ältere Version des 89_ESPInk.pm in FhEM geladen, dort funktioniert der Upload. Mangels Versionsangabe kann ich nur die Größe angeben, 106.338 KB, ich hatte sie am 25.2. geladen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 02 März 2020, 17:44:03
Die letzten V heruntergeladen und Größe verglichen - die bei mir funktionierende Version ist aus Antwort #110 am: 21 Februar 2020, 15:51:37
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 02 März 2020, 23:37:06
Hier nun eine Version, die das Problem hoffentlich beseitigt und mit der auch das NOTIFYDEV Problem und die Fehler mit der Drehung korrigiert sind.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 03 März 2020, 09:10:20
ESP32 funktioniert.

ESP8266 sieht schwarzweiß vergrieselt wie im Bild aus.

verbose=4 (1x convert, 2x upload):
2020.03.03 09:03:53 4: Start forked process to convert output picture
2020.03.03 09:03:53 1: PERL WARNING: Invalid conversion in sprintf: end of string at ./FHEM/89_ESPEInk.pm line 1194.
2020.03.03 09:03:55 4: File /opt/fhem/www/images/test_SWBalkenStrichLogo.png opened, sizes is 640 x 384
2020.03.03 09:04:12 4: Finished conversion in background
2020.03.03 09:04:19 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: eb
2020.03.03 09:04:32 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.03.03 09:04:42 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.03.03 09:04:52 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.03.03 09:04:52 2: einkDiplay01: Upload of image currently running, try again later
2020.03.03 09:05:02 1: einkDiplay01: problems with communication to device, max retries (3) reached
2020.03.03 09:05:31 3: einkDiplay01: sending HTTP request to http://10.0.0.130/EPD with data: eb
2020.03.03 09:05:44 3: einkDiplay01: problems with communication to device, trying once more (1 of 3 done)
2020.03.03 09:05:54 3: einkDiplay01: problems with communication to device, trying once more (2 of 3 done)
2020.03.03 09:06:04 3: einkDiplay01: problems with communication to device, trying once more (3 of 3 done)
2020.03.03 09:06:14 1: einkDiplay01: problems with communication to device, max retries (3) reached
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 03 März 2020, 09:27:45
Nach dem Einspielen des neuen Files, einem Update von FHEM und dessen Neustart ist als erstes mein 4. definiertes Display (2.9"-Flex) verschwunden. Grund? das zugrundeliegende Picturefile ist gelöscht worden?

...
Das scheint mir immer dann aufzutreten, wenn das picturefile der devicedefinition im Unterordner (zB /opt/fhem/www/images/eDisplayFlex/) des Displays liegt. Seit ich es in den Ordner /opt/fhem/www/images/ verschoben habe, wird das device nicht mehr gelöscht.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 03 März 2020, 10:24:37
Hallo,

endlich hatte ich gestern etwas Zeit mich dem Display intensiver zu beschäftigen. Ich kann vermelden, dass zumindest bei meinem Display alle so wie erwartet funktioniert. Upload, Konvertierung funktioniert ohne Beanstandung. Das einzige was mir aufgefallen ist, ist  der Löschung der Definitionen über "removeobject". Manchmal werden nicht alle die Ausgewählt wurden, gelöscht. Eine Kleinigkeit, die nicht wirklich störend ist. Ich benutze die Version aus dem Beitrag #128.
Als nächstes ist der Dauerbetrieb an der Reihe.

Gruß
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 03 März 2020, 10:44:20
Hier nun eine Version, die das Problem hoffentlich beseitigt und mit der auch das NOTIFYDEV Problem und die Fehler mit der Drehung korrigiert sind.
Danke. NOTIFYDEV funktioniert (jetzt wieder) nur mit dem Attribut "definition", nicht jedoch mit "definitionFile".
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 03 März 2020, 14:38:39
Noch ein Versuch bezüglich Problem mit ESP8266, sollte jetzt auch bezüglich NOTIFYDEF für definitionfile gehen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 03 März 2020, 15:01:21
Das wars. ESP32 und ESP8266 uploaden jetzt perfekt. DANKE !!
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 03 März 2020, 16:52:02
Das scheint mir immer dann aufzutreten, wenn das picturefile der devicedefinition im Unterordner (zB /opt/fhem/www/images/eDisplayFlex/) des Displays liegt. Seit ich es in den Ordner /opt/fhem/www/images/ verschoben habe, wird das device nicht mehr gelöscht.

Die Ordner, die in Images mit dem Namen des Devices angelegt werden, kommen vom Modul ESPEInk selbst. Dort sollten eigentlich nur die temporären Daten des Devices verwaltet werden (die Ordner werden vom Modul bei define angelegt und bei delete auch wieder aufgeräumt). Wie genau der von Dir genannte Seiteneffekt zustande kommt (zumal noch bei reload des Moduls oder so) muss ich auch erst mal schauen. Aber der Hinweise war schon mal weiterführen, danke.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 03 März 2020, 16:56:23
Danke für die Erklärung. Passt ja wenn ich es weiß.
Ich würde einfach in die device specific help reinschreiben, dass in diese Ordner keine picturefiles reingehören. Damit würden sich weitere Nachforschungen erübrigen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 04 März 2020, 14:23:56
sollte jetzt auch bezüglich NOTIFYDEF für definitionfile gehen.
Geht nach einem FHEM-Restart  :D

Wie konfiguriere ich das Modul so, dass zwar eine automatische Konvertierung, nicht jedoch ein Upload durchgeführt wird? Wäre ein zusätzliches Attribut "doUpload" (o.ä.) mit dem Default=1 denkbar? Mit dieser Konstellation kann ich ein DOIF triggern, welches nach erfolgter Konvertierung (ggf. noch Vergleich mittels md5, ob sich etwas am Bild geändert hat) ein MQTT-Topic setzt, welches nach dem Aufwachen des ESPs abgefragt werden kann. Der ESP kann dann seinerseits den Webserver starten und einen Upload per MQTT-Topic in einem zweiten DOIF triggern.

edit
Zum experimentieren (Fehlerbehandlung gibt es noch nicht wirklich) hab ich die angepassten ESP32-waveshare-Sourcen (zur Besseren Übersicht zusätzlich als Patch) angehängt. In der srvr.h müssen die eigenenen WLAN-Credentials sowie MQTT-Daten eingetragen werden. Da der ESP in den Sleep geht, subscribed er auf ein Topic (Setzen bspw mit "mosquitto_pub -q 1 -d -t epaper/needUpdate -m true"), welches mit QOS=1 auf der Serverseite persistiert werden muss. Findet er im Topic den Wert "true", so startet er seinerseits den Webserver und publisht auf dem State-Topic ein "rdy", welches als Trigger für den Upload genutzt wird).
Die DOIFs habe ich leider noch nicht fertig, hier habe ich noch Probleme die Nachricht mit QOS=1 abzusetzen (kann MQTT2_* leider nicht, "retain" ist hierfür ungeeignet, da es bestehen bleibt).
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 04 März 2020, 17:42:48
Zitat
Wie konfiguriere ich das Modul so, dass zwar eine automatische Konvertierung, nicht jedoch ein Upload durchgeführt wird? Wäre ein zusätzliches Attribut "doUpload" (o.ä.) mit dem Default=1 denkbar? Mit dieser Konstellation kann ich ein DOIF triggern, welches nach erfolgter Konvertierung (ggf. noch Vergleich mittels md5, ob sich etwas am Bild geändert hat) ein MQTT-Topic setzt, welches nach dem Aufwachen des ESPs abgefragt werden kann. Der ESP kann dann seinerseits den Webserver starten und einen Upload per MQTT-Topic in einem zweiten DOIF triggern.

Das geht bisher nicht, kommt auf die Liste.
Titel: FYI:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 06 März 2020, 15:29:18
@Midrag hat in einem Forumsbeitrag: https://forum.fhem.de/index.php/topic,87778.msg1029755.html#msg1029755 (https://forum.fhem.de/index.php/topic,87778.msg1029755.html#msg1029755) ein Gehäuse für das Waveshare 7,5" 800x480 Display gepostet, das man sich - auf dem 3D-Drucker - selbst ausdrucken kann.
Titel: ESPEInk: ESP32-Sourcen II
Beitrag von: Jendaw am 06 März 2020, 16:43:55
Ich habe ein wenig Zeit gefunden und auch den FHEM-Part mittels MQTT umgesetzt, vllt. ist es für den ein oder anderen interessant. Mein Vorgehen ist wie folgt:

Benötigt werden:
defmod system_display ESPEInk /opt/fhem/www/images/displayBackground.png
attr system_display boardtype ESP32
attr system_display colormode color
attr system_display convertmode level
attr system_display definitionFile /opt/fhem/FHEM/eink.cfg
attr system_display devStateIcon Starting.conversion.in.background:hm-dis-wm55@green Finished.conversion.in.background:hm-dis-wm55@yellow Uploading.image.to.device:hm-dis-wm55@red Successfully.uploaded.image.to.device:hm-dis-wm55@grey
attr system_display devicetype 7.5inch_e-Paper_HAT_(B)
attr system_display icon hm-dis-wm55
attr system_display interval 48600
attr system_display picturefile /opt/fhem/www/images/displayBackground.png
attr system_display timeout 50
attr system_display url eink-panel
defmod mqtt_device MQTT <mqtt-server>:1883defmod system_display_status_doif DOIF ([system_display_status]) (\
    set system_display convert\
)
attr system_display_status_doif do always
defmod system_display_doif DOIF ([system_display:result_picture]) (\
    set mqtt_device publish qos:1 stat/flur/system_display/needUpdate true\
)
attr system_display_doif do always
defmod system_display_mqtt MQTT_DEVICE
attr system_display_mqtt IODev mqtt_device
attr system_display_mqtt subscribeReading_cmd {fhem("set system_display upload")} cmd/flur/system_display/upload

ESP-Sourcen sowie zusätzlich das diff sind anghängt.

edit bei mir bleibt das Display noch ab und an hängen, hier muss ich noch schauen, woran es liegt.
edit2 mit dem ESP32-Code vom 08.03. bleibt mein Display nicht mehr hängen
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 07 März 2020, 20:36:21
@Jendaw

Danke für deine Daten. Muss ich mal probieren ob dein Code sich bei mir eher mit der Fritzbox verbinden mag.
Funktioniert das den bei Dir stabil (an einer Fritzbox)?

Habe jetzt am Wochenende leider keine Motivation gehabt. Lag ab Mittwoch für 2 Tage im Bett (zum Glück kein Corona).

Bis jetzt ist die Motivation auch sehr begrenzt deswegen.

Bin ich gespannt ob deine Version eher mit der FB sprechen mag. Eine Wirkliche Erklärung habe ich nicht im Netz gefunden warum sich der ESP32 hier so zickig verhält.

Ansonsten versuch ichs mit dem ESP8266

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 07 März 2020, 21:05:47
Funktioniert das den bei Dir stabil (an einer Fritzbox)
Mit dem reconnect hatte ich nie Probleme (auch an einer FriBo). Der Code lässt den ESP32 allerdings auch nur eine Minute schlafen. Was für ein ESP32-Board hast du? Ich habe ein ESP32 WROOM Devkit v1 Board. Es bekommt eine statische IP-Adresse per DHCP, vllt ist das ein Punkt?
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.
Titel: ESPEInk: ESP32-Sourcen III
Beitrag von: Jendaw am 08 März 2020, 11:08:26
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.

Zwei Änderungen im ESP32-Code sind hinzugekommen, die die Stabilität (zumindest bei mir) erhöhen:
* es werden (bis zu) 100 Updatemeldungen bei jedem Durchlauf abgeholt, damit werden Mehrfachmeldungen während des Sleeps als eine Meldung bearbeitet
* Timeout für den Webserver eingebaut, damit er nicht endlos wartet, falls es Kommunikationsprobleme gibt
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 08 März 2020, 11:44:08
Mit dem reconnect hatte ich nie Probleme (auch an einer FriBo). Der Code lässt den ESP32 allerdings auch nur eine Minute schlafen. Was für ein ESP32-Board hast du? Ich habe ein ESP32 WROOM Devkit v1 Board. Es bekommt eine statische IP-Adresse per DHCP, vllt ist das ein Punkt?
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.

Ich habe das Original waveshare ESP32 Board.
Ich hatte mein Code so weit umgebogen das ich alles relevante im Code eingestellt habe.
Erst danach konnte der ESP sich mit der FB verbinden.
Meine Dauerlauf Versuche hatte ich auf 30sekunden gesetzt.
Maximum ohne Aussetzer waren 243 booten hinterreinnander.

Das funktionierte auch manchmal mit vielen connects.
Manchmal aber schon nach dem 6mal mit Unlust.
Manchmal Verband sich der ESP auch noch aber blieb dann stehen.

Und irgendwann war das Wochenende und Fasnacht vorbei und meine Lust ebenso.

Wie ich davor schon schrieb scheint das ein bekanntes Problem zu sein ohne eindeutigen Lösungsweg.

Im Moment nehme ich auch noch mit der Couch vorlieb  :o

Ich bleib dran.

Danke und Gruß
Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 08 März 2020, 21:32:03
@Jendaw

Danke für deine Daten. Muss ich mal probieren ob dein Code sich bei mir eher mit der Fritzbox verbinden mag.
Funktioniert das den bei Dir stabil (an einer Fritzbox)?

Habe jetzt am Wochenende leider keine Motivation gehabt. Lag ab Mittwoch für 2 Tage im Bett (zum Glück kein Corona).

Bis jetzt ist die Motivation auch sehr begrenzt deswegen.

Bin ich gespannt ob deine Version eher mit der FB sprechen mag. Eine Wirkliche Erklärung habe ich nicht im Netz gefunden warum sich der ESP32 hier so zickig verhält.

Ansonsten versuch ichs mit dem ESP8266

Gruss Gerd

ich kann die reconnect Probleme mit FB bestätigen.

Gruß
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: kkoeniger am 09 März 2020, 17:29:46
Kann es sein, dass der DEVICETYPE "7.5inch_e-Paper_HAT_V2_(B)" in der Vorschau gelb angezeigt wird obwohl er rot ist? Auch die Farbdefinition FF0000 nutzt nichts - immer gelb. Am Display selbst kann ich es nicht testen, da ich keines habe.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 09 März 2020, 18:14:36
Moin zusammen,

@Jendaw
Konnte mich heute wieder aufraffen :=)

Ich habe deine Version aufgespielt aber hier ist das gleiche Spiel zu sehen wie mit den anderen Standard-Sourcen.
Im Monitor der IDE sehe ich nun sogar sporadisch ein "Brownout detector was triggered". Da wird irgendwie sehr schnell etwas im ESP gemacht.
Wenn ich dann Reset drücke habe ich Glück das er sich dann irgend wann ein mal mit der FB verbindet. Danach dann aber wieder nicht.

@pepe_11
Im Anhang meine Version der Sourcen (Übername vom Icinger). Ich habe hier diverse Ausgaben eingebaut um zu sehen ob sich da mit irgend welchen Änderungen besser klappt.
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Vielleicht probierst DU damit ob deine Fritte eher gewillt ist sich connecten zu lassen.
Ich gebe die SSID, PW, Kanal (Zeile 52 in srvr.h), die IP, Gateway, Subnet, Hostname (Zeile 75 in srvr.h)  mit an.
Erst damit wollte sich der ESP eher mit der FB verbinden.
Ohne Angabe des Gateway & Subnet gab es zudem beim compilieren Fehlermeldungen (wieso auch immer).
Im Kopf von der srvr.h stehen zudem die (Fehler)Codes welche beim Status ausgegeben werden können.

Bei der Kanalwahl ist zu beachten (Zeile 52 in srvr.h), das hier bei NULL angefangen wird zu zählen  ::)
Wenn man wie ich, auf Kanal 13 schalten will, ist im Source "12" einzugeben (muss man erst mal drauf kommen ....).

Hier also meine zwei Sourcen zum probieren. Am MQTT vom Icinger habe ich nichts verändert.

Viel Erfolg

Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 09 März 2020, 18:42:30
So, der ESP8266 funktioniert schon mal im Prinzip.
Jetzt fehlt noch das DeepSleep.
Hat das schon jemand in seinem ESP8266-Source eingebaut und kann das hier einspielen?

Danke schon mal.

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: pepe_11 am 09 März 2020, 19:55:39


@pepe_11
Im Anhang meine Version der Sourcen (Übername vom Icinger). Ich habe hier diverse Ausgaben eingebaut um zu sehen ob sich da mit irgend welchen Änderungen besser klappt.
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Vielleicht probierst DU damit ob deine Fritte eher gewillt ist sich connecten zu lassen.
Ich gebe die SSID, PW, Kanal (Zeile 52 in srvr.h), die IP, Gateway, Subnet, Hostname (Zeile 75 in srvr.h)  mit an.
Erst damit wollte sich der ESP eher mit der FB verbinden.
Ohne Angabe des Gateway & Subnet gab es zudem beim compilieren Fehlermeldungen (wieso auch immer).
Im Kopf von der srvr.h stehen zudem die (Fehler)Codes welche beim Status ausgegeben werden können.

Bei der Kanalwahl ist zu beachten (Zeile 52 in srvr.h), das hier bei NULL angefangen wird zu zählen  ::)
Wenn man wie ich, auf Kanal 13 schalten will, ist im Source "12" einzugeben (muss man erst mal drauf kommen ....).

Hier also meine zwei Sourcen zum probieren. Am MQTT vom Icinger habe ich nichts verändert.

Viel Erfolg

Gerd

Hi Maista,

habe gerade deine Sourcen aufgespielt. Ich hatte an der FB Kanal 9 eingestellt gehabt (am ESP 8 eingetragen). Damit wollte  der ESP nicht connecten. Mit dem Kanal 13 läuft es, sehr dubios. Grr..
Ich lasse das jetzt laufen und schaue, ob der dauertest genauso funktioniert und bin auf deep Sleep gespannt. Danke

Gruß
Peter
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 09 März 2020, 20:10:56
Ich habe deine Version aufgespielt aber hier ist das gleiche Spiel zu sehen wie mit den anderen Standard-Sourcen.
Im Monitor der IDE sehe ich nun sogar sporadisch ein "Brownout detector was triggered". Da wird irgendwie sehr schnell etwas im ESP gemacht.
Wenn ich dann Reset drücke habe ich Glück das er sich dann irgend wann ein mal mit der FB verbindet. Danach dann aber wieder nicht.
Sry, wenn es nicht so deutlich geworden ist: das ist eine MQTT-Version und funktioniert nur in der Umgebung, wie in https://forum.fhem.de/index.php/topic,104171.msg1029864.html#msg1029864 beschrieben, ist also keinesfalls ein Standard-Ersatz. Der Brownout kommt vermutlich daher, dass bei dir auf FHEM-Seite das MQTT-Kommando nicht korrekt ausgewertet wird, oder? Dann rennt der Webserver kurz durch, weil kein Client verfügbar ist. Würde man dort noch ein delay() unterbringen, so würde das nur den normalen Betrieb verzögern.

Ich schau mir bei Gelegenheit auch mal die ESP8266-Version an, da ich vermutlich auf diesen umsteigen werden, damit der ESP32 für ein anderes Projekt frei wird. Das wird dann jedoch auch eine MQTT-Version, wie oben beschrieben.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 09 März 2020, 22:49:42
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Ich habe eine (ungetestete) ESP8266-Version aus dem waveshare-Code erstellt, die einen Assistenten für die WLAN-Konfiguration beinhaltet - vllt. bekommt ihr die Verbindungsprobleme damit besser in den Griff? Außerdem ist diese Version OTA-Updatefähig. Die WLAN-Zugangsdaten werden im ESP gespeichert, die Einrichtung ist also nur initial notwendig. Dazu wird ein AccessPoint mit dem Namen "ESPEInk-APSetup" erstellt, an den ihr euch mit WLAN verbinden könnt. Im Browser könnt ihr dann auf dessen IP-Adresse gehen (bspw. "http://192.168.4.1") und wählt dort eure FriBo aus und gebt die Zugangdaten ein. Danach startet sich der ESP8266 neu und sollte sich verbinden und wie der normale waveshare-Server verhalten. Falls bereits Zugangsdaten im Speicher des ESP8266 liegen können die einmalig mit "wifiManager.resetSettings()" gelöscht werden. Bei Bedarf kann ich hier auch ein "Löschimage" dafür erstellen.
Leider ist das ungetestet, da ich noch keinen freien ESP8266 habe. Ich hänge die Sourcen wie auch das Binary an. Zum selber kompilieren benötigt man noch zusätzlich die Lib "Wifi-Manager" (https://github.com/tzapu/WiFiManager/archive/master.zip).
Der MQTT- sowie der Deepsleep-Part ist noch nicht enthalten.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 09 März 2020, 22:58:37
Hallo Jendaw

bei mir läuft zwar mqtt2 aber genauer habe ich mich bisher damit nicht beschäftigt. Es werden damit 3 SONOFF angesprochen und ein paar Aquara-Sensoren.
Aber wirklich beschäftigt habe ich mich mit mqtt noch nicht. Icingers Code hat es zumindest geschafft sich anzumelden.
Was nun für deine Idee benötigt wird steht für mich erst mal hinten an, so lange sich der ESP32 nicht stabil verhält.

Das mit dem WLAN-Assistenten hatte ich auch gelesen das es das gibt. Aber sich damit zu befassen wurde dann von anderen Dingen überholt :=)

Zitat
vllt. bekommt ihr die Verbindungsprobleme damit besser in den Griff?

Unsere Probleme bestehen nicht beim ESP8266 sondern mit dem ESP32 !
ESP8266 habe ich einen im Haus der sich seit Jahren ohne Probleme aus dem DeepSleep aufwachen lässt, sich mit der FB verbindet und bei FHEM meldet.
Das ist ja eben nicht das/mein Problem.

Werd ich bei Gelegenheit probieren.

Danke und Gruss
Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 10 März 2020, 08:47:30
Unsere Probleme bestehen nicht beim ESP8266 sondern mit dem ESP32 !
ESP8266 habe ich einen im Haus der sich seit Jahren ohne Probleme aus dem DeepSleep aufwachen lässt, sich mit der FB verbindet und bei FHEM meldet.
Das ist ja eben nicht das/mein Problem.
Sorry, ich komme nicht mehr mit. Vor ein paar Tagen hattest du noch nach dem Deepsleep-Modus für den ESP8622 gefragt. Nun bin ich am Erstellen eines Codes dafür und nun bist du wieder beim ESP32 - warum bleibst du nicht bei dem, was bereits funktioniert? Btw: mein ESP32 tut seit der letzten Änderung vom Sonntag immer noch seinen Dienst. Dazu muss man aber auch die FHEM-Gegenseite entsprechend einrichten. Wenn du das vorerst nicht möchtest, so kann dir mein ESP32-Code nicht helfen. Wie ist überhaupt dein Anwendungsfall, weil du immer nach einem Deepsleep fragst? Das ESPEInk-Modul arbeitet derzeit noch nach dem Push-Prinzip, das Display sollte dann also gerade nicht schlafen, wenn Daten zur Übertragung bereit stehen. Diese Problematik kann man mit MQTT umschiffen.
Ich werde meine MQTT-Idee erst mal auf den ESP8266 portieren (da ich diesen einsetzen werde, da mir kurze Sleepzeiten genügen). Ggf. kann ich danach, wenn Bedarf besteht, die Autokonfiguration und OTA auf den ESP32 portieren.

Kannst du bitte beschreiben, was du tun willst und wie die Sleepzeiten dazu passen müssen? Es stellt ja jeder etwas anderes auf dem Display dar. Manchen genügt eine Aktualisierung am Tag, bei mir ist es ~minütlich, da ich offene Fenster und Türen zeitnah darstellen möchte.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 10 März 2020, 12:18:54
@Jendaw
Zitat
Vor ein paar Tagen hattest du noch nach dem Deepsleep-Modus für den ESP8622 gefragt. Nun bin ich am Erstellen eines Codes dafür und nun bist du wieder beim ESP32 - warum bleibst du nicht bei dem, was bereits funktioniert?
Das ist auch löblich, ich habe dein ESP32-Code auch nur probiert weil Du ihn hier eingestellt hattest.
Und anständig wie ich bin habe ich Dir nur die Rückmeldung geben wollen wie bei mir das Verhalten mit der FB ist.
Ich war der Meinung das dies von Dir so beabsichtigt war.

Wie gesagt, so lange der ESP32 sich nicht sicher mit den Fritzboxen verbindet, was man auch nachlesen kann, so lange werde ich den daher auch nicht bei mir im Netz verwenden können.
Und da dieses nicht-verbinden-wollen nicht mit mqtt zu tun hat, habe ich das auch gar nicht erst bei mir weiter verfolgt.
Ich wollte nur schauen ob deine Vorgehensweise bei dem Verbindungsaufbau irgend ein Positiven Effekt bei mir haben könnte.

Zitat
Wie ist überhaupt dein Anwendungsfall, weil du immer nach einem Deepsleep fragst?
Wie die Idee vom Icinger bei seinem Code schon war, wenn ich ein E-Papier verwende, möchte ich das auch so nutzen.
So lange nichts übertragen wird kann sich die HW dann auch entsprechend schlafen legen. Ansonsten kann ich auch gleich ein OLED o.ä.
verbauen wenn kein Deepsleep funktioniert.

Zitat
Das ESPEInk-Modul arbeitet derzeit noch nach dem Push-Prinzip, das Display sollte dann also gerade nicht schlafen, wenn Daten zur Übertragung bereit stehen
Das ist mir auch klar. Mit dem Code vom Icinger hat das aber trotz allem funktioniert. Weil er sich nach dem Empfang dann erst schlafen legt.

Aber, wie oben schon geschrieben, wenn der ESP32 sich nicht stabil nach dem Deepsleep und im allgemeinen mit der FB verbinden will, ist der im Netz bei mir nicht zu gebrauchen.
Aus diesem Grund werde ich das dann auch mit dem ESP8266  weiter machen. Der ESP32 ist da eh "Oversized" finde ich. Zumindest in der Konstellation.

Zitat
Kannst du bitte beschreiben, was du tun willst und wie die Sleepzeiten dazu passen müssen
Ich habe bisher nur ein 1.54" Display. Und das aus dem Grund weil ich erst ein mal probieren will in wie weit ich damit was anfangen kann.

Meine Test liefen mit 30/60 Sekunden DeepSleep. Die 30 Sekunden aber auch nur um zu schauen ob der ESP32 sich immer sicher verbindet.
Ich denke mal alle 60 Sekunden aufwachen sollte ausreichen um hier Sinnvoll etwas anzuzeigen.
Wenn ich Echtzeit hätte haben wollen, hätte ich Nextion nehmen müssen. Das brauch ich aber nicht.

Soweit nun alles klar?

Gruss Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 10 März 2020, 13:16:04
Das ist auch löblich, ich habe dein ESP32-Code auch nur probiert weil Du ihn hier eingestellt hattest.
....
Ich denke mal alle 60 Sekunden aufwachen sollte ausreichen um hier Sinnvoll etwas anzuzeigen.
Wenn ich Echtzeit hätte haben wollen, hätte ich Nextion nehmen müssen. Das brauch ich aber nicht.

Soweit nun alles klar?
Danke für deine nochmaligen Ausführungen, damit ist mir dein Anwendungsfall immer noch nicht klar - also was du mit deinem Display eigentlich tun möchtest. "60s schlafen lassen" ist ja bereits eine Lösung für eine Aufgabenstellung. Für mich klingt es damit so, als würdest du etwas Unpassendes ("es funktioniert ja trotzdem") auf dein Problem anwenden. Soll jetzt aber nicht mehr Thema sein, betrachte ich hiermit als erledigt.

Wie dem auch sei, mein ESP32 ist mittlerweile (mit meiner MQTT-Lösung) ~3.000 (>2d) schlafen gegangen und hat sich genauso oft erfolgreich mit meiner FriBo verbunden. Also etwas mehr als deine ~250x. Wenn ich in den ESP8266-Code das Deepsleep eingebaut habe, werde ich noch mal eine "60s-Version" posten.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 10 März 2020, 14:27:08
@eki
OK, hier die Version mit einem neuen Attribut "definitionFile" in welchem man einen Filenamen angeben kann, der Definition enthält (gleiche Syntax wie bei "definition").
und mit der Möglichkeit zu Kommentaren (Zeilen in "definition" oder "definitionFile", die mit "#" (oder mit Leerzeichen und dann "#") starten).

Neu dazu gesetzte Attribute erzeugen aber keine neues Readings im Device?! Ist das Richtig?
Die Daten werden korrekt in das Bild gerechnet.

Ein Hinweis das die Config-Datei "definitionFile" unter "FHEM/meine.cfg" stehen muss fehlt noch in der Hilfe.

Ich habe die alten Readings gelöscht um nur noch über "definition" oder "definitionFile" zu editieren.
Aber nun werden die Texthöhen nicht mehr berücksichtigt?

textreading#BSB:Uhrzeit#01#198#13#90#000000
addtext#WW: #35#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#Nina_Device:WarnCount#35#110#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
addtext#T: #65#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#BSB:8700-Aussentemperatur#65#150#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#W132_22:state#95#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#SD_WS07_TH_1:state#125#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#MQTT2_WetterDisplay:state#188#198#13#90#000000
addtext#HT: #155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#HM.EG.fl.TK.Haustuer:hmstate#155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

Wenn ich in der Zweiten Zeile den Pfad zur Schrift gegen "giant" tausche wird der Text in allen folgenden Zeilen ebenfalls so "gross" dargestellt.
Aber wesentlich kleiner als mit DejaVuSans.ttf.
 
Als ich die Readings noch alle hatte wurden die Schriftarten berücksichtigt.

Hab ich hier irgend etwas überlesen?
Gruss
Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 10 März 2020, 14:39:59
Danke für deine nochmaligen Ausführungen, damit ist mir dein Anwendungsfall immer noch nicht klar - also was du mit deinem Display eigentlich tun möchtest. "60s schlafen lassen" ist ja bereits eine Lösung für eine Aufgabenstellung. Für mich klingt es damit so, als würdest du etwas Unpassendes ("es funktioniert ja trotzdem") auf dein Problem anwenden. Soll jetzt aber nicht mehr Thema sein, betrachte ich hiermit als erledigt.
Von Unpassend habe ich nie etwas geschrieben. Die Aufgabe von einem Display ist etwas anzeigen. Was das alles ist wird sich dann zeigen wenn es bei mir Funktioniert.
Dafür brauche ich jetzt erst mal nicht einen speziellen Anwendungsfall? Und nur das er 60s schläft habe ich nicht als Funktion deklariert.
Dazu brauch ich kein Display oder ein ESP. Aber auch das ist eigentlich nicht mein Thema gewesen.
So lange man etwas probiert gibt es auch nicht unbedingt ein Anwendungsfall.

Zitat
Wie dem auch sei, mein ESP32 ist mittlerweile (mit meiner MQTT-Lösung) ~3.000 (>2d) schlafen gegangen und hat sich genauso oft erfolgreich mit meiner FriBo verbunden.
Ein ESP8266 Akku lief zwei Jahre mit LUA und hatte nie Probleme sich nach dem DeepSleep mit der FB zu verbinden. Und auch mit der ESPEasy-Version ist das kein Thema.
Das funktioniert nun auch schon über ein Jahr.

Zitat
Wenn ich in den ESP8266-Code das Deepsleep eingebaut habe, werde ich noch mal eine "60s-Version" posten.
Danke. Werde ich dann testen.

Gruss Gerd
Titel: ESPEInk: ESP8266-Sourcen II
Beitrag von: Jendaw am 11 März 2020, 16:31:37
Ich hab mich weiter mit dem ESP8266 beschäftigt. Leider hängt mein Display immer noch am ESP32, der Code ist daher noch nicht von mir unter Realbedingungen getestet worden. Was kann er/sollte er können:

Ich hänge die Hauptsource (ersetzt das INO-File von waveshare, muss also in Loader.ino umbenannt werden) sowie das aktuelle Image an, damit man es nicht mehr übersetzen muss (vor dem Upload entpacken). Ich hoffe, ich habe nicht zu viele Fehler drin, testen konnte ich es hardwaremässig leider noch nicht :(

Manuell kann der Upload so aussehen (muss natürlich auf eure Umgebung angepasst werden):
% python3 ~/.arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/upload.py --chip esp8266 --port /dev/ttyUSB0 --baud 460800 --before default_reset --after hard_reset write_flash 0x0 /tmp/ESPEInk_ESP8266_v9.ino.bin
edit: Der Einfachheit halber ist ESP8266-Code und Image jetzt auch zu finden auf github (https://github.com/Yattien/ESPEInk_ESP8266)

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 11 März 2020, 23:19:27
Neu dazu gesetzte Attribute erzeugen aber keine neues Readings im Device?! Ist das Richtig?
Ich musste nach dem Tausch erst FHEM restarten. Wichtig ist, die letzte Version von ESPEInk zu nutzen, erst da gingen die Readings in der Datei wieder.

Zitat
Ein Hinweis das die Config-Datei "definitionFile" unter "FHEM/meine.cfg" stehen muss fehlt noch in der Hilfe.
Muss es afair nicht, aber so ist es bequemer (direkt in FHEM) zu editieren.

Zitat
Ich habe die alten Readings gelöscht um nur noch über "definition" oder "definitionFile" zu editieren.
Aber nun werden die Texthöhen nicht mehr berücksichtigt?

textreading#BSB:Uhrzeit#01#198#13#90#000000
addtext#WW: #35#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#Nina_Device:WarnCount#35#110#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
addtext#T: #65#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#BSB:8700-Aussentemperatur#65#150#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#W132_22:state#95#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#SD_WS07_TH_1:state#125#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#MQTT2_WetterDisplay:state#188#198#13#90#000000
addtext#HT: #155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#HM.EG.fl.TK.Haustuer:hmstate#155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

Wenn ich in der Zweiten Zeile den Pfad zur Schrift gegen "giant" tausche wird der Text in allen folgenden Zeilen ebenfalls so "gross" dargestellt.
Aber wesentlich kleiner als mit DejaVuSans.ttf.
Für Gewöhnlich passiert dass, wenn man einen Fehler in der Config hat. Schau dir am Besten die Zeilen an, ab der es nicht mehr wie gewünscht aussieht. Meist fehlt eine Raute "#" oder eine Angabe ist falsch (Schreibung, Pfad etc.).
Bspw. sieht die erste (und alle anderen) Zeile seltsam aus, das Format ist device:reading#x#y#size#angle#color#font#linegap#blockwidth es fehlen also noch Angaben. Schau dir dazu Modulhilfe an, da hat sich ggf. etwas im Laufe der Zeit geändert.

VG
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 12 März 2020, 10:21:35
Moin
Im Moment steht das Projekt hinten an.
Musste wegen Todesfall unvermittelt abbrechen.

Gruß Gerd
Titel: ESPEInk: neue ESP32- und ESP8266-Sourcen
Beitrag von: Jendaw am 12 März 2020, 21:13:07
@Maista mein Beileid

Ich habe die ESP32-Sourcen nun auch angepasst, sie haben einen ähnlichen Funktionsumfang wie die ESP8266-Sourcen (Einrichtungsmanager, OTA-Update, optionales MQTT, ...). Die Sourcen und die Images befinden sich auf github (https://github.com/Yattien?tab=repositories) unter "Releases". Für das OTA-Update ist die Releasenummer ohne das "v" anzugeben (d.h. für den ESP8266 aktuell die "11").

@eki Sorry für die Entführung und das Vollspamen deines Threads mit dem ESP-Zeugs 8)
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 19 März 2020, 15:30:20
So, um mal den Thread wieder zurück zu kapern, das Modul ist jetzt auch Teil des normalen FHEM Packets und kommt mit normalen updates mit.
Ich werde hier also nur noch Testversionen posten, die aktuell freigegebene Version kommt ab heute über das normale FHEM Update.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Andreas.H18 am 23 März 2020, 08:52:56
Moin

@eki Darf ich fragen auf welchem System du das Modul entwickelst?

Ich versuche seit einiger Zeit XML::LibRSVG auf einem Raspberry 3B+ (Buster) zu installieren, scheitere jedoch daran, dass der Compiler Dateien nicht findet. Die entsprechenden Biblietheken habe ich nach und nach installiert (apt install ...), diese landen auch in /usr/include/ , nur sieht der compiler dort nicht hin.

Installationsversuch:
cpanm (App::cpanminus) 1.7044 on perl 5.028001 built for arm-linux-gnueabihf-thread-multi-64int
Work directory is /home/pi/.cpanm/work/1584900022.1401
You have make /usr/bin/make
You have LWP 6.43
You have /bin/tar: tar (GNU tar) 1.30
Copyright © 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Geschrieben von John Gilmore und Jay Fenlason.
You have /usr/bin/unzip
--> Working on .
Entering /usr/include
Configuring /usr/include
-> N/A
-> FAIL The distribution doesn't have a proper Makefile.PL/Build.PL See /home/pi/.cpanm/work/1584900022.1401/build.log for details.
Searching XML::LibRSVG () on cpanmetadb ...
--> Working on XML::LibRSVG
Fetching http://www.cpan.org/authors/id/M/MS/MSERGEANT/XML-LibRSVG-0.01.tar.gz
-> OK
Unpacking XML-LibRSVG-0.01.tar.gz
Entering XML-LibRSVG-0.01
META.yml/json not found. Creating skeleton for it.
Configuring XML-LibRSVG-0.01
Running Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for XML::LibRSVG
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.44)
Building and testing XML-LibRSVG-0.01
cp LibRSVG.pm blib/lib/XML/LibRSVG.pm
Running Mkbootstrap for LibRSVG ()
chmod 644 "LibRSVG.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- LibRSVG.bs blib/arch/auto/XML/LibRSVG/LibRSVG.bs 644
"/usr/bin/perl" "/usr/share/perl/5.28/ExtUtils/xsubpp"  -typemap '/usr/share/perl/5.28/ExtUtils/typemap' -typemap '/home/pi/.cpanm/work/1584900022.1401/XML-LibRSVG-0.01/typemap'  LibRSVG.xs > LibRSVG.xsc
mv LibRSVG.xsc LibRSVG.c
arm-linux-gnueabihf-gcc -c  -I/usr/include/libxml2 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/usr/lib/arm-linux-gnueabihf/perl/5.28/CORE"   LibRSVG.c
LibRSVG.xs:13:10: fatal error: gdk-pixbuf/gdk-pixbuf.h: Datei oder Verzeichnis nicht gefunden
 #include <gdk-pixbuf/gdk-pixbuf.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:336: LibRSVG.o] Fehler 1
-> FAIL Testing XML::LibRSVG failed. See /home/pi/.cpanm/work/1584900022.1401/build.log for details. Retry with --force to force install it.


die gesuchte Datei:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf
Compiler-pfade:
pi@rasfhem:~ $ arm-linux-gnueabihf-gcc -print-search-dirs
install: /usr/lib/gcc/arm-linux-gnueabihf/8/
programs: =/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/
libraries: =/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../:/lib/arm-linux-gnueabihf/8/:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/8/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/

:GD und Image::LibRSVG sind installiert.

Irgendwelche Ideen?

LG Andreas
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 23 März 2020, 13:49:11
Ich fürchte, dass ich da einen falschen Link in der Doku eingebaut habe (ich hatte damit mal experimentiert). Ich verwende lediglich Image:LibRsvg. Müsste also ach ohne XML:LibRsvg gehen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Andreas.H18 am 23 März 2020, 14:46:48
OH
Danke für die Antwort - leider sehe ich die SVG icons nicht alle auf dem convertierten Bild.
Es kommt immer nur das FHEM Häuschen beim Wetter - Forecast.

Layer 8 Fehler mal wieder - die beiden anderen Icons werden ja korrekt angezeigt.
..ich such mal weiter...

edit:
interressant, das wird als fhemicon.png convertiert:
8-angle   0
8-blockwidth   0
8-color   000000
8-def   iconreading#DarkSkyweather:fc1_icon#10#50#80
8-icon   sunny
8-isIcon   1
8-linegap   0
8-size   70
8-trigger   DarkSkyweather:fc1_icon
8-x   10
8-y   55

aber das als sunny.png:
1-angle   0
1-color   000000
1-def   addicon#temp_temperature#10#30#25
1-icon   sunny
1-isIcon   1
1-size   25
1-x   10
1-y   15

Edit2:
Habe die gleichnamigen Ikonendateien bereinigt und verwende für das EInkdisplay andere Namen. Damit funktionierts.

LG Andreas
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: arthur_dent_2015 am 23 März 2020, 17:34:08
muss es unbedingt waveshare sein oder funktioniert der Sketch auch mit andere eInk Displays z.B dem Inkplate 6 https://www.crowdsupply.com/e-radionica/inkplate-6 ?

Gruß
Arthur
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 23 März 2020, 22:45:29
muss es unbedingt waveshare sein oder funktioniert der Sketch auch mit andere eInk Displays z.B dem Inkplate 6 https://www.crowdsupply.com/e-radionica/inkplate-6 ?

Die in diesem Thread vorgestellten Sketche sind (meist) auf Basis der waveshare-Treiber erstellt worden. Beim Inkplate wird die Darstellung im ESP mittels GFX-Library (https://github.com/e-radionicacom/Inkplate-6-Arduino-library) gerendert, in diesem Projekt hier wird bereits in FHEM das Bild berechnet und "nur noch" hochgeladen. Zudem hat es andere technische Daten als die Waveshare-Displays - ich fürchte, es ist inkompatibel mit den waveshare-Displays.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Maista am 24 März 2020, 09:21:27
Moin

Wenn man sich das Video anschaut und etwas weiter liest findet man Vergleiche zwischen
dem Inkplate und Waveshare Display.

https://www.crowdsupply.com/e-radionica/inkplate-6#details-top
 (https://www.crowdsupply.com/e-radionica/inkplate-6#details-top)

Von daher ist das vermutlich andere Technik.

Gruß Gerd
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 24 März 2020, 13:02:09
Ich habe mir die Seite mal angeschaut. Aktuell ist das komplett anders als die waveshare displays. Das Teil hat zwar einen ESP32 drin, aber aktuell wohl keine Software fertig, mit der man per WLAN da Daten rüber schieben kann (das Einzige, was ich gelesen habe, waren Anwendungen, die aus SD Karte oder über USB Daten auf das Display schaufeln). Das müsste aber jemand machen, der das Modul zur Verfügung hat.
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.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 24 März 2020, 14:03:33
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.
Mit der Inkplate-Lib könnte man die Bilder als Vollbild darstellen. Webserver ist auch kein Problem. Zusätzlich müsste man sich noch anschauen, wie das Image zwischengespeichert wird, das macht der Waveshare-Treiber direkt.
Als Übertragungsprotokoll könnte man dann das bisherige ESP32-Protokoll nutzen, kommt ja nur auf das Bild an.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 24 März 2020, 14:12:34
Wenn das Arduino image direkt mit Bildern, die über WLAN reinkommen in irgendeiner Form umgehen kann, dann passe ich das EInk Modul gern an (das aktuelle Übertragungsprotokoll ist direkt an den Webserver von Waveshare angepasst, das wird so direkt keinen Sinn machen.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 24 März 2020, 14:22:10
Wenn das Arduino image direkt mit Bildern, die über WLAN reinkommen in irgendeiner Form umgehen kann, dann passe ich das EInk Modul gern an (das aktuelle Übertragungsprotokoll ist direkt an den Webserver von Waveshare angepasst, das wird so direkt keinen Sinn machen.
Wird das Bild nicht nur zerstückelt oder wird es noch irgendwie umgerechnet? Falls ersteres, würde es den Pflegeaufwand in ESPEInk verringern, ggf. kann man auch ein Sketch für beides nehmen. Beim nächsten Display geht es dann von vorn los...
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Andreas.H18 am 24 März 2020, 16:19:04
@ eki

Vielen Dank für das Modul!  :)

Ich verwende jetzt auch 'definitionFile' und habe damit keine Unklarheiten bei der Iconsuche, es darf halt nur eins gefunden werden

LG Andreas
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: eki am 25 März 2020, 11:05:31
Wird das Bild nicht nur zerstückelt oder wird es noch irgendwie umgerechnet? Falls ersteres, würde es den Pflegeaufwand in ESPEInk verringern, ggf. kann man auch ein Sketch für beides nehmen. Beim nächsten Display geht es dann von vorn los...

Das Bild wird nicht nur zerstückelt. In der aktuellen Version macht das Modul schon etwas mehr. Letztendlich bildet das Modul das komplette Waveshare Protokolle als Gegenstück zur Arduino Seite nach. Dazu gehören Aufteilung in Päckchen entsprechend der maximalen Datengrößen für die Übertragung, aber auch das Umrechnen der Pixelinformationen in ASCII Zeichen so wie die Arduino Software das braucht, das Aufteilen in die verschiedenen Farbkanäle und sequentielles Schicken dieser Teilinformationen. Außerdem gibt es noch einige spezielle Dinge die von der Art des Displays abhängen.
Ich sehe eingentlich 2 Möglichkeiten:
1. Das ESP Modul macht die Unterscheidung und muss sich dann an alle möglichen neuen Displays anpassen (viel Aufwand auf meiner Seite  :-\)
2. Wir definieren eine Art generisches Protokoll zwischen dem Modul und Arduino und der Aufwand für die Anpassung an die jeweiligen Displays findet im Arduino statt. Dann bräuchten wir aber einen Freiwilligen, der die Arduino Seite betreut, dazu reicht meine Freie Zeit trotz Corona leider nicht.
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Andreas.H18 am 26 März 2020, 09:59:03
@eki

Moin!

Anmerkung:
Beim Neustart des fhem Servers kommt es bei mir vor, dass diverse mqtt-Geräte noch nicht 'anwesend' sind.

Das führt zu diesen Logeinträgen (readings haben keine Werte, da nicht vorhanden):

2020.03.26 09:36:30 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 644.
.
.
.
2020.03.26 09:36:31 1: PERL WARNING: Use of uninitialized value $text in split at ./FHEM/89_ESPEInk.pm line 552.
2020.03.26 09:36:31 1: PERL WARNING: Use of uninitialized value $text in split at ./FHEM/89_ESPEInk.pm line 553.

...funktioniert natürlich trotzdem...

LG Andreas
Titel: Antw:Neues Modul: ESPEInk für e-Paper Displays (Name geändert, war ESP8266EInk)
Beitrag von: Jendaw am 30 März 2020, 09:51:44
Ich sehe eingentlich 2 Möglichkeiten:
1. Das ESP Modul macht die Unterscheidung und muss sich dann an alle möglichen neuen Displays anpassen (viel Aufwand auf meiner Seite  :-\)
2. Wir definieren eine Art generisches Protokoll zwischen dem Modul und Arduino und der Aufwand für die Anpassung an die jeweiligen Displays findet im Arduino statt. Dann bräuchten wir aber einen Freiwilligen, der die Arduino Seite betreut, dazu reicht meine Freie Zeit trotz Corona leider nicht.
Das zweite klingt gut, wobei ich gerade wegen Corona (Ganztages-Kinderbetreuung) keine Zeit habe :)
Ansonsten könnte ich, falls überhaupt Bedarf besteht, die Betreuung übernehmen. Ich bin mir nicht mal sicher, ob meine bisherigen Änderungen überhaupt jmd. nutzt oder diese auf anderer Hardware funktionieren.
Titel: Antw:ESPEInk: ESP8266-Sourcen II
Beitrag von: pepe_11 am 30 März 2020, 15:49:41
Ich hab mich weiter mit dem ESP8266 beschäftigt. Leider hängt mein Display immer noch am ESP32, der Code ist daher noch nicht von mir unter Realbedingungen getestet worden. Was kann er/sollte er können:
  • Einrichtungsmanager für WiFi, MQTT und Deepsleep-Zeit
     - Verbinden mit dem AP "ESPEInk-APSetup" und im Browser die URL "http://192.168.4.1" aufrufen
     - MQTT-Server ist optional, falls keiner angegeben wird, wird kein MQTT verwendet
     - Sleeptime in Sekunden ist optional, wird keine angegeben, läuft der ESP ständig
     - Firmware-Basis-URL ist optional
     - die Einrichtungsdaten werden damit im ESP gespeichert und nicht mehr im Quellcode
  • OTA-Firmware-Update
     - unterhalb der Firmware-Basis-URL werden zwei Dateien erwartet, Hauptnamensbestandteil ist die klein geschriebene (WiFi-)MAC-Adresse des ESP
     - "<MAC>.version" eine Datei, die nur eine Zahl enthält, das ist die Versionsnummer des zugehörigen Firmwareimages
     - "<MAC>.bin" das Firmware-Image
     - ein Update erfolgt nur, wenn die aktuelle Versionsnummer kleiner als die auf dem Webserver ist (ja, ist derzeit viel Handarbeit ;) )
  • Deepsleep: der ESP-Webserver wird für 10s für Aktionen gestartet, danach geht er schlafen, falls eine Schlafdauer konfiguriert ist
     - wird ein manueller Upload über die Webseite oder ein ESPEInk-Upload gestartet, wird der Schlaf solange verzögert
  • MQTT-Szenario, wie in diesem Beitrag (https://forum.fhem.de/index.php/topic,104171.msg1029864.html#msg1029864) beschrieben. Funktioniert nicht standalone, benötigt also eine eingerichtete FHEM-Gegenseite
  • Reset-Seite "http://<esp>/reset", um den Einrichtungsassistenten (ohne Rückfrage) zu starten
  • Abort-Seite "http://<esp>/abort", um einen verzögerten Schlaf (bspw. abgebrochener manueller Upload) sofort auszulösen

Ich hänge die Hauptsource (ersetzt das INO-File von waveshare, muss also in Loader.ino umbenannt werden) sowie das aktuelle Image an, damit man es nicht mehr übersetzen muss (vor dem Upload entpacken). Ich hoffe, ich habe nicht zu viele Fehler drin, testen konnte ich es hardwaremässig leider noch nicht :(

Manuell kann der Upload so aussehen (muss natürlich auf eure Umgebung angepasst werden):
% python3 ~/.arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/upload.py --chip esp8266 --port /dev/ttyUSB0 --baud 460800 --before default_reset --after hard_reset write_flash 0x0 /tmp/ESPEInk_ESP8266_v9.ino.bin
edit: Der Einfachheit halber ist ESP8266-Code und Image jetzt auch zu finden auf github (https://github.com/Yattien/ESPEInk_ESP8266)

VG
Hallo Jendaw,

ich habe mich heute mit dem ES8266 beschäftigt da ein ESP bei mir frei geworden ist. Alles nach deiner Anleitung auf dem FHEM konfiguriert und deine Sourcen ohne Probleme kompiliert.
Nach dem Flashen wie erwartet meine AP Daten + Mqtt Server eingetragen. Das ESP startet und Verbindet sich mit dem AP aber der Webserver ist nicht da.

Hier das Protokoll:
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: server
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: port
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: updateTopic
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: commandTopic
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: sleepTime
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: firmwareUrl
15:31:26.824 -> *WM:
15:31:26.824 -> *WM: AutoConnect
15:31:26.824 -> *WM: Connecting as wifi client...
15:31:26.824 -> *WM: Status:
15:31:26.824 -> *WM: 6
15:31:26.824 -> *WM: Using last saved values, should be faster
15:31:29.723 -> *WM: Connection result:
15:31:29.723 -> *WM: 3
15:31:29.757 -> *WM: IP Address:
15:31:29.757 -> *WM: 192.168.8.45
15:31:29.757 -> Connected.
15:31:29.757 -> *WM: freeing allocated params!
15:31:29.757 ->  MQTT Server: 192.168.8.35 :1883, Client: ESPEInk_ecfabcc2b1a9
15:31:29.757 ->  MQTT UpdateStatusTopic: stat/display/needUpdate
15:31:29.757 ->  MQTT CommandTopic: cmd/display/upload
15:31:29.757 ->  sleep time: 60
15:31:29.757 ->  firmware base URL:
15:31:29.757 -> Setup complete.
15:31:29.757 -> Connecting to MQTT...
15:31:29.790 ->  subscribed to stat/display/needUpdate
15:31:29.790 ->  reconnected, waiting for incoming MQTT message
15:31:39.795 -> Going to sleep for 60 seconds.
15:32:36.401 -> sd $ܟ<


Was noch seltsam ist, sind nach dem Aufwachen irgendwelche wilde Zeichen, der der ESP anzeigt (die bekomme ich per copy and paste nicht hier eingefügt).
Mit deiner bin, die Du mal hier hochgeladen hast, funktioniert der WebServer und der Upload tadellos.

VG
Peter
Titel: Antw:ESPEInk: ESP8266-Sourcen II
Beitrag von: Jendaw am 30 März 2020, 17:22:11
Hallo Peter, danke für den Test! Ich habe gleich einen neuen Thread für die Firmware (https://forum.fhem.de/index.php?topic=109690) erstellt.

Nach dem Flashen wie erwartet meine AP Daten + Mqtt Server eingetragen. Das ESP startet und Verbindet sich mit dem AP aber der Webserver ist nicht da.
Der Webserver wird bei MQTT-Verwendung erst gestartet, wenn das Topic stat/display/needUpdate ein "true" enthält, also geänderte Daten zur Übertragung bereitstehen (aus diesem Grund ist die MQTT-Wachzeit auch kürzer und Display-schonender, da nur bei Bedarf ein Update erfolgt).

Zitat
15:31:39.795 -> Going to sleep for 60 seconds.
15:32:36.401 -> sd $ܟ<


Was noch seltsam ist, sind nach dem Aufwachen irgendwelche wilde Zeichen, der der ESP anzeigt (die bekomme ich per copy and paste nicht hier eingefügt).
Mit deiner bin, die Du mal hier hochgeladen hast, funktioniert der WebServer und der Upload tadellos.
Das gucke ich mir mal an, weißt du noch, welche Version das war, die du vorher genutzt hast (hatte die bereits den WifiManager und deepsleep)? Nutzt du das ESP8266-Board v2 von waveshare?

Können wir die Diskussion hier (https://forum.fhem.de/index.php?topic=109690) weiter verfolgen?
Titel: Antw:ESPEInk: ESP8266-Sourcen II
Beitrag von: pepe_11 am 30 März 2020, 17:37:06
Hallo Peter, danke für den Test! Ich habe gleich einen neuen Thread für die Firmware (https://forum.fhem.de/index.php?topic=109690) erstellt.
Der Webserver wird bei MQTT-Verwendung erst gestartet, wenn das Topic stat/display/needUpdate ein "true" enthält, also geänderte Daten zur Übertragung bereitstehen (aus diesem Grund ist die MQTT-Wachzeit auch kürzer und Display-schonender, da nur bei Bedarf ein Update erfolgt).
Das gucke ich mir mal an, weißt du noch, welche Version das war, die du vorher genutzt hast (hatte die bereits den WifiManager und deepsleep)? Nutzt du das ESP8266-Board v2 von waveshare?

Können wir die Diskussion hier (https://forum.fhem.de/index.php?topic=109690) weiter verfolgen?

Hi Jendaw,

ich habe die bin aus dem Beitrag #181 installiert, diese wenn ich mich richtig erinnere war ohne deep sleep aber dafür mit WifiManager. Ich nutze den D1 mini mit 2.13 Display

Viele Grüße
Peter