Autor Thema: Erweiterung der waveshare-Treiber um WifiManager, MQTT, OTA-Update und deepsleep  (Gelesen 5305 mal)

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Ich habe die waveshare-Treiber zur Ansteuerung der EInk-Displays um die Funktionen
  • Wifi-Manager zur Einrichtung
  • MQTT-Anbindung für Display-Updates
  • OTA-Updates
  • konfigurierbares deepsleep
erweitert. Die Displays können mit dem Modul ESPEInk angesteuert werden. Vllt. ist das für den ein oder anderen interessant

Zu finden sind die Sourcen und Firmware-Images auf github, sowohl als ESP32 als auch als ESP8266-Version.

Um nicht weiter im ESPEInk-Thread zu wildern, hab ich diesen Thread erstellt.



Updates
20.07.21
  • Der kommende waveshare-Treiber enthält ein Bugfix für das 7in5 v2-Display, welchen ich bereits im ESP8266-Code eingebaut und als v19 released habe.

FAQ
Wie kann ich die Konfigurationsdaten (WLAN, Sleep-Konfiguration, ...) löschen?
Ist kein MQTT-Szenario konfiguriert, kann die "reset"-Webseite des ESP benutzt werden.
Ist MQTT konfiguriert, wird der Webserver nur (für kurze Zeit) gestartet, wenn Upload-Daten vorliegen. Nur in dieser Zeit ist die reset-Seite auch verfügbar. Daher hat man noch folgende Möglichkeiten:
  • Dem ESP den WLAN-Zugang zu verweigern, damit wird der Konfigurations-AP erneut gestartet.
  • Die Firmware neu flashen, dabei ist als Flash-Option "Erase Flash: 'All Flash Contents'" anzugeben. Siehe auch Screenshot EraseFlash.png im Anhang.
« Letzte Änderung: 22 August 2021, 17:40:57 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 Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #1 am: 30 März 2020, 17:29:05 »
übernommen aus dem ESPEInk-Thread:

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

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?
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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #2 am: 30 März 2020, 21:16:05 »
übernommen aus dem ESPEInk-Thread:

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?

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

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #3 am: 31 März 2020, 06:15:57 »
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
Verwendest du externe Pullups (für D0/GPIO16)? Wie ist die Beschaltung zwischen A0 und RST, eine Drahtbrücke oder eine (Schottky-)Diode/Widerstand? Manche ESP8266-Boards benötigen ext. Pullups um sauber aus dem Deepsleep aufzuwachen. Kannst du testweise die Spannungsversorgung (Pin 3V3) zwischen ESP und e-Paper HAT trennen und schauen, ob der deepsleep damit funktioniert?
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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #4 am: 31 März 2020, 10:53:12 »
Verwendest du externe Pullups (für D0/GPIO16)? Wie ist die Beschaltung zwischen A0 und RST, eine Drahtbrücke oder eine (Schottky-)Diode/Widerstand? Manche ESP8266-Boards benötigen ext. Pullups um sauber aus dem Deepsleep aufzuwachen. Kannst du testweise die Spannungsversorgung (Pin 3V3) zwischen ESP und e-Paper HAT trennen und schauen, ob der deepsleep damit funktioniert?

Hi Jendaw,

ich habe nutze die Drahtbrücke. Allerdings habe ich festgestellt, dass ich erst die Brücke schalten darf, wenn der esp am usb angeschlossen ist, sonst habe ich keine serielle Ausgabe. Der ESP wach jetzt auf (egal ob das Display mit oder ohne strom läuft). Das sieht gut aus. Noch fehlt der Webserver.


10:49:48.744 -> *WM: Adding parameter
10:49:48.744 -> *WM: server
10:49:48.791 -> *WM: Adding parameter
10:49:48.791 -> *WM: port
10:49:48.791 -> *WM: Adding parameter
10:49:48.791 -> *WM: updateTopic
10:49:48.791 -> *WM: Adding parameter
10:49:48.791 -> *WM: commandTopic
10:49:48.791 -> *WM: Adding parameter
10:49:48.791 -> *WM: sleepTime
10:49:48.791 -> *WM: Adding parameter
10:49:48.791 -> *WM: firmwareUrl
10:49:48.791 -> *WM:
10:49:48.791 -> *WM: AutoConnect
10:49:48.791 -> *WM: Connecting as wifi client...
10:49:48.791 -> *WM: Status:
10:49:48.791 -> *WM: 6
10:49:48.791 -> *WM: Using last saved values, should be faster
10:49:51.699 -> *WM: Connection result:
10:49:51.699 -> *WM: 3
10:49:51.699 -> *WM: IP Address:
10:49:51.699 -> *WM: 192.168.8.45
10:49:51.699 -> Connected.
10:49:51.699 -> *WM: freeing allocated params!
10:49:51.699 ->  MQTT Server: 192.168.8.35 :1883, Client: ESPEInk_ecfabcc2b1a9
10:49:51.699 ->  MQTT UpdateStatusTopic: stat/display/needUpdate
10:49:51.699 ->  MQTT CommandTopic: cmd/display/upload
10:49:51.699 ->  sleep time: 60
10:49:51.699 ->  firmware base URL:
10:49:51.746 -> Setup complete.
10:49:51.746 -> Connecting to MQTT...
10:49:51.746 ->  subscribed to stat/display/needUpdate
10:49:51.746 ->  reconnected, waiting for incoming MQTT message
10:50:58.193 -> ;ld############### hier immer noch die Zeichen ###########################
10:50:01.736 -> Going to sleep for 60 seconds.
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: server
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: port
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: updateTopic
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: commandTopic
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: sleepTime
10:50:58.334 -> *WM: Adding parameter
10:50:58.334 -> *WM: firmwareUrl
10:50:58.334 -> *WM:
10:50:58.334 -> *WM: AutoConnect
10:50:58.334 -> *WM: Connecting as wifi client...
10:50:58.334 -> *WM: Status:
10:50:58.334 -> *WM: 6
10:50:58.334 -> *WM: Using last saved values, should be faster
10:51:02.763 -> *WM: Connection result:
10:51:02.763 -> *WM: 3
10:51:02.763 -> *WM: IP Address:
10:51:02.763 -> *WM: 192.168.8.45
10:51:02.763 -> Connected.
10:51:02.763 -> *WM: freeing allocated params!
10:51:02.763 ->  MQTT Server: 192.168.8.35 :1883, Client: ESPEInk_ecfabcc2b1a9
10:51:02.763 ->  MQTT UpdateStatusTopic: stat/display/needUpdate
10:51:02.809 ->  MQTT CommandTopic: cmd/display/upload
10:51:02.809 ->  sleep time: 60
10:51:02.809 ->  firmware base URL:
10:51:02.809 -> Setup complete.
10:51:02.809 -> Connecting to MQTT...
10:51:02.809 ->  subscribed to stat/display/needUpdate
10:51:02.809 ->  reconnected, waiting for incoming MQTT message
10:51:12.799 -> Going to sleep for 60 seconds.



VG
Peter

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #5 am: 31 März 2020, 13:30:08 »
Noch fehlt der Webserver.

...
10:49:51.699 ->  MQTT Server: 192.168.8.35 :1883, Client: ESPEInk_ecfabcc2b1a9
10:49:51.699 ->  MQTT UpdateStatusTopic: stat/display/needUpdate
...
10:49:51.746 -> Connecting to MQTT...
10:49:51.746 ->  subscribed to stat/display/needUpdate
10:49:51.746 ->  reconnected, waiting for incoming MQTT message
...
Das sieht mir danach aus, als würde es Probleme mit dem "needUpdate"-Topic geben. Der Webserver wird erst gestartet, wenn "waiting for incoming MQTT message" ein "true" gefunden hat.

Kannst du bitte folgendes überprüfen:
* welche mosqitto-Version verwendest du?
* falls du ein DOIF verwendest - wurde das gefeuert? (jenes, welches das "needUpdate"-Topic auf "true" setzt, kannst du ggf die Definition posten?)
* kannst du dich auf deinem FHEM-Rechner auf der Konsole einloggen und nachsehen, ob das Topic auf "true" gesetzt wird, wenn das "convert" vom Modul ESPEInk durch ist?
mosquitto_sub -d -q 1 -i ClientId -t stat/display/needUpdate* falls beides funktioniert, kann es nur noch an der Subscription vom ESP liegen, das würde ich mir dann genauer ansehen (mit dem ESP32 hat das zuverlässig funktioniert)

VG
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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #6 am: 31 März 2020, 17:56:43 »
Das sieht mir danach aus, als würde es Probleme mit dem "needUpdate"-Topic geben. Der Webserver wird erst gestartet, wenn "waiting for incoming MQTT message" ein "true" gefunden hat.

Kannst du bitte folgendes überprüfen:
* welche mosqitto-Version verwendest du?
* falls du ein DOIF verwendest - wurde das gefeuert? (jenes, welches das "needUpdate"-Topic auf "true" setzt, kannst du ggf die Definition posten?)
* kannst du dich auf deinem FHEM-Rechner auf der Konsole einloggen und nachsehen, ob das Topic auf "true" gesetzt wird, wenn das "convert" vom Modul ESPEInk durch ist?
mosquitto_sub -d -q 1 -i ClientId -t stat/display/needUpdate* falls beides funktioniert, kann es nur noch an der Subscription vom ESP liegen, das würde ich mir dann genauer ansehen (mit dem ESP32 hat das zuverlässig funktioniert)

VG
Hi,
habe tatsächlich feststellen müssen, dass ich mit dem MQTT Server Probleme hatte.
Jetzt läuft er aber ich bekomme das Display nicht zum Laufen. Fehler in der console -->" Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585668996: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting."

Bei mosquitto_sub -d -q 1 -i ClientId -t stat/display/needUpdate
Error: Cannot assign requested address

bei mosquitto -v:
mosquitto -v
1585669791: mosquitto version 1.5.7 starting
1585669791: Using default config.
1585669791: Opening ipv4 listen socket on port 1883.
1585669791: Opening ipv6 listen socket on port 1883.
1585669791: New connection from 192.168.8.45 on port 1883.
1585669791: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585669791: No will message specified.
1585669791: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (0, 0)
1585669791: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585669791:     stat/display/needUpdate (QoS 1)
1585669791: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585669791: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585669814: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585669814: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.

zu 1. mosquitto version 1.5.7

zu 2.
Internals:
   DEF        ([display:result_picture]) (\set mqtt_device publish qos:1 stat/display/needUpdate true\  )
   FUUID      5e835d64-f33f-36ee-f8fb-7774a3b1e64bf74e
   MODEL      FHEM
   NAME       display_doif
   NOTIFYDEV  display,global
   NR         906
   NTFY_ORDER 50-display_doif
   STATE      initialized
   TYPE       DOIF
   VERSION    21224 2020-02-18 18:45:49
   READINGS:
     2020-03-31 17:13:10   cmd             0
     2020-03-31 17:13:10   mode            enabled
     2020-03-31 17:13:10   state           initialized
   Regex:
     accu:
     cond:
       display:
         0:
           result_picture ^display$:^result_picture:
   condition:
     0          ::ReadingValDoIf($hash,'display','result_picture')
   do:
     0:
       0          \set mqtt_device publish qos:1 stat/display/needUpdate true\ 
     1:
   helper:
     DEVFILTER  ^global$|^display$
     NOTIFYDEV  global|display
     globalinit 1
     last_timer 0
     sleeptimer -1
   perlblock:
   readings:
     all         display:result_picture
   uiState:
   uiTable:
Attributes:
   do         always


zu 3. Ich würde sagen nein FM-->"error
\ set mqtt_device publish qos:1 stat/display/needUpdate true\ : Unknown command \, try help."

Ich hoffe, dass dich das weiter bringt. ich hoffe, dass ich alles dir liefern konnte.

VG
Peter

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #7 am: 31 März 2020, 19:48:38 »
Fehler in der console -->" Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585668996: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting."
Ich will nicht sagen, dass das normal ist, hat jedoch mit dem Keepalive-Timeouts des MQTT-Servers zu tun. Der ESP ist schon wieder weg, ehe der Server nachfragt. Sollte erst mal kein Problem sein, ich schau es mir bei Gelegenheit dennoch an, warum der Client sich nicht vernünftig verabschiedet.

Zitat
Bei mosquitto_sub -d -q 1 -i ClientId -t stat/display/needUpdate
Error: Cannot assign requested address
Hast du das direkt auf dem Rechner ausgeführt, wo auch mosqitto läuft? Normal kommt die Meldung, wenn er einen Rechner-Namen nicht auflösen kann.

Zitat
Internals:
   DEF        ([display:result_picture]) (\set mqtt_device publish qos:1 stat/display/needUpdate true\  )
...
zu 3. Ich würde sagen nein FM-->"error
\ set mqtt_device publish qos:1 stat/display/needUpdate true\ : Unknown command \, try help."
Schau dir mal deine Definitionen noch mal an, hier sind ein paar überzählige Backslash "\" enthalten. Möglicherweise sind die durch copy&paste der Raw-Definitionen aus der Anleitung reingekommen. Das erklärt auch die Fehlermeldung zu 3. Da ergänze ich die Anleitung um einen Hinweis.

VG

edit Kannst du bitte deine Definition etc. in code-Tags (die Raute im Forums-Editor) einschließen? Das liest sich besser :)
« Letzte Änderung: 31 März 2020, 19:52:46 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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #8 am: 31 März 2020, 20:23:31 »
Ich will nicht sagen, dass das normal ist, hat jedoch mit dem Keepalive-Timeouts des MQTT-Servers zu tun. Der ESP ist schon wieder weg, ehe der Server nachfragt. Sollte erst mal kein Problem sein, ich schau es mir bei Gelegenheit dennoch an, warum der Client sich nicht vernünftig verabschiedet.
Hast du das direkt auf dem Rechner ausgeführt, wo auch mosqitto läuft? Normal kommt die Meldung, wenn er einen Rechner-Namen nicht auflösen kann.
Schau dir mal deine Definitionen noch mal an, hier sind ein paar überzählige Backslash "\" enthalten. Möglicherweise sind die durch copy&paste der Raw-Definitionen aus der Anleitung reingekommen. Das erklärt auch die Fehlermeldung zu 3. Da ergänze ich die Anleitung um einen Hinweis.

VG

edit Kannst du bitte deine Definition etc. in code-Tags (die Raute im Forums-Editor) einschließen? Das liest sich besser :)

Hi Jendaw,

ja, ich habe es auf dem Rechner ausgeführt wo auch mosqitto läuft. Ich habe die Backslashes "([display:result_picture]) (set mqtt_device publish qos:1 stat/display/needUpdate true)" und "([display_status]) (set display convert)" entfernt und das sieht jetzt anders aus aber trotzdem auf dem Display bewegt sich nichts oder habe ich da noch etwas übersehen.
pi@FHEM:~ $ mosquitto -v
1585677848: mosquitto version 1.5.7 starting
1585677848: Using default config.
1585677848: Opening ipv4 listen socket on port 1883.
1585677848: Opening ipv6 listen socket on port 1883.
1585677868: New connection from 192.168.8.45 on port 1883.
1585677868: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585677868: No will message specified.
1585677868: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (0, 0)
1585677868: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585677868:     stat/display/needUpdate (QoS 1)
1585677868: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585677868: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585677890: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585677890: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585677903: New connection from 192.168.8.35 on port 1883.
1585677903: New client connected from 192.168.8.35 as NetMQTTpm737 (c1, k60).
1585677903: No will message specified.
1585677903: Sending CONNACK to NetMQTTpm737 (0, 0)
1585677903: Received PINGREQ from NetMQTTpm737
1585677903: Sending PINGRESP to NetMQTTpm737
1585677903: Received SUBSCRIBE from NetMQTTpm737
1585677903:     cmd/display/upload (QoS 0)
1585677903: NetMQTTpm737 0 cmd/display/upload
1585677903: Sending SUBACK to NetMQTTpm737
1585677903: Received SUBSCRIBE from NetMQTTpm737
1585677903:     cmd/display/upload (QoS 0)
1585677903: NetMQTTpm737 0 cmd/display/upload
1585677903: Sending SUBACK to NetMQTTpm737
1585677938: New connection from 192.168.8.45 on port 1883.
1585677938: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585677938: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585677938: No will message specified.
1585677938: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585677938: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585677938:     stat/display/needUpdate (QoS 1)
1585677938: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585677938: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585677960: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585677960: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585677963: Received PINGREQ from NetMQTTpm737
1585677963: Sending PINGRESP to NetMQTTpm737
1585677971: Received PUBLISH from NetMQTTpm737 (d0, q1, r0, m5, 'stat/display/needUpdate', ... (5 bytes))
1585677971: Sending PUBACK to NetMQTTpm737 (Mid: 5)
1585678008: New connection from 192.168.8.45 on port 1883.
1585678008: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678008: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678008: No will message specified.
1585678008: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678008: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d0, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678008: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678008:     stat/display/needUpdate (QoS 1)
1585678008: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678008: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585678023: Received PINGREQ from NetMQTTpm737
1585678023: Sending PINGRESP to NetMQTTpm737
1585678030: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585678030: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678078: New connection from 192.168.8.45 on port 1883.
1585678078: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678078: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678078: No will message specified.
1585678078: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678078: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d1, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678078: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678078:     stat/display/needUpdate (QoS 1)
1585678078: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678078: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585678083: Received PINGREQ from NetMQTTpm737
1585678083: Sending PINGRESP to NetMQTTpm737
1585678100: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585678100: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678143: Received PINGREQ from NetMQTTpm737
1585678143: Sending PINGRESP to NetMQTTpm737
1585678148: New connection from 192.168.8.45 on port 1883.
1585678148: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678148: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678148: No will message specified.
1585678148: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678148: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d1, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678148: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678148:     stat/display/needUpdate (QoS 1)
1585678148: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678148: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585678170: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585678170: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678203: Received PINGREQ from NetMQTTpm737
1585678203: Sending PINGRESP to NetMQTTpm737
1585678217: New connection from 192.168.8.45 on port 1883.
1585678217: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678217: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678217: No will message specified.
1585678217: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678217: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d1, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678217: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678217:     stat/display/needUpdate (QoS 1)
1585678217: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678217: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585678240: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585678240: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678263: Received PINGREQ from NetMQTTpm737
1585678263: Sending PINGRESP to NetMQTTpm737
1585678287: New connection from 192.168.8.45 on port 1883.
1585678287: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678287: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678287: No will message specified.
1585678287: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678287: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d1, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678287: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678287:     stat/display/needUpdate (QoS 1)
1585678287: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678287: Sending SUBACK to ESPEInk_ecfabcc2b1a9
1585678310: Client ESPEInk_ecfabcc2b1a9 has exceeded timeout, disconnecting.
1585678310: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678323: Received PINGREQ from NetMQTTpm737
1585678323: Sending PINGRESP to NetMQTTpm737
1585678357: New connection from 192.168.8.45 on port 1883.
1585678357: Socket error on client ESPEInk_ecfabcc2b1a9, disconnecting.
1585678357: New client connected from 192.168.8.45 as ESPEInk_ecfabcc2b1a9 (c0, k15).
1585678357: No will message specified.
1585678357: Sending CONNACK to ESPEInk_ecfabcc2b1a9 (1, 0)
1585678357: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d1, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
1585678357: Received SUBSCRIBE from ESPEInk_ecfabcc2b1a9
1585678357:     stat/display/needUpdate (QoS 1)
1585678357: ESPEInk_ecfabcc2b1a9 1 stat/display/needUpdate
1585678357: Sending SUBACK to ESPEInk_ecfabcc2b1a9
[sup]

Gruß
Peter

Offline ckbln

  • Jr. Member
  • **
  • Beiträge: 50
Hallo Jendaw
wenn ich versuche mich mit dem AP ESPEInk-APSetup zu verbinden bekomme ich die Info: Keine Verbindung mit diesem Netzwerk möglich.
Ich verwende die ESP32 Version vom Github  Yattien /ESPEInk_ESP32 . Habe noch kein Display angeschlossen.

Das sagt der serielle Monitor:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
E (53) SPIFFS: mount failed, -10025
Failed to mount FS
*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: 6
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESPEInk-APSetup
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started


Kannst du mir helfen?
Gruß
Christof

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #10 am: 01 April 2020, 02:03:59 »
1585678008: Sending PUBLISH to ESPEInk_ecfabcc2b1a9 (d0, q1, r0, m1, 'stat/display/needUpdate', ... (5 bytes))
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.

VG
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
wenn ich versuche mich mit dem AP ESPEInk-APSetup zu verbinden bekomme ich die Info: Keine Verbindung mit diesem Netzwerk möglich.
Ich verwende die ESP32 Version vom Github  Yattien /ESPEInk_ESP32 . Habe noch kein Display angeschlossen.

*WM: Configuring access point...
*WM: ESPEInk-APSetup
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started

Kannst du mir helfen?
Ich versuchs :)
Siehst du in deinen WLAN-Einstellungen denn den AP namens "ESPEInk-APSetup"? Diesen musst du statt deinem Router/AP auswählen, dann solltest du auch auf den Webserver kommen. Oder liegt das Problem wo anders?

VG
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
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #12 am: 01 April 2020, 07:49:23 »
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.
Die Version v14 enthält ein zusätzliches delay, damit die MQTT-Abfrage nicht so durchrauscht. Bin und Src stehen auf github bereit.
Falls das iO ist, übernehme ich das auch für den ESP32.

VG
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 ckbln

  • Jr. Member
  • **
  • Beiträge: 50
Ich versuchs :)
Siehst du in deinen WLAN-Einstellungen denn den AP namens "ESPEInk-APSetup"? Diesen musst du statt deinem Router/AP auswählen, dann solltest du auch auf den Webserver kommen. Oder liegt das Problem wo anders?

VG

Hallo
Windows versucht sich zu verbinden aber erfolgols.
VG

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Windows versucht sich zu verbinden aber erfolgols.
Puh, Win10 - das kann alles mögliche sein. Hattest du die Firmware mal auf einem anderen ESP benutzt?
Ansonsten könntest du das Übliche versuchen:
  • Netzwerk-Problembehandlung ausführen
  • Einstellungen -> Netzwerk-WLAN -> bekannte Netzwerke verwalten -> dann Name den Namen der Verbindung suchen und "Nicht speichern" klicken. Danach erneut verbinden
  • WLAN-Treiber aktualisieren
  • ggf mit Tablet/Handy konfigurieren
  • ...
Falls du eine Lösung für dieses Problem gefunden hast, kannst du sie hier teilen? Ich gucke mir an, ob ich den Namen des AP unique gestalten kann.

VG
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 ckbln

  • Jr. Member
  • **
  • Beiträge: 50
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

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Windows connected nicht zum AP
« Antwort #16 am: 02 April 2020, 02:26:04 »
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.
« Letzte Änderung: 02 April 2020, 06:15: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 Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #17 am: 03 April 2020, 21:13:11 »
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.
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
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #18 am: 07 April 2020, 16:16:04 »
trotzdem auf dem Display bewegt sich nichts oder habe ich da noch etwas übersehen.
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 :)
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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #19 am: 08 April 2020, 11:05:43 »
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

sd l▄ƒ< älÓ|  älõ #|çâý█søbä #─¾no×$gn£Òý cpîÄ${ls$p¹'Ó âlî£ coÒ|lõläcä‗'o´ $îÄl ÿgn d`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.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup aus deepsleep ist der ESP8266 nicht ansprechbar
« Antwort #20 am: 08 April 2020, 13:10:33 »
Danke für deinen Test.

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?
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: 513
  • Alles nur Hobby!
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

Offline pepe_11

  • New Member
  • *
  • Beiträge: 33



Und dann im zweiten Durchlauf wieder gelöscht?

Ja genau.

Gesendet von meinem ANE-LX1 mit Tapatalk


Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Bug: nach Wakeup ohne Daten wird ein "2in13 V2" gelöscht
« Antwort #23 am: 08 April 2020, 20:39:23 »
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.
« Letzte Änderung: 08 April 2020, 21:44:16 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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup ohne Daten wird ein "2in13 V2" gelöscht
« Antwort #24 am: 08 April 2020, 22:56:03 »
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.

rl d£×| îlÓ| îlýc|Ä├õø;ôcîcä¹gnƒdog£Òõc8äçlrd;lx¾oÓ ├ $ ä£  # gÒ|dýd─ bî¾ogþ läÅl`Ï'o d`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`Ï'o d`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

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup ohne Daten wird ein "2in13 V2" gelöscht
« Antwort #25 am: 09 April 2020, 18:06:25 »
Vielen Dank für deinen Input.

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

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 :D

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
« Letzte Änderung: 09 April 2020, 22:42: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 pepe_11

  • New Member
  • *
  • Beiträge: 33
Antw:Bug: nach Wakeup ohne Daten wird ein "2in13 V2" gelöscht
« Antwort #26 am: 10 April 2020, 11:31:46 »
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 :D

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


Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Antw:Bug: nach Wakeup ohne Daten wird ein "2in13 V2" gelöscht
« Antwort #27 am: 10 April 2020, 16:22:04 »
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
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 pepe_11

  • New Member
  • *
  • Beiträge: 33


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


Offline Jendaw

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

  • Jr. Member
  • **
  • Beiträge: 77
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:


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.
« Letzte Änderung: 26 Mai 2021, 15:52:58 von m.zielinski »

Offline Jendaw

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

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.
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 m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
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.

Offline m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
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!

Offline Jendaw

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

Zitat
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.
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.
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
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.
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
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.
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 m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
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.


Offline Jendaw

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

  • Jr. Member
  • **
  • Beiträge: 77
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.

Offline Jendaw

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

  • Jr. Member
  • **
  • Beiträge: 77
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...




Offline Jendaw

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

  • Jr. Member
  • **
  • Beiträge: 77
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...

Offline Jendaw

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

  • Jr. Member
  • **
  • Beiträge: 77
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.

Ich flashe mit Arduino 1.8.15. So eine Option habe ich bisher aber nicht gesehen. Ich gehe immer auf SKetch/Hochladen und lasse in compilieren Hochladen. Das es auf einmal komplett hing war aber ohne, dass ich direkt davor neu geflasht hätte.

Das mit den OTA-Updates muss ich mir wohl endlich mal genauer ansehen...


Den Widerstand werde ich auch noch auf die RST-Leitung legen. Aber ich finde viele Infos zu "Zombie-Modus" bei einigen ESP8266 die zu dem fehlerbild passen - leider ohne eine immer passende Lösung...

Es tritt auch auf egal ob mit USB-Powerbank als STromquelle oder am Windows PC.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Ich flashe mit Arduino 1.8.15. So eine Option habe ich bisher aber nicht gesehen. Ich gehe immer auf SKetch/Hochladen und lasse in compilieren Hochladen.

Hängt vllt. auch vom verwendeten Board ab, ich nutze die selbe ArduinoIDE-Version. Ich hab mal ein Bild angehangen, von dem, was ich meine.
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 m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
OK Die Option war etwas versteckt :-)

Ich habe jetzt mal temporär ein 5V USB-Netzteil angeschlossen. Immernoch läuft die Firmware aber nach unregelmäßiger Zeit gibt es keine Aktualisierungen mehr und das Konfigurations-Wlan ist wieder da- scheint, als ob öfter mal die Wifi-Config verschwunden geht. EInmal hatte ich auch schon, dass aus die MQTT-Konfiguration komplett leer war.

In meiner angepassten Firmware hatte ich die WifiDaten im Quellcode hinterlegt, wodurch es nach einem Restart wieder ging.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Immernoch läuft die Firmware aber nach unregelmäßiger Zeit gibt es keine Aktualisierungen mehr und das Konfigurations-Wlan ist wieder da- scheint, als ob öfter mal die Wifi-Config verschwunden geht. EInmal hatte ich auch schon, dass aus die MQTT-Konfiguration komplett leer war.

In meiner angepassten Firmware hatte ich die WifiDaten im Quellcode hinterlegt, wodurch es nach einem Restart wieder ging.

Der AP wird aufgespannt, wenn er sich nicht mit dem WLAN verbinden konnte. Hat er immer ausreichend WLAN an dem Ort (Reduzierung der WLAN-Stärke und Nachtabschaltung beachten)?
Ich könnte folgende Dinge anbieten:
1. Das Timeout für den Verbindungsversuch erhöhen
2. Für Selberkompilierer den WiFi-Verbindungsmanager optional machen/kennzeichnen, wo der Aufruf erfolgt und die Parameter hinterlegt werden können.
3. Kein Reset der WiFi-Daten, wenn keine WLAN verfügbar ist
 Dafür alternativ ein Reset über einen freien Eingang des ESP.

Schade, dass das bei dir nicht so klappt mit dem WiFi. Gibt aber auch viele Randbedingungen :(
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 m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
Nachtschaltung o.ä. habe ich nicht in meinem Wlan.

2 wäre vermutlich eine gute Idee

zu 3
wäre es möglich, dass er nach einem verlängerten Timeout den WifiManager anzeigt. Wenn der nach 5 Minuten aber immernoch nicht angesprichen wird, den ESP wieder in DeepSleep zu legen und erneut aufwachen zu lassen mit neuem Verbindungsversuch auf den hinterlegten Wifi-Daten ?

Damit würde er sich selbst berappeln und man könnte trotzdem an das Konfig-Wifi kommen ohne Löten/Taster.

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
wäre es möglich, dass er nach einem verlängerten Timeout den WifiManager anzeigt. Wenn der nach 5 Minuten aber immernoch nicht angesprichen wird, den ESP wieder in DeepSleep zu legen und erneut aufwachen zu lassen mit neuem Verbindungsversuch auf den hinterlegten Wifi-Daten ?

Sollte machbar sein. Ich hab die Konstante MAX_CONNECTION_FAILURES = 1 eingeführt, die dafür zuständig ist. Standard ist ein Neuversuch. Das Timeout für den AP habe ich auf 6min gesetzt: wifiManager.setConfigPortalTimeout(360);Ich bin jedoch noch nicht dazu gekommen, das zu testen, hat also Bananenstatus :)
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 m.zielinski

  • Jr. Member
  • **
  • Beiträge: 77
Der Code reift...
Habe die Änderungen installiert und den timeout auf 10 gesetzt.
vorhin war einmal der AP auf aber wie erwartet hat er nach ner Weile rebooted und lief ohne Eingriff meinerseits.

Ich beobachte weiter. sieht erstmal gut aus.

Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Jendaw

  • Full Member
  • ***
  • Beiträge: 111
    • Alternative ESPEInk-Firmware
Ich hab deine Antwort mal "entführt" :)

- Die Software von Yattien konnte ich genau einmal konfigurieren. Egal was ich zwischendurch auf den ESP spiele sobald ich die Yattien Software drauf spiele, zieht er sich von irgendwoher die Daten für das WLAN und den MQTT Server den die ich mal zum testen eingegeben habe. Somit komme ich nicht dazu den Workaround über MQTT aufzubauen. Auch mit /reset komme bekomme ich das Teil nicht zurückgesetzt.

Dein Setup sollte mit der Waveshare-Software laufen - die Yattien-Firmware erweitert diese nur.
Wenn du bereits einmal die MQTT-Daten konfiguriert hast, wird der Webserver gar nicht erst gestartet, um die Daten reseten zu können (hier muss ich mir noch was geschicktes einfallen lassen, damit das dennoch geht, ggf. über die Konsole). Die Daten sind jedoch in einer Datei gespeichert, die du "nur" löschen musst. Die WLAN-Daten sind davon noch mal separat gespeichert.
Was du tun könntest ist:
- dem ESP den WLAN-Zugang zu verweigern, damit wird der Konfigurations-AP erneut gestartet - oder
- die Yattien-Firmware neu zu flashen, dabei als Flash-Option "Erase Flash: 'All Flash Contents'" angeben (der Screenshot dafür ist ein paar Beiträge weiter oben in diesem Thread)

HTH
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)

 

decade-submarginal