State Machine und Command Queue für ESP8266 "Tasks"

[stefan123t]

Ich habe nur Nachts mit dem WiFi WebServer Probleme. Tagsüber läuft alles.
Ich habe die Vermutung, dass wenn die RX Routine keine Payload zusammen bekommt, dann verhungert der weniger priore WebServer „Task“. Wie das Verhalten bei zwei Wechselrichtern ist kann ich nicht sagen.

@lumapu vielleicht sollten wir doch eine State Machine einführen, die dafür sorgt dass alle „Tasks“ erledigt werden. Es geht ja um ein Neben-/Nacheinander von:

• WiFi Verbindung aufbauen
  • NTP Zeit ermitteln oder aktualisieren (WiFi)
  • WebServer Seiten ausliefern (WiFi)
  • MQTT Nachrichten versenden (WiFi)
• TX/RX Aufgaben (nacheinander für alle definierten Wechselrichter) + Payload dekodieren (NTP)

Dabei ist wichtig dass einige Tasks nur mit WiFi funktionieren. Sollte der ESP die WiFi Verbindung verlieren muss er evtl. andere Tasks hinten anstellen.

Auch sollte er mE nicht die WR fragen so lange die NTP Zeit noch nicht gesetzt ist (> 0 unix epoch).
Wie gross die Abweichung der ESP Zeit von der NTP Zeit ist sollte er ggf. auch in regelmäßigen Abständen überprüfen.
Aber das ist nicht so dringend, alle paar / 24 Stunden reicht vielleicht schon.

Wie häufig soll denn eigentlich der/die WR abgefragt werden, reicht das alle paar / 5 Minuten ?

Die MQTT Daten häufiger als die TX/RX Daten zu übermitteln macht auch keinen Sinn.
Das könnte ggf. über ein Flag als nachgelagerter Task oder alle x Minuten erfolgen.

Die beiden wichtigsten Tasks bleiben mE TX/RX Daten an die WR übermitteln (weil zeitkritisch) und den ESP WebServer die Anfragen abarbeiten lassen, weil sonst keine Verbindung möglich ist und ggf auch der Eingangspuffer des ESP/WebServers überlaufen könnte.

Der bisher auch immer wieder geschedulete AccessPoint Task ist mE nicht ganz so wichtig.
Der muss eigentlich nur zwingend nach einem Reboot zur Verfügung stehen.
Eventuell kann man den AP auch gleichzeitig zum WebServer im Station Mode aufmachen, dann könnte man das über eine Option im WebServer Menü jederzeit zusätzlich aktivieren.

Dass er ggf. nach X Verbindungsversuchen mit dem WiFi auch wieder den AP aufmacht ist mE eine nützliche Convenience Funktion, nimmt aber bei mir viel Zeit in Anspruch, die nicht für den (Wieder-)Aufbau der WiFi Verbindung (NTP, WebServer & MQTT Client) zur Verfügung steht.
Da meine WiFi Verbindung (im Keller) manchmal (tagsüber) von vielen anderen Funkteilnehmern stark übersteuert / gestört wird.
Aber mit dem AP kann ich außer zum Setup nicht so viel anfangen.
Dazu müsste ich mich ja jeweils direkt mit dem AP verbinden und habe dann kein Internet mehr am Rechner.
Und den MQTT Broker erreicht der ESP dann vorerst sowieso nicht.

[stefan123t]

Thomas B.‘s OpenDTU verwendet die WiFi Station mode und MQTT Status Events plus eine Event Handler Klasse um ggf. Statusänderungen bzw. deren Events zu behandeln.
Hier der Event Handler für die WiFiEvent_t event types:
https://github.com/tbnobody/OpenDTU/blob/183b919ae6f50563a4b3a8dbe00f7c25b533fc4a/src/MqttSettings.cpp#L13
Und hier die Definition der WiFiEvent_t Typen als enum:
https://github.com/esp8266/Arduino/blob/b0ece8cac42907b14794925ff6d256a0820ee4e9/libraries/ESP8266WiFi/src/ESP8266WiFiType.h#L58
Und hier die Beschreibung eines Kaffeeröster Zustandsautomaten als abstraktes aber zugleich konkretes Beispiel:
https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/

[stefan123t]

Das könnte für den in #142 beschriebenen Scheduler und die Command Queue sinnvoll sein.