Die Software für das Indoor Haus ist einfach zusammenfassen, bietet jedoch eine gewisse Komplexität. Wurde die “requestData”-Flag gesetzt, so wird über MQTT die Node-RED Instanz angestoßen. Diese fordert dann bei der entsprechenden API die benötigten Daten an. Diese Daten werden an das Haus zurückgeschickt und können in der “handle MQTT” Phase verarbeitet werden.
Nach der Verarbeitung sämtlicher MQTT Nachrichten wird geprüft, ob noch weitere Anfragen verarbeitet werden müssen oder ob der Bildschirm deaktiviert ist. Ist dies der Fall, werden die Displays geleert und die Schleife springt zum Anfang zurück. Die Variable “lightOn” kann mittels MQTT, also der App, und per Interrupt an dem Schalter vorne am Haus verändert werden.
Sind die Displays hingegen aktiviert und sollen Daten anzeigen, wird auf einem Display ein Auswahlmenü eingeblendet und auf dem anderen Display werden die Daten angezeigt. Mithilfe des Drehimpulsgebers (Schornstein) ist das Menü navigierbar. Auch diese Interaktion wird über Interrupt und die App realisiert, sodass nicht immer in der Loop erfragt werden muss, ob eine Auswahl stattgefunden hat.
Das Outdoor-Haus erlaubt keine Interaktion und ist so implementiert, dass es von überall Daten aufnehmen und an das Indoor-Haus senden kann. Dazu verbindet sich der Mikrocontroller zuerst mit dem WiFi und baut eine Verbindung zum MQTT-Broker auf. Daraufhin folgt eine Aufnahmereihe von 10 Aufnahmen, aus welchen ein Mittelwert errechnet wird. Ist dies geschehen, werden die Daten mittels MQTT an alle abonnierenden MQTT-Teilnehmer gesendet (Indoor-Haus). Abschließend geht der Controller für eine Minute in den Deep Sleep Modus. Um aus diesem Modus wieder “erwachen” zu können, müssen der D0 und der RST Pin miteinander verbunden sein. Die Nutzung des Deep Sleep Modus hat zwei verschiedene Gründe:
- Der Wemos d1 Mini produziert im Dauerbetrieb eine enorme Menge an Wärme, welche unweigerlich die Aufnahme der Temperaturwerte verfälscht. In einigen Tests wurden Temperaturabweichungen bis zu 10 °C festgestellt.
- Da der Wemos eine Minute lang nahezu ausgeschaltet ist, wird dabei keine Energie verbraucht und der Akku muss seltener geladen werden.
Die Implementierung der App erfolgte online mit Hilfe der Website MIT App Inventor. Durch die Erweiterung eines Beispielprogramms, welches bereits MQTT implementiert hatte, konnte relativ simpel eine einfache App gestaltet und mit MQTT-Funktionalität ausgestattet werden.
Blynk kam in diesem Projekt nicht mehr zum Einsatz. Grund dafür ist Blynks neuer Businessplan, der nicht mit Zielen des Projekts verainbar ist.
Der Node-RED-Flow (siehe Abb. 3) ist aktuell darauf begrenzt, Anfragen an die SpaceX-API zu triggern und die Daten dann wieder mittels MQTT zu übermitteln.
Bibliotheken
Um das Projekt realisieren zu können, wurden diverse Bibliotheken verwendet. Diese Bibliotheken können alle im Library Manger der Arduino IDE heruntergeladen werden:
- “Adafruit GFX Library” by Adafruit, v1.10.10
- “Adafruit SSD1306 Wemos Mini OLED” by Adafruit + mcauser, v1.1.2
- “ArduinoMqttClient” by Arduino, v0.1.5
- “WiFiManager” by tzapu,tablatronix, v2.0.3-alpha
- “DHT sensor library” by Adafruit, v1.3.9
- “Time” by Michael Margolis, v1.6.1 (https://github.com/PaulStoffregen/Time)
Da die Bibliothek “Adafruit SSD1306 Wemos Mini OLED” die selben Klassennamen hat, wie die Bibliothek “Adafruit Da die Bibliothek “Adafruit SSD1306 Wemos Mini OLED” die selben Klassennamen hat wie die Bibliothek “Adafruit SSD1306” by Adafruit, besteht die Gefahr, dass der Compiler nicht die richtige Klasse zuordnen kann. Um dieses Problem zu umgehen, wurden die Klassen in der Bibliothek “Adafruit SSD1306 Wemos Mini OLED” mittels find and replace so bearbeitet, dass alle Klassennamen um den Suffix “_WEMOS” ergänzt wurden. Auf diese Weise können beide Bibliotheken simultan verwendet werden.
Noch keine Kommentare.