Das Projekt ist von der Ideenfindung bis zum fertigen Endprodukt beinahe reibungslos verlaufen – Kommunikation und Zusammenarbeit funktionierten sehr gut und eventuelle Meinungsverschiedenheiten wurden konstruktiv aufgearbeitet.
In der Organisation hat die eingangs erstellte GoogleDocs Tabelle sehr dabei geholfen, den Überblick zu bewahren und Treffen zu organisieren – die wichtigsten Meetings waren jedoch meist die, welche spontan berufen wurden, um Lösungen für akute Probleme zu finden.
Während der Softwareentwicklung gab es ein paar wenige Hürden zu überwinden, mit ein wenig Zeit gelang dies jedoch mehr oder weniger elegant.
Beim Druck der 3D-Modelle gab es unvorhersehbare Komplikation, weshalb zeitlich leider keine zweite Iteration mehr möglich war, welche noch ein paar kleinere Fehler behoben hätte.
Lessons Learned
Unvorhersehbare Komplikationen: Beim 3D-Druck kam es zu einem Problem außerhalb unserer Macht, was dazu führte, dass wir im keine Zeit für einen eventuellen zweiten Design- und Druckdurchgang mehr hatten – für die Zukunft werden wir für solche Eventualitäten mehr Pufferzeit einplanen.
Meetings: Um bei Meetings bei kommenden Projekten nicht verspätet teilzunehmen und von den Projektmitgliedern erinnert werden zu müssen, auch am PC die Erinnerungsfunktion des Kalenders nutzen.
Spontanität: Während eine gute Planung für uns den Projektablauf sehr erleichtert hat ist es doch wichtig zu erwähnen, dass die für uns wichtigsten Meetings meist die waren, welche spontan als Reaktion auf ein akutes Problem stattgefunden haben. Natürlich ist es besser, wenn diese nicht stattfinden müssen – aber wenn sie es tun, ist es sehr gut, gute Entscheidungen auch auf der Stelle treffen zu können.
Verbesserungen für v2
Der begrenzten Projektzeit geschuldet gibt es einige Punkte am Projekt, welche noch verbesserungswürdig sind – entweder, weil sie noch gar nicht berücksichtigt wurden, oder weil sie aus verschiedenen Gründen noch nicht perfekt umgesetzt werden konnten.
Software:
Zugriffsrechte: Aktuell sind sowohl die NodeRED-Instanz als auch der MQTT-Broker frei für jeden im gleichen Netzwerk zugänglich. Beide bieten jedoch die Möglichkeiten, eine Authentifizierung zumindest per Benutzername und Passwort zu verwenden. Hinzu kommt, dass auch die Messenger-Dienste noch keinerlei Filter haben, der nur bestimmten Benutzern erlauben würde, Befehle für das System zu Senden. Die verwendete Telegram-API-Zugriffs-Implementierung bietet hierfür schon eine Möglichkeit an, diese ist jedoch nicht dynamisch änderbar – eine eigene, für beide Messenger wieder verwendbare Lösung wäre also vorzuziehen.
Support für mehr Messenger: Aktuell werden von MED Telegram und Discord unterstützt, da beide vergleichsweise einfache Möglichkeiten für automatisierte Interaktionen bieten. Generell sind diese jedoch nicht die weitverbreitetsten Messenger-Dienste – Unterstützung für weitere Dienste wäre also wünschenswert.
Code-Verbesserungen: Im Quellcode für die Microcontroller gibt es zwei – kommentierte – Ungereimtheiten, für welche wir bis dato jeweils einen etwas unschönen Workaround benutzen müssen. Diese sollten nach Möglichkeit behoben werden.
Design:
GPIO-Cap für das RasPI-Case: Ursprünglich wurde eine Abdeckung für GPIO Pins modelliert, die noch angepasst werden muss, bezüglich der belegten Pins.
Display/Case Anpassungen: Wir haben im Case eine Halterung für das Display eingebaut, dabei allerdings keine Einkerbung für die herausstehenden Pins eingeplant. Dadurch sitzt das Display nicht vollkommen eben und ist auch nicht bündig am rand des Cases, sondern leicht schieß und etwas weiter drinnen.
MC Halterung im Case: Damit der MC im Case nicht wackelt haben wir eine Halterung für ihn mit eingebaut. Dabei haben wir übersehen, dass er von einem Kabel etwas nach hinten geschoben wird. Dadurch wurde der MC versetzt angebracht, sodass er weiter hinten sitzt. Dafür sind die letzten beiden Pins nicht angeschlossen.
Kabelverlauf: Die Kabel laufen ohne eine höhere Ordnung durch den Case es wäre schöner (ästhetischer) gewesen wenn wir eine Halterung für den Kabelverlauf eingebaut hätten.
Höhe und Breite des Mirco-USB Anschlusses: Für leichteres Aufladen mit jedem Micro-USB Kabel hätte das Anschlussloch etwas größer sein sollen. Dadurch das der MC weiter als geplant im Case sitzt macht es den Anschluss noch schwieriger zu erreichen.
Hardware:
Reed-Switches mit längeren Kabeln: Aktuell verwendet der Haustür-Detektor Reed-Switches mit relativ kurzen Kabeln, welche eine Anbringung leicht erschweren können. Ein Modell mit längeren Kabeln wäre hier sinnvoll.
Größeres LCD: Das aktuell verwendete LCD bietet Platz für 32 Zeichen. Es gibt jedoch auch gleichgroße Modelle, welche bis zu 80 Zeichen unterstützen.
MED greift zur Realisierung seiner Software-Komponenten auf einige bestehende Bibliotheken und Projekte zurück, basierend auf welchen er seine eigenen Komponenten aufbaut.
Auf dem verwendeten Raspberry Pi laufen (auf einem kopflosen Raspbian-Betriebssystem) zwei Projektrelevante Softwares:
NodeRED stellt mit seiner graphischen Programmieroberfläche und vielseitigen Integrationen die zentrale Steuereinheit MEDs dar. Zur Ergänzung der Standardfunktionen NodeREDs werden folgende Pakete verwendet:
node-red-contrib-speakerpi erlaubt das Abspielen von Tönen auf dem Raspberry Pi selbst
node-red-contrib-discord erlaubt das Empfangen und Senden von Nachrichten über den Anbieter Discord.
node-red-contrib-telegrambot erlaubt das Empfangen und Senden von Nachrichten über den Anbieter Telegram
node-red-dashboard erlaubt das Anlegen einer Website als Steuereinheit
Mosquitto ist ein einfacher MQTT-Broker, welche eine einfache, kabellose Kommunikation zwischen verschiedenen Geräten – hier Raspberry Pi und ESP8266 – ermöglicht.
Auf beiden verwendeten Microcontrollern kommen bestehende Softwarebibliotheken zum Einsatz, welche folgende Funktionalitäten bereitstellen:
WiFiManager (v0.15.0) von tzapu und tablatronix – Ermöglicht die dynamische Eingabe von WiFi-Verbindungsdaten sowie weiteren Parametern, anstatt diese fest im Quelltext zu hinterlegen
PubSubClient (v2.7.0) von Nick O’Leary– Implementiert MQTT-Kommunikation auf Seiten der Microcontroller
ArduinoJSON (v6.18.3) von Benoit Blanchon – Erlaubt das Erstellen und Auslesen von JSON-Strukturen, welche dann etwa über ein Netzwerk übertragen oder lokal gespeichert werden können.
Zusätzlich werden die Standard-Bibliotheken ESP8266WiFi und FS (Filesystem) verwendet.
Dazu kommt auf dem Klingel-Microcontroller die Bibliothek LiquidCrystal_I2C (v1.1.2) von Frank de Brabander, welche zur Steuerung des angeschlossenen LCD über einen I2C-Bus verwendet wird.
Systemaufbau und Schnittstellen
Gesamtsystem
Das System besteht, wie bereits in der Hardwaredokumentation beschrieben, aus einem Raspberry Pi und zwei ESP8266 Microcontrollern. Aus der obenstehenden Grafik kann der Aufbau des Systems und die Verknüpfung der einzelnen Geräte entnommen werden: Die zentrale Steuereinheit des Systems befindet sich innerhalb von NodeRED und kommuniziert von dort aus auf zwei Arten mit anderen Geräten und Systemen: Der direkt an den Raspberry Pi angeschlossene Reed-Switch für die Überwachung der Haustür wird über einen GPIO-Pin des Raspberry Pi angesteuert, die beiden Microcontroller jeweils per MQTT über einen lokalen Mosquitto-Server als Broker. Die an die Microcontroller angeschlossenen Komponenten sind fest verlötet und werden über die zuvor genannten Bibliotheken angesprochen.
Entwicklungsablauf
Vor Beginn der eigentlichen Entwicklung wurden die oben genannten Bibliotheken und Packages gewählt und installiert.
Als erster eigentlicher Entwicklungsschritt werden die grundlegenden NodeRED-Flows angelegt, welche zu diesem Zeitpunkt bereits eine erste Version des Dashboards sowie einen Debug-Flow enthalten, welcher zur Simulation von MQTT-Eingaben genutzt werden kann. Außerdem enthalten ist die grundlegende Version des Ablaufs, welcher beim Eintreten eines Events (Klingeln, Briefeinwurf, Tür geöffnet/geschlossen) aufgerufen wird:
Flow bei Klingel Event (finale Version)
Dieser Ablauf setzt maßgeblich auf eigenprogrammierte “Gate”-Functions. Diese haben zwei mögliche Inputs: Zum einen die kleinen, grauen Nodes, welche hier Eingänge aus den Dashboard-Einstellungen darstellen – hiermit kann der Status (An/Aus) des Gates verändert werden, wenn eine entsprechende Änderung im Dashboard vom Nutzer vorgenommen wird. Der zweite mögliche Input des Gates wird vom Gate selbst nicht weiter verarbeitet, sondern weitergeleitet, sofern der Status des Gates aktuell “An” ist – andernfalls wird die Nachricht ignoriert. Je nach Gate wird die Nachricht an eine entsprechende Node weitergeleitet – das Aktiv-Gate leitet jeweils an alle Funktionsgates weiter, das Audio-Gate an die Lautsprecherfunktion und so weiter.
Als nächstes werden die grundlegenden Versionen des Microcontroller-Codes angelegt. Diese basieren grob auf Beispielen aus Vorlesung und Übungen, werden jedoch angepasst, um gleichzeitig den WiFiManager und MQTT-Verbindungen benutzen zu können. Dabei werden die Verbindungsdaten zum MQTT-Broker nicht fest im Quelltext hinterlegt sondern dynamisch zum Systemstart als Custom Parameter über den WiFiManager abgefragt:
WiFiManager Custom Parameter
Diese Parameter werden nach einer erfolgreichen Verbindung in Variablen zwischengespeichert und vom System verwendet. Um die Daten nicht bei jedem Systemstart erneut eingeben zu müssen werden diese darüber hinaus noch im Dateisystem in einer .json Datei gespeichert (und vor dem Anlegen der Custom Parameter erneut geladen).
Als nächstes wird Unterstützung für die Messenger Telegram und Discord implementiert, sodass Benutzer des Systems von diesen Nachrichten erhalten und Nachrichten an diese Senden können. Hierfür werden die oben genannten Bibliotheken für die jeweiligen Messenger verwendet, welche jedoch jeweils vom Endbenutzer an zwei Stellen konfiguriert werden müssen: Zum einen muss jeder Benutzer einen eigenen API-Token angeben (erhalten für Telegram vom sog. BotFather, für Discord über die Discord Developer Seite), zum andern muss jeweils klargemacht werden, an welchen Chat oder Chatkanal der jeweilige Bot eine Nachricht senden soll. Diese haben jeweils eine dem jeweiligen System zugehörige ID, welche der Benutzer herausfinden muss. Um dies zu erleichtern, wird die Möglichkeit bereitgestellt, beim Empfang einer Nachricht, welche das Kommando /start oder /info enthält, dem jeweiligen Benutzer diese ID automatisch zuzuschicken:
Ablauf des ID-Findens (Telegram)handleMessage Function Node
Die gefundene ID muss vom Benutzer selbst dann noch einmalig in eine Function-Node eingetragen werden. Diese könnte auch im Dashboard übergeben werden, dort ist sie jedoch nicht persistent, geht also bei Neustarts des Systems verloren – beim Eintragen in einer function-Node ist dies nicht der Fall, weshalb diese Variante ausgewählt wurde.
An dieser Stelle werden die NodeRED-Flows in drei Teile aufgeteilt (sowie den aktuell noch vorhandenen Debug-Flow): > Configuration: Enthält, der Übersicht halber, beinahe ausschließlich Nodes, welche vom Endbenutzer einmalig konfiguriert werden müssen. > MED-Logik: Enthält den Großteil der logischen Abläufe > Dashboard: Enthält alle Komponenten welche direkt im Dashboard verwendet werden sowie die Reaktionen auf Dashboard-Aktionen, welche nicht ebenfalls in anderen Flows verwendet werden. Die drei Flows werden dabei untereinander durch Link in/Link out Nodes verbunden, welche drahtlose Verbindungen zwischen Nodes (auch zwischen verschiedenen Flows) ermöglichen. [Genauere Übersicht über die einzelnen Flows weiter unten]
Zwischenzeitlich werden die tatsächlichen Detektions-Funktionen der Microcontroller programmiert: Ein Knopfdruck für die Klingel und ein IR-Sensor, welche jeweils beim Auslösen eine MQTT-Nachricht versenden, welche dann von NodeRED empfangen und verarbeitet werden.
Nun wird die Historienfunktion hinzugefügt. Diese speichert, sofern jeweils im Dashboard aktiviert, Events sowie die aktuelle Zeit in einer csv-Datei und gibt diese wenn gewünscht auf einer Extraseite im Dashboard wieder aus.
Historientabelle mit Beispieleinträgen
Als letztes Feature wird nun noch das LCD integriert, auf welchem Nachrichten des Benutzers angezeigt werden können. Hierbei kann der Benutzer entweder mit dem Kommando /send Nachricht seine gewünschte Nachricht an NodeRED senden, oder diese direkt im Dashboard in das zuständige Textfeld eingeben. Darüber hinaus kann er im Dashboard auswählen, wie lange die jeweilige Nachricht angezeigt werden soll, wodurch ggf. Akkuleistung gespart werden kann. Wird eine Nachricht von einem Messenger erhalten, so prüft NodeRED zunächst, ob die Nachricht auf das Display passt (Dieses unterstützt mit 2 Reihen a 16 Zeichen insgesamt 32 maximal Zeichen) – ist dies nicht der Fall so wird dem Nutzer eine entsprechende Fehlermeldung angezeigt, andernfalls wird das Display mit der Nachricht für die im Dashboard gewählte Zeit aktiviert. Eine Beispiel-Ausgabe (auf einem 4×20 Display) sieht wie folgt aus:
Ausgabe eines Beispiel-Textes auf einem (größeren) LCD
Nachdem die Softwareentwicklung an sich nun abgeschlossen ist, bleiben nur noch einige Aufräumarbeiten, wie etwa den bisherigen working-title in allen Instanzen durch den neu gewählten Projekttitel MED zu ersetzen oder den Debug-Tab des Dashboards und diverse Serial.println()s aus dem Quelltext der Microcontroller zu entfernen.
Erstellte Oberflächen
An dieser Stelle werden die entworfenen Oberflächen gezeigt, welche entwickelt wurden, bisher aber noch nicht direkt vorgestellt wurden.
Dashboard
Das Dashboard bietet, wie bereits erwähnt, genaue Kontrolle darüber, welche Aktion ausgehend von einem Event getroffen werden soll. Darüber hinaus kann pro Event festgelegt werden, wieviel Zeit zwischen zweimaligem Auslösen des Events vergehen muss. Zusätzlich kann der Nutzer Nachrichten an das LCD im Klingelgehäuse versenden und die Dauer der Nachrichtenanzeige auf dem LCD bestimmen. Zuletzt kann noch ausgewählt werden, ob Nachrichten via Telegram, Discord oder Beidem empfangen werden sollen.
WiFiManager mit MQTT-Custom-Parametern
Diese Oberfläche wird vom WiFiManager automatisch generiert – aus den Standard-Daten, die für einen WiFi-Login benötigt werden, und den übergebenen Custom Parametern (s. Quelltext oben).
Erstellte Flows
An dieser Stelle werden die drei Flows gezeigt, welche entwickelt wurden, bisher aber noch nicht direkt in Gänze vorgestellt wurden.
Configuration-Flow
Der Configuration-Flow enthält Nodes, welche der Benutzer einmalig beim Aufsetzen des Systems konfigurieren muss. Diese sind jeweils mit einem [!] gekennzeichnet und beziehen sich hauptsächlich auf das Empfangen und Senden von Nachrichten über die verschiedenen Messenger.
Dashboard
Der Dashboard-Flow enthält alle Nodes, welche direkt im Dashboard angezeigt werden (türkis/hellblau), oder direkt durch diese Nodes aber keine anderen beeinflusst werden – dies sind teils MQTT-Nodes, die Intervalle oder Texte an Microcontroller versenden, aber auch die Nodes, welche sich mit der Historientabelle befassen (unten) – entweder um Daten zu laden oder um die Tabelle zu leeren.
MED-Logik
Der MED-Logik Flow stellt die grundsätzliche Logik MEDs bereit – einen Eingang für MQTT-Nachrichten, welche dann nach Thema zugeordnet werden und anschließend den bereits beschriebenen Teilflow mit verschiedenen Gates und Ausgängen durchlaufen, sowie einen Eingang für Nachrichten des am Raspberry Pi angeschlossenen Reed-Switches, welche dann ebenfalls einen ähnlichen Ablauf durchlaufen. Außerdem werden wieder verwendbare Teilflows zum schreiben in die Historie und zum Senden von Nachrichten über die jeweils im Dashboard aktivierten Messenger-Dienste definiert (oben).
… jemand klingelt, aber man bekommt es nicht mit, denn man sitzt grade im Garten, hat Kopfhörer auf oder die Klingel ist schlicht zu leise.
… jemand klingelt, aber es ist niemand zu Hause – man möchte der Person aber trotzdem etwas mitteilen.
… man wartet auf einen wichtigen Brief, hat aber nicht die Zeit, den ganzen Vormittag aus dem Fenster zu schauen und auf die Post zu warten.
… man fährt in den Urlaub, möchte aber trotzdem wissen, wann jemand anderes bei einem zu Hause ist – sei es um die Blumen zu gießen oder unbefugt.
All diese Probleme werden durch MED behoben: Das System, bestehend aus drei Geräten, bietet eine eigene Klingel, einen Bildschirm für Nachrichten, einen Magnet-Schalter für die Haustür und einen IR-Sensor, der bemerkt, wenn etwas in den Briefkasten geworfen wird. Die so gesammelten Informationen kommen an zentraler Stelle zusammen und können von dort aus auf verschiedene, beliebig an- und abwählbare, dem Benutzer angezeigt werden – etwa als Nachrichten über verschiedene Messenger-Dienste oder als Audio-Signal. Außerdem können die Informationen können zur späteren Auswertung gespeichert werden. Zusätzlich kann der Benutzer auch in die andere Richtung kommunizieren und per LCD Nachrichten an die Person auf der anderen Seite der Haustür senden.
Das System als ganzes zielt also darauf ab, den Benutzer ein wenig mehr Peace-of-Mind zu ermöglichen und ihren Alltag etwas zu erleichtern. Darüber hinaus bietet es mit seinen Funktionen auch Unterstützung für körperlich Beeinträchtigte – jemand, der etwa sein Gehör verloren hat, wird eine normale Klingel kaum wahrnehmen können – eine Notification auf dem Smartphone jedoch schon.
Die Idee für MED entstand im Anschluss an ein Brainwriting, dessen verschiedene Ideen zu einer zusammen verwoben wurden.
Gestern und heute habe ich mein LCD gelötet und dem Arduino-Code der Klingel die Möglichkeit gegeben, das Display anzusteuern und zu beschreiben, wenn eine entsprechende Nachricht via MQTT empfangen wird. Es hat ein wenig Zeit gebraucht, die richtige Bibliothek zu finden und die per MQTT empfangene Nachricht tatsächlich ausgeben zu lassen, das Ergebnis sieht jedoch sehr gut aus.
Nachrichten können vom Benutzer sowohl vom Dashboard aus als auch per Messenger (Telegram/Discord) über NodeRED an das Display gesendet werden.
Heute habe ich unsere Arbeit an der Historientabelle im Dashboard, in welcher alle Events gespeichert (und betrachtet) werden können, abgeschlossen. Tritt ein Event auf so wird es, zusammen mit der aktuellen Zeit, in eine Datei geschrieben. Ein Benutzer kann diese Datei dann im Dashboard laden und anzeigen lassen.
Außerdem habe ich die Möglichkeit hinzugefügt, Messenger-Notifications nicht nur an Telegram senden zu lassen sondern auch an Discord.
In den letzten Tagen habe ich verstärkt an der NodeRED-Seite der Software gearbeitet. Hierfür habe ich zunächst alle Packages installiert, welche wir benötigen, und die Grundlegende Struktur der Flows aufgebaut. Außerdem habe ich einige Tests angestellt, um mich mit Nodes, welche ich zuvor nicht verwendet habe, vertraut zu machen.
Aktuell implementiert sind bereits die grundsätzliche Struktur des Logik-Flows und eine einfache Version der Telegram-Notifications.
Heute habe ich, basierend auf verschiedenen Aufgaben aus Vorlesungen und Übungen, die ersten Versionen des Codes angelegt, welcher auf den beiden Microcontrollern laufen soll. Aktuell enthält er erst eine statische WLAN-Verbindung und einen einfachen MQTT-Ablauf. Die statische WLAN-Verbindung werde ich in den kommenden Tagen durch den aus der Vorlesung bekannten WiFiManager austauschen, da uns dieser (von bekannten Vorteilen abgesehen) durch Custom Parameter erlaubt, die MQTT-Verbindungsdaten dynamisch zu übergeben, statt diese statisch im Code zu hinterlegen.
Heute haben wir uns nochmal getroffen und unsere bisher eher grobe Planung etwas verfeinert – wir haben eine Überlegung ausgeschlossen und einige andere verbessert.
In den nächsten Tagen wird einer von uns schonmal ein Case für den Raspberry Pi (auf dem bei uns NodeRED zur Verwaltung des Systems laufen soll) etwas anpassen und ein paar von uns werden den eingerichteten Makerspace besuchen um das Case zu drucken und mal zu gucken, was es dort schon an Hardware gibt, die wir verwenden oder Nachkaufen können. Sobald das getan ist werden wir uns dann daran setzen, die Ziele für das Projekt und den Zeitplan festzuhalten.
Vor kurzem haben wir mit unserer Planungsphase begonnen. Dafür haben wir erstmal über ein paar Tage ein Brainwriting via Google Docs (das Ergebnis findet ihr hier) gemacht, um ein paar Ideen zu sammeln und schonmal grob zu gucken, wer Interesse an welchen Teilbereichen des Projekts hat. Anschließend haben wir uns zusammengesetzt und daraus eine grobe Idee entwickelt, die wir umsetzen wollen: Generell soll es darum gehen, eine Art Klingel mit Extra-Feature zu entwickeln. Wir werden jetzt zunächst prüfen, inwiefern die von uns angedachten Features sinnvoll umsetzbar sind, und dann hier Genaueres veröffentlichen.
