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

[Jendaw]

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

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.

[eki]

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.

[hajo23]

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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

[Borkk]

Hallo Zusammen,

bevor hier ein falscher Eindruck aufkommt Vielen Dank an alle die mir (und anderen) hier helfen und vor allem vielen Dank an alle die Module bauen wie eki. Ich selbst habe schon (nicht zuletzt mit Hilfe dieses Forums) echt viel mit meinem FHEM auf die Beine gestellt. Und das alles ohne eine Programmiersprache zu kennen.

Ohne eki´s Modul hätte ich gar nicht erst mit dem ePaper angefangen und des ist auch klasse.

@Jendaw: Was ich meinte, ich finde es schade nicht den Upload Mechaninsmus von ESPInk nutzen zu können und statt dessen einen Weg über MQTT drumherum zu bauen. Dadurch wird das Modul ja zum reinen "PNG Generator" degradiert. ESPInk ist essenziell wichtig, ich wüsste nicht wie ich sonst so ein dynamisches PNG erzeugen sollte. Wäre halt schön wenn auch der Upload aus dem Modul heraus stabil läuft. Ich würde mir echt gerne den Weg über MQTT sparen, zumal man dafür auch noch einen Mosquitto Broker braucht und nicht den FHEM Broker verwenden kann. So wie ich das hier gelesen habe.

[Jendaw]

@Jendaw: Was ich meinte, ich finde es schade nicht den Upload Mechaninsmus von ESPInk nutzen zu können und statt dessen einen Weg über MQTT drumherum zu bauen. Dadurch wird das Modul ja zum reinen "PNG Generator" degradiert. ESPInk ist essenziell wichtig, ich wüsste nicht wie ich sonst so ein dynamisches PNG erzeugen sollte. Wäre halt schön wenn auch der Upload aus dem Modul heraus stabil läuft. Ich würde mir echt gerne den Weg über MQTT sparen, zumal man dafür auch noch einen Mosquitto Broker braucht und nicht den FHEM Broker verwenden kann. So wie ich das hier gelesen habe.

Ich verstehe, was du meinst. Technisch gesehen wird auch der Upload-Mechanismus vom ESPEInk-Modul genutzt, nur eben "on demand" - also wenn der ESP wach ist und die Daten entgegen nehmen kann. Für den "normalen" Betrieb ist die Yattien-Firmware auch gar nicht notwendig. Erst, wenn man den ESP schlafen lassen möchte, kommt MQTT als eine Lösung in Betracht. Alle anderen Fälle sollten und müssen mit der Original-Firmware laufen - die Yattien-Fw ist nur eine simple Erweiterung dieser.

Der FHEM-Broker unterstützt leider kein QOS, daher muss für die Yattien-Lösung ein "richtiger" MQTT-Broker genutzt werden. Das hast du korrekt gelesen
Es scheint aber auch andere Lösungen mit MQTT zu geben, wenn man in den ersten Seiten des Threads liest. Ich weiß allerdings nicht, wie diese funktionieren. Und sleep ohne MQTT scheint auch irgendwie zu gehen.

edit Man könnte MQTT auch weglassen und per einfachem FHEM-Webrequest ansprechen. Das müsste ich mir mal in einer freien Minute anschauen, wie man das mit dem CSRF-Token macht. Falls jmd schon einen ESP8266-Codeschnipsel dazu hat, immer her damit

edit2 Mit vorgenanntem Webrequest müsste noch in das ESPEInk-Modul eingebaut werden, dass er nur Daten sendet, wenn seit dem letzten Update neue anliegen. Damit wird das EInk-Display vor unnützen Updates geschont (erhöhter Verschleiß).

VG

[Borkk]

Vermutlich könnte man auch einfach über ein "set ep_flur upload" manuell triggern, wenn dieser dann einmalig und sauber das PNG auf den ESP schiebt. Die letzte dev. Version von eki macht das ja schon ganz gut, nur scheinbar rennt das Modul in einen loop.

@eki: was "mininterval" angeht... man muss ja das Modell des sPapers auswählen und jedes Modell hat ja eine vom Hersteller angegeben Aktualisierungsdauer (bei meinem 21sec), es wäre doch sinnvoll, wenn du diese Zeit (+ 2-3 sec Sicherheitspuffer) in die Parameter der jeweiligen Displays einträgst und im Modul verwendest. Wichtig wäre nur das die Aktualisierungen die innerhalb der "mininterval" Dauer erfolgen, nicht verworfen werden.

Also mal angenommen ich habe Interval=0 eingestellt und mache 3 Fenster zu. Der erste Upload würde erfolgen weil, das Modul quasi idle war. Fenster 2 und 3 werden innerhalb der "mininterval" Zeit geschlossen. Diese Aktualisierungen dürfen natürlich nicht verworfen werden. Idealer weise wird nur die letzte Aktualisierung, nach der "mininterval" Zeit hochgeladen.   

[eki]

Das mit den Device spezifischen Wartezeiten wäre kein Problem (mininterval = auto) das kann ich einbauen. Das mit dem warten auf das letzte Update ist schwierig, da laufen ja asynchron immer mal wieder Events auf, woher soll ich wissen, was der ,,letzte" ist?
Was ich machen könnte, ist, die während des Updates einlaufenden Events sammeln und dann, wenn die Minimalzeit abgelaufen ist, die bis dahin gesammelten Events noch mal verarbeiten (in einem zusätzlichen convert-upload). Ich mach mir mal Gedanken, kann aber ein bisschen dauern, weil ich gerade wenig Zeit habe.

[Borkk]

Das mit den Device spezifischen Wartezeiten wäre kein Problem (mininterval = auto) das kann ich einbauen. Das mit dem warten auf das letzte Update ist schwierig, da laufen ja asynchron immer mal wieder Events auf, woher soll ich wissen, was der ,,letzte" ist?
Was ich machen könnte, ist, die während des Updates einlaufenden Events sammeln und dann, wenn die Minimalzeit abgelaufen ist, die bis dahin gesammelten Events noch mal verarbeiten (in einem zusätzlichen convert-upload). Ich mach mir mal Gedanken, kann aber ein bisschen dauern, weil ich gerade wenig Zeit habe.

Das PNG kann ja weiter aktualisiert werden nur der Upload sollte dann nur mit dem zuletzt erstellten PNG erfolgen.  Also wenn währed der mininterval Wartezeit 3 Events auflaufen , kann das Modul ja 3 PNG´s erzeugen. Da die PNG´s ja immer überschrieben werden, dürfte doch beim Upload nach der Wartzeit auch nur das aktuellste hochgeladen werden (Ich weiss klingt vermutlich einfacher als es umsetzbar ist )

[hajo23]

@Borkk
geht bei dir ein addicon, wenn icon ein png ist?

[Borkk]

@Borkk
geht bei dir ein addicon, wenn icon ein png ist?

Hab mal versucht ein icon aus dem /default Ordner anzeigen zu lassen, da kommt nichts.

[hajo23]

Hab mal versucht ein icon aus dem /default Ordner anzeigen zu lassen, da kommt nichts.

Nichts, wäre zu wenig. Dies sollte eine Lampe anzeigen, aber nur wenn du den Farbwert ff0000 weglässt, sonst bekommst du nur ein rotes Rechteck.

Code Auswählen Erweitern

addicon#li_wht_on#800#176#18#0#ff0000

Wenn du in eki's code z.B.  diese Zeile änderst in

Code Auswählen Erweitern

$icon_img->setPixel($ix,$iy,$color) if ($r<180 && $g<180 && $b<180 && $color>0); # set color to given color if original color is black
kannst du das icon rot einfärben. Allerdings löst es leider nicht das Problem mit den SVGs. Lösung unten ...

[Borkk]

Hallo eki,

ich habe jetzt die original Waveshare Firmware mit der "Option: All Flash Content" geflasht. Und ich bin sehr zufrieden. Das PNG wird sauber und nur einmal auf das Display geladen. Kein Loop und keine Verschiebung. Also bzgl. der Endlosschleife kann ich Entwarnung geben, lag wohl an meinem ESP. Es spielt auch keine Rolle ob ein Upload über "Set" manuell angestoßen wird oder ob er automatisch erfolgt.

Also das attr. mininterval verhindert definitiv, das sich Uploads in die Quere kommen und dadurch die Darstellung des PNG verschieben. Diese Änderung könntest du vermutlich schon einchecken.

Ich teste später mal was passiert wenn Änderungen innerhalb der mininterval Zeit erfolgen.   

[hajo23]

Die Lösung für das SVG-icon Problems liegt in der Auswertung des alpha-Wertes. Ich musste allerdings auch meine GD-lib updaten.

Code Auswählen Erweitern


($r,$g,$b) = $icon_img->rgb($icon_img->getPixel($ix,$iy));                                       # get color values in source file
(my $alpha) = $icon_img->alpha($icon_img->getPixel($ix,$iy));                                    # get alpha-channel
$icon_img->setPixel($ix,$iy,$color) if ($alpha == 0 && $r<180 && $g<180 && $b<180 && $color>0);  # set color to given color if original color is black  *your favorite tresholds may be different


[Borkk]

Die Lösung für das SVG-icon Problems liegt in der Auswertung des alpha-Wertes. Ich musste allerdings auch meine GD-lib updaten.

Code Auswählen Erweitern


($r,$g,$b) = $icon_img->rgb($icon_img->getPixel($ix,$iy));                                       # get color values in source file
(my $alpha) = $icon_img->alpha($icon_img->getPixel($ix,$iy));                                    # get alpha-channel
$icon_img->setPixel($ix,$iy,$color) if ($alpha == 0 && $r<180 && $g<180 && $b<180 && $color>0);  # set color to given color if original color is black  *your favorite tresholds may be different


Ich habe die Zeilen geändert und ich kann jetzt die Farbe eines SVG Icons ändern, TOP !!!

[Borkk]

Jetzt bin ich fast am Ziel nur eine Sache noch. Wie kann ich denn die Farbe eines Icons aus einem Reading setzen?

so geht es nicht.

Code Auswählen Erweitern

iconreading#speak_volume:e_icon#500#150#40#0#[speak_volume:e_color]

Im Reading "e_color" steht je nach status ff0000 oder 00000