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

Andreas.H18

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

arthur_dent_2015

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

Jendaw

Zitat von: arthur_dent_2015 am 23 März 2020, 17:34:08
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)

Maista

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

eki

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.

Jendaw

Zitat von: eki am 24 März 2020, 13:02:09
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)

eki

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.

Jendaw

Zitat von: eki am 24 März 2020, 14:12:34
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)

Andreas.H18

@ 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

eki

Zitat von: Jendaw am 24 März 2020, 14:22:10
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.

Andreas.H18

@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

Jendaw

Zitat von: eki am 25 März 2020, 11:05:31
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.
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)

pepe_11

Zitat von: Jendaw am 11 März 2020, 16:31:37
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

Jendaw

Hallo Peter, danke für den Test! Ich habe gleich einen neuen Thread für die Firmware erstellt.

Zitat von: pepe_11 am 30 März 2020, 15:49:41
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)

pepe_11

Zitat von: Jendaw 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.
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