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

Icinger

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

eki

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]

Icinger

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

Laffer72

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
Raspberry Pi Rev.B, FB7390 (FHEM2FHEM), Sonos, Smarter Coffee
Osram Lightify:2m LED-Streifen, 5m-LED-Streifen, Gartenspot, Surface 28W, Classic E14,E27, Classic RGBW E27, PAR16 GU10, Plug
CUL868:FS20-ST, FS20-DI, FS20-FMS, FS20-ES1
HMUSB:HM-Sec-RHS,HM-Sec-MDIR2
Jeelink868:TX-29-IT, TFA30.315

eki

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

eki

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

kkoeniger

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>
LG,
Karl

eki

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

kkoeniger

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

eki

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?

kkoeniger

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.
LG,
Karl

Icinger

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

eki

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

Icinger

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

eki

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.