smarthome-presence-detect/bericht/lennart/chapters/4_software.tex

\section{Software der Samrthome Umgebung}
Der Aufbau der Smarthome Umgebung auf dem Raspberry Pi gliedert sich in drei Ebenen:
\begin{itemize}
    \item Logik Ebene
    \item Transport Ebene
    \item Interface Ebene
\end{itemize}
Diese Ebenen werden jeweils über bestimmte Softwarepakete realisiert, die auf dem Raspberry Pi installiert und konfiguriert werden müssen.
Die Logik Ebene dient dabei zur Programmierung der Logik und Darstellung der erfassten Daten beziehungsweise zur Steuerung der Aktoren.
Die Transport Ebene ist die Schnittstelle zwischen der Logik Ebene und der Interface Ebene. 
Sie stellt sicher, dass die beiden Ebenen jeweils verlässlich strukturierte Daten erhalten.
Zusätzlich dient sie als Schnittstelle zu den Mikrocontrollern über den WLAN-Accesspoint.
Die Interface Ebene dient dem Anbinden der kommerziellen Sensoren und Aktoren.

Im Folgenden wird die Funktion, Installation und Konfiguration der einzelnen Ebenen\\
genauer erläutert und beschrieben.

\subsection{Logik Ebene}
Die Logik der Smarthome Umgebung wird durch die Software \emph{Node-Red} realisiert, die Präsenta\-tion der Daten und die Steuerung der Aktoren durch die Node-Red Erweiterung \emph{Node-Red-dashboard}.

\subsubsection{Node-Red}
Node-Red ist ein auf der Plattform node.js basierendes und in JavaScript geschriebenes grafisches Entwicklungswerkzeug.
Es ist speziell entwickelt um Hardware, APIs und Dienste mittels eines Baukasten Prinzips miteinander zu verbinden.
Somit ist es ideal für dieses Projekt um die Informationen der Sensoren zu sammeln, auszuwerten und darauf basierend Entscheidungen zu treffen.

Die Installation von Node-Red ist dank eines von Seiten des Herstellers bereitgestellten Installationsskriptes sehr einfach. 
Das Skript wird mittels folgendem Befehl heruntergeladen, ausgeführt und führt anschließend den Nutzer Schritt für Schritt durch die Installation:
\begin{lstlisting}
bash <(curl -sL https://raw.githubusercontent.com/Node-Red/raspbian-deb-package/master/resources/update-nodejs-and-nodered)
\end{lstlisting}
Nach erfolgter Installation sorgt der Befehl \inline{sudo systemctl enable nodered.service} dafür, dass Node-Red bei Systemstart automatisch gestartet wird.
\inline{sudo service nodered start} startet Node-Red anschließend.
Die Entwicklungsumgebung ist ab diesem Zeitpunkt unter der in Kapitel \ref{staticIP} auf Seite \pageref{staticIP} genannten IP-Adresse und dem Port 1880 erreichbar: \inline{https://141.75.33.126:1880}.

\subsubsection{Node-Red-dashboard}
Das Node-Red-dashboard ist eine Erweiterung für Node-Red und ermöglicht die Konfiguration einer Steuerzentrale mittels Node-Red.
Es wird nach erfolgter Node-Red Installation über den Befehl \inline{npm i Node-Red-dashboard} installiert.
Das Dashboard ist ab dem Zeitpunkt unter dieser Adresse erreichbar: \inline{https://141.75.33.126:1880/ui}.
Ebefalls sind nun die Node-Red-dashboard spezifischen Nodes in Node-Red verfügbar.
Node-Red und das Node-Red-dashboard werden näher in Kapitel \ref{kevin:node-red} auf Seite \pageref{kevin:node-red} erklärt.

\subsection{Transport Ebene}
Auf der Transport Ebene wurde das Internet of Things (IOT) Protokoll \emph{MQTT} mit der Software \emph{Mosquitto} gewählt. 
\begin{figure}[H]
    \centering
    \includestandalone[width=.75\textwidth]{standalone/pub_sub_arch}
    \caption{Die Architektur von MQTT}
    \label{fig:pub_sub_arch}
\end{figure}
\paragraph{Das Message Queue Telemetry Transport (MQTT)} ist ein Maschine-zu-Maschine (M2M) Nachrichtenprotokoll, entworfen nach dem Publish/Subscribe-Modell (pub/sub).
Es baut auf einem zugrundeliegendem TCP/IP Netzwerk auf und wurde speziell für M2M und mobile Anwendungen entwickelt.
Das Publish/Subscribe-Modell basiert auf einem \emph{Broker}, der ähnlich wie ein Server die zentrale Anlaufstelle der Netzwerks und für die Verteilung der Nachrichten zuständig ist.
Neben dem Broker gibt es beliebig viele \emph{Subscriber} und \emph{Publisher}.
Ein Subscriber empfängt bestimmte Nachrichten vom Broker, ein Publisher sendet Nachrichten an den Broker, wobei ein einzelnes Gerät beide Rollen einnehmen kann. 
In Abbildung \ref{fig:pub_sub_arch} gibt es drei Geräte die ausschließlich Daten an den Broker senden, einen Server, der nur Daten vom Broker empfängt und einen Mikrocontroller, der sowohl Daten sendet, als auch empfängt.
\begin{figure}[H]
    \centering
    \includestandalone[width=.6\textwidth]{standalone/mqtt_topic}
    \caption{Aufbau von MQTT Topics}
    \label{fig:mqtt_topic}
\end{figure}
Das Senden der Daten an den Broker wird veröffentlichen \emph{(publish)} genannt.
Möchte ein Client Daten empfangen, muss er diese abonnieren \emph{(subscribe)}.
Dieses Abonnement wird bei erstmaliger Verbindung zum Broker in Form einer Publish-Nachricht angemeldet.
Identifikation von Nachrichten geschieht über \emph{Topics}, die von dem sendenden Gerät festgelegt werden.

Der Broker benutzt diese Topics, die die Form eines UTF-8 Strings haben, um Nachrichten der verbundenen Geräte zu filtern.
Topics bestehen aus mehereren Level, die durch einen Slash voneinander getrennt werden.
In Abbildung \ref{fig:mqtt_topic} ist beispielhaft eine in dieser Arbeit benutzte Topic gezeigt, unter der die von einem Ultraschallsensor gesammelten Daten abonniert werden.
Dabei ist zu Erkennen, wie die Topic hierachisch mit verschiednen Level aufgebaut ist:
Es wird begonnen mit einem allgemein gültigem Level.
In diesem Fall kennzeichnet dies die Hochschule (gso).
Weiterführend ist das Gebäude, der Raum und der entsprechende Sensor festgelegt.
Dadurch wird mit jedem weiteren Level eine immer genauere Herkunft der Daten festgelegt.
Die letzte Topic \inline{/#} ist eine \emph{Wildcard}.
Wildcards werden bei MQTT genutzt um mehrere Topics gleichzeitig zu abonnieren.
\inline{#} ist dabei eine \emph{Multilevel Wildcard}, die mehrere Topic Level abonniert.
So werden beispielhaft die Topics \inline{gso/bb/104/ultraschall/status} und \inline{gso/bb/104/ultraschall/status/subsensor-1} beide mit der Topic aus Abbildung \ref{fig:mqtt_topic} abonniert, wohingegen die Topic \inline{gso/bb/104/pir/status} nicht berücksichtigt wird.
Da die Multiline Wildcard bedeutet, dass alle folgenden Level uneingeschränkt abonniert werden, kann sie nur am Ende einer Topic stehen.
Neben der Multilevel Wildcard steht die Singlelevel Wildcard, repräsentiert durch das \inline{+}.
Sie kann an einem beliebigen Topic Level stehen und ersetzt nur ein einziges Level der Topic.
Sollen beispielsweise die Statusmeldungen aller Ultraschallsensoren im Gebäude BB abonniert werden, wird für den Raum die Singlelevel Wildcard benutzt: \inline{gso/bb/+/ultraschall/status}.

Die Organisation des Datenfluss übernimmt der Broker, wie in Abbildung \ref{fig:pub_sub_flow} gezeigt:
Hier sind zwei Geräte mit dem Broker verbunden, die die Rollen eines Subscribers und eines Pulishers zeigen.
\begin{figure}[H]
    \centering
    \includestandalone[width=.75\textwidth]{standalone/pub_sub_flow}
    \caption{Der Publish/Subscribe Prozess von MQTT}
    \label{fig:pub_sub_flow}
\end{figure}
Der Subscriber sendet seine Abonnement-Nachricht an den Broker und legt die abonnierte Topic fest.
Der Broker registriert diese und leitet von nun an jede Nachricht mit der entsprechenden Topic an den Client mit dem Abonnement weiter.
Abonniert zum Beispiel der Server aus Abbildung \ref{fig:pub_sub_arch} die Topic \inline{gso/bb/104/ultraschall}, registriert dies der Broker.
Veröffentlicht nun ein Sensor Daten unter der selben Topic, gehen diese zunächst beim Broker ein, der die Daten dann sofort an alle Abonnenten dieser Topic, in deisem Fall den Subscriber, weiterleitet.

Neben den bereits gezeigten Eigenschaften von MQTT gibt es noch eine Vielzahl weiterer, wie zum Beispiel die Last-Will Nachricht, die andere Geräte informiert, dass das Sendende Gerät von dem Netzwerk getrennt wurde.
Um die Komplexität der Arbeit im Rahmen zu halten wurde aber auf die Implementierung dieser Funktionen verzichtet.

\paragraph{Mosquitto} ist eine Open-Source Implementation des MQTT-Protokolls und wird in diesem Projekt aufgrund der einfachen Verfügbarkeit als Debian-Paket für den Raspberry Pi benutzt.
Es ist ein Projekt der Eclipse Foundation und da die Software in C geschrieben ist, sehr schnell, flexibel und weitreichend erhältlich.
Installiert wird das Paket auf dem Raspberry Pi mit dem Befehl:
\begin{lstlisting}
sudo apt install mosquitto
\end{lstlisting}
Dadurch werden die drei Teile des Mosquitto-Projektes installiert: Der \inline{mosquitto} Server, die \inline{mosquitto_sub} und \inline{mosquitto_pub} Anwendungen und ein MQTT-C/C++-Bibliothek-Wrapper, der hier aber nicht benutzt wird.
Um den Mosquitto Server zu starten werden die folgenden Kommandos benötigt:
\begin{lstlisting}
sudo systemctl enable mosquitto
sudo systemctl start mosquitto
\end{lstlisting}
Von nun an ist der Mosquitto Broker über die IP-Adresse des Raspberry Pis und mit dem Port 1883 erreichbar.
Um die Funktionalität zu testen können die Anwendungen \inline{mosquitto_sub} und \inline{mosquitto_pub} genutzt werden:
Mit Hilfe des Befehls
\begin{lstlisting}
mosquitto_sub -t 'test/topic' -v
\end{lstlisting}
kann man testweise eine Topic abonnieren und mit dem Befehl 
\begin{lstlisting}
mosquitto_pub -t 'test/topic' -m 'hello world'
\end{lstlisting}
eine Testnachricht abschicken. Kommt die Nachricht in dem \inline{mosquitto_sub}-Fenster an, ist der MQTT-Broker einsatzbereit.
Um zu testen ob Geräte richtig an das Netzwerk angeschlossen sind, ist es ebenfalls hilfreich den mosquitto\_sub Client mit der Wildcard \# zu Nutzen um alle eingehenden Nachrichten einzusehen.
Im laufenden Betrieb läuft Mosquitto dann weitestgehend im Hintergrund und es muss sich nur um angemessene Definitionen der Topics gekümmert werden.

\subsection{Interface Ebene}
Die letzte Ebene dient der Kommunikation mit den kommerziellen Sensoren.
Da jeder Hersteller von Smarthome Geräten sein eigenes Protokoll benutzt um mit seinen Geräten zu kommunizieren, wird hier Software, die in der Lage ist verschiedene Protokolle zu sprechen, mit Hardware - den Funk-Sendern und -Empfängern - gekoppelt.

\subsubsection{Homegear}
\label{homegear}
Die in dem Blogartikel von Patrik Mayer in Kapitel \ref{blog} auf Seite \pageref{blog} genutzte Software um mit verschiedenen Aktoren und Sensoren zu kommunizieren ist \emph{homegear}.
Homegear ist ein Open-Source Programm um IoT Geräte zentral zu kontrollieren und zu verwalten.
Dazu spricht es eine Vielzahl an Protokollen diverser Hersteller wie Homematic, Intertechno, Philips Hue und Sonos, und unterstützt auch das MQTT-Protokoll.
Homegear ist dabei in der Lage sowohl als komplette Smarthome Umgebung inklusive konfigurierbaren Dashboard zu dienen als auch als bloße Schnittstelle die die Verbindung mit den kommerziellen Geräten übernimmt und die Daten über HTTP, MQTT oder anderwertig weiterleitet.
Um die Flexibilität der Umgebung zu erhöhen wird homegear hier nur als Schnittstelle genutzt.

Homegear selbst besteht aus dem Homegear-Grundmodul, welches die grundlegende Funktionalität bereitstellt und weiteren spezifischen Modulen, die die verschiedenen Hersteller/Protokolle bedienen oder das Dashboard zur Verfügung stellen.
Installiert auf dem Raspberry Pi wird das Grundmodul über das Offizielle Repository:

\begin{lstlisting}
sudo apt install apt-transport-https
wget https://apt.homegear.eu/Release.key && apt-key add Release.key && rm Release.key
sudo echo 'deb https://apt.homegear.eu/Raspbian/ stretch/' >> /etc/apt/sources.list.d/homegear.list
sudo apt update
sudo apt install homegear homegear-nodes-core homegear-management
\end{lstlisting}
Die verfügbaren Hersteller-spezifischen Module können in der Homegear Dokumentaiton \cite{homegear2018documentation} gefunden werden.
Homematic BidCos, welches das Standard Funkprotokoll von Homematic bis 2015 war, kann beispielsweise über das vorher eingerichtete Repository ganz einfach mittels \inline{apt install} installiert werden:
\begin{lstlisting}
sudo apt install homegear-homematicbidcos
\end{lstlisting}

Nach der Installation eines Moduls muss der homegear-Service mittels
\begin{lstlisting}
sudo service homegear restart
\end{lstlisting}
neu gestartet werden.
Die ordnungsgemäße Funktion des Moduls kann anschließend in der Log-Datei von homegear überprüft werden:
\begin{lstlisting}
tail -n 1000 -f /var/log/homegear/homegear.log
\end{lstlisting}

Funktioniert das Modul einwandfrei muss als nächstes das Funkmodul Homegear bekannt gemacht werden.
Für das Modul aus Abschnitt \ref{funkmodul} müssen folgende Zeilen zu der Homematic BidCos Konfigurationsdatei \inline{/etc/homegear/homematicbiscos.conf} hinzugefügt werden:
\lstinputlisting{code/bidcos.tex}

Homematic BidCos Geräte werden bei korrekter Funktion des Moduls über das Komando\-zeilen-Interface hinzugefügt.
Über \inline{homegear -r} wird das Komandozeilen-Interface gestartet.
Mittels \inline{families select 0} wird die Homematic BidCos Gerätefamilie ausgewählt.
\inline{pairing on} versetzt homegear schließlich in den Pairing-Modus.
Nun muss nur noch der Pairing-Modus an dem entsprechenden Gerät eingeschaltet werden.
Nach wenigen Sekunden können mit dem Befehl \inline{ls} die Verbundenen Geräte angezeigt werden.

Um über Node-Red mit den angeschlossenen Geräten zu kommunizieren muss das MQTT-Interface von homegear eingerichtet werden.
Dazu wird dient die Konfigurationsdatei \inline{mqtt.conf} in dem homegar Konfigurationsverzeichnis \inline{/etc/homegear}.

\subsubsection{Homematics Protokolle}
Wie in Abschnitt \ref{homegear} bereits erwähnt wurde das Standardprotokoll von Homematic \emph{Homematic BidCos} im Jahre 2015 von \emph{Homematic IP} abgelöst.
Homegear unterstützt das neue Protokoll Homematic IP jedoch nicht.
Um beispilsweise den bereits angesprochenen Präsenzsensor von Homematic nutzen zu können, der das Homematic IP Protokoll benutzt, ist es notwendig eine Alternative zu homegear zu finden.
Dazu wurden nach einer Webrecherche drei Optionen gefunden:
\begin{enumerate}
    \item RaspberryMatic
    \item YAHM
    \item piVCCU
\end{enumerate}
\paragraph{RaspberryMatic} ist ein von Jens Maus entwickeltes Projekt, welches ein einfaches, Linux/ buildroot-basierendes Homematic kompatibles Betriebssystem für Einplatinencomputer wie den Raspberry Pi zur Verfügung stellt.
Es basiert auf der \textbf Open-\textbf Central-\textbf Control-\textbf Unit-SDK (OCCU) die von eq-3 zur freien Verfügung gestellt wird.
Damit ist RaspberryMatic in der Lage die gesamte Protokollpalette von Homematic zu bedienen.

Der Vorteil von RaspberryMatic ist die einfachheit der Bedienung und die enorme Anzahl an extra Features.
Verworfen wurde RaspberryMatic jedoch, da es nur als komplettes Betriebssystemimage installierbar ist.
Dies bedeutet, dass bei Benutzung beziehungsweise bei der Installation von RaspberryMatic die gesamte bestehende Konfiguration des Raspberry Pi zurückgesetzt wird und widerholt werden muss nachdem das neue Betriebssystem installiert ist, was sehr Aufwändig und nicht Anwenderfreundlich ist.
Zusätzlich ist der Nutzen eines Alternativ-Programmes zu homegear nur als Zwischenlösung gedacht.
Implementiert homegear das Homematic IP Protokoll in der Zukunft oder wird kein Homematic IP Gerät in der Smarthome Umgebung benutzt, ist es wünschenswert RaspberryMatic vom Raspberry Pi entfernen zu können.
Dies ist mit RaspberryMatic aber nicht ohne größeren Aufwand möglich.
Aus diesen Gründen wurde von der Benutzung von RaspberryMatic abgesehen.

\paragraph{YAHM} ist eine von Leonid Kogan entwickelte Lösung, die die Central-Control-Unit 2 (CCU2) von eq-3 in einem Virtuellen Linux Container (LXC) auf dem Raspberry Pi emuliert.
Die CCU2 wird normalerweise von eq-3 separat mit eigener Hardware verkauft, durch YAHM läuft sie als eigenständiges System auf dem Raspbery Pi.
Das Hinzufügen von Geräten geschieht bei YAHM über das Homematic eigene Webinterface und es werden wie bei RaspberryMatic alle Homematic Protokolle unterstützt.

Die Entscheidung gegen YAHM ist gefallen, da YAHM seit Juni 2018 nicht mehr aktiv Entwickelt wird und damit die Akutalität der Installation nicht gewährleistet werden kann.

\paragraph{piVCCU} ist die dritte Alternative um Homematic IP zu benutzen.
piVCCU ist ein Project von Alexander Reinert, welches wie YAHM einen Virtuellen Linux Container benutzt um die CCU2 oder auch die CCU3 (die neueste Generation der Homematic CCUs) auf dem Raspberry Pi zu emulieren.
Durch den Virtuellen Linux Container wird ebenfalls wie bei YAHM das Homematic Webinterface erreichbar gemacht, womit das Anlernen, Konfigurieren und Bedienen aller mit der CCU2 beziehungsweise CCU3 kompatiblen Homematic BidCos und Homematic IP Geräte ermöglicht wird.
piVCCU ist im Rahmen eines Debian-Repositorys für den Raspberry Pi installierbar und lässt sich damit bei Bedarf sehr einfach wieder von der Smarthome Umgebung entfernen.
Im Gegensatz zu YAHM wird an piVCCU immer noch aktiv gearbeitet, weshalb die Entscheidung auf piVCCU gefallen ist.

\subsubsection{Homematic CentralControlUnit mittels piVCCU}
Die Installation von piVCCU erfolgt anhand der auf Github bereitgestellten Installationsanleitung \cite{alexreinert2019pivccusetup}.
Dabei wird direkt die aktuelle Version 3 der CCU (CCU3) gewählt.

Nach erfolgreicher Installation wird mittels des Befehls \inline{sudo pivccu-info} in Schritt 10 die IP-Adresse der CCU ermittelt.
In diesem Fall ist sie \inline{141.75.33.250}.
Unter dieser IP-Adresse ist das Webinterface der CCU von nun an im Hochschulnetzwerk erreichbar und die Homematic Geräte können angelernt werden.
Das Anlernen und die Funktionen des Webinterfaces werden in Abschnitt \ref{dohle:homematic-anlernen} auf Seite \pageref{dohle:homematic-anlernen} genauer erläutert.

Um piVCCU vollständig in die Smarthome Umgebung einzubinden muss noch die Kommunikation mit dem MQTT Broker und Node-Red eingerichtet werden.
piVCCU stellt dafür keine eigene Schnittstelle zur Verfügung, weshalb eine Behelfslösung für die Kommunikation gewählt wurde.
Diese stellt sich in Form von RedMatic dar.
\paragraph{RedMatic} ist ein Addon für die CCU3 und RaspberryMatic, was eine Node-Red Installation auf diesen Geräten verfügbar macht.
Da durch piVCCU die originale CCU-Software auf dem Raspberry Pi emuliert wird, ist RedMatic auch unter piVCCU installierbar.
Die Nutzung von RedMatic bedeutet, dass eine zweite, eigenständige Node-Red Installation in der Smarthome Umgebung läuft, welche sich aber auf die in dem LXC-Container betriebene CCU beschränkt und nichts mit der eigentlichen Node-Red Installation auf dem Raspberry Pi zu tun hat.
Sie dient lediglich der Kommunikation der CCU über MQTT mit Node-Red auf dem Raspberry Pi.
Der Nachteil dieser Lösung ist der größere Fest- und Arbeitsspeicher Bedarf des Raspberry Pis.
Dies fällt jedoch nicht ins Gewicht, solange die Smarthome Umgebung sich auf einzelne Räume der Hochschule beschränkt und damit eine überschaubare Anzahl an Geräten angeschlossen sind.
\label{pivccu:expansion}
Bei einer größeren Expansion des Systems ist es zu Empfehlen, die Kommunikation der CCU mit dem Raspberry Pi auf Ebene des Linux Containers in Form einer TCP/IP-Kommunikation zu realisieren.

Installiert wird RedMatic nach der Installtionsanleitung für RedMatic \cite{sebastianraff2019redmaticinstallation} über die Weboberfläche der CCU.
Nach einen Neustart des Raspberry Pis ist RedMatic unter der Adresse \inline{http://141.75.33.250/addons/red} erreichbar.
Um den unberechtigten Zugriff auf RedMatic zu verhindern ist der Zugriff Passwort geschützt.
Die Zugangsdaten wurden folgendermaßen festgelegt:
\begin{lstlisting}
User: pi
Password: smarthome
\end{lstlisting}
Die Anbindung von piVCCU an den MQTT Broker geschieht mittels der RedMatic spezifischen Home\-matic-Nodes.
Wie diese Nodes Konfiguriert werden wird in Kapitel \ref{kevin:redmatic} auf Seite \pageref{kevin:redmatic} beschrieben.

\newpage