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

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

Vorheriges Thema - Nächstes Thema

Jendaw

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:
/* SSID and password of your WiFi net ----------------------------------------*/
const char *ssid = "FB6490"; //"your ssid";
const char *password = "Blallla";   //"your password";


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


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

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

eki

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

Icinger

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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

Maista

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

Jendaw

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

eki

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.

Jendaw

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

eki

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.

Jendaw

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

eki

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.

Jendaw

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

eki

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

Jendaw

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

eki

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.

Jendaw

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