Pflichtenheft Smart Home

Einleitung

Auftraggeber

	Modul Softwarequalität
Ansprechpartner: ⁣⁣ ⁣ ⁣ ⁣ ⁣ ⁣⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣	Prof. Dr. Christian Überall

Auftragnehmer

Richardt Reckling & Dominik Reh

Abstract

Das Projekt ist ein Smart-Home-Prototyp und beinhaltet Front- und Backend für Steuerung eines Smart Homes über einen Windows-PC. Der Nutzer kann Fenster, Heizungsthermostate, sowie Steckdosen in der Oberfläche hinzufügen und steuern. Das Programm bietet Einstellungsmöglichkeiten und Automatismen, über die z.B. automatisch die Temperatur angepasst werden kann.

Auftrag

Entwicklung eines Programms (Front- und Backend), welches Status für Heizungsthermostate, Fenstersensoren und Steckdosen visualisieren kann. Sobald ein definierter Status erreicht ist, soll dieses bearbeitet werden. Smart-Home-Geräte kommunizieren über einen öffentlichen MQTT-Broker mit dem Programm.

Relevante Geräte und ihr Status sind:

• Heizungsthermostat
  • An / Aus
  • Eingestellte Temperatur
• Fenstersensor
  • Offen / Geschlossen
• Steckdose
  • An / Aus

Das Programm muss folgende Interaktionen mit den Sensoren ermöglichen:

• Hinzufügen von Thermostaten, Fenstersensoren und Steckdosen (mit Verwendungsort, wie z.B. Wohnzimmer, Schlafzimmer, usw.)
• Einstellen der Temperatur über Frontend
• Öffnen und Schließen der Fenster über Frontend
• Ein- und Ausschalten der Steckdosen

Weitere Anforderungen

• Dokumentation
  • Ausführliche Code-Doku (Kommentare)
  • UML Klassen- und Zustandsdiagramm
• Unit-Tests

Technische Rahmenbedingungen

Das Steuerungsprogramm ist als WPF (Windows Presentation Foundation)-Anwendung für Windows konzipiert. Das Frontend wird dahingehend über XAML konstruiert. Data Binding und das MVVM-Prinzip werden genutzt, um die Backend-Logik von der Nutzeroberfläche zu trennen. Der verwendete MQTT-Broker ist öffentlich und erreichbar über broker.hivemq.com. Um auf dem öffentlichen Broker versehentliches Mithören oder Verwechslung mit anderen Instanzen der Software zu vermeiden, wird je Client eine UUID erzeugt, welche Teil des Topic-Strings ist. Somit kann gewährleistet werden, dass nur Frontends mit Kenntnis dieser einzigartigen ID das Topic abonnieren können.

Systemanforderungen

• Frontend-Nutzeroberfläche für Windows-PCs über WPF
  • MVVM für strikte Trennung von UI & Backend
• Visualisieren von Sensoren im Frontend in einer Tabelle / Liste
• Hinzufügen von Sensoren im Frontend über einen Dialog
  • Auswahl aus den drei Sensortypen in ComboBox
  • Angabe des Raums per TextBox
  • Angabe des Sensornamens per TextBox
• Kontrollmöglichkeiten der Sensoren:
  • Fenster
    • Öffnen / Schließen
  • Steckdose
    • An / Ausschalten
  • Thermostat
    • An / Ausschalten
    • Temperatur (hoch) einstellen
• Automatismen
  • Fenster offen ⇾ Thermostat im selben Raum regelt auf 12 °C herunter (außer, es ist aus)
  • Fenster zu ⇾ Thermostat im selben Raum regelt auf die zuvor eingestellte Temperatur hoch (außer, es ist aus. Standard 22 °C)
  • Fenster offen nach 22:00 Uhr ⇾ Steckdose geht an (Bsp. Alarmanlage)

Die Kommunikation findet per MQTT über einen öffentlichen Broker statt. Die Sensoren fungieren als eigenständige MQTT-Clients. Sie haben jeweils ein einzigartiges Topic, auf das sie ihre Nachrichten publishen. Der Client fungiert der Einfachheit halber in diesem Prototyp als Pseudo-Server und hat Kenntnis aller Sensoren. Er verwaltet die Erstellung der Sensoren und abonniert ihr Topic über seinen eigenen MQTT-Client, sobald sie in die interne Liste eingetragen wurden. Die Sensoren abonnieren ein "globales" Topic, auf das der Client UI-Anfragen publisht. Sie filtern in der empfangenen Nachricht anhand eines ID-Vergleichs, ob die Anforderung aus der UI (z.B. An/Aus umschalten oder Temperatur einstellen) für sie bestimmt ist. Außerdem wird aus der Nachricht ausgewertet, ob sich der veränderte Sensor im selben Raum befindet. Ist dem so, kann entsprechend der oben beschriebenen Automatismen weiter ausgearbeitet werden, ob der Sensor reagieren muss.

Interaktionsdiagramm der MQTT-Kommunikation zwischen Sensor, Broker und Client

Bearbeitungszeit

Das Projekt muss bis Dienstag, 13. September 2022 fertiggestellt sein. Die verfügbare Arbeitszeit entspricht dabei grob drei Tagen.

Benötigte Software / Hardware

Als Smart Home-Anwendung ist die Software für das fertige Produkt auf diverse physische Sensoren angewiesen, welche für diesen Prototyp des Umfangs halber allerdings simuliert werden.

Problemanalyse

Erwartete Probleme:

• Kommunikation mit und über den Broker
  • Lösungsansatz: Verwendung vorgefertigter Libraries, spezifisch MQTTnet
• Strikte Trennung von Front- und Backend zur Steigerung der Qualität und Stabilität
  • Lösungsansatz: Verwendung von striktem MVVM und Data Binding

Qualitätsanforderungen

• Dokumentation (siehe oben)
• Hohe Stabilität
• Intuitive Bedienung ohne Einführung

Entwicklung

• 11.09.2022
  • Aufsetzen des Github-Repos
  • Erstellen der MVVM-Struktur mit benötigten View Models
  • Einfaches Back- und Frontend
    • Verbindung und Kommunikation mit dem Broker
• 12.09.2022
  • Schreiben von noch fehlenden Tests und Dokumentationskommentaren
  • Ausarbeitung UML Klassen- und Zustandsdiagramm
• 13.09.2022
  • Vorstellung und Rücksprache