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

Zitat von: Maista am 09 März 2020, 18:14:36
Ich habe deine Version aufgespielt aber hier ist das gleiche Spiel zu sehen wie mit den anderen Standard-Sourcen.
Im Monitor der IDE sehe ich nun sogar sporadisch ein "Brownout detector was triggered". Da wird irgendwie sehr schnell etwas im ESP gemacht.
Wenn ich dann Reset drücke habe ich Glück das er sich dann irgend wann ein mal mit der FB verbindet. Danach dann aber wieder nicht.
Sry, wenn es nicht so deutlich geworden ist: das ist eine MQTT-Version und funktioniert nur in der Umgebung, wie in https://forum.fhem.de/index.php/topic,104171.msg1029864.html#msg1029864 beschrieben, ist also keinesfalls ein Standard-Ersatz. Der Brownout kommt vermutlich daher, dass bei dir auf FHEM-Seite das MQTT-Kommando nicht korrekt ausgewertet wird, oder? Dann rennt der Webserver kurz durch, weil kein Client verfügbar ist. Würde man dort noch ein delay() unterbringen, so würde das nur den normalen Betrieb verzögern.

Ich schau mir bei Gelegenheit auch mal die ESP8266-Version an, da ich vermutlich auf diesen umsteigen werden, damit der ESP32 für ein anderes Projekt frei wird. Das wird dann jedoch auch eine MQTT-Version, wie oben beschrieben.

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)

Jendaw

Zitat von: Maista am 09 März 2020, 18:14:36
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Ich habe eine (ungetestete) ESP8266-Version aus dem waveshare-Code erstellt, die einen Assistenten für die WLAN-Konfiguration beinhaltet - vllt. bekommt ihr die Verbindungsprobleme damit besser in den Griff? Außerdem ist diese Version OTA-Updatefähig. Die WLAN-Zugangsdaten werden im ESP gespeichert, die Einrichtung ist also nur initial notwendig. Dazu wird ein AccessPoint mit dem Namen "ESPEInk-APSetup" erstellt, an den ihr euch mit WLAN verbinden könnt. Im Browser könnt ihr dann auf dessen IP-Adresse gehen (bspw. "http://192.168.4.1") und wählt dort eure FriBo aus und gebt die Zugangdaten ein. Danach startet sich der ESP8266 neu und sollte sich verbinden und wie der normale waveshare-Server verhalten. Falls bereits Zugangsdaten im Speicher des ESP8266 liegen können die einmalig mit "wifiManager.resetSettings()" gelöscht werden. Bei Bedarf kann ich hier auch ein "Löschimage" dafür erstellen.
Leider ist das ungetestet, da ich noch keinen freien ESP8266 habe. Ich hänge die Sourcen wie auch das Binary an. Zum selber kompilieren benötigt man noch zusätzlich die Lib "Wifi-Manager" (https://github.com/tzapu/WiFiManager/archive/master.zip).
Der MQTT- sowie der Deepsleep-Part ist noch nicht enthalten.

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)

Maista

Hallo Jendaw

bei mir läuft zwar mqtt2 aber genauer habe ich mich bisher damit nicht beschäftigt. Es werden damit 3 SONOFF angesprochen und ein paar Aquara-Sensoren.
Aber wirklich beschäftigt habe ich mich mit mqtt noch nicht. Icingers Code hat es zumindest geschafft sich anzumelden.
Was nun für deine Idee benötigt wird steht für mich erst mal hinten an, so lange sich der ESP32 nicht stabil verhält.

Das mit dem WLAN-Assistenten hatte ich auch gelesen das es das gibt. Aber sich damit zu befassen wurde dann von anderen Dingen überholt :=)

Zitatvllt. bekommt ihr die Verbindungsprobleme damit besser in den Griff?

Unsere Probleme bestehen nicht beim ESP8266 sondern mit dem ESP32 !
ESP8266 habe ich einen im Haus der sich seit Jahren ohne Probleme aus dem DeepSleep aufwachen lässt, sich mit der FB verbindet und bei FHEM meldet.
Das ist ja eben nicht das/mein Problem.

Werd ich bei Gelegenheit probieren.

Danke und Gruss
Gerd

Jendaw

Zitat von: Maista am 09 März 2020, 22:58:37
Unsere Probleme bestehen nicht beim ESP8266 sondern mit dem ESP32 !
ESP8266 habe ich einen im Haus der sich seit Jahren ohne Probleme aus dem DeepSleep aufwachen lässt, sich mit der FB verbindet und bei FHEM meldet.
Das ist ja eben nicht das/mein Problem.
Sorry, ich komme nicht mehr mit. Vor ein paar Tagen hattest du noch nach dem Deepsleep-Modus für den ESP8622 gefragt. Nun bin ich am Erstellen eines Codes dafür und nun bist du wieder beim ESP32 - warum bleibst du nicht bei dem, was bereits funktioniert? Btw: mein ESP32 tut seit der letzten Änderung vom Sonntag immer noch seinen Dienst. Dazu muss man aber auch die FHEM-Gegenseite entsprechend einrichten. Wenn du das vorerst nicht möchtest, so kann dir mein ESP32-Code nicht helfen. Wie ist überhaupt dein Anwendungsfall, weil du immer nach einem Deepsleep fragst? Das ESPEInk-Modul arbeitet derzeit noch nach dem Push-Prinzip, das Display sollte dann also gerade nicht schlafen, wenn Daten zur Übertragung bereit stehen. Diese Problematik kann man mit MQTT umschiffen.
Ich werde meine MQTT-Idee erst mal auf den ESP8266 portieren (da ich diesen einsetzen werde, da mir kurze Sleepzeiten genügen). Ggf. kann ich danach, wenn Bedarf besteht, die Autokonfiguration und OTA auf den ESP32 portieren.

Kannst du bitte beschreiben, was du tun willst und wie die Sleepzeiten dazu passen müssen? Es stellt ja jeder etwas anderes auf dem Display dar. Manchen genügt eine Aktualisierung am Tag, bei mir ist es ~minütlich, da ich offene Fenster und Türen zeitnah darstellen möchte.

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)

Maista

@Jendaw
ZitatVor ein paar Tagen hattest du noch nach dem Deepsleep-Modus für den ESP8622 gefragt. Nun bin ich am Erstellen eines Codes dafür und nun bist du wieder beim ESP32 - warum bleibst du nicht bei dem, was bereits funktioniert?
Das ist auch löblich, ich habe dein ESP32-Code auch nur probiert weil Du ihn hier eingestellt hattest.
Und anständig wie ich bin habe ich Dir nur die Rückmeldung geben wollen wie bei mir das Verhalten mit der FB ist.
Ich war der Meinung das dies von Dir so beabsichtigt war.

Wie gesagt, so lange der ESP32 sich nicht sicher mit den Fritzboxen verbindet, was man auch nachlesen kann, so lange werde ich den daher auch nicht bei mir im Netz verwenden können.
Und da dieses nicht-verbinden-wollen nicht mit mqtt zu tun hat, habe ich das auch gar nicht erst bei mir weiter verfolgt.
Ich wollte nur schauen ob deine Vorgehensweise bei dem Verbindungsaufbau irgend ein Positiven Effekt bei mir haben könnte.

ZitatWie ist überhaupt dein Anwendungsfall, weil du immer nach einem Deepsleep fragst?
Wie die Idee vom Icinger bei seinem Code schon war, wenn ich ein E-Papier verwende, möchte ich das auch so nutzen.
So lange nichts übertragen wird kann sich die HW dann auch entsprechend schlafen legen. Ansonsten kann ich auch gleich ein OLED o.ä.
verbauen wenn kein Deepsleep funktioniert.

ZitatDas ESPEInk-Modul arbeitet derzeit noch nach dem Push-Prinzip, das Display sollte dann also gerade nicht schlafen, wenn Daten zur Übertragung bereit stehen
Das ist mir auch klar. Mit dem Code vom Icinger hat das aber trotz allem funktioniert. Weil er sich nach dem Empfang dann erst schlafen legt.

Aber, wie oben schon geschrieben, wenn der ESP32 sich nicht stabil nach dem Deepsleep und im allgemeinen mit der FB verbinden will, ist der im Netz bei mir nicht zu gebrauchen.
Aus diesem Grund werde ich das dann auch mit dem ESP8266  weiter machen. Der ESP32 ist da eh "Oversized" finde ich. Zumindest in der Konstellation.

ZitatKannst du bitte beschreiben, was du tun willst und wie die Sleepzeiten dazu passen müssen
Ich habe bisher nur ein 1.54" Display. Und das aus dem Grund weil ich erst ein mal probieren will in wie weit ich damit was anfangen kann.

Meine Test liefen mit 30/60 Sekunden DeepSleep. Die 30 Sekunden aber auch nur um zu schauen ob der ESP32 sich immer sicher verbindet.
Ich denke mal alle 60 Sekunden aufwachen sollte ausreichen um hier Sinnvoll etwas anzuzeigen.
Wenn ich Echtzeit hätte haben wollen, hätte ich Nextion nehmen müssen. Das brauch ich aber nicht.

Soweit nun alles klar?

Gruss Gerd

Jendaw

Zitat von: Maista am 10 März 2020, 12:18:54
Das ist auch löblich, ich habe dein ESP32-Code auch nur probiert weil Du ihn hier eingestellt hattest.
....
Ich denke mal alle 60 Sekunden aufwachen sollte ausreichen um hier Sinnvoll etwas anzuzeigen.
Wenn ich Echtzeit hätte haben wollen, hätte ich Nextion nehmen müssen. Das brauch ich aber nicht.

Soweit nun alles klar?
Danke für deine nochmaligen Ausführungen, damit ist mir dein Anwendungsfall immer noch nicht klar - also was du mit deinem Display eigentlich tun möchtest. "60s schlafen lassen" ist ja bereits eine Lösung für eine Aufgabenstellung. Für mich klingt es damit so, als würdest du etwas Unpassendes ("es funktioniert ja trotzdem") auf dein Problem anwenden. Soll jetzt aber nicht mehr Thema sein, betrachte ich hiermit als erledigt.

Wie dem auch sei, mein ESP32 ist mittlerweile (mit meiner MQTT-Lösung) ~3.000 (>2d) schlafen gegangen und hat sich genauso oft erfolgreich mit meiner FriBo verbunden. Also etwas mehr als deine ~250x. Wenn ich in den ESP8266-Code das Deepsleep eingebaut habe, werde ich noch mal eine "60s-Version" posten.

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)

Maista

@eki
Zitat von: eki am 27 Februar 2020, 08:55:52
OK, hier die Version mit einem neuen Attribut "definitionFile" in welchem man einen Filenamen angeben kann, der Definition enthält (gleiche Syntax wie bei "definition").
und mit der Möglichkeit zu Kommentaren (Zeilen in "definition" oder "definitionFile", die mit "#" (oder mit Leerzeichen und dann "#") starten).

Neu dazu gesetzte Attribute erzeugen aber keine neues Readings im Device?! Ist das Richtig?
Die Daten werden korrekt in das Bild gerechnet.

Ein Hinweis das die Config-Datei "definitionFile" unter "FHEM/meine.cfg" stehen muss fehlt noch in der Hilfe.

Ich habe die alten Readings gelöscht um nur noch über "definition" oder "definitionFile" zu editieren.
Aber nun werden die Texthöhen nicht mehr berücksichtigt?

textreading#BSB:Uhrzeit#01#198#13#90#000000
addtext#WW: #35#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#Nina_Device:WarnCount#35#110#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
addtext#T: #65#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#BSB:8700-Aussentemperatur#65#150#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#W132_22:state#95#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#SD_WS07_TH_1:state#125#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#MQTT2_WetterDisplay:state#188#198#13#90#000000
addtext#HT: #155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#HM.EG.fl.TK.Haustuer:hmstate#155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf


Wenn ich in der Zweiten Zeile den Pfad zur Schrift gegen "giant" tausche wird der Text in allen folgenden Zeilen ebenfalls so "gross" dargestellt.
Aber wesentlich kleiner als mit DejaVuSans.ttf.

Als ich die Readings noch alle hatte wurden die Schriftarten berücksichtigt.

Hab ich hier irgend etwas überlesen?
Gruss
Gerd

Maista

Zitat von: Jendaw am 10 März 2020, 13:16:04
Danke für deine nochmaligen Ausführungen, damit ist mir dein Anwendungsfall immer noch nicht klar - also was du mit deinem Display eigentlich tun möchtest. "60s schlafen lassen" ist ja bereits eine Lösung für eine Aufgabenstellung. Für mich klingt es damit so, als würdest du etwas Unpassendes ("es funktioniert ja trotzdem") auf dein Problem anwenden. Soll jetzt aber nicht mehr Thema sein, betrachte ich hiermit als erledigt.
Von Unpassend habe ich nie etwas geschrieben. Die Aufgabe von einem Display ist etwas anzeigen. Was das alles ist wird sich dann zeigen wenn es bei mir Funktioniert.
Dafür brauche ich jetzt erst mal nicht einen speziellen Anwendungsfall? Und nur das er 60s schläft habe ich nicht als Funktion deklariert.
Dazu brauch ich kein Display oder ein ESP. Aber auch das ist eigentlich nicht mein Thema gewesen.
So lange man etwas probiert gibt es auch nicht unbedingt ein Anwendungsfall.

ZitatWie dem auch sei, mein ESP32 ist mittlerweile (mit meiner MQTT-Lösung) ~3.000 (>2d) schlafen gegangen und hat sich genauso oft erfolgreich mit meiner FriBo verbunden.
Ein ESP8266 Akku lief zwei Jahre mit LUA und hatte nie Probleme sich nach dem DeepSleep mit der FB zu verbinden. Und auch mit der ESPEasy-Version ist das kein Thema.
Das funktioniert nun auch schon über ein Jahr.

ZitatWenn ich in den ESP8266-Code das Deepsleep eingebaut habe, werde ich noch mal eine "60s-Version" posten.
Danke. Werde ich dann testen.

Gruss Gerd

Jendaw

#188
Ich hab mich weiter mit dem ESP8266 beschäftigt. Leider hängt mein Display immer noch am ESP32, der Code ist daher noch nicht von mir unter Realbedingungen getestet worden. Was kann er/sollte er können:

  • Einrichtungsmanager für WiFi, MQTT und Deepsleep-Zeit
    - Verbinden mit dem AP "ESPEInk-APSetup" und im Browser die URL "http://192.168.4.1" aufrufen
    - MQTT-Server ist optional, falls keiner angegeben wird, wird kein MQTT verwendet
    - Sleeptime in Sekunden ist optional, wird keine angegeben, läuft der ESP ständig
    - Firmware-Basis-URL ist optional
    - die Einrichtungsdaten werden damit im ESP gespeichert und nicht mehr im Quellcode
  • OTA-Firmware-Update
    - unterhalb der Firmware-Basis-URL werden zwei Dateien erwartet, Hauptnamensbestandteil ist die klein geschriebene (WiFi-)MAC-Adresse des ESP
    - "<MAC>.version" eine Datei, die nur eine Zahl enthält, das ist die Versionsnummer des zugehörigen Firmwareimages
    - "<MAC>.bin" das Firmware-Image
    - ein Update erfolgt nur, wenn die aktuelle Versionsnummer kleiner als die auf dem Webserver ist (ja, ist derzeit viel Handarbeit ;) )
  • Deepsleep: der ESP-Webserver wird für 10s für Aktionen gestartet, danach geht er schlafen, falls eine Schlafdauer konfiguriert ist
    - wird ein manueller Upload über die Webseite oder ein ESPEInk-Upload gestartet, wird der Schlaf solange verzögert
  • MQTT-Szenario, wie in diesem Beitrag beschrieben. Funktioniert nicht standalone, benötigt also eine eingerichtete FHEM-Gegenseite
  • Reset-Seite "http://<esp>/reset", um den Einrichtungsassistenten (ohne Rückfrage) zu starten
  • Abort-Seite "http://<esp>/abort", um einen verzögerten Schlaf (bspw. abgebrochener manueller Upload) sofort auszulösen

Ich hänge die Hauptsource (ersetzt das INO-File von waveshare, muss also in Loader.ino umbenannt werden) sowie das aktuelle Image an, damit man es nicht mehr übersetzen muss (vor dem Upload entpacken). Ich hoffe, ich habe nicht zu viele Fehler drin, testen konnte ich es hardwaremässig leider noch nicht :(

Manuell kann der Upload so aussehen (muss natürlich auf eure Umgebung angepasst werden):
% python3 ~/.arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/upload.py --chip esp8266 --port /dev/ttyUSB0 --baud 460800 --before default_reset --after hard_reset write_flash 0x0 /tmp/ESPEInk_ESP8266_v9.ino.bin

edit: Der Einfachheit halber ist ESP8266-Code und Image jetzt auch zu finden auf github

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)

Jendaw

Zitat von: Maista am 10 März 2020, 14:27:08
Neu dazu gesetzte Attribute erzeugen aber keine neues Readings im Device?! Ist das Richtig?
Ich musste nach dem Tausch erst FHEM restarten. Wichtig ist, die letzte Version von ESPEInk zu nutzen, erst da gingen die Readings in der Datei wieder.

Zitat
Ein Hinweis das die Config-Datei "definitionFile" unter "FHEM/meine.cfg" stehen muss fehlt noch in der Hilfe.
Muss es afair nicht, aber so ist es bequemer (direkt in FHEM) zu editieren.

ZitatIch habe die alten Readings gelöscht um nur noch über "definition" oder "definitionFile" zu editieren.
Aber nun werden die Texthöhen nicht mehr berücksichtigt?

textreading#BSB:Uhrzeit#01#198#13#90#000000
addtext#WW: #35#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#Nina_Device:WarnCount#35#110#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
addtext#T: #65#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#BSB:8700-Aussentemperatur#65#150#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#W132_22:state#95#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#SD_WS07_TH_1:state#125#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#MQTT2_WetterDisplay:state#188#198#13#90#000000
addtext#HT: #155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
textreading#HM.EG.fl.TK.Haustuer:hmstate#155#180#20#90#000000#/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf


Wenn ich in der Zweiten Zeile den Pfad zur Schrift gegen "giant" tausche wird der Text in allen folgenden Zeilen ebenfalls so "gross" dargestellt.
Aber wesentlich kleiner als mit DejaVuSans.ttf.
Für Gewöhnlich passiert dass, wenn man einen Fehler in der Config hat. Schau dir am Besten die Zeilen an, ab der es nicht mehr wie gewünscht aussieht. Meist fehlt eine Raute "#" oder eine Angabe ist falsch (Schreibung, Pfad etc.).
Bspw. sieht die erste (und alle anderen) Zeile seltsam aus, das Format ist device:reading#x#y#size#angle#color#font#linegap#blockwidth es fehlen also noch Angaben. Schau dir dazu Modulhilfe an, da hat sich ggf. etwas im Laufe der Zeit geändert.

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)

Maista

Moin
Im Moment steht das Projekt hinten an.
Musste wegen Todesfall unvermittelt abbrechen.

Gruß Gerd

Jendaw

#191
@Maista mein Beileid

Ich habe die ESP32-Sourcen nun auch angepasst, sie haben einen ähnlichen Funktionsumfang wie die ESP8266-Sourcen (Einrichtungsmanager, OTA-Update, optionales MQTT, ...). Die Sourcen und die Images befinden sich auf github unter "Releases". Für das OTA-Update ist die Releasenummer ohne das "v" anzugeben (d.h. für den ESP8266 aktuell die "11").

@eki Sorry für die Entführung und das Vollspamen deines Threads mit dem ESP-Zeugs 8)
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

So, um mal den Thread wieder zurück zu kapern, das Modul ist jetzt auch Teil des normalen FHEM Packets und kommt mit normalen updates mit.
Ich werde hier also nur noch Testversionen posten, die aktuell freigegebene Version kommt ab heute über das normale FHEM Update.

Andreas.H18

Moin

@eki Darf ich fragen auf welchem System du das Modul entwickelst?

Ich versuche seit einiger Zeit XML::LibRSVG auf einem Raspberry 3B+ (Buster) zu installieren, scheitere jedoch daran, dass der Compiler Dateien nicht findet. Die entsprechenden Biblietheken habe ich nach und nach installiert (apt install ...), diese landen auch in /usr/include/ , nur sieht der compiler dort nicht hin.

Installationsversuch:
cpanm (App::cpanminus) 1.7044 on perl 5.028001 built for arm-linux-gnueabihf-thread-multi-64int
Work directory is /home/pi/.cpanm/work/1584900022.1401
You have make /usr/bin/make
You have LWP 6.43
You have /bin/tar: tar (GNU tar) 1.30
Copyright © 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Geschrieben von John Gilmore und Jay Fenlason.
You have /usr/bin/unzip
--> Working on .
Entering /usr/include
Configuring /usr/include
-> N/A
-> FAIL The distribution doesn't have a proper Makefile.PL/Build.PL See /home/pi/.cpanm/work/1584900022.1401/build.log for details.
Searching XML::LibRSVG () on cpanmetadb ...
--> Working on XML::LibRSVG
Fetching http://www.cpan.org/authors/id/M/MS/MSERGEANT/XML-LibRSVG-0.01.tar.gz
-> OK
Unpacking XML-LibRSVG-0.01.tar.gz
Entering XML-LibRSVG-0.01
META.yml/json not found. Creating skeleton for it.
Configuring XML-LibRSVG-0.01
Running Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for XML::LibRSVG
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.44)
Building and testing XML-LibRSVG-0.01
cp LibRSVG.pm blib/lib/XML/LibRSVG.pm
Running Mkbootstrap for LibRSVG ()
chmod 644 "LibRSVG.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- LibRSVG.bs blib/arch/auto/XML/LibRSVG/LibRSVG.bs 644
"/usr/bin/perl" "/usr/share/perl/5.28/ExtUtils/xsubpp"  -typemap '/usr/share/perl/5.28/ExtUtils/typemap' -typemap '/home/pi/.cpanm/work/1584900022.1401/XML-LibRSVG-0.01/typemap'  LibRSVG.xs > LibRSVG.xsc
mv LibRSVG.xsc LibRSVG.c
arm-linux-gnueabihf-gcc -c  -I/usr/include/libxml2 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/usr/lib/arm-linux-gnueabihf/perl/5.28/CORE"   LibRSVG.c
LibRSVG.xs:13:10: fatal error: gdk-pixbuf/gdk-pixbuf.h: Datei oder Verzeichnis nicht gefunden
#include <gdk-pixbuf/gdk-pixbuf.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:336: LibRSVG.o] Fehler 1
-> FAIL Testing XML::LibRSVG failed. See /home/pi/.cpanm/work/1584900022.1401/build.log for details. Retry with --force to force install it.


die gesuchte Datei:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf

Compiler-pfade:
pi@rasfhem:~ $ arm-linux-gnueabihf-gcc -print-search-dirs
install: /usr/lib/gcc/arm-linux-gnueabihf/8/
programs: =/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/
libraries: =/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/lib/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../:/lib/arm-linux-gnueabihf/8/:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/8/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/


:GD und Image::LibRSVG sind installiert.

Irgendwelche Ideen?

LG Andreas

eki

Ich fürchte, dass ich da einen falschen Link in der Doku eingebaut habe (ich hatte damit mal experimentiert). Ich verwende lediglich Image:LibRsvg. Müsste also ach ohne XML:LibRsvg gehen.