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

Offline Andreas.H18

  • New Member
  • *
  • Beiträge: 4
OH
Danke für die Antwort - leider sehe ich die SVG icons nicht alle auf dem convertierten Bild.
Es kommt immer nur das FHEM Häuschen beim Wetter - Forecast.

Layer 8 Fehler mal wieder - die beiden anderen Icons werden ja korrekt angezeigt.
..ich such mal weiter...

edit:
interressant, das wird als fhemicon.png convertiert:
8-angle   0
8-blockwidth   0
8-color   000000
8-def   iconreading#DarkSkyweather:fc1_icon#10#50#80
8-icon   sunny
8-isIcon   1
8-linegap   0
8-size   70
8-trigger   DarkSkyweather:fc1_icon
8-x   10
8-y   55

aber das als sunny.png:
1-angle   0
1-color   000000
1-def   addicon#temp_temperature#10#30#25
1-icon   sunny
1-isIcon   1
1-size   25
1-x   10
1-y   15

Edit2:
Habe die gleichnamigen Ikonendateien bereinigt und verwende für das EInkdisplay andere Namen. Damit funktionierts.

LG Andreas
« Letzte Änderung: 24 März 2020, 11:44:19 von Andreas.H18 »

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 258
muss es unbedingt waveshare sein oder funktioniert der Sketch auch mit andere eInk Displays z.B dem Inkplate 6 https://www.crowdsupply.com/e-radionica/inkplate-6 ?

Gruß
Arthur

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
muss es unbedingt waveshare sein oder funktioniert der Sketch auch mit andere eInk Displays z.B dem Inkplate 6 https://www.crowdsupply.com/e-radionica/inkplate-6 ?

Die in diesem Thread vorgestellten Sketche sind (meist) auf Basis der waveshare-Treiber erstellt worden. Beim Inkplate wird die Darstellung im ESP mittels GFX-Library gerendert, in diesem Projekt hier wird bereits in FHEM das Bild berechnet und "nur noch" hochgeladen. Zudem hat es andere technische Daten als die Waveshare-Displays - ich fürchte, es ist inkompatibel mit den waveshare-Displays.
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)

Online Maista

  • Sr. Member
  • ****
  • Beiträge: 514
  • Alles nur Hobby!
Moin

Wenn man sich das Video anschaut und etwas weiter liest findet man Vergleiche zwischen
dem Inkplate und Waveshare Display.

https://www.crowdsupply.com/e-radionica/inkplate-6#details-top


Von daher ist das vermutlich andere Technik.

Gruß Gerd

Offline eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1394
Ich habe mir die Seite mal angeschaut. Aktuell ist das komplett anders als die waveshare displays. Das Teil hat zwar einen ESP32 drin, aber aktuell wohl keine Software fertig, mit der man per WLAN da Daten rüber schieben kann (das Einzige, was ich gelesen habe, waren Anwendungen, die aus SD Karte oder über USB Daten auf das Display schaufeln). Das müsste aber jemand machen, der das Modul zur Verfügung hat.
Was man machen müsste (zumindest) wäre, einen Webserver auf den Arduino bringen, der Bilder entgegen nimmt und dann auf das Display schiebt. Falls das vorhanden wäre, könnte ich das sicher auch in das FHEM Modul mit einbauen.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Was man machen müsste (zumindest) wäre, einen Webserver auf den Arduino bringen, der Bilder entgegen nimmt und dann auf das Display schiebt. Falls das vorhanden wäre, könnte ich das sicher auch in das FHEM Modul mit einbauen.
Mit der Inkplate-Lib könnte man die Bilder als Vollbild darstellen. Webserver ist auch kein Problem. Zusätzlich müsste man sich noch anschauen, wie das Image zwischengespeichert wird, das macht der Waveshare-Treiber direkt.
Als Übertragungsprotokoll könnte man dann das bisherige ESP32-Protokoll nutzen, kommt ja nur auf das Bild an.
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)

Offline eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1394
Wenn das Arduino image direkt mit Bildern, die über WLAN reinkommen in irgendeiner Form umgehen kann, dann passe ich das EInk Modul gern an (das aktuelle Übertragungsprotokoll ist direkt an den Webserver von Waveshare angepasst, das wird so direkt keinen Sinn machen.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Wenn das Arduino image direkt mit Bildern, die über WLAN reinkommen in irgendeiner Form umgehen kann, dann passe ich das EInk Modul gern an (das aktuelle Übertragungsprotokoll ist direkt an den Webserver von Waveshare angepasst, das wird so direkt keinen Sinn machen.
Wird das Bild nicht nur zerstückelt oder wird es noch irgendwie umgerechnet? Falls ersteres, würde es den Pflegeaufwand in ESPEInk verringern, ggf. kann man auch ein Sketch für beides nehmen. Beim nächsten Display geht es dann von vorn los...
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)

Offline Andreas.H18

  • New Member
  • *
  • Beiträge: 4
@ eki

Vielen Dank für das Modul!  :)

Ich verwende jetzt auch 'definitionFile' und habe damit keine Unklarheiten bei der Iconsuche, es darf halt nur eins gefunden werden

LG Andreas

Offline eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1394
Wird das Bild nicht nur zerstückelt oder wird es noch irgendwie umgerechnet? Falls ersteres, würde es den Pflegeaufwand in ESPEInk verringern, ggf. kann man auch ein Sketch für beides nehmen. Beim nächsten Display geht es dann von vorn los...

Das Bild wird nicht nur zerstückelt. In der aktuellen Version macht das Modul schon etwas mehr. Letztendlich bildet das Modul das komplette Waveshare Protokolle als Gegenstück zur Arduino Seite nach. Dazu gehören Aufteilung in Päckchen entsprechend der maximalen Datengrößen für die Übertragung, aber auch das Umrechnen der Pixelinformationen in ASCII Zeichen so wie die Arduino Software das braucht, das Aufteilen in die verschiedenen Farbkanäle und sequentielles Schicken dieser Teilinformationen. Außerdem gibt es noch einige spezielle Dinge die von der Art des Displays abhängen.
Ich sehe eingentlich 2 Möglichkeiten:
1. Das ESP Modul macht die Unterscheidung und muss sich dann an alle möglichen neuen Displays anpassen (viel Aufwand auf meiner Seite  :-\)
2. Wir definieren eine Art generisches Protokoll zwischen dem Modul und Arduino und der Aufwand für die Anpassung an die jeweiligen Displays findet im Arduino statt. Dann bräuchten wir aber einen Freiwilligen, der die Arduino Seite betreut, dazu reicht meine Freie Zeit trotz Corona leider nicht.
« Letzte Änderung: 25 März 2020, 11:08:19 von eki »

Offline Andreas.H18

  • New Member
  • *
  • Beiträge: 4
@eki

Moin!

Anmerkung:
Beim Neustart des fhem Servers kommt es bei mir vor, dass diverse mqtt-Geräte noch nicht 'anwesend' sind.

Das führt zu diesen Logeinträgen (readings haben keine Werte, da nicht vorhanden):

2020.03.26 09:36:30 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/89_ESPEInk.pm line 644.
.
.
.
2020.03.26 09:36:31 1: PERL WARNING: Use of uninitialized value $text in split at ./FHEM/89_ESPEInk.pm line 552.
2020.03.26 09:36:31 1: PERL WARNING: Use of uninitialized value $text in split at ./FHEM/89_ESPEInk.pm line 553.

...funktioniert natürlich trotzdem...

LG Andreas

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Ich sehe eingentlich 2 Möglichkeiten:
1. Das ESP Modul macht die Unterscheidung und muss sich dann an alle möglichen neuen Displays anpassen (viel Aufwand auf meiner Seite  :-\)
2. Wir definieren eine Art generisches Protokoll zwischen dem Modul und Arduino und der Aufwand für die Anpassung an die jeweiligen Displays findet im Arduino statt. Dann bräuchten wir aber einen Freiwilligen, der die Arduino Seite betreut, dazu reicht meine Freie Zeit trotz Corona leider nicht.
Das zweite klingt gut, wobei ich gerade wegen Corona (Ganztages-Kinderbetreuung) keine Zeit habe :)
Ansonsten könnte ich, falls überhaupt Bedarf besteht, die Betreuung übernehmen. Ich bin mir nicht mal sicher, ob meine bisherigen Änderungen überhaupt jmd. nutzt oder diese auf anderer Hardware funktionieren.
« Letzte Änderung: 30 März 2020, 11:14:51 von Jendaw »
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)

Offline pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:ESPEInk: ESP8266-Sourcen II
« Antwort #207 am: 30 März 2020, 15:49:41 »
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
Hallo Jendaw,

ich habe mich heute mit dem ES8266 beschäftigt da ein ESP bei mir frei geworden ist. Alles nach deiner Anleitung auf dem FHEM konfiguriert und deine Sourcen ohne Probleme kompiliert.
Nach dem Flashen wie erwartet meine AP Daten + Mqtt Server eingetragen. Das ESP startet und Verbindet sich mit dem AP aber der Webserver ist nicht da.

Hier das Protokoll:
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: server
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: port
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: updateTopic
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: commandTopic
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: sleepTime
15:31:26.824 -> *WM: Adding parameter
15:31:26.824 -> *WM: firmwareUrl
15:31:26.824 -> *WM:
15:31:26.824 -> *WM: AutoConnect
15:31:26.824 -> *WM: Connecting as wifi client...
15:31:26.824 -> *WM: Status:
15:31:26.824 -> *WM: 6
15:31:26.824 -> *WM: Using last saved values, should be faster
15:31:29.723 -> *WM: Connection result:
15:31:29.723 -> *WM: 3
15:31:29.757 -> *WM: IP Address:
15:31:29.757 -> *WM: 192.168.8.45
15:31:29.757 -> Connected.
15:31:29.757 -> *WM: freeing allocated params!
15:31:29.757 ->  MQTT Server: 192.168.8.35 :1883, Client: ESPEInk_ecfabcc2b1a9
15:31:29.757 ->  MQTT UpdateStatusTopic: stat/display/needUpdate
15:31:29.757 ->  MQTT CommandTopic: cmd/display/upload
15:31:29.757 ->  sleep time: 60
15:31:29.757 ->  firmware base URL:
15:31:29.757 -> Setup complete.
15:31:29.757 -> Connecting to MQTT...
15:31:29.790 ->  subscribed to stat/display/needUpdate
15:31:29.790 ->  reconnected, waiting for incoming MQTT message
15:31:39.795 -> Going to sleep for 60 seconds.
15:32:36.401 -> sd $ܟ<


Was noch seltsam ist, sind nach dem Aufwachen irgendwelche wilde Zeichen, der der ESP anzeigt (die bekomme ich per copy and paste nicht hier eingefügt).
Mit deiner bin, die Du mal hier hochgeladen hast, funktioniert der WebServer und der Upload tadellos.

VG
Peter

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:ESPEInk: ESP8266-Sourcen II
« Antwort #208 am: 30 März 2020, 17:22:11 »
Hallo Peter, danke für den Test! Ich habe gleich einen neuen Thread für die Firmware erstellt.

Nach dem Flashen wie erwartet meine AP Daten + Mqtt Server eingetragen. Das ESP startet und Verbindet sich mit dem AP aber der Webserver ist nicht da.
Der Webserver wird bei MQTT-Verwendung erst gestartet, wenn das Topic stat/display/needUpdate ein "true" enthält, also geänderte Daten zur Übertragung bereitstehen (aus diesem Grund ist die MQTT-Wachzeit auch kürzer und Display-schonender, da nur bei Bedarf ein Update erfolgt).

Zitat
15:31:39.795 -> Going to sleep for 60 seconds.
15:32:36.401 -> sd $ܟ<


Was noch seltsam ist, sind nach dem Aufwachen irgendwelche wilde Zeichen, der der ESP anzeigt (die bekomme ich per copy and paste nicht hier eingefügt).
Mit deiner bin, die Du mal hier hochgeladen hast, funktioniert der WebServer und der Upload tadellos.
Das gucke ich mir mal an, weißt du noch, welche Version das war, die du vorher genutzt hast (hatte die bereits den WifiManager und deepsleep)? Nutzt du das ESP8266-Board v2 von waveshare?

Können wir die Diskussion hier weiter verfolgen?
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)

Offline pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:ESPEInk: ESP8266-Sourcen II
« Antwort #209 am: 30 März 2020, 17:37:06 »
Hallo Peter, danke für den Test! Ich habe gleich einen neuen Thread für die Firmware erstellt.
Der Webserver wird bei MQTT-Verwendung erst gestartet, wenn das Topic stat/display/needUpdate ein "true" enthält, also geänderte Daten zur Übertragung bereitstehen (aus diesem Grund ist die MQTT-Wachzeit auch kürzer und Display-schonender, da nur bei Bedarf ein Update erfolgt).
Das gucke ich mir mal an, weißt du noch, welche Version das war, die du vorher genutzt hast (hatte die bereits den WifiManager und deepsleep)? Nutzt du das ESP8266-Board v2 von waveshare?

Können wir die Diskussion hier weiter verfolgen?

Hi Jendaw,

ich habe die bin aus dem Beitrag #181 installiert, diese wenn ich mich richtig erinnere war ohne deep sleep aber dafür mit WifiManager. Ich nutze den D1 mini mit 2.13 Display

Viele Grüße
Peter