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

ckbln · 02 April 2020, 00:37:52

Hallo Jendaw
ich kann mich auch nicht per Iphone mit dem AP ESPEInk-APSetup verbinden.
Auch mit einem ES8266 funktioniert es nicht.
Kannst du mir eventuell ein fertige bin Datei, die bei dir funktioniert, zusenden.
Die würde ich dann auf den ESP flashen. Und dann schauen ob es funktioniert
VG

Jendaw · 02 April 2020, 02:26:04

Zitat von: ckbln am 02 April 2020, 00:37:52
Kannst du mir eventuell ein fertige bin Datei, die bei für funktioniert, zusenden.

Die bin-Dateien hängen auch in der github-Version, müssen nur noch entpackt werden. Beide Versionen funktionieren bei mir, wobei ich nicht immer das komplette Setup getestet habe. Ich habe die Boards "Wemos D1 Mini" und "ESP32 Devkit v1".
Ich werde zur Sicherheit jedoch noch einmal das komplette Setup bei mir testen, wobei ich derzeit nur den ESP8266 frei habe.

HTH

edit: Ich habe den ESP-AP umbenannt, er bekommt jetzt noch die MAC-Adresse des ESP angehängt, so dass er eindeutig sein sollte. Ich verspreche mir davon, dass Windows unterschiedliche ESP-APs nicht gleich behandelt. Ein nächster Versuch könnte noch sein, einen AP mit einem Passwort zu benutzen.
Die Sourcen sind in github eingecheckt, ich habe jedoch noch keine Version released, da es noch ungetestet ist. Das bin für das ESP-devkit-Modul habe ich angehängt.

Jendaw · 03 April 2020, 21:13:11

Zitat von: Jendaw am 01 April 2020, 02:03:59
Das sieht von FHEM-Seite aus gut aus. Ich habe für die Subscription etwas geändert, muss ich noch testen und stelle es dann zur Verfügung.

Ich habe nun (endlich) einen Wemos D1 mini (ESP8266) an das Display angeschlossen, einige Dinge gefixt und die Version v15 bereit gestellt. Diese funktioniert bei mir mit dem MQTT-Szenario.

Jendaw · 07 April 2020, 16:16:04

Zitat von: pepe_11 am 31 März 2020, 20:23:31
trotzdem auf dem Display bewegt sich nichts oder habe ich da noch etwas übersehen.
Code Auswählen Erweitern
pi@FHEM:~ $ mosquitto -v ... 1585677903: Received SUBSCRIBE from NetMQTTpm737 1585677903: cmd/display/upload (QoS 0) 1585677903: NetMQTTpm737 0 cmd/display/upload

Geht es denn mittlerweile bei dir? In deinem Log sieht es ja so aus, dass der ESP einen Upload mit "cmd/display/upload" anfordert. Das müsstest du auch im DOIF, welches auf dieses Topic reagiert, sehen (im Beispiel hab ich das DOIF "display_mqtt" genannt). Falls da alles iO ist, sollte auch das ESPEInk-Modul reagieren und einen Upload veranlassen.

Ich habe noch eine andere MQTT-Lib probiert (async-mqtt-client: für Interessierte habe ich dafür einen separaten ESP8266-Branch in github erstellt), die hat jedoch auch das Problem, dass der Server den Client in ein Timeout laufen lässt. An sich ist das jedoch kein Problem, die Kommunikation funktioniert dennoch.

Ich habe noch einen Bug beim MQTT-disconnect gefixt und neue Versionen für den ESP8266 (v16) und ESP32 (v4) auf github zur Verfügung gestellt. Feedback ist willkommen

pepe_11 · 08 April 2020, 11:05:43

Zitat von: Jendaw am 07 April 2020, 16:16:04
Geht es denn mittlerweile bei dir? In deinem Log sieht es ja so aus, dass der ESP einen Upload mit "cmd/display/upload" anfordert. Das müsstest du auch im DOIF, welches auf dieses Topic reagiert, sehen (im Beispiel hab ich das DOIF "display_mqtt" genannt). Falls da alles iO ist, sollte auch das ESPEInk-Modul reagieren und einen Upload veranlassen.

Ich habe noch eine andere MQTT-Lib probiert (async-mqtt-client: für Interessierte habe ich dafür einen separaten ESP8266-Branch in github erstellt), die hat jedoch auch das Problem, dass der Server den Client in ein Timeout laufen lässt. An sich ist das jedoch kein Problem, die Kommunikation funktioniert dennoch.

Ich habe noch einen Bug beim MQTT-disconnect gefixt und neue Versionen für den ESP8266 (v16) und ESP32 (v4) auf github zur Verfügung gestellt. Feedback ist willkommen

Hi,

ich konnte endlich wieder testen. Ich habe die V16 installiert.
1. Erster Connect-->OK Display wird angesteuert und zeigt was es soll.
2. Zweiter Connect nach 60s --> kein upload, da keine keine neue Daten. Wenn sich der ESP wieder schlafen legt wird das Display leer gemacht, nichts wird angezeigt.

wenn ich manuell den convert auslöse, dann wird beim Aufwachen ein neuer Inhalt im Display nach dem Upload angezeigt usw..

Gruß
Peter

Code Auswählen

sd l▄ƒ< älÓ|älõ#|çâý█søbä#─¾no×$gn£ÒýcpîÄ${ls$p¹'Óâlî£coÒ|lõläcä‗'o´ $îÄl ÿgnd`gsÄ█ôo├$`;ôøgâl`£{▄xîd£sø`³├'£reading config file
*WM: Adding parameter
*WM: server
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: updateTopic
*WM: Adding parameter
*WM: commandTopic
*WM: Adding parameter
*WM: sleepTime
*WM: Adding parameter
*WM: firmwareUrl
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.8.45
Connected.
 MQTT Server: 192.168.8.52:1883, Client: ESPEInk_ecfabcc2b1a9
 MQTT UpdateStatusTopic: stat/display/needUpdate
 MQTT CommandTopic: cmd/display/upload
 sleep time: 60
 firmware base URL:
Setup complete.
Connecting to MQTT...
 subscribed to stat/display/needUpdate
 reconnected, waiting for incoming MQTT message
Callback called, isUpdateAvailable=true
Webserver started, waiting for updates
EPD 2.13 inch

EPD_Init_2in13 V2LOAD

 EPD_loadCLOAD

 EPD_loadCLOAD

 EPD_loadCLOAD

 EPD_loadCLOAD

 EPD_loadCLOAD

 EPD_loadCSHOW

 EPD_showAGoing to sleep for 60 seconds.

Jendaw · 08 April 2020, 13:10:33

Danke für deinen Test.

Zitat von: pepe_11 am 08 April 2020, 11:05:43
1. Erster Connect-->OK Display wird angesteuert und zeigt was es soll.
2. Zweiter Connect nach 60s --> kein upload, da keine keine neue Daten. Wenn sich der ESP wieder schlafen legt wird das Display leer gemacht, nichts wird angezeigt.

Das Löschen klingt nicht gut. Kannst du mir bitte das Log für den zweiten Connect, also da, wo das Display gelöscht wird, geben?

Zitat
wenn ich manuell den convert auslöse, dann wird beim Aufwachen ein neuer Inhalt im Display nach dem Upload angezeigt usw..

Und dann im zweiten Durchlauf wieder gelöscht?

Maista · 08 April 2020, 17:49:45

Hallo Jendaw,

sobald ich den Trouble mit der Beerdigung hinter mir habe (erst im Mai

) werde ich mich wieder dem eInk-Projekt widmen.
Mal schauen in wie weit die ESPs dann rum zicken.

Danke erst einmal für dein Einsatz!

Gruss Gerd

pepe_11 · 08 April 2020, 19:36:16

Zitat von: Jendaw am 08 April 2020, 13:10:33

Und dann im zweiten Durchlauf wieder gelöscht?

Ja genau.

Gesendet von meinem ANE-LX1 mit Tapatalk

Jendaw · 08 April 2020, 20:39:23

Zitat von: pepe_11 am 08 April 2020, 19:36:16
Ja genau.

Ich habe eine Änderung vorgenommen, so dass das Display erst initialisiert wird, wenn auch der Webserver angesprochen wird. Vorerst nur in der ESP8266-Version und noch nicht als Release (falls noch weitere Änderungen notwendig werden). Im Anhang das Bin.
Mit meinem "7in5 V2"-Display passiert das zumindest nicht, scheint also, dass ich etwas übersehen habe oder es ist etwas Spezifisches bei diesem Displaytyp.

pepe_11 · 08 April 2020, 22:56:03

Zitat von: Jendaw am 08 April 2020, 20:39:23
Ich habe eine Änderung vorgenommen, so dass das Display erst initialisiert wird, wenn auch der Webserver angesprochen wird. Vorerst nur in der ESP8266-Version und noch nicht als Release (falls noch weitere Änderungen notwendig werden). Im Anhang das Bin.
Mit meinem "7in5 V2"-Display passiert das zumindest nicht, scheint also, dass ich etwas übersehen habe oder es ist etwas Spezifisches bei diesem Displaytyp.

Hi,
habe gerade eben die Version installiert. Ich muss leider berichten, dass das Problem immer noch da ist.

Code Auswählen

rl d£×| îlÓ|îlýc|Ä├õø;ôcîcä¹gnƒdog£Òõc8äçlrd;lx¾oÓ├$ä£#gÒ|dýd─bî¾ogþ läÅl`Ï'od`gsÅÆôoél`rø█gâd`▄{▄xîd£sø`³├'£reading config file
*WM: Adding parameter
*WM: server
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: updateTopic
*WM: Adding parameter
*WM: commandTopic
*WM: Adding parameter
*WM: sleepTime
*WM: Adding parameter
*WM: firmwareUrl
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.8.45
Connected.
 MQTT Server: 192.168.8.52:1883, Client: ESPEInk_ecfabcc2b1a9
 MQTT UpdateStatusTopic: stat/display/needUpdate
 MQTT CommandTopic: cmd/display/upload
 sleep time: 60
 firmware base URL:
Setup complete.
Connecting to MQTT...
 subscribed to stat/display/needUpdate
 reconnected, waiting for incoming MQTT message
Callback called, isUpdateAvailable=true
Webserver started, waiting for updates

Exception (28):
epc1=0x4021f31a epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3fff3e30 end: 3fff4340 offset: 01a0
3fff3fd0:  3fff40d0 00000003 3fff4030 4021d921
3fff3fe0:  ffffffff 00000000 3ffed581 00000004
3fff3ff0:  3ffe8304 00000004 3fff40d0 40221ba6
3fff4000:  ffffffff 3ffec4f0 3ffed581 00000008
3fff4010:  402478ee 3fff0bc8 3fff4a9c 3ffec4f6
3fff4020:  00000000 3ffec4f5 3fff40d0 40221fd7
3fff4030:  00000000 ffffffff 00000000 00000000
3fff4040:  3ffed432 00000004 3f302073 00000000
3fff4050:  00000000 00000000 0000001f 401001c8
3fff4060:  00000000 3fff4153 3fffc228 401051e1
3fff4070:  0000050c 40104f8b 3fff6184 00000000
3fff4080:  4000dd2f 00000030 00000000 ffffffff
3fff4090:  3fff4200 3fff41d0 0000000c 3ffe8304
3fff40a0:  00001ce8 00000009 00000001 0000002e
3fff40b0:  00001ce8 3fff41d2 54e96900 4020395c
3fff40c0:  3fff3228 3ffe8304 00000040 4021f245
3fff40d0:  3fff4184 00000010 0000003b ffff0208
3fff40e0:  3fff4180 0000003f 00000000 00000000
3fff40f0:  3fff442c 00000010 00000020 40100ac0
3fff4100:  00000020 00000014 00000020 00000b36
3fff4110:  3fff442c 00000b33 00000000 40100b09
3fff4120:  3fff63e1 00000010 3fff4200 0000000a
3fff4130:  00000001 00000010 3fff4200 4021067a
3fff4140:  00001b28 00000008 3fff3050 4021f288
3fff4150:  3fff4200 3fff41d0 00000008 3fff4248
3fff4160:  00000000 4bc6a7f0 00001627 00000430
3fff4170:  00000000 00000000 00000000 4020f664
3fff4180:  20445045 ffffffff 00000000 402119b3
3fff4190:  00001a70 0000034e 0000034e 40100800
3fff41a0:  00001627 ffffffff 3fff6454 00000000
3fff41b0:  00000000 3fff3074 00000020 40100a8b
3fff41c0:  3fff4200 3fff41d0 00000008 00000002
3fff41d0:  009c1001 3fff3074 00000003 00000205
3fff41e0:  00000002 00000001 3fff3050 4020395c
3fff41f0:  3ffec4f0 00000000 3fff41d0 3fff4200
3fff4200:  74736f00 00000001 3fff6274 4020395c
3fff4210:  00000003 ffffff9f 3fff3050 402069f3
3fff4220:  00000003 00000001 3fff6274 4021a78e
3fff4230:  00000003 4020113c 3fff6274 401000d9
3fff4240:  3fff6274 3fff3090 3fff6274 40203992
3fff4250:  44504500 00000000 80000000 80fffffe
3fff4260:  3fff6274 3fff3090 3fff3050 4020662a
3fff4270:  4450452f 80000000 84ff6300 0000001f
3fff4280:  80002044 1b071ef1 00001600 4063850c
3fff4290:  00000001 00000001 00000000 3fff3100
3fff42a0:  00000003 00000003 3fff3050 3fff2f51
3fff42b0:  00000001 3fff3074 3fff3050 3fff2f51
3fff42c0:  00000001 3fff3074 3fff3050 402072ab
3fff42d0:  d92b7fe0 404c1431 00001388 3fff42e0
3fff42e0:  007a1200 1b074006 3fff2f6c 4021adbc
3fff42f0:  0772e428 3fff2d3c 3fff2f50 40207467
3fff4300:  00000000 00000000 00000001 401001c8
3fff4310:  3fffdad0 00000000 3fff4348 3fff4388
3fff4320:  3fffdad0 00000000 3fff4348 40211ac8
3fff4330:  feefeffe feefeffe 3ffe8ab4 40100d9d
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1392, room 16
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld
reading config file
*WM: Adding parameter
*WM: server
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: updateTopic
*WM: Adding parameter
*WM: commandTopic
*WM: Adding parameter
*WM: sleepTime
*WM: Adding parameter
*WM: firmwareUrl
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.8.45
Connected.
 MQTT Server: 192.168.8.52:1883, Client: ESPEInk_ecfabcc2b1a9
 MQTT UpdateStatusTopic: stat/display/needUpdate
 MQTT CommandTopic: cmd/display/upload
 sleep time: 60
 firmware base URL:
Setup complete.
Connecting to MQTT...
 subscribed to stat/display/needUpdate
 reconnected, waiting for incoming MQTT message
 no update available
Disconnecting from MQTT...
Going to sleep for 60 seconds.
;l d£▀| î$Ó|î$ýc|Ä├õô;ôcîcî¹g'ƒlog£Òõc8äçlrl;lx¾oÓ├$ä£#gÒ|dýd─bî¾ogþ läÅl`Ï'od`gsÅÆôoél`rø█'âd`▄{£xäd£s█`³é'£reading config file
*WM: Adding parameter
*WM: server
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: updateTopic
*WM: Adding parameter
*WM: commandTopic
*WM: Adding parameter
*WM: sleepTime
*WM: Adding parameter
*WM: firmwareUrl
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.8.45
Connected.
 MQTT Server: 192.168.8.52:1883, Client: ESPEInk_ecfabcc2b1a9
 MQTT UpdateStatusTopic: stat/display/needUpdate
 MQTT CommandTopic: cmd/display/upload
 sleep time: 60
 firmware base URL:
Setup complete.
Connecting to MQTT...
 subscribed to stat/display/needUpdate
 reconnected, waiting for incoming MQTT message
 no update available
Disconnecting from MQTT...
Going to sleep for 60 seconds.

Gruß
Peter

Jendaw · 09 April 2020, 18:06:25

Vielen Dank für deinen Input.

Zitat von: pepe_11 am 08 April 2020, 22:56:03
habe gerade eben die Version installiert. Ich muss leider berichten, dass das Problem immer noch da ist.

Code Auswählen Erweitern
Callback called, isUpdateAvailable=true Webserver started, waiting for updates Exception (28): epc1=0x4021f31a epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

Die Exc sieht leider gar nicht gut aus. Leider kann ich das bei mir nicht nachstellen. Ich habe versucht, das mit einem "wemos D1 mini" ohne Display und einer FHEM-VM mit deiner Konfiguration (displaytype "2.13inch_e-Paper_HAT" nachzustellen). Das funktioniert leider, auch wenn nichts angezeigt wird

Da ich nur den "wemos D1 mini" als ESP8266-Board habe und die Binaries auch nur für diesen gebaut habe, könnte es auch daran liegen. Wenn du die Original-waveshare-Firmware baust, welchen Boardtyp nutzt du da in der Arduino-IDE zum bauen? Vllt. passen unsere beiden Boards nicht zusammen, so dass ich eine andere Einstellung zum Bauen benötige. Alternativ könntest du das Image aus den Sourcen selbst bauen. Da bin ich gern behilflich, falls eine Lib fehlt oder die Anleitung ungenau ist. Gern auch per PM.

edit:
Lt. Anleitung von waveshare müsste es das Board "NodeMCU 1.0" sein. Um diese Fehlerquelle auszuschließen, anbei das Image für dieses Board (werde ich zukünftig auch als default benutzen, scheint auf dem wemos D1 mini auch zu tun).

VG

pepe_11 · 10 April 2020, 11:31:46

Zitat von: Jendaw am 09 April 2020, 18:06:25
Vielen Dank für deinen Input.
Die Exc sieht leider gar nicht gut aus. Leider kann ich das bei mir nicht nachstellen. Ich habe versucht, das mit einem "wemos D1 mini" ohne Display und einer FHEM-VM mit deiner Konfiguration (displaytype "2.13inch_e-Paper_HAT" nachzustellen). Das funktioniert leider, auch wenn nichts angezeigt wird

Da ich nur den "wemos D1 mini" als ESP8266-Board habe und die Binaries auch nur für diesen gebaut habe, könnte es auch daran liegen. Wenn du die Original-waveshare-Firmware baust, welchen Boardtyp nutzt du da in der Arduino-IDE zum bauen? Vllt. passen unsere beiden Boards nicht zusammen, so dass ich eine andere Einstellung zum Bauen benötige. Alternativ könntest du das Image aus den Sourcen selbst bauen. Da bin ich gern behilflich, falls eine Lib fehlt oder die Anleitung ungenau ist. Gern auch per PM.

edit:
Lt. Anleitung von waveshare müsste es das Board "NodeMCU 1.0" sein. Um diese Fehlerquelle auszuschließen, anbei das Image für dieses Board (werde ich zukünftig auch als default benutzen, scheint auf dem wemos D1 mini auch zu tun).

VG

Hi,

ich habe sowohl "NodeMCU 0.9","NodeMCU 1.0" und "Wemos D1 R1" durchprobiert. Alle laufen bei mir ohne Probleme durch. Ich hänge eine bin, die ich mit dem "D1 R1" kompiliert habe an. Das ist deine V16. Für mich sieht es danach aus, dass mein Display eine Besonderheit ist.

Schöne Grüße
Peter

Jendaw · 10 April 2020, 16:22:04

Zitat von: pepe_11 am 10 April 2020, 11:31:46
ich habe sowohl "NodeMCU 0.9","NodeMCU 1.0" und "Wemos D1 R1" durchprobiert. Alle laufen bei mir ohne Probleme durch. Ich hänge eine bin, die ich mit dem "D1 R1" kompiliert habe an. Das ist deine V16. Für mich sieht es danach aus, dass mein Display eine Besonderheit ist.

Heißt das, dass dein selbst kompilierter Code bei dir erwartungsgemäß und ohne Exception funktioniert und nicht mehr beim zweiten Durchlauf das Display löscht?
Hattest du mein Image von gestern abend in Post #25 auch probiert? Dieses habe ich mit dem Boardtyp "NodeMCU 1.0" kompiliert. Falls das auch nicht funktioniert, brauche ich das Image nicht mehr an die Release im github anhängen, wenn es nur bei mir funktioniert.

Ich habe mir den waveshare-Code für dein Displaytyp oberflächlich angesehen, ein paar Warnungen wirft der Compiler dafür, habe aber keine gefunden, die nach einem Bug aussieht.

VG

pepe_11 · 10 April 2020, 22:14:32

Zitat von: Jendaw am 10 April 2020, 16:22:04
Heißt das, dass dein selbst kompilierter Code bei dir erwartungsgemäß und ohne Exception funktioniert und nicht mehr beim zweiten Durchlauf das Display löscht?
Hattest du mein Image von gestern abend in Post #25 auch probiert?

Hi,
Leider nein, es wird zwar keine exception ausgeworfen aber das Display wird trotzdem gelöscht.
Ja ich habe dein Image installiert aber das Ergebnis war gleich.

VG
Peter

Gesendet von meinem ANE-LX1 mit Tapatalk

Jendaw · 27 April 2020, 15:29:19

Zitat von: pepe_11 am 10 April 2020, 22:14:32
Zitat von: Jendaw am 10 April 2020, 16:22:04
Heißt das, dass dein selbst kompilierter Code bei dir erwartungsgemäß und ohne Exception funktioniert und nicht mehr beim zweiten Durchlauf das Display löscht?
Leider nein, es wird zwar keine exception ausgeworfen aber das Display wird trotzdem gelöscht.
Ja ich habe dein Image installiert aber das Ergebnis war gleich.

Update Leider haben Peter und ich es nicht hinbekommen, das 2.13-waveshare-Display mit einem wemos D1 mini (oder Clone) und dem deepsleep-Mode zum laufen zu bekommen. Das Problem ist, dass das Display den selben Port wie die interne LED für ein Reset benutzt. Der Reset ist bei diesem Display auch einfach gehalten: sobald die Leitung auf LOW wechselt, wird das Display gelöscht. Nach unseren Beobachtungen geschieht das mit einer Regelmässigkeit beim Betreten des deepsleep-Mode, ohne dass man da programmatisch oder mit einem externen Pullup etwas ändern kann. Danke nochmal Peter für deine Geduld!

Mit einem 7.5B und einen wemos D1 mini läuft das Display bei mir jedoch seit mehreren Wochen problemlos.

Falls jmd dafür eine Lösung hat oder einen Hinweis, so nehme ich gern pull-Requests oder Codeschnipsel entgegegen!

VG