Softwaredoku

Software Dokumentation

Anmerkung:
Dateien, in denen für den Leertrinkbetrieb programmiert wurde.
ESP-Memory(alles)
ESP-Bestellen: Bestellen.ino, functions.h,functions.cpp, Leertrinkbetrieb.h, index.h, jquery.h

Beginnen möchten wir mit der Vorstellung des Aufgabengebietes: Auswertung der Informationen
Wie bereits erwähnt, wurde die Auswertung auf zwei ESPs verteilt(ESP-Memory, ESP-Bestellen).
Der erste Codeausschnitt zeigt die erste Auswertung auf dem ESP-Memory:

Memory_ESP

Gesendet wird eine stock[8] dieser wird abgefragt und entsprechend der Bedingung wird das
Array transfer_data mit bool-Werten befüllt. Die Logik ist in dem File ESPnow.cpp in der
Funktion OnDataReceive implementiert. Anschließend wird transfer_data[8] via UART gesendet.
Der zweite Teil, der auch wesentlich umfangreicher ist, übernimmt die
ESP-Bestellen:

Das Auswertungs_array, welches mit dem Transfer_data_array beschrieben wird, wird hier ausgelesen.
Hier werden die einzelnen Zutaten mit ihren jeweiligen, aktuellen Werte beschrieben.
Nun kommen wir zu der eigentlichen Auswertung(welche Cocktails sind überhaupt machbar).
Hierzu werden die einzelnen Zutaten Funktionen übergeben, die auswerten,
ob ein Cocktail möglich ist, oder nicht und das Ergebnis in einem Array für alkoholische Cocktails
und antialkoholische Cocktails wieder mit bool Werten beschreibt.

Funktionen_Loop

Natürlich wird dasselbe auch für die antialkoholischen Getränke gemacht. Zu finden ist dieser Teil
des Codes in der Bestellen.ino, genauer gesagt in der loop(da es ja immer wieder
kontolliert werden soll. Die Funktionen sind
ausgelagert in den functions.cpp und functions.h. Noch ein kleiner Ausschnitt aus der
functions.cpp, der Vollständigkeit halber.

UART-Kommunikation

Nun kommen wir zu der UART-Kommunikation. Betrachten müssen wir hier den Code in ESP-Memory und den
Code in ESP-Bestellen. Wir beginnen wieder mit der ESP-Memory. Zu sehen ist die vollständige Loop
der Ino Datei.

Die vielen auskommentierten Zeilen sind ein Überbleibsel eines komplizierten Handshakes zwsichen ESP-Bestellen
ESP-Memory, welcher aber im Endeffekt eher negative Auswirkungen hatte, deshalb wurde auf ein
Handshake zwsichen ESP-Bestellen und ESP-Memory in dem Sinne verzichtet. Wichtig ist allerdings der
programmierte handshake, der im Prinzip signalisiert, dass alle Daten von ESP-Wiegen angekommen
sind und somit als Startzeichen für die UART-Kommunikation dient. Anschließend wird das halb
ausgewertete Array transfer_data(siehe obere Erklärung zu Auswertung) via UART versendet(Serial.write). Die
counter-logik mit dem Reset des ESPs wird eingeführt, um die Kommunikation zu synchronisieren, da
erst beim Reset des ESP-Memory richtige Daten bei der ESP-Bestellen ankommen, bzw. die Kommunikation
im richtigen Rhythmus ist. Vor dem Hintergrund eines Zwischenspeichers ist es jedoch klar,
dass die Kommunikation, insbesondere die Synchronität bzw. das Detektieren von richtigen
Nachrichten kein einfaches Unterfangen ist. In Bezug auf unser Unterfangen ist jedoch ein gewisses Zeitfenster
gegeben, da sich die Zutaten für ca. 10-15 Sekunden in aller Regel nicht verändern(Auswahl Getränk,
Zubereitung etc.). Das heißt unsere Kommunikation sollte alle 10-15 Sekunden eine "richtige Nachricht"
versenden bzw. empfangen. Stand jetzt ist dies gewährleistet, sofern synchronisiert(geresetet wird). Kommen wir
nun wieder zu dem ESP-Bestellen. Hier befindet sich die UART-Logik logischerweise in der Bestell.ino / loop.

Bestellen_Loop1

Der Handshake ist wie auch bei der ESP-Memory auskommentiert. Mit Serial.available() wird überprüft, ob
die Kabelverbindungen(RX/TX) besteht. Die Abfrage hat sich insofern als nützlich erwiesen, da wenn keine
Verbindung besteht, die Loop nicht ausgeführt wird! Mit Serial.read wird die Nachricht ausgelesen. Da wir wie
bereits erwähnt mit einem Synchronisationsproblem zu kämpfen hatten, wurde ein Filter implementiert
der die falschen Nachrichten(immer nur 1er) rausfiltert und nur Nachrichten, mit unterschiedlichen Werten
in das auswertungs_array schreibt. Ferner bestand das Problem, dass für eine gewisse Zeit immer diesselbe
Nachricht geschickt wird, obwohl die Nachricht an sich nicht mehr dieselbe war. Auch dieses Problem
war verschmerzbar, da das Empfangen von gleichen Werten unproblematisch ist, wenn nach einer
gewissen Zeit, wieder eine Synchronität hergestelllt werden kann. Schlimmer wären unterschiedliche falsche
Werte, da dies bedeuten würde, dass sich die Leertrinkfunktion(welche Cocktails sind darstellbar ..)
sich verändern würde. Halten wir also fest: die Kommunikation ist ein fragiles Gebilde, bei dem
die Synchronität der Nachrichten und das Empfangen der richtigen Nachricht komplex ist.

Wichtig für die UART-Kommunikation:

Die beiden ESPs, die miteinander kommunizieren über die UART, benötigen unbedingt eine
gemeinsame Masse! . Das heißt ESP-Memory und ESP-Bestellen

In Anbetracht der aufgebrachten Zeit für das Projekt gehen wir zwar diesem Problem nach,
allerdings belassen wir es darauf, das Problem zu detektieren und ggf. schnell zu beheben. -Stand 24.04.2020

/*Nachtrag/*

Erste Test haben gezeigt, dass höchstwahrscheinlich nur ein Problem der Bezugsmasse vorhanden ist. Wenn
ESP-Bestellen und ESP-Memory den gleichen Massebezug besitzen, spielt es keine Rolle von welchem Gerät
die Energieversorgung stammt.

Dynamische Webseite

Der ESP-Bestellen erstellt verschiedene Dateien, die für das Bilden der Webseite notwendig sind. Dazu gehören
die design.css, die alle Anpassungen des Aussehens der Webseite enthält, die cocktails.json, die die
Informationen über die Verfügbarkeit der Cocktails enthält und die jquery, die notwendig ist, um die
Webseite teileweise neuzuladen, ohne dass ein neues Bilden der Webseite Cocktailmaschine
gemacht werden muss. Index.h in der die Verlinkung des empty_drink_mode implementiert ist.
Schlussendlich noch die Leertrinkbetrieb.h in der teilweise statische Elemente implementiert sowie dynamsiche
Elemente umgesetzt sind.

Beim Aufruf des Links empty_drink_mode auf der Index Seite der Cocktailmaschine wird im Hintergrund ein
Javascript ausgeführt, dass im Intervall von 5 Sekunden die Lister der alkoholischen und anti-
alkoholischen Cocktails aktualisiert. Dabei wird die Cocktail.json geparst, um die Information der
verfügbaren Cocktails auszulesen. Die noch verfügbaren Cocktails werden über eine Abfrage
dann in einem HTML String gepackt. Durch eine AJAX-Programmierung(Asynchronous JavaScript
and XML), die das partielle Neuladen einer HTML-Webseite ermöglicht, wird der String, der noch
verfügbaren Cocktails, geladen. Nachfolgend wieder ein paar gut auskommentierte Programmzeilen.
Momentan bereitet der Bestellbutton noch Probleme, d.h. man kann keinen Cocktail bestellen auf der empty
drink_mode Seite.(Stand 24.04.2020)

JQueryLoop1

Zu finden ist dieser Codeausschnitt in ESP-Bestellen, Bestellen.ino in der setup-Funktion.
Nachfolgender Codeausschnitt ist in der Leertrinkbetrieb.h zu finden.

V1_Lerrtrink