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

[Borkk]

Dann ist das die aktuelle Version (erkenne ich daran, weil ich dieses Display verwende und diese Änderung nur in der aktuellen Version vorhanden ist).
Exakt. Meiner Meinung nach muss in diese Datei in die Funktion EPD_7IN5_HD_Show() als letzte Zeile die nachfolgende eingetragen werden:

Code: [Auswählen]

EPD_Send_1(0X10, 0X01); //deep sleep

Sieht dann so aus:

Code: [Auswählen]

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");
    EPD_Send_1(0X10, 0X01); //deep sleep
}

Allerdings ohne Gewähr - ich habe das Display nicht und kann es nicht testen. Falls du es testest und bei dir funktioniert es, würde ich mich über ein Feedback freuen und es auch in die Yattien-Firmware einbauen.

HTH

Hallo Jendaw,

Ich habe folgende Änderungen in epd7in5_HD.h vorgenommen:

Code: [Auswählen]

static void EPD_7IN5B_HD_Show(void)
{
    EPD_SendCommand(0x22);
    EPD_SendData(0xC7);
    EPD_SendCommand(0x20);
    delay(200);
    EPD_7IN5_HD_Readbusy();
    Serial.print("EPD_7IN5B_HD_Show END\r\n");
}
in

Code: [Auswählen]

static void EPD_7IN5B_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");
    EPD_Send_1(0X10, 0X01); //deep sleep
}
Der Fehler

Code: [Auswählen]

2022.01.02 16:23:33 1: ep_flur: problems with communication to device, max retries (0) reached
am Ende der Übertragung kommt weiterhin und leider ist die Darstellung nicht korrekt.

[m.zielinski]

Heureka - nach endlosen Fragen, Suchen, Probieren habe ich endlich den Grund gefunden, warum ich keine Icons anzeigen konnte - bzw warum sie ,wenn überhaupt, als gefüllte Rechtecke angezeigt wurden:

Es lag an der Background.PNG nachdem ich eine neue mit xGIMP(Android) erzeugt habe funktionieren nun auch Icons wie gewünscht.
ich hänge hier mal die beiden PNGs an:
displayBackground.png ist die defekte
displayBackground3.png funktioniert

[Jendaw]

Ich habe folgende Änderungen in epd7in5_HD.h vorgenommen:
...
Der Fehler

Code: [Auswählen]

2022.01.02 16:23:33 1: ep_flur: problems with communication to device, max retries (0) reached
am Ende der Übertragung kommt weiterhin und leider ist die Darstellung nicht korrekt.

Diese Änderung soll gegen das Einfrieren des ESP nach einigen Tagen helfen.

Ich schätze, die Übertragungsfehler müssen im FHEM-Module ESPEink gefixt werden. Ich vermisse dort für dein Display den korrekten Typen, imo müsste es "7.5inch_e-Paper_HD" sein, es gibt jedoch nur die B-Version zur Auswahl. Das hatte sich in der Firmware zwischenzeitlich mal geändert (B wurde in die normale Version integriert) - evtl. ist das bereits die Ursache. Müsste sich @eki mal anschauen.
edit Hab nicht richtig gelesen.

[Jendaw]

Heureka - nach endlosen Fragen, Suchen, Probieren habe ich endlich den Grund gefunden, warum ich keine Icons anzeigen konnte - bzw warum sie ,wenn überhaupt, als gefüllte Rechtecke angezeigt wurden:

Es lag an der Background.PNG nachdem ich eine neue mit xGIMP(Android) erzeugt habe funktionieren nun auch Icons wie gewünscht.
ich hänge hier mal die beiden PNGs an:
displayBackground.png ist die defekte
displayBackground3.png funktioniert

Schön, dass es bei dir nun klappt
Neben der Pixeldichte unterscheiden sie sich noch im Farbraum. Das funktionierende hat RGB, das nicht funktionierenden nur 16 Farben. Ich verwende die selbe Pixeldichte wie dein defektes Bild, es sollte also am Farbraum liegen.

VG

[Borkk]

Diese Änderung soll gegen das Einfrieren des ESP nach einigen Tagen helfen.

Ich schätze, die Übertragungsfehler müssen im FHEM-Module ESPEink gefixt werden. Ich vermisse dort für dein Display den korrekten Typen, imo müsste es "7.5inch_e-Paper_HD" sein, es gibt jedoch nur die B-Version zur Auswahl. Das hatte sich in der Firmware zwischenzeitlich mal geändert (B wurde in die normale Version integriert) - evtl. ist das bereits die Ursache. Müsste sich @eki mal anschauen.

Die genaue Bezeichnung lt. Bestellung lautet "Waveshare 17059 7.5inch HD e-Paper (B) (WS3-017059)". Ist das nicht die B Variante ?

[Jendaw]

Die genaue Bezeichnung lt. Bestellung lautet "Waveshare 17059 7.5inch HD e-Paper (B) (WS3-017059)". Ist das nicht die B Variante ?

Never mind, mein Fehler 

[Borkk]

Kurzes Update von mir.

Ich habe den ESP8266 gegen einen ESP32 mit aktueller standard Waveshare software getauscht. Im ESPEink Modul habe ich auf ESP32 umgestellt und siehe da -kein Fehler beim Upload. Der Upload wird sauber mit "Succesfull..." vom Modul zurückgemeldet.

Das erhärtet aus meiner Sicht den Verdacht, das ESPEink nicht lange genug wartet bis der EPS8266 sich "fertig" meldet. Der ESP32 ist da ja ein Stück schneller und schafft das wohl.

[eki]

Es gibt das Attribut uploadTimeout, damit kann man einstellen, wie lange das Modul auf Antwort auf die REST Anfragen zum Device wartet.

[Borkk]

Es gibt das Attribut uploadTimeout, damit kann man einstellen, wie lange das Modul auf Antwort auf die REST Anfragen zum Device wartet.

Ok, ich hatte das Attribut nicht gesetzt. Aber es löst scheinbar das Problem nicht. Ich habe es bis 120 angehoben und der Fehler kommt immer noch. Zudem kommt jetzt noch ein weiterer Fehler den ich vorher nicht hatte. (Mit ESP8266)

Code: [Auswählen]

2022.01.10 19:58:22 3: ep_flur: sending HTTP request to http://192.168.23.76/EPD with data: ib
2022.01.10 19:58:45 1: ep_flur: problems with communication to device, max retries (0) reached
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 2525
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3386
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3390
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3391
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3392
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3402
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3403
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3404
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3405
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3406
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3407
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3408
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3409
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3418
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3419
2022.01.10 20:00:02 1: Timeout for ESPEInk_DoConvert reached, terminated process 3420
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3421
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3422
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3423
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3424
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3433
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3434
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3435
2022.01.10 20:00:03 1: Timeout for ESPEInk_DoConvert reached, terminated process 3436
2022.01.10 20:00:26 1: Timeout for ESPEInk_DoConvert reached, terminated process 3437
2022.01.10 20:00:26 1: Timeout for ESPEInk_DoConvert reached, terminated process 3793


[eki]

Ich habe Dir, glaube ich, den falschen Parameter genannt, sorry. Es gibt grundsätzlich 2 Mechanismen, die in dem Modul mit Timeouts arbeiten:

Erstens die eigentliche Erstellung des Bildes. Damit FHEM vor allem bei größeren Displays nicht hängt, findet das in einem ausgelagerten Hintergrundprozess statt. Hierfür gibt es einen Timeout, der den Prozess killt, falls die Konversion zu lang dauert. Der Default ist hier bei 290 Sekunden (falls die Konversion früher fertig ist, dann ist der Prozess ja sowieso beendet). Den Parameter solltest Du also, vor allem bei großen Displays, eher auf einen recht großen Wert setzen.

Zweitens der Upload des Bildes zum Device. Hierfür gibt es einen zweiten Timeout, der per Default auf 10 Sekunden steht und per Attribut timeout einstellbar ist.

Wenn das Problem tatsächlich die Antwort vom Device ist, dann musst Du timeout höher setzen (beim ESP32 gibt es übrigens gar keine Antwort vom Device, insofern kann es da bei der Kommunikation auch nicht zu Timeouts kommen).

[Borkk]

Ich habe Dir, glaube ich, den falschen Parameter genannt, sorry. Es gibt grundsätzlich 2 Mechanismen, die in dem Modul mit Timeouts arbeiten:

Erstens die eigentliche Erstellung des Bildes. Damit FHEM vor allem bei größeren Displays nicht hängt, findet das in einem ausgelagerten Hintergrundprozess statt. Hierfür gibt es einen Timeout, der den Prozess killt, falls die Konversion zu lang dauert. Der Default ist hier bei 290 Sekunden (falls die Konversion früher fertig ist, dann ist der Prozess ja sowieso beendet). Den Parameter solltest Du also, vor allem bei großen Displays, eher auf einen recht großen Wert setzen.

Zweitens der Upload des Bildes zum Device. Hierfür gibt es einen zweiten Timeout, der per Default auf 10 Sekunden steht und per Attribut timeout einstellbar ist.

Wenn das Problem tatsächlich die Antwort vom Device ist, dann musst Du timeout höher setzen (beim ESP32 gibt es übrigens gar keine Antwort vom Device, insofern kann es da bei der Kommunikation auch nicht zu Timeouts kommen).

Hallo Eki,

Ich habe in dem Zusammenhang die folgenden Attribute für mein 7,5" an einem ESP8622 gesetzt:

Code: [Auswählen]

interval = 0 -> ich möchte das nur bei Wechsel der definitierten Readings ein Convert/Upload ausgelöst wird.
maxretries= 0 -> Das Display wird in meinem WLAN immer sauber aufgebaut, somit ist kein retry nötig
mininterval = 40 -> Das Attribut hattest du damals auf meinen Fehler mit den überlagerten Uploads hin gebaut, seitdem wird jeder Upload sauber ausgeführt
uploadTimeout = 60 -> Das Attribut habe ich aufgrund des jüngsten Hinweise hier im Threat gesetzt.

Dann gibt es noch ein Attribut "timeout". Da es noch keine Beschreibung in der Commandref für "uploadTimeout" und "timeout" gibt, ist mir immer noch nicht ganz klar was die Attribute genau beeinflussen.   

[eki]

Mein Vorschlag (besser erklären als zuvor kann ich es leider nicht  ):

Setzte uploadTimeout (das ist der Parameter der für das zuvor erwähnte erste Timeout Thema zuständig ist) auf einen großen Wert (z.B. 300) um genügend Zeit für die Berechnung des "Bildes" zu erlauben und nicht in die "ESPEInk_DoConvert" Timeouts zu laufen.

Setze timeout  (das ist der Parameter der für das zuvor erwähnte zweite Timeout Thema zuständig ist) auf einen größeren Wert als den Default (z.B. 60), dadurch wartet das Modul länger auf die Antwort beim Senden des Bildes zum ESP8266.

Der Rest Deiner Settings ist aus meiner Sicht OK.

[Borkk]

Mein Vorschlag (besser erklären als zuvor kann ich es leider nicht  ):

Setzte uploadTimeout (das ist der Parameter der für das zuvor erwähnte erste Timeout Thema zuständig ist) auf einen großen Wert (z.B. 300) um genügend Zeit für die Berechnung des "Bildes" zu erlauben und nicht in die "ESPEInk_DoConvert" Timeouts zu laufen.

Setze timeout  (das ist der Parameter der für das zuvor erwähnte zweite Timeout Thema zuständig ist) auf einen größeren Wert als den Default (z.B. 60), dadurch wartet das Modul länger auf die Antwort beim Senden des Bildes zum ESP8266.

Der Rest Deiner Settings ist aus meiner Sicht OK.

Hallo Eki,
nur damit das klar ist, ich bin sehr froh das du das Modul gebaut hast und es funktioniert super .
Ich habe jetzt die Timeouts verstanden und so gesetzt wie du sie vorgeschlagen hast. Und siehe da, kaum macht man es richtig, geht es auch. Danke.

Aber wäre es nicht besser die zwei, doch recht wichtigen Attribute "sprechender" zu benennen?

z.B. 
uploadTimeout -> convertTimeout
timeout -> uploadTimeout

[eki]

Ja, das hatte ich auch schon überlegt, bin mir aber nicht sicher, ob das dann nicht irgendwelche Einstellungen bei bestehenden Installationen kaputt macht. Ich Probier bei mir mal aus, wie sich das verhält.

[Borkk]

Hallo Zusammen,

Ich würde gerne die Uhrzeit des letzten Uploads auf´s Display schreiben. Dazu haben ich 2 Fragen:

1.) kann ich das Reading "updatestart" welches Datum und Uhrzeit im Unix.Style enthält vie userReadings im als lesbare Uhrzeit darstellen?
2.) wie kann ich verhindern, das durch verändern dieses Reading kein neuer Upload angestoßen wird? (das wäre dann ja eine Endlosschleife)