Herausforderungen bei der Entwicklung
Im Entwicklungsprozess dieses Projektes gab es einige Schwierigkeiten. Hier werden deren Problematik und wie diese Überwunden wurden erklärt. Es wird auch auf Schlüsse, welche für weitere Projekte gezogen wurden eingegangen.
Ändern des Standardnutzers des Raspberry Pis
Ganz zu Beginn des Projektes wurde bei der Ersteinrichtung des Pis der Standardnutzer pi geändert. Dies führte zu eine Reihe an Problemen, welche schwierig zu identifizieren waren.
Eines der Probleme war, das Zigbee2MQTT bei der Installation Berechtigungen an den Nutzer pi vergibt. Wird der Nutzer jedoch geändert, muss dies auch angepasst werden. Außerdem startet die dort zur Verfügung gestellte Konfigurationsdatei, welche es ermöglicht Zigbee2MQTT als Hintergrundprogramm auszuführen, das Programm mit dem Nutzer pi. Wenn dies nicht angepasst wird, kann Zigbee2MQTT nicht starten. Da Hintergrundprogramme jedoch nur nach expliziter Aufforderung Protokolle anzeigen, war dieser Fehler schwierig zu finden.
Ein weiteres Problem stellte die Audiowiedergabe dar. Selbst wenn der Nutzer pi auf dem System nicht existiert, erhält dieser die alleinigen Rechte mit aplay Audio abzuspielen. aplay ist das vorinstallierte Terminal-Audioausgabeprogramm. Das wird sowohl von Rhasspy als auch von dem PlayMusic-Skill verwendet. Dieses Problem kann zwar mit der Ausführung des Systems als Administrator gelöst werden.Das erzeugt allerdings ein Sicherheitsproblem, da Programme immer nur so viele Rechte erhalten sollten, wie zwingend notwendig ist.
Gelöst wurde dieses Problem indem der geänderte Nutzer zur audio Gruppe hinzugefügt wurde. In der Installationsanleitung ist dies vermerkt.
Für zukünftige Projekte sollte der Standardnutzer nur geändert werden, wenn es aus Sicherheitsgründen zwingend nötig ist.
Probleme bei der Entwicklung und der Umgang mit diesen
Bei der Entwicklung sind immer wieder Probleme im Programmcode aufgetaucht. Teilweise waren diese schwer recherchierbar und haben den Entwicklungsprozess sehr ins Stocken geraten lassen. Statt diese Probleme in die Dokumentation mit aufzunehmen und eine Anforderung nicht (vollständig) zu erfüllen, wurden diese über einen langwierigen Versuch und Irrtum Prozess gelöst.
Im Nachhinein wurde erkannt, das nicht jedes Problem zwingend lösbar sein muss. In Zukunft sollte für die Lösung jedes Problems eine maximale Zeitspanne festgelegt werden.
Iteration der Installationsanleitung
In der ursprünglichen Installationsanleitung von Finn Wehn gab es einige Lücken. Diese mussten zunächst identifiziert und gelöst werden. Mit diesem Mehraufwand wurde nicht gerechnet. Die nötigen Ergänzungen sind in der Installationsanleitung dieses Projektes festgehalten.
In Zukunft sollte zunächst das Projekt auf welchem aufgebaut werden soll ausführlich getestet werden, bevor sich dafür entschieden wird.
Vorgehensreihenfolge
Es wurde zunächst das Grundset an Skills konzipiert und danach erst das bestehende System evaluiert. Dies hatte zur Konsequenz, dass die konzipierten Skills noch einmal überarbeitet werden mussten. Dies ist besonders ärgerlich, da die nötigen Änderungen in den Skills durch Rhasspy bedingt waren. Diese Arbeitsdopplung hätte durch eine ausführlichere Initialrecherche verhindert werden können. Allerdings wurden so Lösungsansätze für diese Probleme entdeckt.
Freie Benennung von Entitäten
Die freie Benennung von Entitäten wie Weckern, Timern, Listen und Szenen ist mit Rhasspy nicht möglich. Dies wurde in der Evaluation erkannt. Wie schon im Zwischenfazit angemerkt und erklärt, ist es mit dem verwendeten Sprachmodell nicht möglich dieses Problem zu lösen. Deshalb wurde an der Stelle die Entwicklung abgebrochen und die Anforderungen iteriert.
Jekyll
Die Gliederung der Dokumentation musste verändert werden, da zu spät aufgefallen ist, dass das verwendete Jekyll Theme keine verschachtelte Navigationsstruktur unterstützt.