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

viegener

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

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

eki

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.

viegener

@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
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

viegener

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...
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

viegener

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

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

eki

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.

appi

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




eki

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?

appi

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


Jendaw

Was sagt denn die serielle Konsole dazu? Kannst du das bitte posten?
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)

Jojocra

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

viegener

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
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Jojocra

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?

Jendaw

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

Jojocra

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