Erweiterung der waveshare-Treiber um WifiManager, MQTT, OTA-Update und deepsleep

m.zielinski · 26 Mai 2021, 15:35:53

Ich benutze die vorcompilierrte ESPEInk_ESP8266.ino.bin aus dem github vom 2.11.2020

Frisch geflasht auf einen waveshare esp8266. Dann habe ich mich mit dem AP verbunden und die Wifi daten hintelegt sowie die IP des Mosquitto

Seitdem geht nach ca 1 Minute die rote LED an und bleibt. Das Display aktualisiert sich gar nicht.
Im Seriellen Debug scheint sich nach dem Deepspleep die Baudrate zu ändern, die rote LED geht an und bleibt an.
Das die LED geht NICHT an, wenn der Mosquitto nicht gestartet ist. - Dann bleibt das Protokoll aber auch entsprechend früher hängen.

Wenn die rote LED an ist, bleibt ürbiges auch fhem hängen bis ich den mosquitto ausschalte - scheinbar beim Upload.

In der Doku sollte auch erwähnt werden dass der Name des epaper-device in Fhem unbedingt display sein muss (bei deinem Beispielcode)

Ein paar Debugausgaben:

Code Auswählen



14:19:54.304 -> ESPEInk_ESP8266 v17, reset reason='Deep-Sleep Wake'...
14:19:54.304 -> Entering setup...
14:19:54.368 ->  Reading config file...
14:19:54.368 ->  Config file read.
14:19:54.368 ->  Connecting to WiFi...
14:19:57.282 ->  Connected to WiFi.
14:19:57.282 ->  Using configuration:
14:19:57.282 ->   MQTT Server: 192.168.1.45:1883, Client: ESPEInk_24a1603bdc22
14:19:57.282 ->   MQTT UpdateStatusTopic: stat/display/needUpdate
14:19:57.282 ->   MQTT CommandTopic: cmd/display/upload
14:19:57.282 ->   sleep time: 60
14:19:57.282 ->   firmware base URL: 
14:19:57.282 -> Setup complete.
14:19:57.282 -> Connecting to MQTT...
14:19:57.322 ->  Subscribed to stat/display/needUpdate
14:19:57.322 ->  Reconnected, waiting for incoming MQTT messages...
14:19:58.303 ->  No update available.
14:19:58.303 -> Disconnecting from MQTT...
14:19:58.343 -> 
14:19:58.343 -> Going to sleep for 60 seconds.
14:19:58.343 -> 
14:20:56.522 -> rl (danach wirre Zeichen - als ob die Baudrate nicht stimmt) 
gleichzeitig geht die LED an und bleibt an (rot)


Bei 74880Baud
⸮⸮⸮ ⸮⸮⸮  8 2013,rst cause:5, boot mode:(3,6)
14:52:32.572 -> 
14:52:32.572 -> ⸮⸮⸮⸮⸮⸮⸮⸮.⸮ 



pi@raspberrypi:~ $ mosquitto -v
1622032553: mosquitto version 1.5.7 starting
1622032553: Using default config.
1622032553: Opening ipv4 listen socket on port 1883.
1622032553: Opening ipv6 listen socket on port 1883.
1622032558: New connection from 192.168.1.97 on port 1883.
1622032558: New client connected from 192.168.1.97 as ESPEInk_24a1603bdc22 (c0, k15).
1622032558: No will message specified.
1622032558: Sending CONNACK to ESPEInk_24a1603bdc22 (0, 0)
1622032558: Received SUBSCRIBE from ESPEInk_24a1603bdc22
1622032558:     stat/display/needUpdate (QoS 1)
1622032558: ESPEInk_24a1603bdc22 1 stat/display/needUpdate
1622032558: Sending SUBACK to ESPEInk_24a1603bdc22
1622032559: Received DISCONNECT from ESPEInk_24a1603bdc22
1622032559: Client ESPEInk_24a1603bdc22 disconnected.
1622032606: New connection from 127.0.0.1 on port 1883.
1622032606: New client connected from 127.0.0.1 as Net::MQTT::Message[30339] (c1, k60).
1622032606: No will message specified.
1622032606: Sending CONNACK to Net::MQTT::Message[30339] (0, 0)
1622032606: Received PINGREQ from Net::MQTT::Message[30339]
1622032606: Sending PINGRESP to Net::MQTT::Message[30339]
1622032606: Received SUBSCRIBE from Net::MQTT::Message[30339]
1622032606:     cmd/display/upload (QoS 0)
1622032606: Net::MQTT::Message[30339] 0 cmd/display/upload
1622032606: Sending SUBACK to Net::MQTT::Message[30339]
1622032607: Received SUBSCRIBE from Net::MQTT::Message[30339]
1622032607:     cmd/display/upload (QoS 0)
1622032607: Net::MQTT::Message[30339] 0 cmd/display/upload
1622032607: Sending SUBACK to Net::MQTT::Message[30339]

Komme ich irgendwie an die Konfigurationsseite ? Die URL's zun resetten etc scheinen ihn nicht zu jucken. Neu Flashen löst das Problem auch nicht.

Jendaw · 27 Mai 2021, 10:29:22

Zitat von: m.zielinski am 26 Mai 2021, 15:35:53
Ich benutze die vorcompilierrte ESPEInk_ESP8266.ino.bin aus dem github vom 2.11.2020

Frisch geflasht auf einen waveshare esp8266. Dann habe ich mich mit dem AP verbunden und die Wifi daten hintelegt sowie die IP des Mosquitto

Seitdem geht nach ca 1 Minute die rote LED an und bleibt. Das Display aktualisiert sich gar nicht.

Was sagt dein FHEM-EInk-Gerät zu diesem Zeitpunkt? Passt das Attribut "url" noch zum ESP (in deinem Fall "192.168.1.97")? Steht etwas im FHEM-Log zu diesem Vorgang?

Zitat
Im Seriellen Debug scheint sich nach dem Deepspleep die Baudrate zu ändern, die rote LED geht an und bleibt an.
Das die LED geht NICHT an, wenn der Mosquitto nicht gestartet ist. - Dann bleibt das Protokoll aber auch entsprechend früher hängen.

Wenn die rote LED an ist, bleibt ürbiges auch fhem hängen bis ich den mosquitto ausschalte - scheinbar beim Upload.

Ich sehe in den Logs keine Anzeichen für ein Display-Upload. Es müsste dann so etwas wie "EPD_load" auf der Konsole ausgegeben werden. Warum FHEM hängen bleibt, erschließt sich mir aktuell noch nicht.

Zitat
In der Doku sollte auch erwähnt werden dass der Name des epaper-device in Fhem unbedingt display sein muss (bei deinem Beispielcode)

Ich weiß nicht genau, was du meinst. Das FHEM-Device kann beliebig benannt werden, es müssen nur die DOIFs und MQTT-Devices dazu passen. Der Pfad für die MQTT-Übertragung muss nur auf beiden Seiten gleich sein und kann sich vom FHEM-Namen unterscheiden.

Zitat
Ein paar Debugausgaben:

Code Auswählen Erweitern
14:19:54.304 -> ESPEInk_ESP8266 v17, reset reason='Deep-Sleep Wake'... 14:19:54.304 -> Entering setup... ... 14:19:58.303 -> Disconnecting from MQTT... 14:19:58.343 -> 14:19:58.343 -> Going to sleep for 60 seconds. 14:19:58.343 -> 14:20:56.522 -> rl (danach wirre Zeichen - als ob die Baudrate nicht stimmt) gleichzeitig geht die LED an und bleibt an (rot) ... Bei 74880Baud ⸮⸮⸮ ⸮⸮⸮ 8 2013,rst cause:5, boot mode:(3,6) 14:52:32.572 -> 14:52:32.572 -> ⸮⸮⸮⸮⸮⸮⸮⸮.⸮

Das sieht schon mal nicht so schlecht aus: Konfiguration wird geladen und es erfolgt ein Connect zu mosquitto - die grundlegende Kommunikation scheint also zu funktionieren.

Zitat
Komme ich irgendwie an die Konfigurationsseite ? Die URL's zun resetten etc scheinen ihn nicht zu jucken. Neu Flashen löst das Problem auch nicht.

Die Reset-Seite funktioniert nur, wenn der Webserver auch verfügbar ist - also wenn er nicht grad schläft oder mit anderen Dingen beschäftigt ist. Beim MQTT-Szenario ist es fast unmöglich, diesen Zeitpunkt zu erwischen (es gäbe noch die Möglichkeit, den Reset über den OTA-Updatemechanismus zu erreichen, ist jedoch bei dir nicht eingerichtet).
Die Einstellungsseite wird jedoch auch aufgespannt, wenn der ESP keine Verbindung zum WLAN hat.

Am Besten wäre es vermutlich, wenn du die Firmware erst einmal ohne MQTT testest. Die grundlegenden Funktionen, inkl. Waveshare-Webserver, sollten genau wie bisher funktionieren
Ich versuche das mal nachzustellen, wie sich der ESP in der Konsole verhält, wenn er aus dem Deepsleep kommt. Das erst einmal wirre Zeichen kommen, ist, soweit ich mich erinnere, jedoch normal, da er selbst erst mal booten muss.

m.zielinski · 27 Mai 2021, 13:52:51

Ich nun - ich hatte deinen Code erst nicht komplett verstanden und daher hiess mein FHEM-Device falsch.
Auf der FW-Gthub beschreibung wäre auch ein define des dummy schön.

Nachdem ich alles in FHem nochmal neu angelegt habe, kommt jetzt auch direkt nach dem Start ein Update der Seite - dann kommt der 60 sekunden Sleep und danach bleibt er mit rot leuchtender LED hängen - es scheint also am deepsleep zu liegen.

In die Einstellungen bin ich wieder gekommen, nachdem ich ihn aus dem Wlan gekickt habe und verhindert habe, dass sich neue Geräte melden dürfen..

Die Meldungen die ich beim aktivieren der roten LED sehen, passen auch zu dem Thread: https://github.com/esp8266/Arduino/issues/6007

Also evtl ein Problem mit dem Deepsleep auf der Original Waveshare Hardware ?

Ich könnte versuchen mal einen Sketch nur mit deepsleep ohne die anderen Sachen hochzuladen ob es daran liegt.

m.zielinski · 27 Mai 2021, 17:54:25

Der Waveshare Support meinte zum Sleep übrigens diese Stelle - das lässt das 7.5Zoll Display schlafen - nicht den ESP. Keine Ahnung warum das für kleine Displays im Code aktiviert ist und bei dem 7.5er nicht.... ich musste nur ein par delays verlängern damit die Aktualisierung durchkommt.

Ich habe jetzt mal das http-FW-Update rausgeworfen und die Waveshare Änderung vorgenommen. Damit kann ich compilieren und hochladen - der Fehler mit dem Weghängen tritt weiterhin auf - nach Verbinden der Pins D0 mit RST ist auch dieser Fehler behoben. War ja auch im Code gezeichnet - aber ich habe das einfach übersehen...

Mein Problem ist also behoben. Du könntest im Github noch erwähnen, dass bei jeder Aktualisierung von dem Dummy die Convertierung neu gestartet wird - das war mir auch nicht ganz klar - ein Codeblock mit dem nötigen AT und dem define des Dummy würde das klarer machen.

Danke für die Hilfe!

Jendaw · 28 Mai 2021, 09:06:03

Zitat von: m.zielinski am 27 Mai 2021, 17:54:25
Der Waveshare Support meinte zum Sleep übrigens diese Stelle - das lässt das 7.5Zoll Display schlafen - nicht den ESP. Keine Ahnung warum das für kleine Displays im Code aktiviert ist und bei dem 7.5er nicht.... ich musste nur ein par delays verlängern damit die Aktualisierung durchkommt.

Gut zu wissen. Wenn der ESP schläft, wird mMn auch das Display nicht mehr versorgt, war also ein ungewollter Nebeneffekt.
Deine Änderung werde ich aber auch gleich mit einbauen.

ZitatIch habe jetzt mal das http-FW-Update rausgeworfen und die Waveshare Änderung vorgenommen. Damit kann ich compilieren und hochladen - der Fehler mit dem Weghängen tritt weiterhin auf - nach Verbinden der Pins D0 mit RST ist auch dieser Fehler behoben. War ja auch im Code gezeichnet - aber ich habe das einfach übersehen...

Mein Problem ist also behoben. Du könntest im Github noch erwähnen, dass bei jeder Aktualisierung von dem Dummy die Convertierung neu gestartet wird - das war mir auch nicht ganz klar - ein Codeblock mit dem nötigen AT und dem define des Dummy würde das klarer machen.

Schön, dass es bei dir jetzt klappt und Danke für den Tipp, werde ich noch mit in das Readme aufnehmen.

Btw: der verlinkte Artikel von dir beschreibt, dass einige ESPs ein stabiles/gutes Netzteil benötigen, ein kurzzeitiges Unterschreiten der 3,3V lässt einige ESP(-Clones) einfrieren. Ggf. ist das für andere noch interessant zu wissen.

Jendaw · 12 Juni 2021, 21:55:40

Ich habe (hoffentlich) die Probleme aus dem master-Branch behoben:
- Verbindung zum MQTT-Server
- Kompilierungsprobleme mit den aktuellen Board-Definitionen für den ESP8266

Die aktuelle Release-Version für den ESP8266 ist damit die v18 (entspricht derzeit noch dem master). Das Binary "ESPEInk_ESP8266.ino.bin.gz" hängt dem Release an und kann nach dem Entpacken durch OTA aufgespielt werden.

Jendaw · 20 Juli 2021, 08:33:41

Ich habe mir ein neues Display zugelegt: das 7,5 v2.
Waveshare hat einen Bug gefixt, welcher den Betrieb des Displays mit dem aktuellen waveshare-HAT Rev2.2 unmöglich machte. Der Fix ist bereits in meinen ESP8266-Sourcen enthalten und kommt vermutlich demnächst auch offiziell in den waveshare-Treiber.

Dazu passend gibt es das neue Release v19, das Binary für OTA-Updates hängt dem Release an.

m.zielinski · 20 Juli 2021, 08:56:09

Prima. Was für ein Fehler war das denn?
Mein 7.5v2 friert immer mal wieder ein unregelmäßig und die SW bleibt hängen. Habe auch schon im DebugMode an nen PC gehängt aber keine Erklärung/Lösung gefunden.

Jendaw · 20 Juli 2021, 09:03:28

Zitat von: m.zielinski am 20 Juli 2021, 08:56:09
Prima. Was für ein Fehler war das denn?
Mein 7.5v2 friert immer mal wieder ein unregelmäßig und die SW bleibt hängen. Habe auch schon im DebugMode an nen PC gehängt aber keine Erklärung/Lösung gefunden.

Es lief überhaupt nicht an einem HAT der Rev2.2. Das Initialisieren "init" endete in einem Crash des Treibers.

Zitat
Mein 7.5v2 friert immer mal wieder ein unregelmäßig und die SW bleibt hängen. Habe auch schon im DebugMode an nen PC gehängt aber keine Erklärung/Lösung gefunden.

Wann passiert das, beim Aufwachen? Hast du den waveshare-ESP8266? Falls du kein NodeMCU-Board hast, hast du einen Widerstand zwischen RST und D0 (470 - 1k)?

m.zielinski · 20 Juli 2021, 09:31:59

Zitat von: Jendaw am 20 Juli 2021, 09:03:28
Es lief überhaupt nicht an einem HAT der Rev2.2. Das Initialisieren "init" endete in einem Crash des Treibers.

Wann passiert das, beim Aufwachen? Hast du den waveshare-ESP8266? Falls du kein NodeMCU-Board hast, hast du einen Widerstand zwischen RST und D0 (470 - 1k)?

Er wacht normal auf, und aktualisiert das Display - anschließend bleibt er aktiv und geht nicht mehr in den Deepsleep sondern hängt wobei er weiterhin Strom zieht .
Ich habe den https://www.waveshare.com/wiki/E-Paper_ESP8266_Driver_Board und eine Kabelbrücke zwischen RST und D0.

Jendaw · 20 Juli 2021, 09:42:15

Zitat von: m.zielinski am 20 Juli 2021, 09:31:59
Er wacht normal auf, und aktualisiert das Display - anschließend bleibt er aktiv und geht nicht mehr in den Deepsleep sondern hängt wobei er weiterhin Strom zieht .

Das E-Paper-Sleep hattest du ja bereits auskommentiert. Der neue Treiber hat noch Änderungen an der Readbusy-Funktion für dieses Display bekommen, auch das Init() ist geändert worden. Wäre auf alle Fälle einen Versuch wert.

Zitat
Ich habe den https://www.waveshare.com/wiki/E-Paper_ESP8266_Driver_Board und eine Kabelbrücke zwischen RST und D0.

Hier könntest du auch probieren, einen Widerstand zwischen 470 und 1k statt einer Brücke zu nehmen.

Wenn ich mein Display in Betrieb habe, sehe ich vllt. auch noch ein paar Dinge

m.zielinski · 21 Juli 2021, 08:14:49

Dein Code hat es jetzt geschafft, dass selbst mit Stromlos machen das Display nicht mehr aktualisiert.

Debugausgabe:
06:55:24.565 -> ESPEInk_ESP8266 v19, reset reason='External System'...
06:55:24.565 -> Entering setup...
06:55:24.613 -> Reading config file...
06:55:24.613 -> Config file read.
06:55:24.613 -> Connecting to WiFi...

Auch ein Reflashen der FW hat keine Änderung gebracht - auch nicht ein aussperren aus dem WLan.

Nach Reflasjh mit meiner FW und umbenennen des config-file im code kommt
08:12:30.132 -> ESPEInk_ESP8266 v17, reset reason='External System'...
08:12:30.132 -> Entering setup...
08:12:30.226 -> Connecting to WiFi...

Jendaw · 21 Juli 2021, 08:52:09

Zitat von: m.zielinski am 21 Juli 2021, 08:14:49
Dein Code hat es jetzt geschafft, dass selbst mit Stromlos machen das Display nicht mehr aktualisiert.

Debugausgabe:
06:55:24.565 -> ESPEInk_ESP8266 v19, reset reason='External System'...
06:55:24.565 -> Entering setup...
06:55:24.613 -> Reading config file...
06:55:24.613 -> Config file read.
06:55:24.613 -> Connecting to WiFi...

Auch ein Reflashen der FW hat keine Änderung gebracht - auch nicht ein aussperren aus dem WLan.

Nach Reflasjh mit meiner FW und umbenennen des config-file im code kommt
08:12:30.132 -> ESPEInk_ESP8266 v17, reset reason='External System'...
08:12:30.132 -> Entering setup...
08:12:30.226 -> Connecting to WiFi...

Wird der Einstellungs-AccessPoint aufgespannt (im WLAN taucht das Gerät "ESPEInk-APSetup*" auf)?

m.zielinski · 21 Juli 2021, 09:30:14

Upps - ja - der Einstellungs AP geht auf - habe mit meiner FW den wieder befüllt und dann aktualisiert er wieder. Werde jetzt nochmal deine Version flashen, Merkwürdig das alles.

Die Debug Meldung auf dem seriellen port hatte mich denken lassen, dass er wieder hängt...

Jendaw · 21 Juli 2021, 09:37:29

Zitat von: m.zielinski am 21 Juli 2021, 09:30:14
Upps - ja - der Einstellungs AP geht auf - habe mit meiner FW den wieder befüllt und dann aktualisiert er wieder. Werde jetzt nochmal deine Version flashen, Merkwürdig das alles.

Die Debug Meldung auf dem seriellen port hatte mich denken lassen, dass er wieder hängt...

Ich drücke die Daumen

Wie updatest du den ESP, mit der Arduino-IDE? Beim Flashen mit der Arduino-IDE gibt es (neuerdings?) die Option, u.a. die WiFi-Daten beim Upload zu löschen. Ich schätze mit dem ESP-upload-Tool wäre das eine separate Option. Mit einem OTA-Update sollte das jedoch nicht sein.