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

Offline eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1405
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.

Offline kkoeniger

  • Full Member
  • ***
  • Beiträge: 132
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.
LG,
Karl

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
sollte jetzt auch bezüglich NOTIFYDEF für definitionfile gehen.
Geht nach einem FHEM-Restart  :D

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).
« Letzte Änderung: 04 März 2020, 14:57:37 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 eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1405
Zitat
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.

Das geht bisher nicht, kommt auf die Liste.

Offline kkoeniger

  • Full Member
  • ***
  • Beiträge: 132
@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.
LG,
Karl

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
ESPEInk: ESP32-Sourcen II
« Antwort #170 am: 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
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
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
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
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)
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
    « Letzte Änderung: 08 März 2020, 11:10:03 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 Maista

    • Sr. Member
    • ****
    • Beiträge: 517
    • Alles nur Hobby!
    @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

    Offline Jendaw

    • Full Member
    • ***
    • Beiträge: 111
      • Alternative ESPEInk-Firmware
    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.
    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 Jendaw

    • Full Member
    • ***
    • Beiträge: 111
      • Alternative ESPEInk-Firmware
    ESPEInk: ESP32-Sourcen III
    « Antwort #173 am: 08 März 2020, 11:08:26 »
    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
    « Letzte Änderung: 08 März 2020, 11:10:36 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 Maista

    • Sr. Member
    • ****
    • Beiträge: 517
    • Alles nur Hobby!
    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  :o

    Ich bleib dran.

    Danke und Gruß
    Gerd
    « Letzte Änderung: 08 März 2020, 11:47:52 von Maista »

    Offline pepe_11

    • New Member
    • *
    • Beiträge: 33
    @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

    Offline kkoeniger

    • Full Member
    • ***
    • Beiträge: 132
    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.
    LG,
    Karl

    Offline Maista

    • Sr. Member
    • ****
    • Beiträge: 517
    • Alles nur Hobby!
    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
    « Letzte Änderung: 09 März 2020, 18:16:13 von Maista »

    Offline Maista

    • Sr. Member
    • ****
    • Beiträge: 517
    • Alles nur Hobby!
    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

    Offline pepe_11

    • New Member
    • *
    • Beiträge: 33


    @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

     

    decade-submarginal