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

eki · 03 März 2020, 16:52:02

Zitat von: kkoeniger am 03 März 2020, 09:27:45
Das scheint mir immer dann aufzutreten, wenn das picturefile der devicedefinition im Unterordner (zB /opt/fhem/www/images/eDisplayFlex/) des Displays liegt. Seit ich es in den Ordner /opt/fhem/www/images/ verschoben habe, wird das device nicht mehr gelöscht.

Die Ordner, die in Images mit dem Namen des Devices angelegt werden, kommen vom Modul ESPEInk selbst. Dort sollten eigentlich nur die temporären Daten des Devices verwaltet werden (die Ordner werden vom Modul bei define angelegt und bei delete auch wieder aufgeräumt). Wie genau der von Dir genannte Seiteneffekt zustande kommt (zumal noch bei reload des Moduls oder so) muss ich auch erst mal schauen. Aber der Hinweise war schon mal weiterführen, danke.

kkoeniger · 03 März 2020, 16:56:23

Danke für die Erklärung. Passt ja wenn ich es weiß.
Ich würde einfach in die device specific help reinschreiben, dass in diese Ordner keine picturefiles reingehören. Damit würden sich weitere Nachforschungen erübrigen.

Jendaw · 04 März 2020, 14:23:56

Zitat von: eki am 03 März 2020, 14:38:39
sollte jetzt auch bezüglich NOTIFYDEF für definitionfile gehen.

Geht nach einem FHEM-Restart

Wie konfiguriere ich das Modul so, dass zwar eine automatische Konvertierung, nicht jedoch ein Upload durchgeführt wird? Wäre ein zusätzliches Attribut "doUpload" (o.ä.) mit dem Default=1 denkbar? Mit dieser Konstellation kann ich ein DOIF triggern, welches nach erfolgter Konvertierung (ggf. noch Vergleich mittels md5, ob sich etwas am Bild geändert hat) ein MQTT-Topic setzt, welches nach dem Aufwachen des ESPs abgefragt werden kann. Der ESP kann dann seinerseits den Webserver starten und einen Upload per MQTT-Topic in einem zweiten DOIF triggern.

edit
Zum experimentieren (Fehlerbehandlung gibt es noch nicht wirklich) hab ich die angepassten ESP32-waveshare-Sourcen (zur Besseren Übersicht zusätzlich als Patch) angehängt. In der srvr.h müssen die eigenenen WLAN-Credentials sowie MQTT-Daten eingetragen werden. Da der ESP in den Sleep geht, subscribed er auf ein Topic (Setzen bspw mit "mosquitto_pub -q 1 -d -t epaper/needUpdate -m true"), welches mit QOS=1 auf der Serverseite persistiert werden muss. Findet er im Topic den Wert "true", so startet er seinerseits den Webserver und publisht auf dem State-Topic ein "rdy", welches als Trigger für den Upload genutzt wird).
Die DOIFs habe ich leider noch nicht fertig, hier habe ich noch Probleme die Nachricht mit QOS=1 abzusetzen (kann MQTT2_* leider nicht, "retain" ist hierfür ungeeignet, da es bestehen bleibt).

eki · 04 März 2020, 17:42:48

ZitatWie konfiguriere ich das Modul so, dass zwar eine automatische Konvertierung, nicht jedoch ein Upload durchgeführt wird? Wäre ein zusätzliches Attribut "doUpload" (o.ä.) mit dem Default=1 denkbar? Mit dieser Konstellation kann ich ein DOIF triggern, welches nach erfolgter Konvertierung (ggf. noch Vergleich mittels md5, ob sich etwas am Bild geändert hat) ein MQTT-Topic setzt, welches nach dem Aufwachen des ESPs abgefragt werden kann. Der ESP kann dann seinerseits den Webserver starten und einen Upload per MQTT-Topic in einem zweiten DOIF triggern.

Das geht bisher nicht, kommt auf die Liste.

kkoeniger · 06 März 2020, 15:29:18

@Midrag hat in einem Forumsbeitrag: https://forum.fhem.de/index.php/topic,87778.msg1029755.html#msg1029755 ein Gehäuse für das Waveshare 7,5" 800x480 Display gepostet, das man sich - auf dem 3D-Drucker - selbst ausdrucken kann.

Jendaw · 06 März 2020, 16:43:55

Ich habe ein wenig Zeit gefunden und auch den FHEM-Part mittels MQTT umgesetzt, vllt. ist es für den ein oder anderen interessant. Mein Vorgehen ist wie folgt:

das Attribut "interval" in ESPEInk steht auf einem hohen Wert, da kein automatischer Upload erfolgen soll
ein DOIF triggert die Konvertierung
ein weiteres DOIF reagiert auf Änderungen im ESPEInk-Reading "result_picture" und setzt das MQTT-Topic "stat/flur/system_display/needUpdate" mit dem QOS 1 (=wird im MQTT-Server zwischengespeichert, solange der ESP schläft)
ein MQTT_DEVICE wartet auf das ESP-Signal im Topic "cmd/flur/system_display/upload"
der ESP erwacht und befragt das Topic "stat/flur/system_display/needUpdate", ob es was zu tun gibt. Falls nicht, geht er wieder schlafen (Wachzeit ~ 5s).
falls es etwas zu tun gibt, startet der ESP seinen Webserver und setzt das MQTT-Topic "cmd/flur/system_display/upload"
das MQTT_DEVICE reagiert darauf und startet den ESPEink-upload

Benötigt werden:

ESPEInk

Code Auswählen

defmod system_display ESPEInk /opt/fhem/www/images/displayBackground.png
attr system_display boardtype ESP32
attr system_display colormode color
attr system_display convertmode level
attr system_display definitionFile /opt/fhem/FHEM/eink.cfg
attr system_display devStateIcon Starting.conversion.in.background:hm-dis-wm55@green Finished.conversion.in.background:hm-dis-wm55@yellow Uploading.image.to.device:hm-dis-wm55@red Successfully.uploaded.image.to.device:hm-dis-wm55@grey
attr system_display devicetype 7.5inch_e-Paper_HAT_(B)
attr system_display icon hm-dis-wm55
attr system_display interval 48600
attr system_display picturefile /opt/fhem/www/images/displayBackground.png
attr system_display timeout 50
attr system_display url eink-panel

mosquitto als MQTT-Server (MQTT2_* kann leider kein QOS)
MQTT als Verbindung zu mosquitto

Code Auswählen

defmod mqtt_device MQTT <mqtt-server>:1883

ein DOIF als Trigger für die Konvertierung (derzeit ist die Konvertierung und der Upload noch gekoppelt), im Beispiel reagiere ich auf die Änderungen in einem dummy-Device "system_display_status", welches bereits alle relevante Informationen enthält

Code Auswählen

defmod system_display_status_doif DOIF ([system_display_status]) (\
    set system_display convert\
)
attr system_display_status_doif do always

ein DOIF, welches bei einem Update des konvertierten ESPEInk-Bildes reagiert und das Topic mit qos=1 setzt

Code Auswählen

defmod system_display_doif DOIF ([system_display:result_picture]) (\
    set mqtt_device publish qos:1 stat/flur/system_display/needUpdate true\
)
attr system_display_doif do always

ein MQTT_DEVICE um auf die Nachrage des ESP zu reagieren (wichtig ist, dass das Attribut "subscribeReading_cmd" heißt, ansonsten wird das FHEM-Kommando nicht ausgeführt, zumindest nicht in meinen Tests)

Code Auswählen

defmod system_display_mqtt MQTT_DEVICE
attr system_display_mqtt IODev mqtt_device
attr system_display_mqtt subscribeReading_cmd {fhem("set system_display upload")} cmd/flur/system_display/upload

ESP-Sourcen sowie zusätzlich das diff sind anghängt.

edit bei mir bleibt das Display noch ab und an hängen, hier muss ich noch schauen, woran es liegt.
edit2 mit dem ESP32-Code vom 08.03. bleibt mein Display nicht mehr hängen

Maista · 07 März 2020, 20:36:21

@Jendaw

Danke für deine Daten. Muss ich mal probieren ob dein Code sich bei mir eher mit der Fritzbox verbinden mag.
Funktioniert das den bei Dir stabil (an einer Fritzbox)?

Habe jetzt am Wochenende leider keine Motivation gehabt. Lag ab Mittwoch für 2 Tage im Bett (zum Glück kein Corona).

Bis jetzt ist die Motivation auch sehr begrenzt deswegen.

Bin ich gespannt ob deine Version eher mit der FB sprechen mag. Eine Wirkliche Erklärung habe ich nicht im Netz gefunden warum sich der ESP32 hier so zickig verhält.

Ansonsten versuch ichs mit dem ESP8266

Gruss Gerd

Jendaw · 07 März 2020, 21:05:47

Zitat von: Maista am 07 März 2020, 20:36:21
Funktioniert das den bei Dir stabil (an einer Fritzbox)

Mit dem reconnect hatte ich nie Probleme (auch an einer FriBo). Der Code lässt den ESP32 allerdings auch nur eine Minute schlafen. Was für ein ESP32-Board hast du? Ich habe ein ESP32 WROOM Devkit v1 Board. Es bekommt eine statische IP-Adresse per DHCP, vllt ist das ein Punkt?
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.

Jendaw · 08 März 2020, 11:08:26

Zitat von: Jendaw am 07 März 2020, 21:05:47
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.

Zwei Änderungen im ESP32-Code sind hinzugekommen, die die Stabilität (zumindest bei mir) erhöhen:
* es werden (bis zu) 100 Updatemeldungen bei jedem Durchlauf abgeholt, damit werden Mehrfachmeldungen während des Sleeps als eine Meldung bearbeitet
* Timeout für den Webserver eingebaut, damit er nicht endlos wartet, falls es Kommunikationsprobleme gibt

Maista · 08 März 2020, 11:44:08

Zitat von: Jendaw am 07 März 2020, 21:05:47
Mit dem reconnect hatte ich nie Probleme (auch an einer FriBo). Der Code lässt den ESP32 allerdings auch nur eine Minute schlafen. Was für ein ESP32-Board hast du? Ich habe ein ESP32 WROOM Devkit v1 Board. Es bekommt eine statische IP-Adresse per DHCP, vllt ist das ein Punkt?
Aktuell habe ich nur das Problem, dass das Display einfriert und nicht mehr ansprechbar ist. Ursache ist noch unbekannt.

Ich habe das Original waveshare ESP32 Board.
Ich hatte mein Code so weit umgebogen das ich alles relevante im Code eingestellt habe.
Erst danach konnte der ESP sich mit der FB verbinden.
Meine Dauerlauf Versuche hatte ich auf 30sekunden gesetzt.
Maximum ohne Aussetzer waren 243 booten hinterreinnander.

Das funktionierte auch manchmal mit vielen connects.
Manchmal aber schon nach dem 6mal mit Unlust.
Manchmal Verband sich der ESP auch noch aber blieb dann stehen.

Und irgendwann war das Wochenende und Fasnacht vorbei und meine Lust ebenso.

Wie ich davor schon schrieb scheint das ein bekanntes Problem zu sein ohne eindeutigen Lösungsweg.

Im Moment nehme ich auch noch mit der Couch vorlieb

Ich bleib dran.

Danke und Gruß
Gerd

pepe_11 · 08 März 2020, 21:32:03

Zitat von: Maista am 07 März 2020, 20:36:21
@Jendaw

Danke für deine Daten. Muss ich mal probieren ob dein Code sich bei mir eher mit der Fritzbox verbinden mag.
Funktioniert das den bei Dir stabil (an einer Fritzbox)?

Habe jetzt am Wochenende leider keine Motivation gehabt. Lag ab Mittwoch für 2 Tage im Bett (zum Glück kein Corona).

Bis jetzt ist die Motivation auch sehr begrenzt deswegen.

Bin ich gespannt ob deine Version eher mit der FB sprechen mag. Eine Wirkliche Erklärung habe ich nicht im Netz gefunden warum sich der ESP32 hier so zickig verhält.

Ansonsten versuch ichs mit dem ESP8266

Gruss Gerd

ich kann die reconnect Probleme mit FB bestätigen.

Gruß
Peter

kkoeniger · 09 März 2020, 17:29:46

Kann es sein, dass der DEVICETYPE "7.5inch_e-Paper_HAT_V2_(B)" in der Vorschau gelb angezeigt wird obwohl er rot ist? Auch die Farbdefinition FF0000 nutzt nichts - immer gelb. Am Display selbst kann ich es nicht testen, da ich keines habe.

Maista · 09 März 2020, 18:14:36

Moin zusammen,

@Jendaw
Konnte mich heute wieder aufraffen :

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.

@pepe_11
Im Anhang meine Version der Sourcen (Übername vom Icinger). Ich habe hier diverse Ausgaben eingebaut um zu sehen ob sich da mit irgend welchen Änderungen besser klappt.
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Vielleicht probierst DU damit ob deine Fritte eher gewillt ist sich connecten zu lassen.
Ich gebe die SSID, PW, Kanal (Zeile 52 in srvr.h), die IP, Gateway, Subnet, Hostname (Zeile 75 in srvr.h) mit an.
Erst damit wollte sich der ESP eher mit der FB verbinden.
Ohne Angabe des Gateway & Subnet gab es zudem beim compilieren Fehlermeldungen (wieso auch immer).
Im Kopf von der srvr.h stehen zudem die (Fehler)Codes welche beim Status ausgegeben werden können.

Bei der Kanalwahl ist zu beachten (Zeile 52 in srvr.h), das hier bei NULL angefangen wird zu zählen

Wenn man wie ich, auf Kanal 13 schalten will, ist im Source "12" einzugeben (muss man erst mal drauf kommen ....).

Hier also meine zwei Sourcen zum probieren. Am MQTT vom Icinger habe ich nichts verändert.

Viel Erfolg

Gerd

Maista · 09 März 2020, 18:42:30

So, der ESP8266 funktioniert schon mal im Prinzip.
Jetzt fehlt noch das DeepSleep.
Hat das schon jemand in seinem ESP8266-Source eingebaut und kann das hier einspielen?

Danke schon mal.

Gruss Gerd

pepe_11 · 09 März 2020, 19:55:39

Zitat von: Maista am 09 März 2020, 18:14:36

@pepe_11
Im Anhang meine Version der Sourcen (Übername vom Icinger). Ich habe hier diverse Ausgaben eingebaut um zu sehen ob sich da mit irgend welchen Änderungen besser klappt.
MQTT ist da so lange unwichtig wie sich das Teil nicht zuverlässig verbindet.

Vielleicht probierst DU damit ob deine Fritte eher gewillt ist sich connecten zu lassen.
Ich gebe die SSID, PW, Kanal (Zeile 52 in srvr.h), die IP, Gateway, Subnet, Hostname (Zeile 75 in srvr.h) mit an.
Erst damit wollte sich der ESP eher mit der FB verbinden.
Ohne Angabe des Gateway & Subnet gab es zudem beim compilieren Fehlermeldungen (wieso auch immer).
Im Kopf von der srvr.h stehen zudem die (Fehler)Codes welche beim Status ausgegeben werden können.

Bei der Kanalwahl ist zu beachten (Zeile 52 in srvr.h), das hier bei NULL angefangen wird zu zählen
Wenn man wie ich, auf Kanal 13 schalten will, ist im Source "12" einzugeben (muss man erst mal drauf kommen ....).

Hier also meine zwei Sourcen zum probieren. Am MQTT vom Icinger habe ich nichts verändert.

Viel Erfolg

Gerd

Hi Maista,

habe gerade deine Sourcen aufgespielt. Ich hatte an der FB Kanal 9 eingestellt gehabt (am ESP 8 eingetragen). Damit wollte der ESP nicht connecten. Mit dem Kanal 13 läuft es, sehr dubios. Grr..
Ich lasse das jetzt laufen und schaue, ob der dauertest genauso funktioniert und bin auf deep Sleep gespannt. Danke

Gruß
Peter