FHEM Forum

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:

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

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

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

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

Edit 25.11.2019:
Neue version
Zusätzliche Features:

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

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

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.

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

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).

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

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.

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).

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.

ZitatIch 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).

Klar ich helfe doch gern  :)

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

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.

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.

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).

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.

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:

• Basis des Wettermoduls PROPLANTA mit em Devicenamen "AgroWeather" als Lieferanten der Daten
  
• per attr testInk url <url> muss noch die IP addresse des ESP Treibers angegeben werden
  
• das test_fhem.png file ist unten angehängt und muss ins entsprechende fhem Verzeichnis auf der Platte kopiert werden
  
• In dem Beispiel werden true type fonts verwendet (kann man per "sudo apt install ttf-mscorefonts-installer" installieren), auch hier muss eventuell der Pfad angepasst werden)
  


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


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

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.

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

sudo apt-get install libgd-perl

Danke, jetzt klappt die Definition.

Zitat 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.

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.

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

Zu 1) läuft bei mir schon war tatsächlich nicht schwer. Wenn ich es ein bisschen getestet habe, füge ich es an.

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.

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


ZitatIch 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.

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

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.

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.

Yup, funktioniert.

Zum Thema

Zitateval 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.

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]

ZitatIch 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

ZitatMit 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)

ZitatDisable 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:

Zitat2019.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

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

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.

Ich habe im ersten Beitrag oben jetzt eine neue Version angehängt, die auch die Positionierung per left/mid/right/top/bottom kann.

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:

• Ein reiner Wert von "0" läßt sich mM nicht darstellen (siehe bei Regen% oder Tief-3.Tag). Alle anderen vollen Ziffern und solche mit Kommawerten bereiten mir keine Probleme.
• Der Upload zum Display funktioniert nicht ganz. Es sieht am Display teilweise invertiert und spiegelverkehrt verzerrt aus. Lade ich das generierte Bild über Fhem hoch, so sieht es aus im Foto. Lade ich das file (.../einkDiplay01/result.png direkt über die Weboberfläche des e-paper Driver Boards hoch, geht das problemlos und wird korrekt dargestellt.

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>


Könntest Du bitte noch Dein Basisbild (test_SWBalken.png) posten. Dann kann ich das bei mir besser nachstellen.

Natürlich (logo inzwischen eingefügt). Und großen Dank für Deine Hilfsbereitschaft bei diesem tollen Modul !!

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?

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.

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

Das hört sich interessant an. Das müsste dann ja auch für den ESP8266 übertragbar sein oder?

ZitatDas 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

ZitatInvalid 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

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.

ZitatIch 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

@ 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)

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.

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.

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

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).

Coole Sache, danke.

Funktioniert einwandfrei :)

lg und schönes Wochenende,

Stefan

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)

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.

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.

Danke. Lass Dir Zeit. Das 2.9-D-Display richte ich erst nach Weihnachten ein, ich hatte vorerst nur rumprobiert.

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

Hallo Stefan,

Zitat von: Icinger am 31 Dezember 2019, 05:33:46
mein Display läuft jetzt schon einige Zeit superstabil.

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

VG

Zitat 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

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?

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 :)

irgendwie kann ich zu dem Modul im commandref leider nichts finden, würde es auch gerne testen.

Zitat 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.

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.

Zitat 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 :)

ZitatDas 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.

Danke !

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

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.

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).

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!

Zitat 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):

Code Auswählen Erweitern

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.

Zitat von: bhaal am 18 Januar 2020, 20:57:47

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.

ZitatKann 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.

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).

Da war ich wohl doch zu schnell  :-[

Hier noch mal eine neue Version. Bitte noch mal testen (nach dem Urlaub, viel Spaß).

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

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

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

Hallo Gerd,

Zitat von: Maista am 09 Februar 2020, 19:24:49
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:

Code Auswählen Erweitern

/* 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:

Code Auswählen Erweitern

/* 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

Zitat 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:

• 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

Code Auswählen Erweitern

- $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.

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

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

Zitat von: eki am 10 Februar 2020, 17:12:22
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

ZitatIm 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?

ZitatSollten 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.

Zitat von: eki am 11 Februar 2020, 08:21:31
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.

ZitatDas 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

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.

Zitat 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?

Nein, da geht es. Erst, wenn ich zwischendurch per FHEM uploade, geht die ESP32-Webseite auch nicht mehr.

ZitatFalls 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.

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.

Zitat 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.

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

Ich könnte den HTTP timeout als parameter einbauen, dann kann man das anpassen. Siehst Du das als Lösung des Problems?

Zitat 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?

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?

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.

Zitat 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.

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

Dann mal mit dieser Version testen (würde ich bei positivem Feedback dann auch im ersten Beitrag hier mal "freigeben".

Zitat 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".

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.


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,

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

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

@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

@Maista: Nein, wird kein GPIO benötigt, der ESP32 hat eine interne RTC.

lg, Stefan

Zitat von: Maista am 12 Februar 2020, 22:27:44
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).

ZitatWelche 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

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

Zitat von: pepe_11 am 14 Februar 2020, 11:19:01
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

Zitat von: Jendaw am 14 Februar 2020, 12:03:06
Der waveshare-ESP32-Treiber verwendet die u.a. Pins (epd.h):

Code Auswählen Erweitern

/* 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)

Zitat von: pepe_11 am 14 Februar 2020, 13:08:12
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

Alles klar, danke dir. Vielleicht habe ich mich bei der Verkabelung irgendwo vertan.

VG
Peter

@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

Zitat 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

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


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).

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.

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

Zitat von: Ridchi1980 am 20 Februar 2020, 17:31:32
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?

Zitat 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

Um dazu etwas sagen zu können, bräuchte ich mehr Infos (FHEM device listing, Logeinträge mit verbose 4).

Zitat 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.

Da war für ESP8266 Boards leider noch ein Fehler enthalten. Bitte mit der hier angehängten Version testen, und melden, fals OK.

Zitat von: eki am 21 Februar 2020, 10:00:23
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

Du hast keine URL angegeben (IP Adresse des ESP8266).

So etwas wie:

attr Diplay01 url 192.168.178.xxx

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 heißt ja ESPEink.
Und nicht HATEink.

Gruß Gerd

Zitat 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))

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.

ich musste zum betreibern aber auch den ESP Treiber installieren... von daher dachte ich das wär das gleiche.

Zitat 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.

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

Zitat von: pepe_11 am 16 Februar 2020, 14:17:18
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

Code Auswählen Erweitern


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

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.

Zitat 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.

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

Ich brauche nicht das Log des Devices sondern das von FHEM.

Zitat von: eki am 24 Februar 2020, 08:44:18
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

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

ZitatReason: 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

Zitat von: eki am 21 Februar 2020, 15:51:37
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  :)

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

Zitat von: kkoeniger am 25 Februar 2020, 16:17:21

Code Auswählen Erweitern

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" :) ).

Zitat 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.

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.

ZitatIch 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.

Zitatedit: 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.

Zitat von: Jendaw am 26 Februar 2020, 08:50:59
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).

Zitat von: Jendaw am 26 Februar 2020, 09:01:39
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.

Zitat von: kkoeniger am 26 Februar 2020, 11:20:50
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ß :)

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?!

Zitat von: eki am 26 Februar 2020, 10:37:08
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

Zitat von: eki am 26 Februar 2020, 19:22:27
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 ;)

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.

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).

Zitat 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).

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.

Sieht echt gut aus, hast Du das irgendwo an der Wand hängen?

Zitat von: eki am 27 Februar 2020, 09:44:26
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.

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.

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?

@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

Zitat von: Maista am 28 Februar 2020, 19:29:08
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

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

Zitat 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):

Code Auswählen Erweitern

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.

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.

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.

Zitat von: Maista am 29 Februar 2020, 00:03:46
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

Zitat 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.

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

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

Grrr. Kannst Du bitte Deine Definitionen posten (list <devicename>).

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

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


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.

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?.

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.

Die letzten V heruntergeladen und Größe verglichen - die bei mir funktionierende Version ist aus Antwort #110 am: 21 Februar 2020, 15:51:37

Hier nun eine Version, die das Problem hoffentlich beseitigt und mit der auch das NOTIFYDEV Problem und die Fehler mit der Drehung korrigiert sind.

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

Zitat von: kkoeniger am 02 März 2020, 10:21:04
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.

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

Zitat 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.

Danke. NOTIFYDEV funktioniert (jetzt wieder) nur mit dem Attribut "definition", nicht jedoch mit "definitionFile".

Noch ein Versuch bezüglich Problem mit ESP8266, sollte jetzt auch bezüglich NOTIFYDEF für definitionfile gehen.

Das wars. ESP32 und ESP8266 uploaden jetzt perfekt. DANKE !!

Zitat von: kkoeniger am 03 März 2020, 09:27:45
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.

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.

Zitat von: eki am 03 März 2020, 14:38:39
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).

ZitatWie 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.

@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.

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:

• das Attribut "interval" in ESPEInk steht auf einem hohen Wert, da kein automatischer Upload erfolgen soll
• ein DOIF triggert die Konvertierung
• ein weiteres DOIF reagiert auf Änderungen im ESPEInk-Reading "result_picture" und setzt das MQTT-Topic "stat/flur/system_display/needUpdate" mit dem QOS 1 (=wird im MQTT-Server zwischengespeichert, solange der ESP schläft)
• ein MQTT_DEVICE wartet auf das ESP-Signal im Topic "cmd/flur/system_display/upload"
• der ESP erwacht und befragt das Topic "stat/flur/system_display/needUpdate", ob es was zu tun gibt. Falls nicht, geht er wieder schlafen (Wachzeit ~ 5s).
• falls es etwas zu tun gibt, startet der ESP seinen Webserver und setzt das MQTT-Topic "cmd/flur/system_display/upload"
• das MQTT_DEVICE reagiert darauf und startet den ESPEink-upload

Benötigt werden:

• ESPEInk

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


• mosquitto als MQTT-Server (MQTT2_* kann leider kein QOS)
• MQTT als Verbindung zu mosquitto

defmod mqtt_device MQTT <mqtt-server>:1883

• ein DOIF als Trigger für die Konvertierung (derzeit ist die Konvertierung und der Upload noch gekoppelt), im Beispiel reagiere ich auf die Änderungen in einem dummy-Device "system_display_status", welches bereits alle relevante Informationen enthält

defmod system_display_status_doif DOIF ([system_display_status]) (\
    set system_display convert\
)
attr system_display_status_doif do always

• ein DOIF, welches bei einem Update des konvertierten ESPEInk-Bildes reagiert und das Topic mit qos=1 setzt

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

• ein MQTT_DEVICE um auf die Nachrage des ESP zu reagieren (wichtig ist, dass das Attribut "subscribeReading_cmd" heißt, ansonsten wird das FHEM-Kommando nicht ausgeführt, zumindest nicht in meinen Tests)

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

@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

Zitat von: Maista am 07 März 2020, 20:36:21
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.

Zitat von: Jendaw am 07 März 2020, 21:05:47
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

Zitat von: Jendaw am 07 März 2020, 21:05:47
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

Zitat 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

ich kann die reconnect Probleme mit FB bestätigen.

Gruß
Peter

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.

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

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

Zitat von: Maista am 09 März 2020, 18:14:36


@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

Zitat von: Maista am 09 März 2020, 18:14:36
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

Zitat von: Maista am 09 März 2020, 18:14:36
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

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 :=)

Zitatvllt. 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

Zitat von: Maista am 09 März 2020, 22:58:37
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

@Jendaw

ZitatVor 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.

ZitatWie 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.

ZitatDas 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.

ZitatKannst 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

Zitat von: Maista am 10 März 2020, 12:18:54
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

@eki

Zitat 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).

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

Zitat von: Jendaw am 10 März 2020, 13:16:04
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.

ZitatWie 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.

ZitatWenn ich in den ESP8266-Code das Deepsleep eingebaut habe, werde ich noch mal eine "60s-Version" posten.

Danke. Werde ich dann testen.

Gruss Gerd

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

Zitat von: Maista am 10 März 2020, 14:27:08
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.

ZitatIch 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?

Code Auswählen Erweitern

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

Moin
Im Moment steht das Projekt hinten an.
Musste wegen Todesfall unvermittelt abbrechen.

Gruß Gerd

@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)

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.

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

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.

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

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

Zitat 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 ?

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.

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

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.

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

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.

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.

Zitat 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.

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...

@ 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

Zitat von: Jendaw am 24 März 2020, 14:22:10
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.

@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

Zitat von: eki am 25 März 2020, 11:05:31
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.

Zitat 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:

• 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):

Code Auswählen Erweitern

% 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

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.

Zitat von: pepe_11 am 30 März 2020, 15:49:41
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?

Zitat 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.
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

Bin ich der einzige, der Probleme mit freezes durch ESPEink hat?

Hintergrund ich habe meine eigene Lösung (basierend auf 02_RSS und DoorsignEPD) testweise umgebaut auf ESPEink. Gerade weil 02_RSS freezes bei der Konvertierung erzeugt.

Nun stosse ich in ESPEink auf das Problem, dass beim upload nachvollziehbar regelmässig freezes auftreten (Nicht lange, meistens unter 2 sek).
ich habe ein 7,5Inch epaper Display (alte Auflösung 640x384 oder so) und einen ESP32 mit der Loader-Firmware geflasht.

Die freezes treten auch beim manuellen upload (set ... upload) auf, liegen also nach der Konvertierung ich vermute aber nicht im http-Transfer sondern beim Öffnen der Image-Datei und transfer nach GD

Also das Einzige, was meiner Ansicht nach zu (kurzen) Freezes führen könnte, ist die Umwandlung der pixel aus dem Bild in für die Anzeige "verdaubare" Werte. Dazu gehe ich die pixel einzeln durch und wandle um. Das könnte man natürlich auch noch in den Hintergrund schicken (so wie das Erzeugen des Bildes). Ich muss mal schauen, wie aufwändig das wäre.

@eki: Danke für die schnelle Antwort, Ja das war auch meine Vermutung.
Ich baue bei mir mal temporär ein paar logs ein, damit ich das genauer nachvollziehen kann

Zitat von: viegener am 04 Mai 2020, 14:54:42
@eki: Danke für die schnelle Antwort, Ja das war auch meine Vermutung.
Ich baue bei mir mal temporär ein paar logs ein, damit ich das genauer nachvollziehen kann

Und hier ist das Ergebnis:


2020.05.04 14:59:39 2: epaper: Enter ..._upload
2020.05.04 14:59:39 2: epaper: upload: state set
2020.05.04 14:59:39 2: epaper: upload: files found
2020.05.04 14:59:39 2: epaper: upload: file closed
2020.05.04 14:59:39 2: epaper: upload: GD image created
2020.05.04 14:59:39 2: epaper: upload: start looping
2020.05.04 14:59:41 2: epaper: upload: finalized data creation
2020.05.04 14:59:41 2: epaper: upload: start post to device
2020.05.04 14:59:41 2: epaper: upload: ended
2020.05.04 14:59:41 1: [Freezemon] freezemon: possible freeze starting at 14:59:40, delay is 1.126 possibly caused by: no bad guy found :-(


zu folgendem Code:


#---------------------------------------------------------------------------------------------------
# code converted picture and send it to eInk driver board (and thus to the connected eInk display)
sub ESPEInk_Upload(@) {
    my ($hash) = @_;
    my $name = $hash->{NAME};

  Log3 ($hash, 2, "$name: Enter ..._upload");
my $url = ESPEInk_GetSetting($name,"url");
if (!defined $url) {
return "Error, missing url. Define url to device first";
}

if ($hash->{STATE} =~ /Uploading/) {
Log3 ($hash, 2, "$name: Upload of image currently running, try again later");
return $hash->{STATE};
}

$hash->{STATE} = "Uploading image to device";
  Log3 ($hash, 2, "$name: upload: state set");

my @outarray;

my $devtype = ESPEInk_GetSetting($name,"devicetype");
my $boardtype = ESPEInk_GetSetting($name,"boardtype");
my $devind = $ESPEInk_devices{$devtype}{"id"};

my $rootname = $FW_dir; #File::Spec->rel2abs($FW_dir); # get Filename of FHEMWEB root
my $filename = catfile($rootname,$hash->{SUBFOLDER},$name,"result.png");
  Log3 ($hash, 2, "$name: upload: files found");
if (!open(RESULT,$filename)) {
Log3 $hash, 1, "File $filename cannot be opened";
return "Error opening image file $filename for upload";
} else {
close RESULT;
  Log3 ($hash, 2, "$name: upload: file closed");
my $image = GD::Image->newFromPng($filename);
  Log3 ($hash, 2, "$name: upload: GD image created");
my ($w,$h) = $image->getBounds;
my ($r,$g,$b);
my $i = 0;

  Log3 ($hash, 2, "$name: upload: start looping");
for (my $iy=0; $iy<$h; $iy++) {
for (my $ix=0; $ix<$w; $ix++) {
($r,$g,$b) = $image->rgb($image->getPixel($ix,$iy));
$outarray[$i] = ($r==0&&$g==0)?0:(($r==255&&$g==255)?1:(($r==127&&$g==127)?2:3)); #convert color values to values between 0 and 3
$i++;
}
}
}
  Log3 ($hash, 2, "$name: upload: finalized data creation");

$ESPEInk_uploadcontrol{"retries"} = 0; # actual number of retries
$ESPEInk_uploadcontrol{"maxretries"} = AttrVal($name,"maxretries",3); # maximum number of retries
$ESPEInk_uploadcontrol{"timeout"} = AttrVal($name,"timeout",10); # timout for HTTP calls
$ESPEInk_uploadcontrol{"stepindex"} = 0; # step currently performed (for multi color displays each color is transferred separately)
$ESPEInk_uploadcontrol{"srcindex"} = 0; # index of source array currently transferred (we might need to split due to the limit on arduino code in data transfer length via HTTP)
  Log3 ($hash, 2, "$name: upload: start post to device");
ESPEInk_PostToDevice($hash,($boardtype eq "ESP32")?'EPDx_':'EPD',$devind,\%ESPEInk_uploadcontrol,\@outarray); # convert data from conversion result in appropriate format and send it to the device via HTTP
  Log3 ($hash, 2, "$name: upload: ended");
return $hash->{STATE};
}



Die Schleife läuft bei mir ca 1-2 Sekunden (Raspberry 3 ohne grosse Last) - was nc ht vollständig überraschend ist, denn wir sprechen von ca 250K Durchläufen - mit jeweils einem Pixel, das abgefragt wird und das heisst mehr als 100000 Durchläufe pro Sekunde, was jetzt nicht so schecht ist, aber auch genug für einen Freeze...

Habe mir gerade mal den Code angeschaut - es wäre vermutlich eine Lösung das image (und die Grösseninfos) über params bis zu ESPEInk_CodePixel2Bits mit zu schleifen und dann dort die Berechnungen zu den Pixeln zu machen in dem statt einem Aufruf von ${$array}[$indx] immer dort aus dem image das Pixel berechnet wird.

Habe dazu mal eine neue Version hier angehängt.

Achtung - dabei habe ich noch zwei Probleme korrigiert
-Behandlung von \\n im Blocksatz korrigiert - da gab es ein Problem (ESPEInk_FormatBlockText)
- Ausserdem für lange Strings wurde die texthöhe falsch berechnet

Vielen Dank.

Sieht für mich erst mal OK aus (ich hatte eher daran gedacht das upload einfach, so wie die Konvertierung, per BlockingCall komplett in den Hintergrund zu legen, aber so geht es natürlich auch).
Ich werde das noch ein bisschen weiter testen und dann so in einer Woche ins "Release" übernehmen.

Falls es andere "Testwillige" gibt, gern mit der von hier feedback posten.

Hallo
bräuchte etwas Hilfe bei der Installation des Moduls ESPInk -> kriege kein Image auf das 4.2 EPaper ( von Ali.....)

- E-paper Display läuft perfekt mit anderen Sketches welche die Bibliothek GxEPD benutzen. z.B. https://github.com/G6EJD/ESP32-e-Paper-Weather-Display
- Mit derm Sketch Loader_esp32wf.ino bringe ich kein Bild auf das Display, weder aus dem ESPEInk Modul noch aus der Webpade des ESP32, mit der selben Verdrahtung und der selben HW, Pinbelegung im Loader_esp32wf.ino angepasst.

Ich werde langsam ungeduldig und  verstehe die Welt nicht mehr .....

Was habe ich übersehen oder falsch gelesen? Bin extrem froh um einen Tipp

Remo

Wenn Du mit Webpade die Webpage des ESP32 Eink Treiber Moduls von Waveshare meinst, und es dort auch nicht funktioniert, dann liegt es eher nicht am FHEM Modul sondern auf der ESP Seite würde ich sagen. Wie genau sieht denn Dein Aufbau aus?
Hast Du denn auf dem ESP den Waveshare sketch oder was läuft da?

danke für deine Antwort. 
Auf dem ESP32 ist der Waveshare Sketch (Loader_ESP32wf.ino). Allerdings ist es ein ganz normaler Wemos Lolin ESP32 lite und kein ESP32 von Waveshare. Mehrere andere Sketches laufen mit dem Wemos Lolin ESP32 lite und dem EPaper 4.2 perfekt . Wenn ich aber die Pinzuordnung aus einem funktionierenden Sketch im Loader_ESP32wf.ino anpasse auf:
/* SPI pin definition --------------------------------------------------------*/

#define PIN_SPI_SCK  18
#define PIN_SPI_DIN  23
#define PIN_SPI_CS   5
#define PIN_SPI_BUSY 4
#define PIN_SPI_RST  16
#define PIN_SPI_DC   17

Bringe ich weder aus dem  Webinterface auls aus Fhem nichts auf E-paper

Suche weiter und berichte wenn ich Erfolg habe.
Danke und Gruss

Was sagt denn die serielle Konsole dazu? Kannst du das bitte posten?

Hallo Leute,

tolles Modul. Ich habe das 7.5" Rot/Schwarz V2 Display und bekomme es nicht zum Laufen. pngs werden konvertiert, aber der upload schlägt fehl:

Zitat2020.05.31 21:30:25 1: inky: problems with communication to device, max retries (3) reached

Ich habe den "demo code" von der Wiki installiert. Ist das richtig so? Unter der IP, die ich angegeben habe läuft die "price tag" website und funktioniert auch.

Vielen Dnak für eure Hilfe

Zitat von: Jojocra am 31 Mai 2020, 21:47:26
Hallo Leute,

tolles Modul. Ich habe das 7.5" Rot/Schwarz V2 Display und bekomme es nicht zum Laufen. pngs werden konvertiert, aber der upload schlägt fehl:

Ich habe den "demo code" von der Wiki installiert. Ist das richtig so? Unter der IP, die ich angegeben habe läuft die "price tag" website und funktioniert auch.

Vielen Dnak für eure Hilfe

Es geht nicht um den Democode auf dem ESP32 (oder ESP8266), sondern um den Loader-Code. Beim ESP32 ist es der Loader_esp32wf Sketch der geladen werden muss.

https://www.waveshare.com/wiki/File:E-Paper_ESP32_Driver_Board_Code.7z (https://www.waveshare.com/wiki/File:E-Paper_ESP32_Driver_Board_Code.7z)

Ok, danke für deine antwort. Ich habe diese Datei entpackt:

https://www.waveshare.com/wiki/File:E-Paper_ESP8266_Driver_Board_Code.7z

und die Datei loader/loader.ino auf den esp8226 geladen.
Einen andere sketch find ich nicht. kann mir da jemand helfen?

Zitat von: Jojocra am 03 Juni 2020, 21:37:04
Ok, danke für deine antwort. Ich habe diese Datei entpackt:

https://www.waveshare.com/wiki/File:E-Paper_ESP8266_Driver_Board_Code.7z

und die Datei loader/loader.ino auf den esp8226 geladen.
Einen andere sketch find ich nicht. kann mir da jemand helfen?

Der Pricetag-Democode ist schon die richtige Firmware. Wenn du mit dieser Bilder angezeigt bekommst, dann ist das Display bereit für das FHEM-Modul. Wie sieht deine Konfiguration des Moduls aus? Hast du ggf. einen Tippfehler bei der Display-Adresse?

VG

Ja, auf dem price tag kann ich bilder laden.
Also das hier sind meine Internals und Attribute:

Internals
BOARDTYPE ESP8266
CFGFN
COLORMODE color
CONVERTMODE level
DEF   /opt/fhem/www/images/test-png.png
DEVICETYPE 7.5inch_e-Paper_HAT_(B)
FUUID 5ecd84d1-f33f-c5b4-cf3e-3094dedec8ff3c98
INTERVAL 300
NAME inky
NOTIFYDEV global,inky
NR 1134
NTFY_ORDER 50-inky
PICTUREFILE /opt/fhem/www/images/test-png.png
STATE Error uploading image to device, max retries (3) reached
SUBFOLDER images
TYPE ESPEInk
URL 192.168.1.180

Attributes
colormode color
devicetype 7.5inch_e-Paper_HAT_(B)
url 192.168.1.180


und hier der relevante logeintrag:
2020.06.03 22:44:17 3: inky: sending HTTP request to http://192.168.1.180/EPD with data: eb
2020.06.03 22:44:23 3: inky: problems with communication to device, trying once more (1 of 3 done)
2020.06.03 22:44:29 3: inky: problems with communication to device, trying once more (2 of 3 done)
2020.06.03 22:44:33 3: inky: problems with communication to device, trying once more (3 of 3 done)
2020.06.03 22:44:36 1: inky: problems with communication to device, max retries (3) reached

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

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

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

Danke für das super Modul und Gruss
Remo

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

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

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

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

***mitlesen***

sehr spannendes Thema

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

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

Danke & Gruß
Arthur

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

Danke & Gruß
Arthur

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

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

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

Zitat von: viegener am 24 August 2020, 15:04:50
Generell erscheint mir das inkplate sogar besser geeignet, denn das Rendering der Seite in FHEM ist schon relativ aufwändig und erzeugt erhebliche Last (und freezes bei mir).

Wenn das Display das Rendering durchführen soll, dann muss jeder die (ESP-)Firmware seinen Wünschen anpassen. Es muss ja jede Form einzeln gezeichnet werden. Oder wie meinst du das?
Mein Vorschlag wäre, das Rendering weiterhin in FHEM durchzuführen und mit der Inkplate-Lib nur als Vollbild darzustellen. Würde dir aber nicht helfen.

VG

Zitat von: Jendaw am 24 August 2020, 15:20:54
Mein Vorschlag wäre, das Rendering weiterhin in FHEM durchzuführen und mit der Inkplate-Lib nur als Vollbild darzustellen. Würde dir aber nicht helfen.

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

Gruß
Arthur

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

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

Gruß
Arthur

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

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

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

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

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

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

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

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

VG

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

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

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

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

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

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

VG

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

Hallo,

ich habe zwar keins, lese aber auch mit, weil ich auch mit dem Gedanken spiele (nur weiss ich noch nicht ob Inkplate oder Waveshare .. aber das Inkshare klingt gut und der Preis ist auch noch okay für das Paket.

Vielleicht wäre es Modulmässig doch besser, das in Submodule je Display umzubauen. So das die generelle Logik usw zentral im "Mastermodul" ist und die spezifischen Modulsachen dann jeweils im entsprechenden Submodul fürs Modell.
Das wäre auch für Erweiterungen usw ein sehr passender Weg. Die Frage ist nur, wie aufwendig ein Umbau / Anpassung initial wäre :)

Ansonsten lese ich erstmal mit. WO habt Ihr das denn bestellt, bei Crowssupply oder direkt in Kroatien bei https://e-radionica.com/hr/inkplate.html ?

Ronny

Direkt in Kroatien zu bestellen dürfte etwas günstiger sein. Die Transportkosten, je nach Transporteur, werden geringer sein, die Zollabfertigung und eventuelle Provisionszahlungen an Crowd Supply entfallen.
Dann wären wir schon 3, die Gemeinde wächst...  8)

Moin,

ich habe mir mal eins in Kroatien bestellt. Lese also noch interessierter mit :D

Ronny

Hi,

Ich würde gerne Temepraturen ohne Nachkommastellen ausgeben. wenn ich das Attribut temperature nehme, kommen die Werte mit einer Nachkommastelle. Den Device-Status habe ich bereits für andere zwecke verändert.
Wie bekomme ich das am besten hin?

auch ist es scheinbar nicht möglich, dummy's auszugeben weder mit dem dummynamen noch mit dummyname:state bekomme ich den Inhalt angezeigt.

Dann noch zu Icons.
Ich habe bei Fenstern das Icon so definiert:
devStateIcon Open:fts_door_right_open Closed:fts_door:10px-kreis-gelb

Leider bekomme ich mit iconreading#kueche_balkontuer:icon aber nur ein inverses icon (dunkler Hintergrund) von einem Haus.

Bisher gibt es keine Möglichkeit, die Readings bei der Übergabe an das Modul noch zu formatieren. Am Besten machst Du ein userreading, wandelst dort die Temperatur in einen Wert ohne Nachkommastellen um und verwendest dann dieses Userreading für die Darstellung.

Dummies sollten auf jeden Fall funktionieren, die sind ja auch nichts anderes als FHEM Devices. Bitte poste mal die Definition des ESPEInk devices und des dummy devices (mit list <device>), dann kann ich nachschauen, ob da im Modul noch was falsch ist. Genauso für das Icon.

Zitat von: eki am 21 September 2020, 08:31:25
Bisher gibt es keine Möglichkeit, die Readings bei der Übergabe an das Modul noch zu formatieren. Am Besten machst Du ein userreading, wandelst dort die Temperatur in einen Wert ohne Nachkommastellen um und verwendest dann dieses Userreading für die Darstellung.

Sicher? Ich würde meinen, mit einer Formatangabe geht das. Ich mache das bsp. mit den Temperaturen (man achte auf die geschweiften Klammern) so:
textreading#system_weather:fc0_Tn{% 2.f°C}#5#225#12#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0


Oder ist etwas anderes gemeint?

Du hast recht, natürlich geht das. Ich kenne mein eigenes Modul nicht mehr  :-[

Zitat von: m.zielinski am 20 September 2020, 16:07:46
Ich würde gerne Temepraturen ohne Nachkommastellen ausgeben.

Läuft



Icons
Ich habe das Problem weiter eingegrenzt mit einem
addicon#fts_window_1w#600#48#48
-> obwohl das svg unter openautomation liegt, wird das fhem-Haus-Icon zurückgeliefert



Dummy
Weder mit
textreading#d_time#410#432#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
noch mit
textreading#d_time:STATE#410#432#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

klappt es.

Internals:
  CFGFN      fhemmz.cfg
  FUUID      5c9521b8-f33f-4524-4e20-11aa57302b492f6d
  NAME       d_time
  NR         217
  STATE      07:33:02
  TYPE       dummy
Attributes:
  fp_lcars   410,708,0,

Zitat von: m.zielinski am 22 September 2020, 07:57:16
Icons
Ich habe das Problem weiter eingegrenzt mit einem
addicon#fts_window_1w#600#48#48
-> obwohl das svg unter openautomation liegt, wird das fhem-Haus-Icon zurückgeliefert

Nach einem installieren von Libsvg und restart bekomme ich nun statt des fhem-haus ein schwarzes Rechteck.  Mysteriös

Welchen Display Type verwendest Du denn?
Hast Du Fehlermeldungen im Logfile?

Internals:
   BOARDTYPE  ESP8266
   COLORMODE  monochrome
   CONVERTMODE dithering
   DEF        /opt/fhem/www/images/800x480.png
   DEVICETYPE 7.5inch_e-Paper_HAT_V2
   FUUID      5f65a0ba-f33f-4524-c8ba-d35ff3a12726a55b
   INTERVAL   120
   NAME       epaper
   NOTIFYDEV  kueche_balkontuer,bad_fenster,netatmo_M02_00_00_03_9c_4c,netatmo_M03_00_00_09_1c_ba,netatmo_M03_00_00_08_d9_a4,wohn_aussen_temp,global,kiana_fenster,Feinstaub,bad_temperatur,netatmo_M03_00_00_08_db_d2,d_time,epaper,schlaf_fenster,wohn_fenster,netatmo_D70_ee_50_03_80_88
   NR         1334
   NTFY_ORDER 50-epaper
   PICTUREFILE /opt/fhem/www/images/800x480.png
   STATE      Successfully uploaded image to device
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        192.168.1.189
   Helper:
     DBLOG:
       result_picture:
         logdb:
           TIME       1600756812.16413
           VALUE      <html><img src=/fhem/images/epaper/result.png?dummy=633048.348425838></img><div>/fhem/images/epaper/result.png</div></html>
       state:
         logdb:
           TIME       1600755985.13761
           VALUE      convert
   READINGS:
     2020-09-22 08:17:38   deftexts        0
     2020-09-22 08:40:12   result_picture  <html><img src=/fhem/images/epaper/result.png?dummy=633048.348425838></img><div>/fhem/images/epaper/result.png</div></html>
     2020-09-22 08:17:34   source_picture  <html><img src=/fhem/images/epaper/800x480.png?dummy=712164.636852094></img><div>/fhem/images/epaper/800x480.png</div></html>
   helper:
Attributes:
   convertmode dithering
   definition addtext#Küche##0#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#netatmo_M03_00_00_09_1c_ba:co2#250#0#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#netatmo_M03_00_00_09_1c_ba:temperature{%2.f°}#410#0#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#kueche_balkontuer:state#600#0#48#0#0#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#Bad##48#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#bad_temperatur:temperature{%2.f°}#410#48#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#bad_fenster:state#600#48#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
addicon#fts_window_1w#580#48#48

addtext#Schlaf##96#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#netatmo_M03_00_00_08_d9_a4:co2#250#96#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#netatmo_M03_00_00_08_d9_a4:temperature{%2.f°}#410#96#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#schlaf_fenster:state#600#96#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#Wohn##144#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#netatmo_D70_ee_50_03_80_88:co2#250#144#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#netatmo_D70_ee_50_03_80_88:temperature{%2.f°}#410#144#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#wohn_fenster:state#600#144#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#Kind##192#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#netatmo_M03_00_00_08_db_d2:co2#250#192#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#netatmo_M03_00_00_08_db_d2:temperature{%2.f°}#410#192#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#kiana_fenster:state#600#192#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#.##240#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf

addtext#Straße##288#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#wohn_aussen_temp:temperature{%2.f°}#410#288#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#wohn_aussen_temp:humidity{%2.f%}#530#288#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#Balkon##336#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#netatmo_M02_00_00_03_9c_4c:temperature{%2.f°}#410#336#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#netatmo_M02_00_00_03_9c_4c:humidity{%2.f%}#530#336#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

addtext#Feinstaub##384#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf
textreading#Feinstaub:PM2.5#410#384#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

textreading#d_time#410#432#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

   devicetype 7.5inch_e-Paper_HAT_V2
   interval   120
   room       Alarm
   url        192.168.1.189

Ich habe das jetzt mal bei mir genauso nachgestellt, und da sehe ich sowohl das STATE reading des Dummies als auch das Icon.

Steht irgendwas komisches im Logfile?

Ich habe die definition nochmal gekürzt
addicon#fts_window_1w#580#0#48
textreading#d_time#10#0#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf
textreading#d_time:STATE#120#0#48#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf

auch einzeln diese Zeilen bringen nicht die gewünschten Ergebnisse. Ich bekomme immer nur einen schwarzen Block statt des icon und vom Dummy wird nichts ausgegeben

Manchmal bei verbose 5 habe ich diese Meldung gesehen: 2020.09.23 14:40:10 1: Timeout for ESPEInk_DoConvert reached, terminated process 20583
Ohne Verbose 5 wird die Grafik nach ca 4 Sekunden aktualisiert im WebFrontend und es steht ""Conversion done" da.

Ich hänge nochmal meine leere Grafik an sowie eine Result-Grafik.


Das verbose 5 Logfile wäre etwas sehr lang - auch wenn es nur kurz läuft.

PNG-Icons scheinen zu funktionieren aber wegen monochrome sehen die nicht so richtig aus.

# $Id: 89_ESPEInk.pm 21519 2020-03-26 06:41:38Z eki $

ch habe mal wieder eine neue Version gemacht. Folgendes ist neu:

• 
  Ich habe die hier (https://forum.fhem.de/index.php/topic,104171.msg1050446.html#msg1050446 (https://forum.fhem.de/index.php/topic,104171.msg1050446.html#msg1050446)) gemachten Vorschläge eingebaut (hatte ich völlig vergessen, sorry @viegener).
  
• 
  Es gibt ein neues EInk Display (7.5inch_e-Paper_HAT_(B)_HD) von Waveshare, das wird jetzt unterstützt.
  


• 
  Es gibt jetzt den zusätzlichen Befehl addsymbol. Damit lassen sich Symbole (Linien, Rechtecke, Ellipsen, Bögen) zum Bild hinzufügen. Details sind in der Modulhilfe zu finden.
  

Wäre schön, wenn der Ein oder Andere mal testen könnte. Wenn ich in den nächsten paar Tagen nichts Negatives höre, würde ich die Version dann offiziell freigeben.

@m.zielinski: Habe leider noch keine Idee woran die Probleme bei Dir liegen. Was die Icons betrifft, könnte ich mir allenfalls eine falsch installierte SVGLib vorstellen. Hast Du die Icons im Standarddirectory der FHEM Installation liegen?

Zitat von: eki am 02 November 2020, 08:40:14
@m.zielinski: Habe leider noch keine Idee woran die Probleme bei Dir liegen. Was die Icons betrifft, könnte ich mir allenfalls eine falsch installierte SVGLib vorstellen. Hast Du die Icons im Standarddirectory der FHEM Installation liegen?

SVG habe ich so installiert:
sudo apt-get install librsvg2-dev
sudo apt-get install libimage-librsvg-perl


Die Icons liegen unter /opt/fhem/www/images/openautomation
Wenn ich die Endung svg Weglassse, kommt ein schwarzes kästchen, mache ich .svgf dahinter, wird gar nichts ausgegeben.

Würde LibSVG auch das nicht angezeigte Uhrzeit-Dummy erklären?

zu den Icons: Wenn da ein schwarzes Rechteck kommt, dann deutet das darauf hin, dass SVG zwar installiert ist und dass das entsprechende File auch gefunden wird, dass aber beim Einfügen in das Bild etwas nicht richtig klappt.  Wenn das FHEM Haus angezeigt wird, dann liegt es daran, dass das angegebene Icon nicht gefunden wird. Hast Du im Device "global" das attribut "modpath" gesetzt, wie heißt Dein FHEMWEB Device und ist dort das Attibut "iconPath" gesetzt? Welche GD Library verendest Du?

Zum Dummy: Kannst Du mal von dem Device ein Listing schicken.

global modpath steht auf "."
iconPath ist in keinem meiner FHEMWEB-Devices gesetzt

Wie finde ich den stand der GD Library heraus ?
Installiert habe ich:
sudo apt-get install php-gd
sudo apt-get install libgd-perl


Dummy hatte ich bereits geschickt: https://forum.fhem.de/index.php/topic,104171.msg1086804.html#msg1086804

Zitat von: eki am 02 November 2020, 08:40:14
ch habe mal wieder eine neue Version gemacht. Folgendes ist neu:

• 
  Ich habe die hier (https://forum.fhem.de/index.php/topic,104171.msg1050446.html#msg1050446 (https://forum.fhem.de/index.php/topic,104171.msg1050446.html#msg1050446)) gemachten Vorschläge eingebaut (hatte ich völlig vergessen, sorry @viegener).
  
• 
  Es gibt ein neues EInk Display (7.5inch_e-Paper_HAT_(B)_HD) von Waveshare, das wird jetzt unterstützt.
  


• 
  Es gibt jetzt den zusätzlichen Befehl addsymbol. Damit lassen sich Symbole (Linien, Rechtecke, Ellipsen, Bögen) zum Bild hinzufügen. Details sind in der Modulhilfe zu finden.
  

Wäre schön, wenn der Ein oder Andere mal testen könnte. Wenn ich in den nächsten paar Tagen nichts Negatives höre, würde ich die Version dann offiziell freigeben.

@m.zielinski: Habe leider noch keine Idee woran die Probleme bei Dir liegen. Was die Icons betrifft, könnte ich mir allenfalls eine falsch installierte SVGLib vorstellen. Hast Du die Icons im Standarddirectory der FHEM Installation liegen?

Ich habe mal einen ersten Test gemacht, bin aber auf einige perl-Warnungen gestossen:

2020.11.02 22:52:30.231 1: PERL WARNING: Use of uninitialized value $type in string ne at ./FHEM/89_ESPEInk.pm line 1249.
2020.11.02 22:52:34.207 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/89_ESPEInk.pm line 1993.
2020.11.02 22:52:34.256 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/89_ESPEInk.pm line 2004.


Brauchst Du mehr Infos?

Nachtrag: Ich habe mal etwas debugged, es entsteht durch Leerzeilen in der Definition

Das sind ja erst mal nur Warnungen (ich denke ich habe den "Fehler" gefunden, wollte sowas jetzt aber erst mal sammeln, bevor ich eine neue Version mache). Funktioniert denn das Modul grundsätzlich?

Zitat von: eki am 03 November 2020, 09:33:58
Das sind ja erst mal nur Warnungen (ich denke ich habe den "Fehler" gefunden, wollte sowas jetzt aber erst mal sammeln, bevor ich eine neue Version mache). Funktioniert denn das Modul grundsätzlich?

Aber klar - Sorry wenn ich das nicht gesagt hatte
Durch entfernen der Leerzeilen kann ich momentan auch die Warnungen zumindest reduzieren

Zu dem Problem mit dem nicht angezeigten Zeit-Dummy.
Ich habe das dumme gefüllt mit setstate - dadurch wird die Zeit bei den Internals unter State eingetragen. -> keine Augabe auf epaper
Wenn ich das dummy mit set fülle, wird der wert in das reading "state" geschrieben (nicht unter Internals!) und die Ausgabe kommt wie erwartet.

Kannst Du mal ein List Deines dummies jeweils mit den beiden Varianten posten (geht/geht nicht).

Funktioniert :
Internals:
   CFGFN      fhemmz.cfg
   FUUID      5c9521b8-f33f-4524-4e20-11aa57302b492f6d
   NAME       d_time
   NR         217
   STATE      06:53
   TYPE       dummy
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1610430821.36789
           VALUE      06:53
   READINGS:
     2021-01-12 06:53:41   state           06:53
Attributes:
   fp_lcars   410,708,0,



Funktioniert nicht :

Internals:
  CFGFN      fhemmz.cfg
  FUUID      5c9521b8-f33f-4524-4e20-11aa57302b492f6d
  NAME       d_time
  NR         217
  STATE      07:33:02
  TYPE       dummy
Attributes:
  fp_lcars   410,708,0,

Zitat von: m.zielinski am 11 Januar 2021, 11:46:33
Zu dem Problem mit dem nicht angezeigten Zeit-Dummy.
Ich habe das dumme gefüllt mit setstate - dadurch wird die Zeit bei den Internals unter State eingetragen. -> keine Augabe auf epaper
Wenn ich das dummy mit set fülle, wird der wert in das reading "state" geschrieben (nicht unter Internals!) und die Ausgabe kommt wie erwartet.

Soweit ich die Syntax kenne werden dort Readings verarbeitet (und nicht Internals) also hast Du Dir die Erklärung doch selber gegeben gerade?
In dem nicht funktionierenden Dummy ist kein Reading state vorhanden - damit gibt es dafür keinen Wert - Internals sind etwas komplett anderes und eher intern im Modul gedacht.


PS: Bitte trage doch Lists / logs / etc in Code tags ein - damit das besser lesbar wird

Hallo Zusammen,

ich möchte ein 7,5" ePaper als Status Panel installieren und habe dafür den Threat ausgiebig studiert. Nach etwas ausprobieren habe ich alles hinbekommen was ich anzeigen möchte. Sehr schönes Modul  :) Danke eki

Nun möchte ich mir die entsprechende Hardware bestellen und würde gerne eure Meinung hören.

1.) ESP32 oder ESP8266?
Bringt die bessere Leistung des ESP32 in dieser Anwendung was oder reicht ein ESP8266. Dabei geht es mir nicht um die 3 EUR die der 32er mehr kostet, sondern vielmehr um den Stromverbrauch. Bluetooth benötige auch nicht.

2.) Welches ePaper?
Ich würde gerne schwarz, weis und rot darstellen, bin aber unsicher ob ich das waveshare mit 800x480 oder das HD oder das V2 Panel nehmen soll. Die Preisunterschiede sind nicht ja so groß? Hat jemand Erfahrung?

Was bedeutet Refreshrate von 16s oder gar 21s? Es dauert doch nicht 21 sec bis das Display neu aufgebaut ist, oder?

Vielen Dank für Eure Hinweise.

Zitat von: Borkk am 12 April 2021, 18:56:57
1.) ESP32 oder ESP8266?
Bringt die bessere Leistung des ESP32 in dieser Anwendung was oder reicht ein ESP8266. Dabei geht es mir nicht um die 3 EUR die der 32er mehr kostet, sondern vielmehr um den Stromverbrauch. Bluetooth benötige auch nicht.

Der ESP hat kaum etwas zu tun, da genügt der ESP8266. Falls du die Original-Firmware einsetzt, so gibt es dort keine Stromsparmechanismen, der läuft ständig. Falls es dir nicht auf die Minute darauf ankommt, könntest du ein geänderte Firmware einsetzen, die MQTT unterstützt. Damit kann der ESP die meiste Zeit schlafen. Nach dem Aufwachen fragt er kurz an, ob neue Daten vorhanden sind und diese sich dann zuschicken lassen. So habe ich es bei mir gelöst.

Zitat
2.) Welches ePaper?
Ich würde gerne schwarz, weis und rot darstellen, bin aber unsicher ob ich das waveshare mit 800x480 oder das HD oder das V2 Panel nehmen soll. Die Preisunterschiede sind nicht ja so groß? Hat jemand Erfahrung?

Was bedeutet Refreshrate von 16s oder gar 21s? Es dauert doch nicht 21 sec bis das Display neu aufgebaut ist, oder?

Ich habe das ältere 7,5" Display, mir genügt die Auflösung um den Status aller Fenster, Temperaturen, Abfallabholtermine und versch. Status anzuzeigen. Und ja, die Refreshrate ist tatsächlich die Zeit, die bis zur Darstellung des Bildes vergeht. Das dauert bei den großen recht lange - da gewöhnt man sich dran (wenn man es nicht anders kennt) ;)

VG

Hallo Jendaw,

Danke für deine Antwort.
Ich habe mir mal das Waveshare 17059 7.5 HD in sw/ws/rt, ein kleines Waveshare 13339 2.9  und je ein ESP32 und ein ESP8266 bestellt. Bin mal gespannt wie das alles so funktioniert. Das Modul ESPEInk Modul läuft jedenfalls schon mal und generiert das png file. Hab übrigens bei Welectron bestellt, dort waren die Komponenten deutlich günstiger als bei Amazon.

Ich bin in das ESP Thema erst vor kurzem eingestiegen und habe ein 0,96 OLED Display mit ESPEasy angeschaltet. Das ging überraschend einfach. Nach 2 sehr schönen Projekten von jjRobots (iBoardBot und Spher-O-Bot) bin ich jetzt auf den Geschmack gekommen. ;)

Zitat von: Jendaw am 16 April 2021, 18:40:37
Der ESP hat kaum etwas zu tun, da genügt der ESP8266. Falls du die Original-Firmware einsetzt, so gibt es dort keine Stromsparmechanismen, der läuft ständig.

Ich habe ein 7.5v2 seit ein 7 Monaten laufen. Jetzt ist das Schwarz nur noch ein Grau und der Support von Waveshare sagt, dass der Dauerstrom (seiner eigenen Software) dazu geführt hat.
Hat noch jemand dieses Problem?

Ich lasse das Display 24*7 an Strom hinter dem esp8266 und aktualisiere alle 5 Minuten.

Hat noch jemand dieses Problem?

Denn wenn die Firmware von Waveshare den Strom dauerhaft an lässt und das Display dadurch beschädigt wird, kann man dieses Modul doch nicht länger nutzen?

Zitat von: m.zielinski am 24 Mai 2021, 12:36:53
Ich habe ein 7.5v2 seit ein 7 Monaten laufen. Jetzt ist das Schwarz nur noch ein Grau und der Support von Waveshare sagt, dass der Dauerstrom (seiner eigenen Software) dazu geführt hat.
Hat noch jemand dieses Problem?

Ich lasse das Display 24*7 an Strom hinter dem esp8266 und aktualisiere alle 5 Minuten.

Hat noch jemand dieses Problem?

Denn wenn die Firmware von Waveshare den Strom dauerhaft an lässt und das Display dadurch beschädigt wird, kann man dieses Modul doch nicht länger nutzen?

Mein 7.5'er läuft seit fast 1,5a, das Schwarz sieht noch schwarz aus. Ich nutze eine leicht geänderte Firmware, die eine konfigurierbare Sleeptime hat (bei mir sind es ~60s). Zusätzlich lasse ich via MQTT anfragen, ob neue Daten in FHEM vorliegen und lasse diese dann abholen. Damit wird das Displays nicht aktualisiert, wenn keine neuen Daten anliegen und der Verschleiß macht sich bisher nicht so bemerkbar.

Zitat von: Jendaw am 24 Mai 2021, 13:41:28
Mein 7.5'er läuft seit fast 1,5a, das Schwarz sieht noch schwarz aus. Ich nutze eine leicht geänderte Firmware, die eine konfigurierbare Sleeptime hat (

Dann werde ich auch auf diese Firmware umsteigen. Wichtig war mir, andere zu warnen, dass es dabei nicht nur um den Stromverbrauch sondern auch um die Haltbarkeit des Display geht.
Denn auch im Waveshare Wiki wird ausdrücklich vor dauerstrom gewarnt wegen Fading und sonstigen Schäden.

Ich lese schon länger mit und habe mir nun auch ein 7,5" HD und ein EPS8266 eingerichtet. Ich verwende den Sketch aus dem git (https://github.com/Yattien). Mit dem aktuellen ESP8266er Boardpackage lässt sich der Sketch nicht kompilieren. Ich habe deshalb die Version 2.7.4 installiert. Ohne mqtt und ohne sleep läuft mein ESP zusammen mit FHEM.

Wenn ich sleep einstelle, dann wacht der ESP nicht mehr auf. Die rote LED leuchtet.

14:41:17.746 ->  Using configuration:
14:41:17.746 ->   MQTT Server: :1883, Client: ESPEInk_8caab56cee2d
14:41:17.746 ->   MQTT UpdateStatusTopic: stat/display/needUpdate
14:41:17.746 ->   MQTT CommandTopic: cmd/display/upload
14:41:17.746 ->   sleep time: 120
14:41:17.746 ->   firmware base URL:
14:41:17.746 -> Setup complete.
14:41:17.746 -> Webserver started, waiting 10s for data
14:41:27.766 ->
14:41:27.766 -> Going to sleep for 120 seconds.
14:41:27.766 ->
14:43:24.322 -> rl
Der ESP wird mit 3,3V direkt versorgt, deshalb schließe ich die Stromversorgung aus.

Wenn ich mqtt einstelle, verbindet sich der ESP mit Mosquitto und wirft sofort eine Exception. Laut Logfile ist keine Verbindung erkannt worden.

17:03:12.518 ->
17:03:12.518 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
17:03:12.518 ->
17:03:12.518 -> load 0x4010f000, len 3584, room 16
17:03:12.518 -> tail 0
17:03:12.518 -> chksum 0xb0
17:03:12.518 -> csum 0xb0
17:03:12.518 -> v2843a5ac
17:03:12.518 -> ~ld
17:03:12.585 ->
17:03:12.585 -> ESPEInk_ESP8266 v18, reset reason='Software/System restart'...
17:03:12.585 -> Entering setup...
17:03:12.651 ->  Reading config file...
17:03:12.651 ->  Config file read.
17:03:12.651 ->  Connecting to WiFi...
17:03:14.641 ->  Connected to WiFi.
17:03:14.641 ->  Using configuration:
17:03:14.641 ->   MQTT Server: 192.168.2.7:1883, Client: ESPEInk_8caab56cee2d
17:03:14.641 ->   MQTT UpdateStatusTopic: stat/display/needUpdate
17:03:14.641 ->   MQTT CommandTopic: cmd/display/upload
17:03:14.641 ->   sleep time: 0
17:03:14.641 ->   firmware base URL:
17:03:14.641 -> Setup complete.
17:03:14.641 -> Connecting to MQTT...
17:03:14.641 ->
17:03:14.641 -> User exception (panic/abort/assert)
17:03:14.641 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
17:03:14.641 ->
17:03:14.641 -> Abort called
17:03:14.641 ->
17:03:14.641 -> >>>stack>>>
17:03:14.641 ->
17:03:14.641 -> ctx: cont
17:03:14.641 -> sp: 3ffffe00 end: 3fffffc0 offset: 0000
17:03:14.675 -> 3ffffe00:  3fff4688 00000000 00000000 3fff4688 
17:03:14.675 -> 3ffffe10:  000000fe 00000000 00000000 00000000 
17:03:14.675 -> 3ffffe20:  00000000 00000000 00000000 3fff47a0 
17:03:14.675 -> 3ffffe30:  00000000 00000000 401002be 00000000 
17:03:14.675 -> 3ffffe40:  3fff39d0 3fff81dc 00004145 402199c2 
17:03:14.675 -> 3ffffe50:  3fff39d0 3fff81dc 00000020 402199d4 
17:03:14.675 -> 3ffffe60:  007a1200 865bb1d3 00004145 4022be6d 
17:03:14.675 -> 3ffffe70:  00000000 00000000 3fff3dcc 4022be08 
17:03:14.675 -> 3ffffe80:  3fff33d0 3fff3dcc 3fff3dcc 40211922 
17:03:14.708 -> 3ffffe90:  0000000e 3fff4218 00000001 40219458 
17:03:14.708 -> 3ffffea0:  00000000 00000000 00000000 40219aba 
17:03:14.708 -> 3ffffeb0:  00000000 3fff3dcc 3fff7bdc 402105a8 
17:03:14.708 -> 3ffffec0:  3fff3fc8 00000d50 3fffff00 3fff3b84 
17:03:14.708 -> 3ffffed0:  0000075b 3fff3dcc 3fff39d0 3fff3b84 
17:03:14.708 -> 3ffffee0:  0000075b 3fff3dcc 3fff39d0 40211b85 
17:03:14.708 -> 3ffffef0:  40223880 0702a8c0 40223880 0702a8c0 
17:03:14.741 -> 3fffff00:  3fff3a04 3fff3d80 00000000 40215950 
17:03:14.741 -> 3fffff10:  40216b68 3fff4078 3ffece76 40216b74 
17:03:14.741 -> 3fffff20:  3fff3a84 00000000 00000000 00000000 
17:03:14.741 -> 3fffff30:  3fff4078 3fff3d80 3fff3dcc 40210d12 
17:03:14.741 -> 3fffff40:  3fff4078 00000000 3fff3d80 3fff3d65 
17:03:14.741 -> 3fffff50:  3fff4078 3fff3d80 00000000 40203b88 
17:03:14.741 -> 3fffff60:  00000000 00000000 00000000 40222dac 
17:03:14.741 -> 3fffff70:  3fff3d80 00000000 3fff3d64 40207ead 
17:03:14.774 -> 3fffff80:  feefeffe 80efeffe 3fff6d00 0017001f 
17:03:14.774 -> 3fffff90:  80efeffe feefeffe feefeffe 3fff41b8 
17:03:14.774 -> 3fffffa0:  3fffdad0 00000000 3fff4178 40219570 
17:03:14.774 -> 3fffffb0:  feefeffe feefeffe 3ffe8b2c 40100d39 
17:03:14.774 -> <<<stack<<<
17:03:14.774 ->
17:03:14.774 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------

Die mqtt-Kommunikation funktioniert, wenn ich den ESP-Part manuell übernehme. Soll heißen, ich bekomme "stat/display/needUpdate true" und antworte mit cmd/display/upload. Dann startet der Upload.

Beim Kompilieren des Sketches sehe ich keine Fehler. Hat jemand eine Idee, was da schief gelaufen sein könnte?


Beim FHEM-Modul bin ich auch auf einen Fehler gestoßen. Ich nutze AddSymbol um ein rotes Rechteck zu erzeugen. Der Code erwartet offenbar Parameter für solide oder gestrichelte Linien usw. in $s1 und $s2. Die beiden Variablen sind aber nicht initialisiert. Das führt zu
2021.06.08 14:13:46 1: PERL WARNING: Use of uninitialized value $s2 in string eq at ./FHEM/89_ESPEInk.pm line 1402.
2021.06.08 14:13:46 1: PERL WARNING: Use of uninitialized value $s1 in string eq at ./FHEM/89_ESPEInk.pm line 1403.
2021.06.08 14:13:46 1: PERL WARNING: Use of uninitialized value $s2 in string eq at ./FHEM/89_ESPEInk.pm line 1403.
2021.06.08 14:13:46 1: PERL WARNING: Use of uninitialized value $s1 in string eq at ./FHEM/89_ESPEInk.pm line 1404.
Das Rechteck wird aber trotzdem erzeugt.

Für das Modul möchte ich noch vorschlagen timeout für ESPEInk_Convert nit einem Attribut festzulegen.

Zum Problem mit dem deepsleep und der roten LED - hast du die kabelbrücke wie im Sourcecode beschrieben gesetzt?

Zitat von: hajo23 am 09 Juni 2021, 17:21:35
Ich lese schon länger mit und habe mir nun auch ein 7,5" HD und ein EPS8266 eingerichtet. Ich verwende den Sketch aus dem git (https://github.com/Yattien). Mit dem aktuellen ESP8266er Boardpackage lässt sich der Sketch nicht kompilieren. Ich habe deshalb die Version 2.7.4 installiert. Ohne mqtt und ohne sleep läuft mein ESP zusammen mit FHEM.

Das werde ich mir die Tage noch mal ansehen. Ich habe mir auch ein zweites 7.5" besorgt und werde meine Buildumgebung aktualisieren.
Welche Version kompilierst du, den Head (neueste Version) oder einen Tag? Welches ESP8266-Board nutzt du, das Originale von waveshare?

edit: Du nutzt den Head, konnte es nachstellen. In der Version 3.0.0 des Boardpkg gibt es einige Änderungen, u.a. sind auch APIs verschwunden. Das betrifft aktuell:
* die OTA-Update-Funktion, Fix ist im git
* die Überprüfung der TLS-Verbindung zum MQTT-Server, könnte man auskommentieren, bis ich eine Lösung gefunden habe: L428-436

diff --git a/ESPEInk_ESP8266.ino b/ESPEInk_ESP8266.ino
index 647bb57..da674f7 100644
--- a/ESPEInk_ESP8266.ino
+++ b/ESPEInk_ESP8266.ino
@@ -425,16 +425,6 @@ void reconnect() {

// -----------------------------------------------------------------------------------------------------
void verifyFingerprint() {
-       if (ctx.mqttFingerprint && strlen(ctx.mqttFingerprint) > 0) {
-               if(!espClient.verify(ctx.mqttFingerprint, ctx.mqttServer)) {
-                       Serial.printf("MQTT fingerprint '%s' does not match, rebooting...\r\n", ctx.mqttFingerprint);
-                       Serial.flush();
-                       delay(200);
-                       ESP.restart();
-               } else {
-                       Serial.println("MQTT fingerprint does match");
-               }
-       }
}

// -----------------------------------------------------------------------------------------------------

Damit lässt es sich mit den aktuellen Versionen wieder übersetzen.


VG

Zitat von: m.zielinski am 09 Juni 2021, 20:31:49
Zum Problem mit dem deepsleep und der roten LED - hast du die kabelbrücke wie im Sourcecode beschrieben gesetzt?

Du meinst das hier?

if the ESP does not wakeup from deepsleep a 220 resistor between SD0(MISO) and 3.3v might help

Oh je, danke für die Erinnerung. Ich war mir mit der Interpretation der Beschaltung (PIN-Belegung/Darstellung im Code) nicht ganz sicher, hatte das zurückgestellt und dann glatt vergessen.  Ich habe das originale Waveshare ESP verwendet.

Laut Plan im Code soll GPIO 16 (D0) mit RST gebrückt werden. An anderer Stelle wird auch zu einer Beschaltung von GPIO 16 und RST über R470 und ein RC-Glied (12K/100nf-1µF) geraten. Lt. Waveshare ist MISO/SD0 = PIN 10 beim ESP 12-E, ich habe aber einen 12-F bekommen. Ist das Layout beim 12-E und 12-F gleich? Ich nehme an, dass es gleich ist. Hast Du MISO über R220 an 3V3 geschaltet und hast Du D0 und Reset "nur" gebrückt?

Zitat von: Jendaw am 09 Juni 2021, 22:09:30
Das werde ich mir die Tage noch mal ansehen. Ich habe mir auch ein zweites 7.5" besorgt und werde meine Buildumgebung aktualisieren.
Welche Version kompilierst du, den Head (neueste Version) oder einen Tag? Welches ESP8266-Board nutzt du, das Originale von waveshare?

edit: Du nutzt den Head, konnte es nachstellen. In der Version 3.0.0 des Boardpkg gibt es einige Änderungen, u.a. sind auch APIs verschwunden. Das betrifft aktuell:
* die OTA-Update-Funktion, Fix ist im git
* die Überprüfung der TLS-Verbindung zum MQTT-Server, könnte man auskommentieren, bis ich eine Lösung gefunden habe: L428-436

Code Auswählen Erweitern


diff --git a/ESPEInk_ESP8266.ino b/ESPEInk_ESP8266.ino
index 647bb57..da674f7 100644
--- a/ESPEInk_ESP8266.ino
+++ b/ESPEInk_ESP8266.ino
@@ -425,16 +425,6 @@ void reconnect() {

// -----------------------------------------------------------------------------------------------------
void verifyFingerprint() {
-       if (ctx.mqttFingerprint && strlen(ctx.mqttFingerprint) > 0) {
-               if(!espClient.verify(ctx.mqttFingerprint, ctx.mqttServer)) {
-                       Serial.printf("MQTT fingerprint '%s' does not match, rebooting...\r\n", ctx.mqttFingerprint);
-                       Serial.flush();
-                       delay(200);
-                       ESP.restart();
-               } else {
-                       Serial.println("MQTT fingerprint does match");
-               }
-       }
}

// -----------------------------------------------------------------------------------------------------

Damit lässt es sich mit den aktuellen Versionen wieder übersetzen.


VG

Wow, das ging echt schnell. Sobald ich die Beschaltung geklärt habe, teste ich. Vielen Dank!

VG

Zitat von: hajo23 am 10 Juni 2021, 00:03:13
Du meinst das hier?

Code Auswählen Erweitern

if the ESP does not wakeup from deepsleep a 220 resistor between SD0(MISO) and 3.3v might help

[...]

Laut Plan im Code soll GPIO 16 (D0) mit RST gebrückt werden. An anderer Stelle wird auch zu einer Beschaltung von GPIO 16 und RST über R470 und ein RC-Glied (12K/100nf-1µF) geraten. Lt. Waveshare ist MISO/SD0 = PIN 10 beim ESP 12-E, ich habe aber einen 12-F bekommen. Ist das Layout beim 12-E und 12-F gleich? Ich nehme an, dass es gleich ist. Hast Du MISO über R220 an 3V3 geschaltet und hast Du D0 und Reset "nur" gebrückt?

Gemeint ist die Brücke zwischen GPIO16/D0 und RST.
Der ESP12-F ist der Nachfolger vom 12-E und hat nur eine geänderte Antenne. Der Rest ist gleich.

VG

Zitat von: Jendaw am 10 Juni 2021, 07:47:13
Gemeint ist die Brücke zwischen GPIO16/D0 und RST.
Der ESP12-F ist der Nachfolger vom 12-E und hat nur eine geänderte Antenne. Der Rest ist gleich.

VG

Beim Herumspielen mit dem Pullup habe ich festgestellt, dass meine Kabelbrücke einen Wackel hat. Andere Kabelbrücke und schon läuft es mit dem Deepsleep.  :)

Ich habe den Verify-Teil auskommentiert, aber der Compiler beschwert sich noch:
Arduino: 1.8.15 (Linux), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for IRAM/PROGMEM, 4MB (FS:2MB OTA:~1019KB), 2, v2 Lower Memory, Disabled, None, Sketch + WiFi Settings, 115200"











In function 'void getUpdate()',
    inlined from 'void getUpdate()' at /home/adm1h/Arduino/ESPEInk_ESP8266/ESPEInk_ESP8266.ino:211:6:
ESPEInk_ESP8266:224:18: error: call to 'HTTPClient::begin' declared with attribute error: obsolete API, use ::begin(WiFiClient, url)
  224 |  httpClient.begin(firmwareVersionUrl);
      |  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
exit status 1
call to 'HTTPClient::begin' declared with attribute error: obsolete API, use ::begin(WiFiClient, url)

Zitat von: hajo23 am 10 Juni 2021, 10:54:30
Ich habe den Verify-Teil auskommentiert, aber der Compiler beschwert sich noch:

Code Auswählen Erweitern

Arduino: 1.8.15 (Linux), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for IRAM/PROGMEM, 4MB (FS:2MB OTA:~1019KB), 2, v2 Lower Memory, Disabled, None, Sketch + WiFi Settings, 115200"

In function 'void getUpdate()',
    inlined from 'void getUpdate()' at /home/adm1h/Arduino/ESPEInk_ESP8266/ESPEInk_ESP8266.ino:211:6:
ESPEInk_ESP8266:224:18: error: call to 'HTTPClient::begin' declared with attribute error: obsolete API, use ::begin(WiFiClient, url)
  224 |  httpClient.begin(firmwareVersionUrl);
      |  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
exit status 1
call to 'HTTPClient::begin' declared with attribute error: obsolete API, use ::begin(WiFiClient, url)

Sorry, hatte vergessen, die letzte Änderung auch zu pushen. Ist jetzt im Git, mach mal bitte noch mal ein "git pull" oder lade den aktuellen Stand herunter.
(Zeile 224 muss "httpClient.begin(espClient, firmwareVersionUrl);" lauten.)

Zitat von: Jendaw am 10 Juni 2021, 10:58:28
Sorry, hatte vergessen, die letzte Änderung auch zu pushen. Ist jetzt im Git, mach mal bitte noch mal ein "git pull" oder lade den aktuellen Stand herunter.
(Zeile 224 muss "httpClient.begin(espClient, firmwareVersionUrl);" lauten.)

Das läuft.

Nun habe ich (nur) das mqtt Problem. Mit dem aktuellen Sketch steht jetzt im Log:

1623320567: New connection from 192.168.2.171 on port 1883.
1623320568: Socket error on client <unknown>, disconnecting.


Die IP-Adresse ist vom ESP. Muss ich beim mqtt-Server noch etwas konfigurieren?

Zitat von: hajo23 am 10 Juni 2021, 12:37:16
Das läuft.

Nun habe ich (nur) das mqtt Problem. Mit dem aktuellen Sketch steht jetzt im Log:

Code Auswählen Erweitern


1623320567: New connection from 192.168.2.171 on port 1883.
1623320568: Socket error on client <unknown>, disconnecting.


Die IP-Adresse ist vom ESP. Muss ich beim mqtt-Server noch etwas konfigurieren?

Am Server muss nichts mehr konfiguriert werden. Ich schätze, dass beim connect() ein Fehler steckt, muss ich mir näher anschauen und melde mich dazu noch mal. Bis dahin könntest du die letzte stable nutzen - das v17-Binary (https://github.com/Yattien/ESPEInk_ESP8266/releases/tag/v17) oder das v17-Tag (https://github.com/Yattien/ESPEInk_ESP8266/tree/v17) kompilieren (mit altem Boardpackage). Da lief, MQTT noch.

Besten Dank an Euch für die Unterstützung. Mit der V17 läuft es jetzt.  :)

Zitat von: hajo23 am 10 Juni 2021, 13:16:22
Besten Dank an Euch für die Unterstützung. Mit der V17 läuft es jetzt.  :)

Danke für die Rückmeldung und deine Geduld :D Da weiß ich jetzt, wo ich suchen muss.

Hallo Zusammen,

ich habe mich mal an die Sache mit dem E-Paper Display gewagt. Mit Fhem kenne ich mich recht gut aus, aber mit den EPS8266 oder EPS32 Modulen habe ich noch keine große Erfahrung gesammelt. Ich bin jetzt an einem Punkt wo ich etwas Hilfe gebrauchen könnte.

Als Display habe ich ein Waveshare "7.5 Inch HD e-Paper (B)" als Board ein ESP32 oder ein ESP8266, beide auch von Waveshare.

Das Modul ESPEInk habe ich konfiguriert, es funktioniert einwandfrei. D.h. es wird ein PNG File mit Messwerten und Icons generiert.

Das ESP32 Board habe ich nach der Anleitung auf der Waveshare Seite konfiguriert. Es kommt ins WLAN und wenn ich es unter Spannung setze, sehe ich im Serial Monitor auf Arduino IDE, eine ganze Reihe "LOAD>>" Befehle gesendet werden und irgendwann mal ein "Show>>". Dann wird das PNG vom Modul auf auf das Display geladen und ordentlich angezeigt.

Das war es aber auch. Danach tut sich nichts mehr. Die Anzeige wird nicht mehr aktualisiert auch wenn sich das PNG im Modul ändert. Drücke ich den Reset Taster auf dem Board, wird das aktuelle Bild geladen. (Attr "Interval" steht auf 0)

Bevor ich hier Listings oder Protokolle poste wollte ich erst mal fragen ob ich einen Denkfehler habe.

Ich habe hier was von einer Brücke wegen "Deep Sleep" gelesen, von einer geänderten Firmware und einem für ESPInk angepassten Sketch. Vielleicht kann jemand meinen Knoten im Kopf lösen :-) und den besten Lösungsweg skizzieren.

Zitat von: Borkk am 08 August 2021, 12:13:00
Als Display habe ich ein Waveshare "7.5 Inch HD e-Paper (B)" als Board ein ESP32 oder ein ESP8266, beide auch von Waveshare.

Das Modul ESPEInk habe ich konfiguriert, es funktioniert einwandfrei. D.h. es wird ein PNG File mit Messwerten und Icons generiert.

Das ESP32 Board habe ich nach der Anleitung auf der Waveshare Seite konfiguriert. Es kommt ins WLAN und wenn ich es unter Spannung setze, sehe ich im Serial Monitor auf Arduino IDE, eine ganze Reihe "LOAD>>" Befehle gesendet werden und irgendwann mal ein "Show>>". Dann wird das PNG vom Modul auf auf das Display geladen und ordentlich angezeigt.

Das war es aber auch. Danach tut sich nichts mehr. Die Anzeige wird nicht mehr aktualisiert auch wenn sich das PNG im Modul ändert. Drücke ich den Reset Taster auf dem Board, wird das aktuelle Bild geladen. (Attr "Interval" steht auf 0)

Kannst du bitte überprüfen, ob du mehrere Bilder mit der "Price-Tag"-Webseite der Original-Firmware hochladen kannst? Dazu rufst du den ESP einfach per Browser auf und konfigurierst dort dein Display.
Falls das funktioniert - gibt es Auffälligkeiten im FHEM-Log?

ZitatIch habe hier was von einer Brücke wegen "Deep Sleep" gelesen, von einer geänderten Firmware und einem für ESPInk angepassten Sketch.

Einige haben einen Deepsleep in die Firmware eingebaut. Der ESP8266 wacht nicht aus dem DeepSleep auf, wenn ein Widerstand (470-1k) zwischen D0 und RST fehlt. Die Waveshare-Boards sollten diesen jedoch bereits onboad haben.
Grundsätzlich sollte aber erst einmal der Upload mit der Original-Firmware laufen, auch mehrmals hintereinander.

Hallo eki,

vielen Dank für das großartige Modul. Ich habe seit 3 Jahren ein 7,5" b/w/r Display in Betrieb. Damals habe ich per rss Feed und exterem Script das Bild-File generiert und dann vom ESP8266 periodisch abholen lassen. Also alles per Hand zusammen gebastelt. Mit Deinem Modul ist das schon eine geschmeidige Sache!

Ich hab hier noch folgendes Display rumliegen:

https://www.waveshare.com/pico-epaper-5.65.htm (https://www.waveshare.com/pico-epaper-5.65.htm)

Könntest Du dieses Display in einem Update einpflegen? Mit 7 Farben läßt sich hinsichtlich bestimmer (Betriebs) Zustände richtig viel darstellen. In jedem Fall vielen Dank für Deine Arbeit.

Das muss ich mir erst mal genauer anschauen, einerseits hat sich da bei Waveshare offensichtlich eine große Änderung bezüglich der Treiber ergeben und andererseits kann es sein, dass sich da auch für das Mehrfarbige Display einiges an Anpassung ergibt, kann also etwas dauern und ich möchte auch nicht zu viel versprechen, mal schauen.

Ich habe es mir noch mal angeschaut. Das basiert ja auf einem pi pico, wie machst Du denn da die Verbindung zu FHEM (hat ja kein WLAN oder so was).
Ich habe den Typ mal in das Modul eingebaut (Testversion angehängt), damit kann man aber erst mal nur Bilder (mit set convert) genrieren, die die entsprechenden Farben haben und eventuell per dithering Darstellung möglichst nah an die gewünschten Farben kommen (siehe Beispiel). Das mit der Übertragung zum Device ist mir, wie gesagt, unklar.

eki du bist wunderbar! Vielen Dank, ich werde die Anapssung soweit prüfen!

Ich Hammel habe Dir gestern den falschen Link gepostet. Hier ist der richtige. Das Display kommt genauso, wie die anderen. Entweder RAW oder mit dem Treiber gleich dabei. Dann, wie immer, eine SPI Schnittstelle. Ich lasse das Display mit einem Wemos testweise laufen. Im neuesten Loader von Waveshare ist dieser Displaytyp bereits enthalten.

Display mit Treiber: https://www.waveshare.com/product/displays/e-paper/epaper-1/5.65inch-e-paper-module-f.htm (https://www.waveshare.com/product/displays/e-paper/epaper-1/5.65inch-e-paper-module-f.htm)
Display RAW: https://www.waveshare.com/product/displays/e-paper/epaper-1/5.65inch-e-paper-f.htm (https://www.waveshare.com/product/displays/e-paper/epaper-1/5.65inch-e-paper-f.htm)

Aktuelle Loader Version für den ESP8266: https://www.waveshare.com/w/upload/d/d5/E-Paper_ESP8266_Driver_Board_Code.7z (https://www.waveshare.com/w/upload/d/d5/E-Paper_ESP8266_Driver_Board_Code.7z)

Übringens bzgl. DEEP SLEEP ESP8266:

Ich habe das bei meinem ersten E-Ink Display folgendermaßen gelöst:

Grundsätzlich benutze ich den Timer: https://www.ti.com/lit/ds/symlink/tpl5110.pdf?ts=1628458116847 (https://www.ti.com/lit/ds/symlink/tpl5110.pdf?ts=1628458116847)

Einer der Vorteile ist, dass der Timer von 1.8 bis 5.5V läuft und in Ruhe nur <40nA braucht.

Mit diesem Timer schalte ich über einen Mosfest die Stromversorgung für den LDO von einem ESP-12F. Wenn der ESP mit was auch immer fertig ist, gibt er ein Low über den GPIO4 auf den DONE Eingang des Timers. (GPIO 4 benötigt einen Pull-Up). Der Timer geht wieder schlafen und der komplette Rest der Schaltung ist ohne Energie. Hilft gegen Ghosting beim Display und auch gegen nicht immer saubere Deep-Sleep Zyklen beim ESP.

Der Zeitbereich des Timers ist von ca. 100ms bis 7200s einstellbar. Wenn der LDO einen geringen voltage drop hat (<150mV) kann man das ganze mit einer Li-Ion Batterie bis zu einer Entladeschlussspannung von ca. 3.3V betreiben. Manche ESP laufen bis ca. 2,5V, dann könnte man noch weiter runter gehen.

Wichtig ist, dass das DONE Signal von dem GIPO 4 oder GPIO 5 kommt. Die anderen Ausgänge flackern zu sehr beim Start und lösen den DONE Eingang des Timers schon beim booten aus.

Ganz puristisch läßt sich noch eine evtl. vorhandene LED auslöten.

hallo eki!

Wenn ich in deinem Testmodul das 5.65" Display als devicetype auswähle, bekomme ich folgende Fehlermeldung, wenn ich den colormode auf color setzen möchte: Invalid argument color to colormode. Device does not support color mode.

Das kann eigentlich nur daran liegen, dass irgendetwas bei der Initialisierung nicht geklappt hat. Kannst Du einfach das device noch mal löschen und neu anlegen. Ansonsten poste mal ein Listing des Devices.

Gute Idee! Nach dem erneutem Anlegen funktioniert die Konvertierung und sieht gut aus! Hoffentlich macht Dir die Anpassung mit dem Upload nicht all zu große Schwierigkeiten.

Ist fast fertig, werde hoffentlich morgen eine Testversion haben, dann kannst Du testen (ich kann meine Ausgaben mit denen der Webapp vergleichen, aber sicher ist man erst, wenn man wirklich mit den echten Displays testet).

Zitat von: Jendaw am 08 August 2021, 15:01:32
Kannst du bitte überprüfen, ob du mehrere Bilder mit der "Price-Tag"-Webseite der Original-Firmware hochladen kannst? Dazu rufst du den ESP einfach per Browser auf und konfigurierst dort dein Display.

Grundsätzlich sollte aber erst einmal der Upload mit der Original-Firmware laufen, auch mehrmals hintereinander.

Hallo Jendaw,

Also das funktioniert. Ich kann über die PriceTag Seite das vom FHEM Modul generierte PNG problemlos hochladen und es wird sauber angezeigt. Lasse ich jetzt aber das Modul direkt auf die IP des ESP8266 los, bekomme ich nur endlose Fehlermeldungen im Serial Monitor vom Arduino IDE und das Display macht nichts.

22:43:50.948 -> Unknown URI: /ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppaibappppapaaaaaaaapappppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppiodaLOAD_
22:43:50.948 -> Unknown URI: /ppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnpppppapaaaaaaaahappppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnpppppapaaaaaaaahappppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnpppppapaaaaaaaahappppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnpppppapaaaaaaaahappppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnppppphpppopphpphoppppppppppppppppppppppppppppppppppppppppppppiodaLOAD_
22:43:50.981 -> Unknown URI: /ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnppppphpppopphpphoppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppplnppppphpppopphpphoppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppmpaapnppppppppppppammbpmppppppppppppplnppppphpppopphpphoppoppddapmbpppppdadodphppppppdpmhpppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppmpaapnppppppppppppammbpmppppppppppppplnppppphpppopphpphoppipobdahpamphopdabinohppppppdpmhoppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppiodaLOAD_


Zitat von: Borkk am 10 August 2021, 22:52:13
Hallo Jendaw,

Also das funktioniert. Ich kann über die PriceTag Seite das vom FHEM Modul generierte PNG problemlos hochladen und es wird sauber angezeigt. Lasse ich jetzt aber das Modul direkt auf die IP des ESP8266 los, bekomme ich nur endlose Fehlermeldungen im Serial Monitor vom Arduino IDE und das Display macht nichts.

Ich habe jetzt mal den ESP32 zur Seite gelegt und alles mit dem ESP8266 probiert und bin jetzt schon etwas weiter. Mit der Original Firmware von Waveshare aktualisiert das ESPEink Modul jetzt regelmässig das Display. Allerdings wird das PNG in unregelmäßigen Intervalen verschoben dargestellt. Dafür habe ich noch keine Erklärung.

Mich würde jetzt natürlich interessieren, was hier "Best Practise" ist.

- Nimmt das Display in dieser Konfiguration dauerhaft Schaden (Stichwort: Dauerstrom)
- was bringt der "Umweg" über MQTT mit dem DOIF (Git von Yattien)

Ich habe jetzt mal eine Testversion für das neue 5.65 Farbdisplay fertig und angehängt. Bitte mal testen. Müsste eigentlich sowohl mit ESP32 als auch mit ESP8266 gehen.

Zitat von: Borkk am 10 August 2021, 22:52:13
Lasse ich jetzt aber das Modul direkt auf die IP des ESP8266 los, bekomme ich nur endlose Fehlermeldungen im Serial Monitor vom Arduino IDE und das Display macht nichts.

Was hast du für ein Display? Klingt danach, als würde eine Einstellung im FHEM-Modul fehlen oder inkorrekt sein.

Zitat von: Borkk am 11 August 2021, 00:17:23
Allerdings wird das PNG in unregelmäßigen Intervalen verschoben dargestellt. Dafür habe ich noch keine Erklärung.

Erfolgt hier das Update evtl. zu schnell? (Bild ist zwar schon hochgeladen, das Display aber noch nicht fertig mit darstellen, ehe das nächste kommt)

Zitat
Mich würde jetzt natürlich interessieren, was hier "Best Practise" ist.
- Nimmt das Display in dieser Konfiguration dauerhaft Schaden (Stichwort: Dauerstrom)

Das Display selbst sollte nach dem SHOW in den DeepSleep gehen. Beim 7,5" tut es das leider mit der aktuellen Firmware nicht, hier muss noch eine Funktion in Loader/epd7in5.h angepasst werden, sonst nimmt es Schaden.

static void EPD_7IN5_V2_Show(void)
{
  EPD_SendCommand(0x12); //DISPLAY REFRESH
  delay(100);            //!!!The delay here is necessary, 200uS at least!!!
  // EPD_7in5_V2_Readbusy();

  //Enter sleep mode
  EPD_SendCommand(0X02); //power off
  EPD_7in5_V2_Readbusy();
  EPD_SendCommand(0X07); //deep sleep
  EPD_SendData(0xA5);
}

Zitat
- was bringt der "Umweg" über MQTT mit dem DOIF (Git von Yattien)

Ich kann nur für mich sprechen, ist also keineswegs BestPractise ;)

• In Zusammenhang mit einem Sleep des ESP muss FHEM mit dem Upload nicht warten (und ggf. fehlschlagen), bis das Display wieder wach ist. Der ESP fordert die Daten an, wenn es wieder da ist. Kommt immer darauf an, was du darstellen möchtest und wie lang deine Sleeptime damit ist.
• Ab v17 der Yattien-Firmware wird das 7in5v2 mit dem neuen Display-HAT v2 unterstützt. In der offiziellen Firmware ist das noch nicht enthalten.
• Obiger Bug in der 7in5-Datei ist hier auch bereits behoben (ab v18).

HTH

Hallo Jendaw,

erst mal Danke für deinen Support, ich bin ja wie gesagt in der "ESP Szene" :-) noch recht neu aber so langsam verstehe ich auch wie Arduino IDE arbeitet.

Mein Display ist ein "7.5 inch HD e-Paper (B)" wenn ich richtig verstanden habe müsste der Code im "Waveshare Original Loader" im Reiter esp7in5_HD.h sein. Allerdings fehlt mir da noch das "(B)" 

Der Code dort lautet:

static void EPD_7IN5_HD_Show(void)
{   
unsigned int i;
EPD_SendCommand(0x26);
    for(i=0; i<880*528/8; i++) {
        EPD_SendData(0xff);
    }
    EPD_SendCommand(0x22);
    EPD_SendData(0xF7);
    EPD_SendCommand(0x20);
    delay(200);
    EPD_7IN5_HD_Readbusy();
    Serial.print("EPD_7IN5_HD_Show END\r\n");
}

Wie müsste ich den Umbauen das mein Display keinen Schaden nimmt? Und ist das überhaupt der richtige Code (ohne (B))

Ich hätte da noch eine kleine Verständnisfrage zum Arduino IDE. Im ersten Reiter steht ja immer der "Hauptcode" in den über #include Bibliothek eingebunden werden. Ich habe verstanden das die Bibliotheken in "" im gleichen Verzeichnis liegen wie der Sketch und die in <> an verschiedenen anderen Stellen in der Arduino Installation. Haben die Farben eine Bedeutung? Manche Bibliotheken werden im Code orange und manche grün angezeigt. Beim Hochladen auf dem ESP werden aber scheinbar alle Bibliotheken gefunden und der upload läuft fehlerfrei.   

Zitat von: Borkk am 11 August 2021, 11:06:16
Mein Display ist ein "7.5 inch HD e-Paper (B)" wenn ich richtig verstanden habe müsste der Code im "Waveshare Original Loader" im Reiter esp7in5_HD.h sein. Allerdings fehlt mir da noch das "(B)" 

[...]
Wie müsste ich den Umbauen das mein Display keinen Schaden nimmt? Und ist das überhaupt der richtige Code (ohne (B))

Für das 7in5-HD ist nichts am Code anzupassen. Gilt nur für das 7in5 (ohne HD).

Zitat
Ich hätte da noch eine kleine Verständnisfrage zum Arduino IDE. Im ersten Reiter steht ja immer der "Hauptcode" in den über #include Bibliothek eingebunden werden. Ich habe verstanden das die Bibliotheken in "" im gleichen Verzeichnis liegen wie der Sketch und die in <> an verschiedenen anderen Stellen in der Arduino Installation. Haben die Farben eine Bedeutung? Manche Bibliotheken werden im Code orange und manche grün angezeigt. Beim Hochladen auf dem ESP werden aber scheinbar alle Bibliotheken gefunden und der upload läuft fehlerfrei.

Die orangenen sollten die sein, die du zusätzlich hinzugefügt hast (Verzeichnis Arduino/libraries).
Die Grünen kommen vom Boardverwalter.
Die schwarzen sollten die sein, die aus der IDE selbst kommen.

Ist allerdings nur meine Vermutung, wenn ich mir die anschaue.

Hallo Jendaw,

Ok, danke für die Info. Mein Display läuft jetzt einwandfrei am ESP8288 mit der Original Waveshare Firmware. Die Verschieber in der Darstellung scheinen tatsächlich von einem zu frühen Upload zu kommen. Dazu muss ich in FHEM noch etwas anpassen, einige Werte kamen zu oft.

Aber so gefällt mir das erst mal sehr gut. Ich sehr für mich jetzt keinen Grund die Yattien Lösung einzusetzen?

Oder habe ich was übersehen?

Zitat von: Borkk am 11 August 2021, 12:28:58
Aber so gefällt mir das erst mal sehr gut. Ich sehr für mich jetzt keinen Grund die Yattien Lösung einzusetzen?
Oder habe ich was übersehen?

Prima! Wenn alles bei dir wie gewünscht läuft, gibt es keinen Grund. Die alternative Yattien-Firmware (https://forum.fhem.de/index.php/topic,109690.0/all.html) baut ja auch nur auf den waveshare-Sourcen auf.

Eine Frage habe ich doch noch. Ich habe jetzt die gleiche Konstellation mit meinem ESP32 in Betrieb genommen. Funktioniert auch grundsätzlich, nur mit dem Problem das der ESP32 scheinbar nach dem ersten Upload "einschläft" und nicht mehr aufwacht. D.h. das Display wird nicht mehr aktualisiert.

Nach einem ersten, schnellen Test: Der Upload funktioniert. Allerdings hängt sich das Dispaly nach der ersten Routine auf. Anbei ein Vergleich aus dem Serial Monitor in Bezug auf einen Upload mit dem Waveshare Uploader. Ich habe nur die letzen beiden Schritte eingefügt, da sich hier der Ablauf unterscheidet:

Waveshare:

21:31:22.563 ->  EPD_loadGLOAD
21:31:22.655 ->
21:31:22.655 ->  EPD_loadG
21:31:22.750 -> SHOW
21:31:22.750 ->
21:31:22.750 ->
21:31:22.750 -> e-Paper busy
21:31:22.845 -> e-Paper busy release
21:31:22.845 ->
21:31:22.845 -> e-Paper busy
21:31:34.261 -> e-Paper busy release
21:31:34.261 ->
21:31:34.261 -> e-Paper busy
21:31:34.308 -> e-Paper busy release
21:31:34.497 -> EPD_5IN65F_Show END


Über FEHM:

21:32:48.899 ->  EPD_loadGLOAD
21:32:48.946 ->
21:32:48.946 ->  EPD_loadG
21:32:49.041 -> SHOW
21:32:49.041 ->
21:32:49.041 ->
21:32:49.041 -> e-Paper busy
21:32:49.136 -> e-Paper busy release
21:32:49.136 ->
21:32:49.136 -> e-Paper busy
21:33:00.587 -> e-Paper busy release
21:33:00.587 ->
21:33:00.587 -> e-Paper busy
21:33:00.587 -> e-Paper busy release
21:33:00.774 -> EPD_5IN65F_Show END
21:33:00.966 ->
21:33:00.966 -> SHOW
21:33:00.966 ->
21:33:00.966 ->
21:33:00.966 -> e-Paper busy


Sieht so aus, als wenn die End-Routine noch einmal aufgerufen wird.

Kannst Du mal für einen Upload verbose auf 5 stellen und mir dann den damit erzeugten Teil des Logfiles hier posten. Das SHOW wird, zumindest hier bei mir, nur einmal geschickt.

Hier ein Upload, den Mittelteil habe ich zwecks Übersicht rausgeschnitten. Ich denke, du interessierst dich ja eher für Anfang und vor allem Ende.


2021.08.12 17:07:11 5: EInk: Event received from device global (events are: ATTR EInk verbose 5)
2021.08.12 17:07:12 1: RMDIR: ./restoreDir/save/2021-08-09
2021.08.12 17:07:12 5: EInk: Event received from device global (events are: SAVE)
2021.08.12 17:07:20 3: EInk: sending HTTP request to http://192.168.200.244/EPD with data: jb
2021.08.12 17:07:20 5: EInk: Event received from device EInk (events are: upload)
2021.08.12 17:07:21 5: EInk: callback from command EPD, URL http://192.168.xxx.xxx/EPD status code 200
2021.08.12 17:07:21 5: EInk: 1500, 0, gdgdgdgdgdfdbgbgdgdfdfdfdgdgdgdgdgdgbgbabababgbgdgdgdgdgdgdgdgdgdgbgbgdgdgbgbagdgdgdgdgdfdgdgdgbgdgdgdgdgdgdgdgdgdfdgdgdgdgdgdgdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdfdfbbbbbbbbbbagagagagbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdgdfdfdfdgdgdgdgdgdgbgbgbababgbgbgdgdgdgdgdgdgdgdgdgbgbgbababgbgbadgdgdgdgdgbbgdfdfbgbagdgdfdfdgdfdgdgdfbgdgdgdfdgdgdgdgdfdfdgdgdfdgdgdfdfdfdgdgdfdfdgdfdfdgdgdfdgagagdgdagagdgdgdgdgdgdgdgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgdgdfbgbgdfdgdfdfdfdgdgdgdgdgdgdgdgdgdfbgbgdgdfdfdfdgdgdgdgdgdgdfbababgbgbgdgdgdgdgdgdbabababgbababgbgbadgdgdgdgbabababgbababababababababababababagdgdgdgdgdgdgdfdgdgdgdgdgdgdgdgagdgdgagadgdfdbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 3000, 0, bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgdgdgdgdgdgdgdfdfdgdfdfbgbgdfdfdfdfdgdgdgdgdgdgbgbgdgdfdfbgbabababababababagagagdgdgagdgdgdgdgdgdgdgdgbababgbgdgdgdgdgdgdgdgdgbgdgdgdgbabababababababababagdgdfdgdgdgdfdgdgdgdgdgdgdgdgdgabagaadgdgdgdgdgdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdfdgdfdfbgbgdgdgdgdgdgdgdgdgdgdgbgbgbgdgdfbgbgbagdgdfdgdgdgdgdgdgdfbgbabgbagdgdgdgdgdgdfdfdfdgdfbgbgdgdgdgdgdgdgdgdgdfdfdgdfdfdgdgdfdfdgdgdgdgdgdgdgdgdgdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgabagdgdgdgdgagagdgdadgagdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 4500, 0, gdgdgdgdgdgbgdfdfbgbgbababgdfdfdgdgdgdgdgdgdbdgdgdfdbgbgdgdfdfdfdgdgdgdgdgdgdgagababgbgdgdgdfdgdgdgdgdgdfbgbgdgdfdfdgdgdgdgdgdfdgdgdfdfdgdfdfdfdgdgdgdfdgdgdgdfdgdgdfdfdgdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgdggababagagabadgdgagdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgbgbabagdgdgdgdgdgdgdgdgdgbgbgbgdgdfdfdfdfdgababagdgdgdfdgdgdbgbgbgdfdfbgbgdfdbdgdgdgdgdgdfdfbgbgdgbabgdgdgdgdgdgdbgdgdfdfbgdgdgdfdgdgdgdgdgdgdgdgdfdfdgdgdfdgdgagdgdgdgdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgggdgdgdfdgdgdgdgdgagdgdgdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdbdbgdbabgbgbgbabababababadgdgdgdgdgbgbgbababgbgbgbagdgdgdgdgdgdgdgdgdgdgdfdgagbgbabababgdgdgdgdgdgdgdbgbgdgdfdfdgagdgdgdgdgdgdgdgbgbababgbgdgagdfdgdgdgdgdgbgdgdgdfdfagababagagagdgdgagagdgdgagdgdgagagdgdgagdgdgdgdgdgdgdgdgdgdgdfdgdgdgdgdgadgdgdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 6000, 0, bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgagdgagdgdgdgdfdgdgbgbgbgbababgbgbgdadgdgdgdgdgdgdgdgdgbgbgbgdgdfdfdgagagagdgdaadgdgdgdgdfbgdgdgdfdfdgdgdgdgdgdfbdgdgdfbgbagdgbgbadgdgdgdgdfdfdgdgbgbagdfdfdgdgdgdgdgdgdgdgdbdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdfdgdgdgdgdfdfdfdgdfdfdgagdgdgdadgdgdgdgdgdgbgbgbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdgdgdbabagdgdgdgdgdgdgdgdgdgdgdbdbgbggdfdfdfdfdgdgdgdgdgdgdgdgdgdfdbbbdgdbgbgbggaagagagdgdgdfdgdgdfbgbagdgbgbgdagdgdgdgdgdgdgdgdfbgdgdfdfbgdgdgdfdgdgdgdgdgbabagdfdfdgdgdfdfdfdfdfdfdfdgdfdfdgdgdfdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdgdfdgdgdgdgdgdgdgdgdfdfdfdgdfdgagdfdgdadgdgdgdgdgbgbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 7500, 0, gbgbgbgbgdgdfdfdfdfdgdgdgdgdgdgagdgdgdgdfbgbgbababgbgbgdgdgdfdfdgdgagagdgdgdbdbdfdgdbbgbagdgdfdfdgdgdgdgdgdgdbgdgdfdbgbagdgdfdfdgdgdfdgdgdfdgdgdgbgdgdgbgbagdgdgdgdgdgdgdgdgdgdgdgdgdgababagdgdgdgdgdgdfdfdgagdgdgagdgdgdgdgdgdgdgdgdgdgdfdgdgdgdfdgdgdgdgdfdgdgdgdgdggggdfdgagdfdgdgdgdgdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdgdgdgdgdgdgdbgbgbabababgbgbgdgdgdgdfdgdadgdgdgdgdgdbdbgdfdfdbgbgbababababagagagdgdgabdfbabababgbgdgdgbgbgdgaagdgdgagdgdgdgdgbgbabababgbagdgdfdfdgdfdgdgdgbabagdfdfdgdgdfdfdgagagdfdfdgdgdfdgdgdfdfdgdgdgdgdgdfdfdgdgdfdgdgdgdfdgdgdgdgdgdfdfdgdgdgdgdfdfdgdgdfdgdfdfdgdgbabababababagdgdgagdgdgdagdgdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgdgdgdgdgdgdgdgdgdgdgdgdbdbdbgdfdfbgbgbgbagdfdfdfdgaggdgdgdggdbababababgbgbdgdbgbgbdgagdgdgdgdgdgbgdgdgdgbgbgdgbgbgbagagdfdfdgdgdgdgdgdfbabababgbagdgdfdfdgdgdgdgdgdgabagdgdgdgdgabagagdgdgdgdgdgdgdgdgdfdfdgagdgdgdgdgdgdgdfdgdgdgdfdgdgdgdgdgdgbgdgdgdgdgdgdgdgdgdgbabagdgdgdgbabababgbabababagdgdgagagdgdmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 9000, 0, aagdgdgdgdfdbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgdfdfdfdfdfdgagdgdfdgdgagagdgdgdgdgdbdgdgdfdbgbgbdbdfbgbgbdgagdgdgdgdgdgdgdgagdgbgbbgdfdfbgbgdgdgdfdfdgdadagdgdgdgbgdgdgdfbgbagbgbgbagdgdgdgdgdgdgdgdgbgbababgbgdgagdgbgdgdfdfdgdgdgdgdgdgdgdgdfdfdgagdgdgdgdfdgdgdgdfdfdgagdgdgdgdgdgdgdfbgbagdgdfdgdgdgdgdgdfdfdfdgdgdgbgbabagbgbabagdgdgdfdgdgdfdfdgdfdfdgdfdgagdgdgdgagdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbababgbgbgbgbgdbgbgbgbgbabababgbgdgdgagagdgdgabababagdgdbdbgbdbabgbgbgbagdgdfdbabadgdgdgdgdgdbgbababgbgbgbggbgbgbagdagdgdgdgdgdfdgdgdfbgbababgbgdgagdfdgdagdgdgdgdfdbabagdgdgbgdfdfdgagdfdfdgdgdgdgdfdbabgbabagdfdfdgdgdgdgdbgbgdgdgdgbgdgdgdgdgdgdfdfdgdfdfdfdgdgdgdgdfdfdgdgbabagdgdgdfbgbababgbababababgbagdgdfdfdfdfdfdbababagdgdgdgagdgdgdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:21 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:21 5: EInk: 10500, 0, gdgdgdgdgdgdgagdgdbdbdgdgdgbgdbgbgdgdbbgbgbdgdgdgdbabagagdgagdgdgdbdbgbababgbgbgbagdgbgbgdgaadgdgdgdgdgdgdgdgdbgbggdgbgbgbagdgdfdfdgdadgdgdgdgbgdgdgdfbgdgagbgbagdgagdgdgagdagagagdgdgdgdgdgagdfdfdgagdgdgdgdfdgdgdgdgbgbagadabababababagdgdfdfdgdgdgdgdgdgdgagdfbgbagdgdfdfdgdgdgdfbgdgdgdgdgdgdgdgdfdgdgdbgbgbabababgbagdfdfdfdfdgdgdgdfdgdgdgdgagdgdfdfdbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgbgdgdgagdgdgdgdgagagdgdgdgdfdgdgdggabdbdfbagdfbgbgbgdgdgdbababagagdgdgdgdgdbdbgbababdbbgbgggdfbgbgdgagdfdgdgadgdgdgdgdgbgdgdgdfbgbggdgbgbgdgdgdgdgdadgdgdgdgdbgdgdgdfdbagabababagagagagdfdbabababdbabgbgdgagdfdgdgdgdgdgdfgbgbababababagdgdgdgdgdfdfdgdfdfdbagdgdgdgdfdgdgdfbgbabadgdgdfdfdgdgbgbgdgdfdfdgdgdgdgbgbababgbgbabababgbababababababababagdgbgdgdgdgdgdfdfbgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdbdbgdfdgdfdfbgdgdgdgdfdfdfdgagdgdgdgdgaggdgdgadgdgdbgbababgbgbgbdgdgdfdfdfdgagadgdgdggdgdgdgdgdgbdbgdgdfdbgbgbagdgbgbagaagdgdgdgdgdgdgdgdgbgbagdfbgbgdgagdfdfaagagdgdgabdbagdgdfdgdgdbdfdgagdgdgdgagdgdgdfdbgbabgbagdfdfdgdgdgdgdgdfdgdgdgdfdfdfdgdgdgdgdfdgdgdfdfbgdgdgdfdgdgdgdgggbgbagdgbgbabagdfdgbgdfdmnfaLOAD
2021.08.12 17:07:22 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:22 5: EInk: 12000, 0, gdfbgdgdgbababababgbgbababgbabababgbababgbgbabgbabgbgdgdgbagdgdgdfbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbfbgbbgbgbgbgdbgbgbabgbgbgbgbabababgbgbabaagdfdfdgdgagdgdgdgdgdbdfbgdfdbgbgbgdgdfdfbgbdgagagdgdgdgagdgdgdggdbdbabababdbbdfdgbgbgbgdgagdfdfdgdgdgdgdgdgdfdgdgdfdbdgdgbgbdgagabababagdgdgagdfdgdfdfdfdgdgdfdgdgadgdgdgdfdgdgdgdfdfbgbabagdfdfdgdgdgdgdfdfdfdgdfdfdgdgdgdgdgdfdfdgdfdfdbadgdgdgdgdgdgdfdfdgdgdgbgbagdfdfdgbababgbabababababababababababababababgdgdgdfdfdgbgbabgbabgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdbdgdgdgdbdbgbdbdfdfdbdbdbdfbgbgbdbdbgbababgbgbgbabagabababagagdgdgdgagdbdbgbagdfdbdfbgdgdbgbgbgdgagdfdfdgagagdgdgdgaggbabagdgdbgbdbgbgbgbagdgdfdfdgdgagdgdgdgababadgdfdbdgdfdfdfdgagdbabagdgdgdgdgdfdgdgdfdfdfbgbagdgdgdfdgdgdgdgdgbgbgdgdgdgbgbagdgdgdgdgdfdgdgdfdfbgdgdgdfdgdgdgdgdfbgbgdgdfbgbabababababagdgbgbgbabgdfdgdgdgdfdfdgdgbgbgdgdfdfdgdgdfdfdgdfbgbababababagdgbababbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbmnfaLOAD
2021.08.12 17:07:22 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:22 5: EInk: 13500, 0, gabababababdbgbabababgbgbgbadgdbgbgbgbgbgbdbdbdbgbgbdbgbgbgbabagagdfdbagagadgdgdgagbdgdgdgdgdbdbgbabgbgbgbgdgdgbgbgdgdagdgdgdgagdgagdadgdbbgbgbgbgbgdgdgbgbgbagagdfdfdgagagdgdgdgdfdggdfdbagdfdfdfdgagdgdgdgdgdgdgdfdfbgbabababgbgbadadgdgdgdgdgdgdgdfbgbgdgdgdfdgdgdgdgdgbgbgdgdgbgbabadgdgdgdgdgdgdfbgbababgbagdgdgdgbgdfdgbgbgbgdfdfdgdgdgdfdfdfdfbgbgdfdfdgdgdgdfdgdgbgbabgdfdgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdgdgdgdgdgagdagdgdgdgdgdgdgdgdgdgdbdbdbababgbgbgbdbababdbdbgbgbdbgbgbgbdgdgdfbgbdgdagagdfdgdgagdgdgdgdgdbdbgdfdgdbbgbgdgbgbbgbdgagdgbggdgadgdadadgdfdfdgdgdbgbdbgbgbgbdgdgdfdfdgagagdgdgagdfdgdgdgbdbgbgbgdgagdfdfdgadadgdgdgbabagdfbgbgbgbagdgdfdfdgdgdgdgdfdfdgdgdfdfdfdadabagdgdgdgaggbgbgdgdgdfdgdgdgdgdgdgdgdfbgbagdgdfdgdgdgdgdfdfdgdfbgbgdgdfdgdgdgdfdfdfdfbgdfdfdgdgdgdgdfdgdgbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbdbgbdfdfdfdfdgdgdfdfdfdgdfdfdgdgdgdbdbagdgdgdfbgbdbdfbabdbdbgbgbgbdbdfbgbabdfbgbgbabagdgdfdfdgagagdgdgagdbabgdgdgdbgbgbabdbdbgdgaggbgbgdgagagdgdgdgagdgdgdgdfdfdfdfdfdgdgdfbgbagagdgbabagagdgdagdgdfdgdgbdfgbgbgbadgagdfdgdgdgdgdgdfdfdfdgdgdfdfdgdgdgdgdgdfdgdggbgbgbgdgdfdbdgdgdgdgdfbgbababgbgbmnfaLOAD
2021.08.12 17:07:22 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
.
.
.
.
.
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:43 5: EInk: 264000, 0, bbaagdbadaabadgdgdbabababdgdgdgdgdadadgdgdgdaaadcdbdcdbaadadcdgdcdcdcdadcdcdcdcdcdcdcdcdcdcdadadadadadgdgdadadadadadadadgdgdadadgdgdgdadadgdfdfdfdgbgdfgdgdgdgaaaaaagaaaagagagagdagdgdaagdgagagdgdgdgdgdgdgagagagagagdgdgdgdbbbbbbbgbgbbbbbbbbbbbbgbgbgbbbbbbbgbgbgdgdgdgdadgdcdcdcdcdgdgdcdgdadadgdgdbdgdddagacacagagagdgdcgdgacagacdcgacacdcdcdcdcdgdgdcacacdcgcagagacagacecgacacacacacacecececeacacagagdcacagdcacagacacgcacgcagagagacagdcacagcacagacagagdgdgagdgagacagafagabagdfdfacacdcagdcdcecacgcgdcgcgcgdgdcgacdcdfdfdcacbdbdbbbbcbcbbbbbbbbbcbdbdbdbdbbbcbcbcbcbcbcbbbbbbbcbcbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbbgdgdababagaabagdfdfdbabababababagdgagagdgdgdgaaagdgdbdfdbaadgdcdgdgdgdgdadadgdgdgdgdgdgdgdgdgdgdgdgdgdcdcdgdgdgdgdgdgdgdcdadaaaaadadadgdgdgdfbgbgbgbabgdfgbagagdgdgaaagaaaaaaaaaagdgagagdgagdgdgagagaagagagdgdgdgdgdgdgagdgbgbgbgbgbbbbgbgbgbgbgbgbbbbbbgbgbgbbbbbbdgdcdcdfdadgdgdgdbdbdcdgdgdgdgdcdbdcdcdfdfcagagacacacacagacgagacagagacagdgagagagcgcacagagabagagdfdcabacagacdcgdgdgagabagacdcacacagagacacagagcagagacagdfdgdgdcacacacaaacafagacagagacagcdcacacacacacagdfdfdfdfabacgcgdgaggabcggcdcecaagcgdgdgdfcggdcececgagagdgdbbbbcbdbdbbdbdbdbdbdbbbbcbbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbcbcbcbcbcbcbcbcbcbcbcbcbabdcdfdbadadaabdaadababababdgdgdgdgadadadgdgdgdaadcdcdcdbabdaadadcdcdcdcdgdgdadcdcdcdcdcdcdcdcdcdadadadgdgdgdcdadadadadcdgdgdgdadaagdgdadadadadgdfdfdfbgbgdgdfdgdgagdgaaagaaagagagdagdgdgagdgagagdgdgdgdagdgdgdgagagagagdgdfdgbgbbbbbbgbbbbbbbbbbbbbgbgbgbbbbbbbgbgbgdgdgdgdadgdcdcdcdcdgdgdcdcdadadgdcdbdbdcddmnfaLOAD
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:43 5: EInk: 265500, 0, agdcagdgagagdcdgdcacagcdcdgdcacacdcdcdgdgdgcacdcacacgcgcgcagdcabagacacacacacacecececeagacagdgacacdgacdcagacacacacgagagaaaacagdcdcagcdcagacagagagagagdgdgacgafdfafdfagdgdfacacacagdcecabafdcdcgcgcgdgdfgdcdcdcdcacacgbdbdbbbbbdbbbbbbbbbbdbdbdbdbbcbbbbcbcbcbcbcbbbcbbbcbcbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbabaadfdgdgagdaaaabdfdgdfdbabadgdgagagadgdgdgdgdgdgdbabdgdgdadadgdgdgdgdcdagdadgdgdgdgdadgdgdgdgdgdgdadcdcdgdgdgdgdgdgdadadagdadadadgdgdgdgdgbgbgbgbgbgbgbgbgdgdgdgdgaaaaaaaaaaagaagagdgagagagagagagagdgagagababababagdfdgbabdfbgbgbbgbgbgbgbgbgbbbbbbbgbgbgbbbbbbbadcdcdfdadgdgdgdbdbdcdgdgdgdgdcdbdgdcdbdfdgagabacacacagacgcecacagagcagagagagagacacacdgdgcececdgdgdgdcafacacagagagagdgagacdcdcdcdcgdcacagagacabagacagagagdgacgcdcgcaaacagagacagagacagacacacacdcgcgcgdfdfabagcdfacgcdgagagdcagacecacafagdgdgdcacgdcgggafagagaadabbbbdbdbcbdbdbdbdbdbbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbcbcbcbcbcbcbcbcbcbcbcbcbcbdadbbbdaagdadgaadgdfdfdbdfdgdgdgdadadagdcdcdcdcdcdcdbdcdbdcdaadadcdcdcdgdgdaaaadadcdcdcdadcdcdcdcdadgdgdgdcdcdadadadadcdgdgdadaaaagdadadcdaadabababgbgbgdgdgbgdfdgagdgagagagagaaagaagagagdgagagdgdgagagdgdgdgagagagababababgbgbbbbbbbbbbbbbbbbbbbgbgbgbbbbbbgbgbgbabababadgdadcdcdcdgdgdcdcdcdadgdgdbdbdgdgdfacacagdgagacagagdcececacagacacdcdcdcagagdgcacdgdgagcacacafabagagacabacacacacagagagagafdceagdcacagacacagacacacacabacagaagcgagacacagacacagacagagagdgagdgagcgcgdfabagagdgdgcacacagacagabagdfdcgcacafdgdfagdcacdcacacafdgbbbbbbbdbbcbcbbbbbcbdbdbdbbcbcbcbbbcbcbcbcbcbbbcbcbcbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdcmnfaLOAD
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:43 5: EInk: 267000, 0, abadbaaaaaagdaababdbdfdfdfdcdcdgdgagdagdgdgdgdgdgdgdgdfdgdgdaadadgdgdcdcdgdadagdadgdgdgdadgdgdgdgdadadcdadgdgdgdgdgdgdgdcdgdgdadadgdgdadgdgagdfbgbgbgbgbgbgdfgdfdgdgdgdgaaaaaagaagdgdgdgaagdgagagdadgagagagdgdgdgdgdgdfdfdbgbgbgbgbgbgbgbgbgbgbbbbbbbgbgbgbbbbbbbgdgdgdgdadgdgdbdgdcdcdgdgdadgdcdbabababdbddgagacacacagacacagdcdcececaagagagagagacdcgagdfacacdgdgagagdcacdcabagagagagagacdcdcdcdfbbacdcgagacagagacagagagagacafacacadacdcagagacagagacagacdcdcgcdcgcdgdgdcgdfacdcacgcdgdgdgacecacacgcgafdgdgdfafafdfagagagagagagdgdbbbbdbcbdbbdbdbdbdbbbbbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbcbcbcbcbcbcbcbcbcbcbcdcdcdcdgdgdbaaaaaaaabadgdfdfdbdbdbdbdfdcdcdgdcdbdbdcdcdcdcdbdbdbdcdgdadadcdgdgdcdgdaaaadadcdcdcdadcdcdcdgdgdadgdcdcdcdadadadcdgdadadgdaaadadgdadadadgdfdfdfdfdfdfbgbgbgbggdgdgdgagagaaaaaaaagaagdagagdgagagagdgadgagagabababgdfdfbbbbbbbbbbbbbbbbbbbbgbgbgbbbbbbbgbgbgbdbadcdcdgdadcdcdcdgdgdgdcdgdcdgdgdbdbdbadgcgacagabagacdgdgdcafagacdcagcdcdcdcdcagagdcdcgdgdgacacacacagagagafabacacacdcdgagafagagdfdgagdcacaacacagacdcacdcagacagagafagagacdcaagacacagacagagagdgagdgcgcgcecgdgagabagafacgacagagagagdgdcacacacdcdcgcacacacacacdcagdgdbbbbbbbbdbbbbcbbbdbdbdbdbbcbcbbcbcbcbcbcbcbcbbbbbbbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdaadcdgadgaaaaadgbaabdbdfdfdfdfdbdbdbdbdbdfdfdbdbdbdbdgdcdcdgdcdgdgdgdcdcdgdcdgdadaadadgdgdgdadgdgdgdadadcdgdgdgdgdgdgdgdgdgdgdadadadgdadgdgdgdadgbgbgbgbgbgbabgdgdgdfdggdgdgaaagagagagaagdagagdgagdgdgdaaagagdgdgdgdgdgdfdfdfdfbgbgbgbgbgbgbgbgbbbbbbgbgbgbbbbbbbbgdgdgdgdcdgdgdgdgdcdcdcdgdadadcdbababadbadddmnfaLOAD
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:43 5: EInk: 268500, 0, gdgdcacgdgcgcagabacdgafdcdgggagagagdcdcgagdcgcacdgagagabacdcdcdcacagagagagcgdfdfdcdcgdcacgcecagagagacagagagagacecacacacacacagagcacagdgacagacacacacdcaagdgdgdgcgabacacdcdfdcagacacacacacgagdgdfagagagdgdgdgagagagdgdgdgdbbbbbdbbdbdbdbdbbbbbbbbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbcbcbcbcbcbcbcbcbcbcbcbcdcbdcadgdagdgdgdabdgdbababdbdbdbdbabababababdbdfdcdcdcdcdgdgdbdbdgdcdadadgdcdgdcdgdgdaaadadcdcdgdadcdcdgdgdadadcdcdadadadadcdadagdgdgaaagdadadadgdgdgdfdfdbgbgbgbgbgbgbgbabagagdgdgdagaaagdagadgagdgagagagagdgdgagagagdggdfdfbgbbbbbbbbbbbbbbbbbbbgbgbgbbbbbbgbgbgbgbdgdcdcdgdadcdcdcdgdgdgdadgdgdgdgdbdbdbadbabaacagdgdcgagdgcdcagacdcaggcdcdfdcdcagagdcdcgdgdgacacacagabagagagagacacdcacagcgcgdfagdcgdgdgdcacacacagdcacacdcagacecagagagagacacagdgacacagacagaagagagagacgcgcgdgdgagdgagagagacagdfdgdgdgacacacgdcdfdfacacacacacacagdgdgdgdbbbbbbbbbbcbcbdbdbdbdbbbbcbcbcbcbcbcbcbcbcbbbbbbbcbcbcbdbdbdbdbdbdbdbdbdbdbdbdbdbcbdgdbadbbdadgagbdbdbdbdfdfdfdfdbdbdbdbdbababdbdbdbdbdcdcdcdcdcdgdgdgdcdgdcdgdgdadgdaaagdgdgdcdgdgdgdadagdgdgdgdgdgdgdgdgdgdgdadadadgdagdgdgdadadagbgbgbgbgbgbgbgbgbabgbababagagagdgdgdagdgagdgagdgdgaadgagagdgdgdgdfdfdfbdbgbgbgbgbgbgbgbgbgbgbbbbbbgbgbgbbbbbbbbgdgdgdgdcdgdgdgdgdcdcdcdgdadadcdbababadbadgdbgdgcgcgacacgagagacececgdggggcgagagdcdcecgdcgcgdfdfdgdgdfacdcacacagdgagagdgdgdgcgdfagdcgcacgagagagdcagagdgagacagdcecacacacagabacacagagacaagacacacdcacagdgdgdfacacacacacdcdcecdcacacacacagdgdgagagagdgdgdgdgdgdgdgdgdgdgdgdbdbbbbbdbdbdbbcbbbbbcbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbcbcbcbcbcbcbcbcbcbcbcbcdcdbdbmnfaLOAD
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:43 5: EInk: 268800, 1, dfbbabagababdbcbabcbdbdbdbdbdfdfdfdfdbdbdbababababdbdgdgdgdbdcdcdcdgdcdgdcdcdgdagdadadadcdgdadadcdgdadadadcdadadadadadadcdgdgdgdaaadadadagdgdgdadgdbabgbgbgbgbgbgbgdfbgbgbdfdgdgdgagdgagdgagdgagagdgagdgdgdgdggdgdgdfdfgbbbbbbbbbbbbbbbbbbbbgbgbgbbbbbbgbgbgbgbgdgdcdcdgdadcdcdcdgdgdgdadgdgdgdbdbdcdgdbadadmcbaLOAD
2021.08.12 17:07:43 5: EInk: callback from command LOAD, URL http://192.168.200.244/LOAD status code 200
2021.08.12 17:07:53 5: EInk: callback from command SHOW, URL http://192.168.200.244/SHOW status code
2021.08.12 17:07:53 3: EInk: problems with communication to device, trying once more (1 of 3 done)
2021.08.12 17:08:03 5: EInk: callback from command SHOW, URL http://192.168.200.244/SHOW status code
2021.08.12 17:08:03 3: EInk: problems with communication to device, trying once more (2 of 3 done)
2021.08.12 17:08:13 5: EInk: callback from command SHOW, URL http://192.168.200.244/SHOW status code
2021.08.12 17:08:13 3: EInk: problems with communication to device, trying once more (3 of 3 done)
2021.08.12 17:08:23 5: EInk: callback from command SHOW, URL http://192.168.200.244/SHOW status code
2021.08.12 17:08:23 1: EInk: problems with communication to device, max retries (3) reached

Sieht so aus, als ob das SHOW Kommando nicht vom Device quittiert wird. Das Modul prüft, ob ein Status 200 also OK vom HTTP Kommando zurück kommt und probiert es dann noch mal (maximal 3 mal per default). Setze mal Folgendes:
attr EInk maxretries 0

Problem solved! Vielen Dank dafür!

Zitat von: eki am 12 August 2021, 18:07:17
Sieht so aus, als ob das SHOW Kommando nicht vom Device quittiert wird. Das Modul prüft, ob ein Status 200 also OK vom HTTP Kommando zurück kommt und probiert es dann noch mal (maximal 3 mal per default). Setze mal Folgendes:

Code Auswählen Erweitern

attr EInk maxretries 0

Hallo Eki,

ich kämpfe mit einem 7.5" HD (B) Display. Ich habe Interval auf 0 stehen, da ich nur ein Update benötige wenn sich ein Status bei einem Fenster ändert. Das Modul generiert auch sauber das PNG file. Wenn ich das PNG über
set epaper upload manuell hochlade passt auch alles (siehe Bild1). Sobald das Modul aber einen Upload automatisch startet kommt nur Schrott auf dem Display an (Bild2). Das fängt sich dann auch nicht mehr, von alleine z.B. mit dem nächsten Upload. Erst wenn ich den Upload wieder manuell starte, sieht es wieder korrekt aus.

Egal wie ich das PNG auch hochlade, am Ende zeigt das Modul immer:
Error uploading image to device, max retries (3) reached
an. Egal ob das PNG richtig oder verschoben angezeigt wird. Im Arduino IDE Log sehen beide Übertragungen identisch aus. Ich habe maxretries auf 0 stehen. Ich nutze den original Waveshare loader Sketch.

Kann es sein, dass die automatischen uploads immer mehrfach angestoßen werden und sich dann gegenseitig überschreiben?

Poste mal ein List Deines EInk Devices und ein Stück Logfile mit verbose 5 (das erzeugt sehr viele Ausgaben, also nicht vergessen wieder zurück zu stellen) wenn ein automatischer Update läuft.

Hier das List:

Internals:
   BOARDTYPE  ESP8266
   COLORMODE  color
   CONVERTMODE level
   DEF        /opt/fhem/www/images/custom/display_hd.png
   DEVICETYPE 7.5inch_e-Paper_HAT_(B)_HD
   FUUID      60840029-f33f-1248-e0e3-fe715672d3502017
   FVERSION   89_ESPEInk.pm:0.233970/2020-12-21
   INTERVAL   0
   NAME       ep_flur
   NOTIFYDEV  ku_rollo,bd_rollo,elle,bd_fenster,Steffen,speak_volume,wz_rollo_rechts,wz_rollo,ku_fenster,wz_tuer,ep_flur,ds_tuer,wz_rollo_f,ds_rollo,global,wz_links,wz_rechts,sz_tuer,sz_rollo,bewohner_riedberg,wz_rollo_links,el_tuer,el_rollo
   NR         345
   NTFY_ORDER 50-ep_flur
   PICTUREFILE /opt/fhem/www/images/custom/display_hd.png
   STATE      Error uploading image to device, max retries (3) reached
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        192.168.23.76
   Helper:
     DBLOG:
       result_picture:
         DBLogging:
           TIME       1628873996.69715
           VALUE      <html><img src=/fhem/images/ep_flur/result.png?dummy=93347.8841268141></img><div>/fhem/images/ep_flur/result.png</div></html>
       state:
         DBLogging:
           TIME       1628868598.72424
           VALUE      upload
   READINGS:
     2021-08-13 17:07:30   deftexts        0
     2021-08-13 18:59:56   result_picture  <html><img src=/fhem/images/ep_flur/result.png?dummy=93347.8841268141></img><div>/fhem/images/ep_flur/result.png</div></html>
     2021-08-13 17:07:30   source_picture  <html><img src=/fhem/images/ep_flur/display_hd.png?dummy=973013.175388139></img><div>/fhem/images/ep_flur/display_hd.png</div></html>
   helper:
Attributes:
   DbLogInclude .*
   boardtype  ESP8266
   colormode  color
   convertmode level
   definition addsymbol#line#0#50#81#0#FF0000#879#0
addsymbol#line#0#527#20#0#FF0000#879#0
addtext#Home Status Riedberg#260#15#24#0#ffffff#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0

iconreading#speak_volume:e_icon#500#100#40#0#000000

iconreading#bewohner_riedberg:e_icon#600#100#40#0#000000
iconreading#elle:e_icon#600#150#40#0#000000
iconreading#Steffen:e_icon#600#200#40#0#000000

addtext#Schlafzimmer#10#68#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#sz_tuer:e_icon#145#60#40
iconreading#sz_rollo:e_icon#190#60#40

addtext#Zimmer Elle#10#118#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#el_tuer:e_icon#145#110#40
iconreading#el_rollo:e_icon#190#110#40

addtext#Duschbad#10#168#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#ds_tuer:e_icon#145#160#40
iconreading#ds_rollo:e_icon#190#160#40

addtext#Badezimmer#10#218#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#bd_fenster:e_icon#140#210#40
iconreading#bd_rollo:e_icon#190#210#40

addtext#Küche#10#268#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#ku_fenster:e_icon#140#260#40
iconreading#ku_rollo:e_icon#190#260#40

addtext#Wohnzimmer#10#318#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_tuer:e_icon#145#310#40
iconreading#wz_rollo:e_icon#190#310#40

addtext#Wohnz. Fenster#10#368#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_rollo_f:e_icon#190#360#40

addtext#Wohnz. links#10#418#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_links:e_icon#140#410#40
iconreading#wz_rollo_links:e_icon#190#410#40

addtext#Wohnz. rechts#10#468#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_rechts:e_icon#140#460#40
iconreading#wz_rollo_rechts:e_icon#190#460#40
   devicetype 7.5inch_e-Paper_HAT_(B)_HD
   interval   0
   maxretries 0
   room       03 LED Panel
   url        192.168.23.76
   verbose    5

Ich habe vor kurzem auf DBLog umgestellt. So richtig viele Meldungen landen auch bei Verbose 5 nicht in der DB. was ich aber sehen kann, ist das wenn er einen Upload macht, nur ein Antrag in der DB erscheint.

Also ich muss meine Aussage revidieren, auch bei einem manuellen Upload wird das PNG manchmal verschoben dargestellt.

Wäre u.u. ein Attr "block_time" hilfreich. Also ein Wert in Sekunden den das Modul immer abwartet, bevor ein neuer Upload gestartet wird? Ich scheue mich noch ein wenig den doch recht aufwendigen Umweg über MQTT zu gehen. Dort könnte man so einen Timer ja über FHEM realisieren.

Hier wäre mal eine Version mit einem neuen Attribut ("mininterval"). Wenn da ein Wert (in Sekunden) gesetzt ist, wird überprüft, ob der letzte upload mindestens sol lange her ist. Falls nicht, wird kein upload durchgeführt.
Bitte schau mal, ob das funktioniert und Dein Problem löst. Falls ja, würde ich das auch in das FHEM repository als neue Version packen (inklusive auch des neuen Displays mit 7 Farben).

Zitat von: eki am 18 August 2021, 10:45:42
Hier wäre mal eine Version mit einem neuen Attribut ("mininterval"). Wenn da ein Wert (in Sekunden) gesetzt ist, wird überprüft, ob der letzte upload mindestens sol lange her ist. Falls nicht, wird kein upload durchgeführt.
Bitte schau mal, ob das funktioniert und Dein Problem löst. Falls ja, würde ich das auch in das FHEM repository als neue Version packen (inklusive auch des neuen Displays mit 7 Farben).

Hallo Eki,

Danke für das Modul. Ich habe es installiert und habe folgende Einstellung gewählt.

Interval=0 (ich will nur eine Upload wenn sich der Status eines Fensters ändert, dann aber möglichst zeitnah)
mininterval =60 (um sicher zugehen, das sich die Uploads nicht ins Gehege kommen.)

Und in der Tat, wartete das Modul mit dem ersten Upload die "mininterval" Zeit ab. Dann jedoch startete eine Schleife, der Upload wurde quasi unendlich wiederholt. Und zwar in 15sec Intervallen. Aber die gute Nachricht, alle Uploads wurden fehlerfrei dargestellt.

(Arduino LOG)
17:52:30.447 -> LOAD
17:52:30.447 ->
17:52:30.447 ->  EPD_loadALOAD
17:52:30.547 ->
17:52:30.547 ->  EPD_loadALOAD
17:52:30.614 ->
17:52:30.614 ->  EPD_loadALOAD
17:52:30.749 ->
17:52:30.749 ->  EPD_loadALOAD
17:52:30.816 ->
17:52:30.816 ->  EPD_loadALOAD
17:52:30.884 ->
17:52:30.884 ->  EPD_loadALOAD
17:52:30.952 ->
17:52:30.952 ->  EPD_loadALOAD
17:52:31.020 ->
17:52:31.020 ->  EPD_loadALOAD
17:52:31.089 ->
17:52:31.089 ->  EPD_loadALOAD
17:52:31.123 ->
17:52:31.123 ->  EPD_loadALOAD
17:52:31.198 ->
17:52:31.198 ->  EPD_loadALOAD
17:52:31.265 ->
17:52:31.265 ->  EPD_loadALOAD
17:52:31.333 ->
17:52:31.333 ->  EPD_loadALOAD
17:52:31.404 ->
17:52:31.404 ->  EPD_loadALOAD
17:52:31.472 ->
17:52:31.472 ->  EPD_loadALOAD
17:52:31.539 ->
17:52:31.539 ->  EPD_loadALOAD
17:52:31.606 ->
17:52:31.606 ->  EPD_loadALOAD
17:52:31.673 ->
17:52:31.673 ->  EPD_loadALOAD
17:52:31.741 ->
17:52:31.741 ->  EPD_loadALOAD
17:52:31.809 ->
17:52:31.809 ->  EPD_loadALOAD
17:52:31.876 ->
17:52:31.876 ->  EPD_loadALOAD
17:52:31.943 ->
17:52:31.943 ->  EPD_loadALOAD
17:52:31.976 ->
17:52:31.976 ->  EPD_loadALOAD
17:52:32.044 ->
17:52:32.044 ->  EPD_loadALOAD
17:52:32.111 ->
17:52:32.111 ->  EPD_loadALOAD
17:52:32.178 ->
17:52:32.178 ->  EPD_loadALOAD
17:52:32.247 ->
17:52:32.247 ->  EPD_loadALOAD
17:52:32.317 ->
17:52:32.317 ->  EPD_loadALOAD
17:52:32.384 ->
17:52:32.384 ->  EPD_loadALOAD
17:52:32.451 ->
17:52:32.451 ->  EPD_loadALOAD
17:52:32.521 ->
17:52:32.521 ->  EPD_loadALOAD
17:52:32.589 ->
17:52:32.589 ->  EPD_loadALOAD
17:52:32.624 ->
17:52:32.624 ->  EPD_loadALOAD
17:52:32.693 ->
17:52:32.693 ->  EPD_loadALOAD
17:52:32.763 ->
17:52:32.763 ->  EPD_loadALOAD
17:52:32.831 ->
17:52:32.831 ->  EPD_loadALOAD
17:52:32.898 ->
17:52:32.898 ->  EPD_loadALOAD
17:52:32.965 ->
17:52:32.965 ->  EPD_loadALOAD
17:52:33.033 ->
17:52:33.033 ->  EPD_loadALOAD
17:52:33.101 ->
17:52:33.101 ->  EPD_loadALOAD
17:52:33.135 ->
17:52:33.135 ->  EPD_loadALOAD
17:52:33.202 ->
17:52:33.202 ->  EPD_loadALOAD
17:52:33.275 ->
17:52:33.275 ->  EPD_loadALOAD
17:52:33.345 ->
17:52:33.345 ->  EPD_loadALOAD
17:52:33.417 ->
17:52:33.417 ->  EPD_loadALOAD
17:52:33.488 ->
17:52:33.488 ->  EPD_loadALOAD
17:52:33.588 ->
17:52:33.588 ->  EPD_loadALOAD
17:52:33.655 ->
17:52:33.655 ->  EPD_loadALOAD
17:52:33.723 ->
17:52:33.723 ->  EPD_loadALOAD
17:52:33.789 ->
17:52:33.789 ->  EPD_loadALOAD
17:52:34.103 ->
17:52:34.103 ->  EPD_loadALOAD
17:52:34.172 ->
17:52:34.172 ->  EPD_loadALOAD
17:52:34.238 ->
17:52:34.238 ->  EPD_loadALOAD
17:52:34.506 ->
17:52:34.506 ->  EPD_loadALOAD
17:52:34.573 ->
17:52:34.573 ->  EPD_loadALOAD
17:52:34.640 ->
17:52:34.640 ->  EPD_loadALOAD
17:52:34.709 ->
17:52:34.709 ->  EPD_loadALOAD
17:52:34.814 ->
17:52:34.814 ->  EPD_loadALOAD
17:52:34.847 ->
17:52:34.847 ->  EPD_loadALOAD
17:52:34.915 ->
17:52:34.915 ->  EPD_loadALOAD
17:52:35.016 ->
17:52:35.016 ->  EPD_loadALOAD
17:52:35.052 ->
17:52:35.052 ->  EPD_loadALOAD
17:52:35.433 ->
17:52:35.433 ->  EPD_loadALOAD
17:52:35.501 ->
17:52:35.501 ->  EPD_loadALOAD
17:52:35.568 ->
17:52:35.568 ->  EPD_loadALOAD
17:52:35.634 ->
17:52:35.634 ->  EPD_loadALOAD
17:52:35.702 ->
17:52:35.702 ->  EPD_loadALOAD
17:52:35.769 ->
17:52:35.769 ->  EPD_loadALOAD
17:52:35.870 ->
17:52:35.870 ->  EPD_loadALOAD
17:52:35.937 ->
17:52:35.937 ->  EPD_loadALOAD
17:52:36.005 ->
17:52:36.005 ->  EPD_loadALOAD
17:52:36.073 ->
17:52:36.073 ->  EPD_loadALOAD
17:52:36.107 ->
17:52:36.107 ->  EPD_loadALOAD
17:52:36.176 ->
17:52:36.176 ->  EPD_loadALOAD
17:52:36.278 ->
17:52:36.278 ->  EPD_loadALOAD
17:52:36.346 ->
17:52:36.346 ->  EPD_loadALOAD
17:52:36.415 ->
17:52:36.415 ->  EPD_loadALOAD
17:52:36.449 ->
17:52:36.449 ->  EPD_loadANEXT
17:52:36.517 -> LOAD
17:52:36.517 ->
17:52:36.517 ->  EPD_loadALOAD
17:52:36.587 ->
17:52:36.587 ->  EPD_loadALOAD
17:52:36.657 ->
17:52:36.657 ->  EPD_loadALOAD
17:52:36.725 ->
17:52:36.725 ->  EPD_loadALOAD
17:52:36.794 ->
17:52:36.794 ->  EPD_loadALOAD
17:52:36.861 ->
17:52:36.861 ->  EPD_loadALOAD
17:52:36.929 ->
17:52:36.929 ->  EPD_loadALOAD
17:52:36.997 ->
17:52:36.997 ->  EPD_loadALOAD
17:52:37.069 ->
17:52:37.069 ->  EPD_loadALOAD
17:52:37.102 ->
17:52:37.102 ->  EPD_loadALOAD
17:52:37.206 ->
17:52:37.206 ->  EPD_loadALOAD
17:52:37.274 ->
17:52:37.274 ->  EPD_loadALOAD
17:52:37.344 ->
17:52:37.344 ->  EPD_loadALOAD
17:52:37.613 ->
17:52:37.613 ->  EPD_loadALOAD
17:52:37.681 ->
17:52:37.681 ->  EPD_loadALOAD
17:52:37.954 ->
17:52:37.954 ->  EPD_loadALOAD
17:52:38.021 ->
17:52:38.021 ->  EPD_loadALOAD
17:52:38.090 ->
17:52:38.090 ->  EPD_loadALOAD
17:52:38.164 ->
17:52:38.164 ->  EPD_loadALOAD
17:52:38.231 ->
17:52:38.231 ->  EPD_loadALOAD
17:52:38.299 ->
17:52:38.299 ->  EPD_loadALOAD
17:52:38.332 ->
17:52:38.332 ->  EPD_loadALOAD
17:52:38.400 ->
17:52:38.400 ->  EPD_loadALOAD
17:52:38.468 ->
17:52:38.468 ->  EPD_loadALOAD
17:52:38.537 ->
17:52:38.537 ->  EPD_loadALOAD
17:52:38.604 ->
17:52:38.604 ->  EPD_loadALOAD
17:52:38.675 ->
17:52:38.675 ->  EPD_loadALOAD
17:52:38.745 ->
17:52:38.745 ->  EPD_loadALOAD
17:52:38.813 ->
17:52:38.813 ->  EPD_loadALOAD
17:52:38.880 ->
17:52:38.880 ->  EPD_loadALOAD
17:52:38.947 ->
17:52:38.947 ->  EPD_loadALOAD
17:52:39.014 ->
17:52:39.014 ->  EPD_loadALOAD
17:52:39.049 ->
17:52:39.049 ->  EPD_loadALOAD
17:52:39.116 ->
17:52:39.116 ->  EPD_loadALOAD
17:52:39.184 ->
17:52:39.184 ->  EPD_loadALOAD
17:52:39.251 ->
17:52:39.251 ->  EPD_loadALOAD
17:52:39.320 ->
17:52:39.320 ->  EPD_loadALOAD
17:52:39.388 ->
17:52:39.388 ->  EPD_loadALOAD
17:52:39.454 ->
17:52:39.454 ->  EPD_loadALOAD
17:52:39.521 ->
17:52:39.521 ->  EPD_loadALOAD
17:52:39.589 ->
17:52:39.589 ->  EPD_loadALOAD
17:52:39.624 ->
17:52:39.624 ->  EPD_loadALOAD
17:52:39.693 ->
17:52:39.693 ->  EPD_loadALOAD
17:52:39.761 ->
17:52:39.761 ->  EPD_loadALOAD
17:52:39.829 ->
17:52:39.829 ->  EPD_loadALOAD
17:52:39.898 ->
17:52:39.898 ->  EPD_loadALOAD
17:52:39.966 ->
17:52:39.966 ->  EPD_loadALOAD
17:52:40.034 ->
17:52:40.034 ->  EPD_loadALOAD
17:52:40.101 ->
17:52:40.101 ->  EPD_loadALOAD
17:52:40.138 ->
17:52:40.138 ->  EPD_loadALOAD
17:52:40.209 ->
17:52:40.209 ->  EPD_loadALOAD
17:52:40.277 ->
17:52:40.277 ->  EPD_loadALOAD
17:52:40.346 ->
17:52:40.346 ->  EPD_loadALOAD
17:52:40.413 ->
17:52:40.413 ->  EPD_loadALOAD
17:52:40.481 ->
17:52:40.481 ->  EPD_loadALOAD
17:52:40.547 ->
17:52:40.547 ->  EPD_loadALOAD
17:52:40.615 ->
17:52:40.615 ->  EPD_loadALOAD
17:52:40.649 ->
17:52:40.649 ->  EPD_loadALOAD
17:52:40.750 ->
17:52:40.750 ->  EPD_loadALOAD
17:52:40.822 ->
17:52:40.822 ->  EPD_loadALOAD
17:52:40.890 ->
17:52:40.890 ->  EPD_loadALOAD
17:52:40.958 ->
17:52:40.958 ->  EPD_loadALOAD
17:52:41.029 ->
17:52:41.029 ->  EPD_loadALOAD
17:52:41.097 ->
17:52:41.097 ->  EPD_loadALOAD
17:52:41.164 ->
17:52:41.164 ->  EPD_loadALOAD
17:52:41.199 ->
17:52:41.199 ->  EPD_loadALOAD
17:52:41.301 ->
17:52:41.301 ->  EPD_loadALOAD
17:52:41.369 ->
17:52:41.369 ->  EPD_loadALOAD
17:52:41.438 ->
17:52:41.438 ->  EPD_loadALOAD
17:52:41.472 ->
17:52:41.472 ->  EPD_loadALOAD
17:52:41.540 ->
17:52:41.540 ->  EPD_loadALOAD
17:52:41.607 ->
17:52:41.607 ->  EPD_loadALOAD
17:52:41.673 ->
17:52:41.673 ->  EPD_loadALOAD
17:52:41.741 ->
17:52:41.741 ->  EPD_loadALOAD
17:52:41.809 ->
17:52:41.809 ->  EPD_loadALOAD
17:52:41.878 ->
17:52:41.878 ->  EPD_loadALOAD
17:52:41.946 ->
17:52:41.946 ->  EPD_loadALOAD
17:52:41.984 ->
17:52:41.984 ->  EPD_loadA
17:52:42.018 -> SHOW
17:52:42.018 ->
17:52:42.227 ->
17:52:42.227 -> e-Paper busy
17:53:03.840 -> e-Paper busy release
17:53:03.840 -> EPD_7IN5B_HD_Show END
17:53:03.840 ->
17:53:03.840 -> SHOW
17:53:03.840 ->
17:53:04.044 ->
17:53:04.044 -> e-Paper busy
17:53:25.722 -> e-Paper busy release
17:53:25.722 -> EPD_7IN5B_HD_Show END
17:53:27.731 ->
17:53:27.731 -> SHOW
17:53:27.731 ->
17:53:27.938 ->
17:53:27.938 -> e-Paper busy
17:53:49.611 -> e-Paper busy release
17:53:49.611 -> EPD_7IN5B_HD_Show END
17:53:51.609 ->
17:53:51.609 -> SHOW
17:53:51.609 ->
17:53:51.786 ->
17:53:51.786 -> e-Paper busy
17:54:13.451 -> e-Paper busy release
17:54:13.451 -> EPD_7IN5B_HD_Show END
17:54:15.461 ->
17:54:15.461 -> SHOW
17:54:15.461 ->
17:54:15.631 ->
17:54:15.631 -> e-Paper busy
17:54:37.273 -> e-Paper busy release
17:54:37.273 -> EPD_7IN5B_HD_Show END
17:54:39.300 ->
17:54:39.300 -> SHOW
17:54:39.300 ->
17:54:39.503 ->
17:54:39.503 -> e-Paper busy
17:55:01.134 -> e-Paper busy release
17:55:01.134 -> EPD_7IN5B_HD_Show END
17:55:03.116 ->
17:55:03.116 -> SHOW
17:55:03.116 ->
17:55:03.320 ->
17:55:03.320 -> e-Paper busy
17:55:24.989 -> e-Paper busy release
17:55:24.989 -> EPD_7IN5B_HD_Show END
17:55:26.993 ->
17:55:26.993 -> SHOW
17:55:26.993 ->
17:55:27.202 ->
17:55:27.202 -> e-Paper busy
17:55:48.815 -> e-Paper busy release
17:55:48.815 -> EPD_7IN5B_HD_Show END
17:55:50.809 ->
17:55:50.809 -> SHOW
17:55:50.809 ->
17:55:51.011 ->
17:55:51.011 -> e-Paper busy
17:56:12.666 -> e-Paper busy release
17:56:12.666 -> EPD_7IN5B_HD_Show END
17:56:14.673 ->
17:56:14.673 -> SHOW
17:56:14.673 ->
17:56:14.873 ->
17:56:14.873 -> e-Paper busy
17:56:36.553 -> e-Paper busy release
17:56:36.553 -> EPD_7IN5B_HD_Show END
17:56:38.575 ->
17:56:38.575 -> SHOW
17:56:38.575 ->
17:56:38.743 ->
17:56:38.743 -> e-Paper busy
17:57:00.428 -> e-Paper busy release
17:57:00.428 -> EPD_7IN5B_HD_Show END
17:57:02.456 ->
17:57:02.456 -> SHOW
17:57:02.456 ->
17:57:02.633 ->
17:57:02.633 -> e-Paper busy
17:57:24.314 -> e-Paper busy release
17:57:24.314 -> EPD_7IN5B_HD_Show END
17:57:26.340 ->
17:57:26.340 -> SHOW
17:57:26.340 ->
17:57:26.510 ->
17:57:26.510 -> e-Paper busy
17:57:48.200 -> e-Paper busy release
17:57:48.200 -> EPD_7IN5B_HD_Show END
17:57:50.212 ->
17:57:50.212 -> SHOW
17:57:50.212 ->
17:57:50.413 ->
17:57:50.413 -> e-Paper busy
17:58:12.053 -> e-Paper busy release
17:58:12.053 -> EPD_7IN5B_HD_Show END
17:58:14.054 ->
17:58:14.054 -> SHOW
17:58:14.054 ->
17:58:14.256 ->
17:58:14.256 -> e-Paper busy
17:58:35.913 -> e-Paper busy release
17:58:35.913 -> EPD_7IN5B_HD_Show END
17:58:37.889 ->
17:58:37.889 -> SHOW
17:58:37.889 ->
17:58:38.089 ->
17:58:38.089 -> e-Paper busy
17:58:59.760 -> e-Paper busy release
17:58:59.760 -> EPD_7IN5B_HD_Show END
17:59:01.775 ->
17:59:01.775 -> SHOW
17:59:01.775 ->
17:59:01.978 ->
17:59:01.978 -> e-Paper busy
17:59:23.593 -> e-Paper busy release
17:59:23.593 -> EPD_7IN5B_HD_Show END
17:59:25.596 ->
17:59:25.596 -> SHOW
17:59:25.596 ->
17:59:25.802 ->
17:59:25.802 -> e-Paper busy
17:59:47.501 -> e-Paper busy release
17:59:47.501 -> EPD_7IN5B_HD_Show END
17:59:49.514 ->
17:59:49.514 -> SHOW
17:59:49.514 ->
17:59:49.718 ->
17:59:49.718 -> e-Paper busy
18:00:11.392 -> e-Paper busy release
18:00:11.392 -> EPD_7IN5B_HD_Show END
18:00:13.391 ->
18:00:13.391 -> SHOW
18:00:13.391 ->
18:00:13.593 ->
18:00:13.593 -> e-Paper busy
18:00:35.224 -> e-Paper busy release
18:00:35.224 -> EPD_7IN5B_HD_Show END
18:00:37.228 ->
18:00:37.228 -> SHOW
18:00:37.228 ->
18:00:37.430 ->
18:00:37.430 -> e-Paper busy
18:00:59.122 -> e-Paper busy release
18:00:59.122 -> EPD_7IN5B_HD_Show END
18:01:01.120 ->
18:01:01.120 -> SHOW
18:01:01.120 ->
18:01:01.293 ->
18:01:01.293 -> e-Paper busy
18:01:22.956 -> e-Paper busy release
18:01:22.956 -> EPD_7IN5B_HD_Show END
18:01:24.941 ->
18:01:24.941 -> SHOW
18:01:24.941 ->
18:01:25.148 ->
18:01:25.148 -> e-Paper busy
18:01:46.789 -> e-Paper busy release
18:01:46.789 -> EPD_7IN5B_HD_Show END
18:01:48.808 ->
18:01:48.808 -> SHOW
18:01:48.808 ->
18:01:49.014 ->
18:01:49.014 -> e-Paper busy
18:02:10.630 -> e-Paper busy release
18:02:10.630 -> EPD_7IN5B_HD_Show END
18:02:12.656 ->
18:02:12.656 -> SHOW
18:02:12.656 ->
18:02:12.866 ->
18:02:12.866 -> e-Paper busy
18:02:34.498 -> e-Paper busy release
18:02:34.498 -> EPD_7IN5B_HD_Show END
18:02:36.514 ->
18:02:36.514 -> SHOW
18:02:36.514 ->
18:02:36.688 ->
18:02:36.688 -> e-Paper busy
18:02:58.373 -> e-Paper busy release
18:02:58.373 -> EPD_7IN5B_HD_Show END
18:03:00.355 ->
18:03:00.355 -> SHOW
18:03:00.355 ->
18:03:00.557 ->
18:03:00.557 -> e-Paper busy
18:03:22.220 -> e-Paper busy release
18:03:22.220 -> EPD_7IN5B_HD_Show END
18:03:24.223 ->
18:03:24.223 -> SHOW
18:03:24.223 ->
18:03:24.399 ->
18:03:24.399 -> e-Paper busy
18:03:46.103 -> e-Paper busy release
18:03:46.103 -> EPD_7IN5B_HD_Show END
18:03:48.077 ->
18:03:48.077 -> SHOW
18:03:48.077 ->
18:03:48.283 ->
18:03:48.283 -> e-Paper busy
18:04:09.938 -> e-Paper busy release
18:04:09.938 -> EPD_7IN5B_HD_Show END
18:04:11.929 ->
18:04:11.929 -> SHOW
18:04:11.929 ->
18:04:12.133 ->
18:04:12.133 -> e-Paper busy
18:04:33.748 -> e-Paper busy release
18:04:33.748 -> EPD_7IN5B_HD_Show END
18:04:35.754 ->
18:04:35.754 -> SHOW
18:04:35.754 ->
18:04:35.962 ->
18:04:35.962 -> e-Paper busy
18:04:57.625 -> e-Paper busy release
18:04:57.625 -> EPD_7IN5B_HD_Show END
18:04:59.619 ->
18:04:59.619 -> SHOW
18:04:59.619 ->
18:04:59.827 ->
18:04:59.827 -> e-Paper busy
18:05:21.464 -> e-Paper busy release
18:05:21.464 -> EPD_7IN5B_HD_Show END
18:05:23.471 ->
18:05:23.471 -> SHOW
18:05:23.471 ->
18:05:23.681 ->
18:05:23.681 -> e-Paper busy
18:05:45.322 -> e-Paper busy release
18:05:45.322 -> EPD_7IN5B_HD_Show END
18:05:47.326 ->
18:05:47.326 -> SHOW
18:05:47.326 ->
18:05:47.498 ->
18:05:47.498 -> e-Paper busy
18:06:09.138 -> e-Paper busy release
18:06:09.138 -> EPD_7IN5B_HD_Show END
18:06:11.158 ->
18:06:11.158 -> SHOW
18:06:11.158 ->
18:06:11.365 ->
18:06:11.365 -> e-Paper busy
18:06:32.976 -> e-Paper busy release
18:06:32.976 -> EPD_7IN5B_HD_Show END
18:06:34.975 ->
18:06:34.975 -> SHOW
18:06:34.975 ->
18:06:35.176 ->
18:06:35.176 -> e-Paper busy
18:06:56.856 -> e-Paper busy release
18:06:56.856 -> EPD_7IN5B_HD_Show END


Noch ein ergänzender Hinweis, das Bild was quasi unendlich hochgeladen wird ist immer das selbe. Auch wenn im Modul ein neues png erzeugt wird.

Kannst Du mal ein Listing Deines EInk Devices aus FHEM posten und, falls Logmeldungen kommen, auch die.

Edit: Habe das mal bei mir genauso versucht nachzustellen, da verhält sich FHEM wie erwartet (keine automatischen Wiederholungen).

Mach ich heute Abend gerne, welchen Sketch hast du denn auf dem ESP8266?

Kannst du mir deinen mal hier hochladen, dann könnte ich das schon mal als Fehlerquelle ausschließen.

Ich habe, weil ich aktuell kein entsprechendes Device habe (meins ist kaputt), einfach einen Dummy Webserver dagegen laufen lassen, der fristt einfach nur die POSTs und meldet OK zurück.

Wenn der übers Web erreichbar ist, könnte ich zum testen meine Posts in einem Zeitfenster auch mal da hin schicken.

Der ist lokal. Trage einfach mal 127.0.0.1:8083/fhem als url im Device ein, dann laufen die Daten auf den FHEM Webserver, das sollte zum Testen gehen.

Zitat von: eki am 20 August 2021, 07:01:52
Kannst Du mal ein Listing Deines EInk Devices aus FHEM posten und, falls Logmeldungen kommen, auch die.

Hier das Listing:

Internals:
   BOARDTYPE  ESP8266
   COLORMODE  color
   CONVERTMODE level
   DEF        /opt/fhem/www/images/custom/display_hd.png
   DEVICETYPE 7.5inch_e-Paper_HAT_(B)_HD
   FUUID      60840029-f33f-1248-e0e3-fe715672d3502017
   FVERSION   89_ESPEInk.pm:0.233970/2020-12-21
   INTERVAL   0
   NAME       ep_flur
   NOTIFYDEV  bd_rollo,ku_fenster,Steffen,elle,el_rollo,speak_volume,wz_rollo_links,wz_links,wz_rechts,rg_felix,el_tuer,ep_flur,bd_fenster,ku_rollo,wz_rollo_rechts,sz_rollo,wz_rollo_f,wz_tuer,ds_rollo,daylist,sz_tuer,wz_rollo,ds_tuer,global
   NR         344
   NTFY_ORDER 50-ep_flur
   PICTUREFILE /opt/fhem/www/images/custom/display_hd.png
   STATE      Error uploading image to device, max retries (0) reached
   SUBFOLDER  images
   TYPE       ESPEInk
   URL        192.168.23.76
   Helper:
     DBLOG:
       result_picture:
         DBLogging:
           TIME       1629497769.07276
           VALUE      <html><img src=/fhem/images/ep_flur/result.png?dummy=955740.955649642></img><div>/fhem/images/ep_flur/result.png</div></html>
       state:
         DBLogging:
           TIME       1629379928.38145
           VALUE      convert
       updatestart:
         DBLogging:
           TIME       1629497769.07932
           VALUE      1629497769.07864
   READINGS:
     2021-08-18 17:36:42   deftexts        0
     2021-08-21 00:16:09   result_picture  <html><img src=/fhem/images/ep_flur/result.png?dummy=955740.955649642></img><div>/fhem/images/ep_flur/result.png</div></html>
     2021-08-18 17:36:41   source_picture  <html><img src=/fhem/images/ep_flur/display_hd.png?dummy=808923.261242171></img><div>/fhem/images/ep_flur/display_hd.png</div></html>
     2021-08-21 00:16:09   updatestart     1629497769.07864
   helper:
Attributes:
   DbLogInclude .*
   boardtype  ESP8266
   colormode  color
   convertmode level
   definition addsymbol#line#0#50#81#0#FF0000#879#0
addsymbol#line#0#527#20#0#FF0000#879#0
addtext#Home Status Riedberg#260#15#24#0#ffffff#/usr/share/fonts/truetype/msttcorefonts/arialbd.ttf#0#0
addsymbol#rectangle#510#50#4#0#FF0000#367#50#0
addsymbol#rectangle#1#50#4#0#FF0000#260#460#0
           
iconreading#speak_volume:e_icon#500#150#40#0#000000

iconreading#elle:e_icon#800#120#40#0#000000
iconreading#Steffen:e_icon#800#170#40#0#000000
iconreading#rg_felix:e_icon#800#220#40#0#000000

addtext#Elle:#750#130#16#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
addtext#Steffen:#718#180#16#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
addtext#Felix:#740#230#16#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0

addtext#Heute ist:#525#65#16#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
textreading#daylist:state#620#65#16#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0

addtext#Schlafzimmer#10#68#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#sz_tuer:e_icon#145#60#40
iconreading#sz_rollo:e_icon#190#60#40

addtext#Zimmer Elle#10#118#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#el_tuer:e_icon#145#110#40
iconreading#el_rollo:e_icon#190#110#40

addtext#Duschbad#10#168#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#ds_tuer:e_icon#145#160#40
iconreading#ds_rollo:e_icon#190#160#40

addtext#Badezimmer#10#218#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#bd_fenster:e_icon#140#210#40
iconreading#bd_rollo:e_icon#190#210#40

addtext#Küche#10#268#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#ku_fenster:e_icon#140#260#40
iconreading#ku_rollo:e_icon#190#260#40

addtext#Wohnzimmer#10#318#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_tuer:e_icon#145#310#40
iconreading#wz_rollo:e_icon#190#310#40

addtext#Wohnz. Fenster#10#368#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_rollo_f:e_icon#190#360#40

addtext#Wohnz. links#10#418#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_links:e_icon#140#410#40
iconreading#wz_rollo_links:e_icon#190#410#40

addtext#Wohnz. rechts#10#468#14#0#000000#/usr/share/fonts/truetype/msttcorefonts/arial.ttf#0#0
iconreading#wz_rechts:e_icon#140#460#40
iconreading#wz_rollo_rechts:e_icon#190#460#40
   devicetype 7.5inch_e-Paper_HAT_(B)_HD
   interval   0
   maxretries 0
   mininterval 60
   room       03 LED Panel
   url        192.168.23.76

Im Event Monitor gibt es folgende Einträge:


2021-08-21 00:46:01 ESPEInk ep_flur updatestart: 1629499561.94323
dummy=188740.374623709></img><div>/fhem/images/epaper_klein/result.png</div></html>
2021-08-21 00:46:01 ESPEInk ep_flur updatestart: 1629499561.94323
2021-08-21 00:47:11 ESPEInk ep_flur updatestart: 1629499631.6928
2021-08-21 00:48:14 ESPEInk ep_flur updatestart: 1629499694.24449
2021-08-21 00:49:12 ESPEInk ep_flur upload
2021-08-21 00:49:34 ESPEInk ep_flur updatestart: 1629499774.39812
2021-08-21 00:50:15 ESPEInk ep_flur convert
2021-08-21 00:50:23 ESPEInk ep_flur result_picture: <html><img src=/fhem/images/ep_flur/result.png?dummy=697587.579341924></img><div>/fhem/images/ep_flur/result.png</div></html>
2021-08-21 00:50:30 ESPEInk ep_flur upload
2021-08-21 00:50:48 ESPEInk ep_flur updatestart: 1629499848.64535


Sorry wenn ich ein wenig verzweifelt klinge aber ich komme einfach nicht weiter... Dieser ESP8266 macht mich echt fertig. (Der ESP32 erste recht)

- Mit der Waveshare Original Software und dem Standard ESPInk Modul bekomme ich im Grunde nur Schrott auf das Display. Mit dem ESPink Modul von EKI (Danke :))mit dem Attr. mininterval sieht die Anzeige 1A aus, allerdings aktualisiert sie sich endlos.

- Die Software von Yattien konnte ich genau einmal konfigurieren. Egal was ich zwischendurch auf den ESP spiele sobald ich die Yattien Software drauf spiele, zieht er sich von irgendwoher die Daten für das WLAN und den MQTT Server den die ich mal zum testen eingegeben habe. Somit komme ich nicht dazu den Workaround über MQTT aufzubauen. Auch mit /reset komme bekomme ich das Teil nicht zurückgesetzt.

Ich habe keine Idee mehr.. Ich verstehe diese ESP Teile einfach nicht. Ich hab auch einen "Reset Sketch" versucht, der macht aber gefühlt auch nicht mehr wie wenn ich kurz die Spannung abziehe.

Also ich habe mich schon zu anderen Themen immer erfolgreich durch Google und YouTube gewühlt aber hier bin ich echt am verzweifeln. Zumal viele Beiträge schon viele Jahre alt sind.  So langsam glaube ich das es eine Schnapsidee war, von einer LED Anzeige auf e-Paper umsteigen zu wollen....

Ich wäre echt für ein paar Tipps dankbar ... ::)

Jetzt bin ich auf ein weiteres Problem gestoßen, das ich mir nicht erklären kann.

Um auf den E-Paper Zustände per ICONS darstellen zu können, generiere ich über Userreadings in dem entsprechenden Device ein Reading "e_icon" in dem der Name des svg Icons steht. Das klappt mit den in FHEM eingebauten ICONs wunderbar. Ich habe aber auch ein paar Icons die ich mit Inkscape selbst gemalt habe. Die eignen Icons werden auch anstandslos in FHEM angezeigt. ESPInk kommt damit aber gar nicht klar. Entweder wird das Icon der letzen "iconreading" Zeile angezeigt oder der "FHEM-Smilie".

Hat denn jemand schon mal eigene Icons über den Weg aufs ePaper bekommen?

Zitat von: Borkk am 22 August 2021, 11:33:03
Um auf den E-Paper Zustände per ICONS darstellen zu können, generiere ich über Userreadings in dem entsprechenden Device ein Reading "e_icon" in dem der Name des svg Icons steht. Das klappt mit den in FHEM eingebauten ICONs wunderbar. Ich habe aber auch ein paar Icons die ich mit Inkscape selbst gemalt habe. Die eignen Icons werden auch anstandslos in FHEM angezeigt. ESPInk kommt damit aber gar nicht klar. Entweder wird das Icon der letzen "iconreading" Zeile angezeigt oder der "FHEM-Smilie".

Hat denn jemand schon mal eigene Icons über den Weg aufs ePaper bekommen?

Eigene Icons funktionieren prinzipiell und habe ich auch so im Einsatz. Ohne jetzt eine konkrete Lösung für dich zu haben, habe ich mich erinnert, dass das in diesem Thread schon mal diskutiert wurde. Schau mal um diesen Post (https://forum.fhem.de/index.php/topic,104171.msg1097576/topicseen.html#msg1097576) herum, vllt. hilft es dir.

HTH

Zitat von: Jendaw am 22 August 2021, 11:38:05
Eigene Icons funktionieren prinzipiell und habe ich auch so im Einsatz. Ohne jetzt eine konkrete Lösung für dich zu haben, habe ich mich erinnert, dass das in diesem Thread schon mal diskutiert wurde. Schau mal um diesen Post (https://forum.fhem.de/index.php/topic,104171.msg1097576/topicseen.html#msg1097576) herum, vllt. hilft es dir.

HTH

Das mit mit dem Modpath usw. kenne ich. Die eigene SVG Icons funktionieren in FHEM auch einwandfrei. Nur ESPInk kommt scheinbar nicht damit klar. Man braucht nur ein Standard Icon mit Inkscape öffnen und unverändert wieder speichern, dann ist es für ESPInk tot.

Eben bin ich auf weiteres Problem gestoßen. Im Gegensatz zu "addsymbol" oder "addtext" wird die Angabe einer Farbe bei "iconreading" ignoriert. Icons werden immer schwarz dargestellt auch wenn ich z.B. ff0000 für rot eintrage.

Vielleicht liegt es auch an meiner grundsätzlichen Installation? Ich habe 2 FHEM Instanzen auf Docker laufen. Meine eigenen Icons liegen z.B. unter ./www/images/custom/ den Ordner habe ich über Docker auf den Host gemappt. Wie man das halt so macht und es funktioniert auch einwandfrei. Den Ordner habe ich natürlich in FHEMWEB bekannt gemacht.

@Eki: nicht das du denkt ich nörgle an deinem super Modul rum. Ich glaube nur es hat schon noch ein paar größere issues. Die zuletzt von mir genanten Punkte habe ich gar nicht in Verbindung mit dem Display festgestellt, sondern schon beim generieren des PNG Files.

Zitat von: Borkk am 22 August 2021, 12:21:43
Das mit mit dem Modpath usw. kenne ich. Die eigene SVG Icons funktionieren in FHEM auch einwandfrei. Nur ESPInk kommt scheinbar nicht damit klar. Man braucht nur ein Standard Icon mit Inkscape öffnen und unverändert wieder speichern, dann ist es für ESPInk tot.

Ich hatte auch ein Problem mit Inkscape. FHEM wollte meine geänderten SVGs nicht anzeigen. In einem zweiten Versuch habe ich dann die Änderungen sehr "einfach" gehalten und damit lief es dann in FHEM. Ich vermute daher, dass es vielleicht ein Problem mit der "Umwandlung in Pfade" in Inkscape sein könnte. Allerdings habe ich nicht getestet, ob meine geänderten SVGs in ESPInk dargestellt werden können.

Im WIKI finde ich dazu noch: 'das gesamte Bild muss als "Normales SVG" gespeichert werden (Standardeinstellung bei Inkscape ist "Inkscape SVG")'. Vielleicht hängt es bei dir damit zusammen.

Ich hatte in meinem Source-pic anfangs auch ein rotes Rechteck (ff0000) eingefügt. ESPInk konnte das dann aber nicht (in rot) darstellen. So muss der PI das Rechteck leider jedes Mal berechnen, was leider auch noch zu einem anderen Fehler (s. Beitrag #270) führt.  Der ESPInk erwartet offenbar Parameter für solide oder gestrichelte Linien usw. in $s1 und $s2.

Hallo Hajo23,

ja so ähnlich wie du es aufgebaut hast möchte ich es auch machen. Die Temperatur und Humidity Werte zieht du aber über einen Dummy, oder. Ich hatte das auch erst vor aber die direkten Werte aus den Sensoren werden zu oft neu geschrieben. Oder hast die einen festen Intervall eingestellt?

Das mit Inkscape und dem "normalen svg" hatte ich gelesen und auch beachtet. Wie gesagt in FHEM machen die Icons keine Probleme. Sie werden sauber angezeigt un lassen sich mit z.B. "@red" auch einfärben.

Was für einen ESP und Sketch nutzt du?

Versuch doch bitte mal eines deiner Fenster Icons in rot darzustellen, so wie dein Sonnenaufgang und Sonnenuntergangs Icon.

Für meine Übersicht habe mir zwei "DOIF-Kollektoren" angelegt. Alle 5 Minuten werden dort die Readings erzeugt, die ich direkt in ESPInk verwenden möchte. Das sieht z.B. für Rolladen und Lampen so aus:

{ [+:05];
  my $T = POSIX::strftime('%H:%M', localtime);
  my $D = POSIX::strftime('%a, %e. %b %Y', localtime);
  my %EinkDevState =  ( on  => 'light_light_dim_100', off => '');
  my %Shutter = (0 => 'fts_window_2w', 10 => 'fts_garage_door_10', 20 => 'fts_garage_door_20', 30 => 'fts_garage_door_30', 40 => 'fts_garage_door_40', 50 => 'fts_garage_door_50', 60 => 'fts_garage_door_60', 70 => 'fts_garage_door_70', 80 => 'fts_garage_door_80', 90 => 'fts_garage_door_90', 100 => 'fts_garage_door_100');
  my %ShutterSw = (off => 'fts_shutter_manual', always => 'fts_shutter_automatic', absent => 'fts_shutter_manual', home => 'fts_shutter_manual');
  set_Reading_Begin;
    set_Reading_Update("Time",$T);
set_Reading_Update("Date",$D);
    set_Reading_Update("R_Ankleidezimmer", $Shutter{ReadingsVal("R_Ankleidezimmer","pct",0)});
set_Reading_Update("R_Ankleidezimmer_Up", $ShutterSw{AttrVal("R_Ankleidezimmer","ASC_Mode_Up",0)});
set_Reading_Update("R_Ankleidezimmer_Down", $ShutterSw{AttrVal("R_Ankleidezimmer","ASC_Mode_Down",0)});
set_Reading_Update("R_Wohnzimmer", $Shutter{ReadingsVal("R_Wohnzimmer","pct",0)});
set_Reading_Update("R_Wohnzimmer_Up", $ShutterSw{AttrVal("R_Wohnzimmer","ASC_Mode_Up",0)});
set_Reading_Update("R_Wohnzimmer_Down", $ShutterSw{AttrVal("R_Wohnzimmer","ASC_Mode_Down",0)});
set_Reading_Update("R_Kueche", $Shutter{ReadingsVal("R_Kueche","pct",0)});
set_Reading_Update("R_Kueche_Up", $ShutterSw{AttrVal("R_Kueche","ASC_Mode_Up",0)});
set_Reading_Update("R_Kueche_Down", $ShutterSw{AttrVal("R_Kueche","ASC_Mode_Down",0)});
set_Reading_Update("R_WC", $Shutter{ReadingsVal("R_WC","pct",0)});
set_Reading_Update("R_WC_Up", $ShutterSw{AttrVal("R_WC","ASC_Mode_Up",0)});
set_Reading_Update("R_WC_Down", $ShutterSw{AttrVal("R_WC","ASC_Mode_Down",0)});
set_Reading_Update("R_HWR", $Shutter{ReadingsVal("R_HWR","pct",0)});
set_Reading_Update("R_HWR_Up", $ShutterSw{AttrVal("R_HWR","ASC_Mode_Up",0)});
set_Reading_Update("R_HWR_Down", $ShutterSw{AttrVal("R_HWR","ASC_Mode_Down",0)});
set_Reading_Update("R_Buero", $Shutter{ReadingsVal("R_Buero","pct",0)});
set_Reading_Update("R_Buero_Up", $ShutterSw{AttrVal("R_Buero","ASC_Mode_Up",0)});
set_Reading_Update("R_Buero_Down", $ShutterSw{AttrVal("R_Buero","ASC_Mode_Up",0)});
set_Reading_Update("R_Bibliothek", $Shutter{ReadingsVal("R_Bibliothek","pct",0)});
set_Reading_Update("R_Bibliothek_Up", $ShutterSw{AttrVal("R_Bibliothek","ASC_Mode_Up",0)});
set_Reading_Update("R_Bibliothek_Down", $ShutterSw{AttrVal("R_Bibliothek","ASC_Mode_Down",0)});
set_Reading_Update("R_Bad", $Shutter{ReadingsVal("R_Bad","pct",0)});
set_Reading_Update("R_Bad_Up", $ShutterSw{AttrVal("R_Bad","ASC_Mode_Up",0)});
set_Reading_Update("R_Bad_Down", $ShutterSw{AttrVal("R_Bad","ASC_Mode_Down",0)});
set_Reading_Update("R_Schlafzimmer", $Shutter{ReadingsVal("R_Schlafzimmer","pct",0)});
set_Reading_Update("R_Schlafzimmer_Up", $ShutterSw{AttrVal("R_Schlafzimmer","ASC_Mode_Up",0)});
set_Reading_Update("R_Schlafzimmer_Down", $ShutterSw{AttrVal("R_Schlafzimmer","ASC_Mode_Down",0)});
set_Reading_Update("BueroTischLampe",$EinkDevState{ReadingsVal("BueroTischLampe","state",0)});
set_Reading_Update("BueroTischStrahler",$EinkDevState{ReadingsVal("BueroTischStrahler","state",0)});
set_Reading_Update("BuerodeckenStrahler",$EinkDevState{ReadingsVal("BuerodeckenStrahler","state",0)});
set_Reading_Update("Ankleideschrank",$EinkDevState{ReadingsVal("AnkleideDose","state",0)});
set_Reading_Update("AnkleideStrahler",$EinkDevState{ReadingsVal("AnkleideStrahler","state",0)});
set_Reading_Update("AussenNord",$EinkDevState{ReadingsVal("AussenNord","state",0)});
set_Reading_Update("AussenOst",$EinkDevState{ReadingsVal("AussenOst","state",0)});
set_Reading_Update("AussenSued",$EinkDevState{ReadingsVal("AussenSued","state",0)});
set_Reading_Update("AussenWest",$EinkDevState{ReadingsVal("AussenWest","state",0)});
set_Reading_Update("BadStrahler",$EinkDevState{ReadingsVal("BadStrahler","state",0)});
set_Reading_Update("BibliothekLampe",$EinkDevState{ReadingsVal("BibliothekLampe","state",0)});
set_Reading_Update("BibliothekStrahler",$EinkDevState{ReadingsVal("BibliothekStrahler","state",0)});
set_Reading_Update("EsszimmerAnrichte",$EinkDevState{ReadingsVal("EsszimmerAnrichte","state",0)});
set_Reading_Update("EsszimmerLampe",$EinkDevState{ReadingsVal("EsszimmerLampe","state",0)});
set_Reading_Update("EsszimmerStrahler",$EinkDevState{ReadingsVal("EsszimmerStrahler","state",0)});
set_Reading_Update("Globus",$EinkDevState{ReadingsVal("HS100_WLAN4","state",0)});
set_Reading_Update("HWR",$EinkDevState{ReadingsVal("HWR","state",0)});
set_Reading_Update("KuechePlatte",$EinkDevState{ReadingsVal("KuechePlatte","state",0)});
set_Reading_Update("KuecheStrahler",$EinkDevState{ReadingsVal("KuecheStrahler","state",0)});
set_Reading_Update("KuecheTisch",$EinkDevState{ReadingsVal("KuecheTisch","state",0)});
set_Reading_Update("SchlafzimmerBettLinks",$EinkDevState{ReadingsVal("SchlafzimmerBettLinks","state",0)});
set_Reading_Update("SchlafzimmerBettRechts",$EinkDevState{ReadingsVal("SchlafzimmerBettRechts","state",0)});
set_Reading_Update("SchlafzimmerDeckenStrahler",$EinkDevState{ReadingsVal("SchlafzimmerDeckenStrahler","state",0)});
set_Reading_Update("Terrasse",$EinkDevState{ReadingsVal("Terrasse","state",0)});
    set_Reading_Update("WindfangLampe",$EinkDevState{ReadingsVal("WindfangLampe","state",0)});
    set_Reading_Update("FlurStrahler",$EinkDevState{ReadingsVal("FlurStrahler","state",0)});
set_Reading_Update("WC_Deckenstrahler",$EinkDevState{ReadingsVal("WC_Deckenstrahler","state",0)});
set_Reading_Update("WohnzimmerStehlampe",$EinkDevState{ReadingsVal("WohnzimerDose3","state",0)});
set_Reading_Update("WohnzimmerSchirmlampe",$EinkDevState{ReadingsVal("WohnzimerDose4","state",0)});
set_Reading_Update("WohnzimmerBaum",$EinkDevState{ReadingsVal("WohnzimerDose5","state",0)});
set_Reading_Update("WohnzimmerStrahler1",$EinkDevState{ReadingsVal("WohnzimmerStrahler1","state",0)});
set_Reading_Update("WohnzimmerHifi",$EinkDevState{ReadingsVal("WohnzimmerStrahler2","state",0)});
set_Reading_Update("WohnzimmerTank",$EinkDevState{ReadingsVal("WohnzimmerTank","state",0)});
  set_Reading_End(1);
}

Ich habe einen ESP8266 mit V17 im Einsatz. Die Kombi läuft völlig stabil. Das eine oder andere Problemchen habe ich nur mit dem ESPInk. Ich habe daher ESPInk aus dem fhem-update herausgenommen um ein paar individuelle Anpassungen zu behalten bzw. testen zu können. Z.B. ist mein 7,5" HD nur als B&W in der Displayliste. Nach einem Neustart würde der colormode immer wieder ausgeschaltet werden.

Testergebnis folgt später.

Zitat von: hajo23 am 22 August 2021, 15:39:45
Ich habe einen ESP8266 mit V17 im Einsatz. Die Kombi läuft völlig stabil. Das eine oder andere Problemchen habe ich nur mit dem ESPInk. Ich habe daher ESPInk aus dem fhem-update herausgenommen um ein paar individuelle Anpassungen zu behalten bzw. testen zu können. Z.B. ist mein 7,5" HD nur als B&W in der Displayliste. Nach einem Neustart würde der colormode immer wieder ausgeschaltet werden.

Testergebnis folgt später.

Danke für deinen doch recht umfangreichen Code  ::), d.h. du nutzt die Version von Yattien aber ohne MQTT?

Zitat von: Borkk am 22 August 2021, 16:12:17
Danke für deinen doch recht umfangreichen Code  ::), d.h. du nutzt die Version von Yattien aber ohne MQTT?

Der Code ist umfangreich, aber einfach und viel copy und paste. Mir war dabei wichtig, dass ich meinen Readings für die Darstellung auf dem e-paper optimierte (andere) Symbole zuweisen kann, als in fhem-web.

Ich nutzte die Version von Yattien mit MQTT. Ist ab Beitrag #270 nachzulesen.

Ich kann dir nun bestätigen, dass auch meine rote Test-SVG-Lampe in schwarz dargestellt wird. Hatte zunächst meine Displayeinstellung in Verdacht. 7,5" (B) HD ist aber rot, schwarz, weiß und damit richtig. Allerdings weiß ich noch nicht, weshalb sich bei mir trotzdem der colormode beim Neustart abschalten möchte.

Zitat von: Borkk am 22 August 2021, 00:11:46
- Die Software von Yattien konnte ich genau einmal konfigurieren. Egal was ich zwischendurch auf den ESP spiele sobald ich die Yattien Software drauf spiele, zieht er sich von irgendwoher die Daten für das WLAN und den MQTT Server den die ich mal zum testen eingegeben habe. Somit komme ich nicht dazu den Workaround über MQTT aufzubauen. Auch mit /reset komme bekomme ich das Teil nicht zurückgesetzt.

Ich weiß nicht, ob die Forensoftware dich über das "Entführen" deiner Antwort benachrichtigt hat, vermutlich nicht. Zu obiger Frage gibt es hier (https://forum.fhem.de/index.php/topic,109690.msg1171238.html#msg1171238) eine Antwort.

VG

Nein ich habe keine Nachricht bekommen aber danke fürs "Entführen". Den Thread hatte ich auch schon mal gesehen aber nicht Beitrag für Beitrag gelesen. Das ganze Projekt hängt an so vielen Stellen, das ich gar nicht mehr weiss wo ich zuerst anfangen soll. Mir scheint aber das alle die hier eine lauffähige Installation betreiben, den Weg über MQTT gehen und das ESPInk Modul nur zum generieren des PNG nutzen.

Ich konnte jetzt die Yattien Firmware zurücksetzen und werde erst mal einen sauberen Weg über MQTT bauen. Eigentlich schade, die Idee von eki ist eigentlich ganz gut, läuft aber offenbar noch nicht ganz rund.


 

Zitat von: Borkk am 22 August 2021, 18:29:37
Den Thread hatte ich auch schon mal gesehen aber nicht Beitrag für Beitrag gelesen. Das ganze Projekt hängt an so vielen Stellen, das ich gar nicht mehr weiss wo ich zuerst anfangen soll. Mir scheint aber das alle die hier eine lauffähige Installation betreiben, den Weg über MQTT gehen und das ESPInk Modul nur zum generieren des PNG nutzen.

:) Ist in der Tat recht umfangreich. Es gibt auch so viele Displays und ESP-Boards, dass es unübersichtlich ist. Ich nutze bspw. einen wemos D1, das Original-Waveshare-Board ist ein NodeMCU. Dann gibt es noch Probleme mit WLAN-Verbindungen (daher der Versuch mit dem WiFi-Manager), Sleep-Modes usw. Und dann sind die Darstellungswünsche auch noch verschieden - wie oft soll aktualisiert, was soll in wievielen Farben dargestellt werden...

Zitat
Ich konnte jetzt die Yattien Firmware zurücksetzen und werde erst mal einen sauberen Weg über MQTT bauen. Eigentlich schade, die Idee von eki ist eigentlich ganz gut, läuft aber offenbar noch nicht ganz rund.

Den Punkt verstehe ich nicht ganz. Falls du die Yattien-Fw nutzt, wird ja auch das Modul von eki als Gegenstelle genutzt. Oder was meinst du? Es läuft, hat man es einmal hinbekommen, mit der Original-Fw ganz gut. Vermutlich muss man step by step vorgehen - eine richtige Vorgehensweise habe ich allerdings auch noch nicht finden können. Dazu beschäftige ich mich zu wenig damit, weil es bei mir seit ein paar Monaten super läuft :)

Eine Übersicht, wie das mit dem MQTT funktionieren kann, findet man bspw. in diesem Blogpost (https://cohob.de/fhem-waveshare-e-ink-display-mit-mqtt-und-deep-sleep-einbinden).

Zitat von: Borkk am 22 August 2021, 12:21:43
Das mit mit dem Modpath usw. kenne ich. Die eigene SVG Icons funktionieren in FHEM auch einwandfrei. Nur ESPInk kommt scheinbar nicht damit klar. Man braucht nur ein Standard Icon mit Inkscape öffnen und unverändert wieder speichern, dann ist es für ESPInk tot.

Eben bin ich auf weiteres Problem gestoßen. Im Gegensatz zu "addsymbol" oder "addtext" wird die Angabe einer Farbe bei "iconreading" ignoriert. Icons werden immer schwarz dargestellt auch wenn ich z.B. ff0000 für rot eintrage.

Vielleicht liegt es auch an meiner grundsätzlichen Installation? Ich habe 2 FHEM Instanzen auf Docker laufen. Meine eigenen Icons liegen z.B. unter ./www/images/custom/ den Ordner habe ich über Docker auf den Host gemappt. Wie man das halt so macht und es funktioniert auch einwandfrei. Den Ordner habe ich natürlich in FHEMWEB bekannt gemacht.

@Eki: nicht das du denkt ich nörgle an deinem super Modul rum. Ich glaube nur es hat schon noch ein paar größere issues. Die zuletzt von mir genanten Punkte habe ich gar nicht in Verbindung mit dem Display festgestellt, sondern schon beim generieren des PNG Files.

Wenn jemand Fehler findet, freue ich mich erst mal, dass er mein Modul überhaupt benutzt, und mache mich dran die zu beseitigen  ;).

Das mit den SVGs ist so ne Sache, ich nutze im Modul zum lesen der SVGs eine Perl SVG Lib, eventuell kommt die ja nicht mit allen SVG Files zurecht. Kannst Du mal ein Beispiel eines nicht verarbeiteten SVGs posten, dann schau ich mir das mal an. Bezüglich der Farbe muss ich mal schauen, ob ich das Umwandeln der Farben für Icons überhaupt schon drin habe  ???. Ich schau mir auch das an.

Zitat von: eki am 22 August 2021, 18:53:34
Wenn jemand Fehler findet, freue ich mich erst mal, dass er mein Modul überhaupt benutzt, und mache mich dran die zu beseitigen  ;).

Das mit den SVGs ist so ne Sache, ich nutze im Modul zum lesen der SVGs eine Perl SVG Lib, eventuell kommt die ja nicht mit allen SVG Files zurecht. Kannst Du mal ein Beispiel eines nicht verarbeiteten SVGs posten, dann schau ich mir das mal an. Bezüglich der Farbe muss ich mal schauen, ob ich das Umwandeln der Farben für Icons überhaupt schon drin habe  ???. Ich schau mir auch das an.

Ich hätte da einen Wunsch. Wenn der String für das svg leer ist, dann einfach weiterspringen. Habe das bei mir so geändert:
sub ESPEInk_AddObjects($$) {
my ($name, $image) = @_;
my ($r,$g,$b);
my $color;
my $font;
my $deftexts = ReadingsVal($name,"deftexts",0);
my $angle;
my $icon_img = undef;
my $rsvg = undef;
    my $hash = $defs{$name};
my $rootname;
my $outfile;

my $definition = AttrVal($name,"definition",undef);
my $definitionFile = AttrVal($name,"definitionFile",undef);

if ($definitionFile) {
my ($error, @content) = FileRead({FileName=>$definitionFile, ForceType=>"file"});

if (!$error) {
$definition .= "\n" . (join("\n", @content));
} else {
Log3 $hash, 1, "Error ($error) reading definition from file $definitionFile";
}
}

if ($definition) { # work on all definitions if definition attribute is defined
foreach my $line (split(/\n/,$definition)) { # go through the definition line by line
next if ($line =~ /^\s*\#.*/); # check for comment lines
my ($type, $text, $x, $y, $size, $ang, $col, $fnt,$linegap,$blockwidth,$docolor);
$type = undef;
$text = undef;
($type, $text, $x, $y, $size, $ang, $col, $fnt, $linegap, $blockwidth) = split("#",$line);
$linegap = int($linegap) if ($linegap);
$blockwidth = int($blockwidth) if ($blockwidth);

next if (!defined $type);
next if (!defined $text);

$x = 0 if (!$x || (($x !~ '-?\d+')&&($x !~ '(left|mid|right)')));
$y = 0 if (!$y || (($y !~ '-?\d+')&&($y !~ '(top|mid|bottom)')));
$size = 10 if (!$size || ($size !~ '-?\d+'));
$ang = 0 if (!$ang || ($ang !~ '-?\d+'));
$docolor = $col?1:0;
$col = "000000" if (!$col || !ESPEInk_CheckColorString($col));
$fnt = "medium" if (!ESPEInk_CheckFontString($fnt) && $type ne "addsymbol");
$angle = $ang/180*(4*atan2(1,1));
$color = $col;

if ($type eq "iconreading" || $type eq "textreading") {
my $eval=0;
($text,$eval) = split("{",$text);
my ($device,$reading) = split(':',$text,2);
$reading = "state" if (!$reading);
$text = ReadingsVal($device,$reading,'');
                next if (($type eq 'iconreading') && (length($text) == 0)); # hajo: skip empty string
...



Viele default-Zustände (z.B. eine Lampe) sind schon im source-pic und müssen daher nur nach dem Einschalten berechnet werden. Für den default-Zustand übergebe ich deshalb einen leeren String.

Ein Schnellschuss zur SVG-Farbe:
In dieser Zeile soll wohl die Pixelfarbe auf $color gesetzt werden, soweit ich es verstehe. In $color steht der Farbwert aus dem iconreading.
Der Farbwert für schwarz im svg sollte doch 0,0,0 sein. $color wird hier aber nur gesetzt, wenn das Original-Pixel nicht schwarz ist und jeder rgb-Wert > 0 ist. Nach meinem Verständnis wäre das für ff0000 verkehrt.
$icon_img->setPixel($ix,$iy,$color) if ($r>0 && $g>0 && $b>0); # set color to given color if original color is black

so müsste es eigentlich richtig sein:

($r,$g,$b) = $icon_img->rgb($icon_img->getPixel($ix,$iy)); # get color values in source file
$icon_img->setPixel($ix,$iy,$color) if ($r==0 && $g==0 && $b==0 && $color>0); # set color to given color if original color is black

es liefert aber mit ff0000 nur ein rotes Kästchen, weil getPixel davor aus dem konvertierten svg (svg>png) aus irgendeinem Grund nur schwarze Pixel zurückgibt.

Ein paar kleine Fehler würden mich nicht davon abhalten dein Modul zu nutzen.  :)

Vielen Dank dafür!
HaJo