smarthome-presence-detect/bericht/lennart/main.tex

\documentclass[11pt,a4paper,ngerman]{article}
\usepackage[utf8]{inputenc}

\title{Projektarbeit}
%%Präsenzerkennung im Rahmen einer custom Smart Home Umgebung
\author{Lennart Heimbs}
\date{August 2019}

\usepackage[a4paper, right=2cm, top=2cm, left=3cm, bottom=3cm]{geometry}
\usepackage{natbib}
\usepackage{graphicx}
%\usepackage{acronym}
\usepackage{listings}
\usepackage[utf8]{inputenc}
\usepackage{xcolor}
\usepackage{realboxes}
\usepackage{xpatch}
\usepackage{standalone}
\usepackage{tikz}
\usepackage[ngerman]{babel}
\usepackage{float}


\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}

\lstdefinestyle{listingstyle}{
    backgroundcolor=\color{backcolour},   
    commentstyle=\color{codegreen},
    keywordstyle=\color{magenta},
    numberstyle=\tiny\color{codegray},
    stringstyle=\color{codepurple},
    basicstyle=\ttfamily\footnotesize,
    breakatwhitespace=false,         
    breaklines=true,                 
    captionpos=b,                    
    keepspaces=true,                 
    numbers=left,                    
    numbersep=5pt,                  
    showspaces=false,                
    showstringspaces=false,
    showtabs=false,                  
    tabsize=2
}

\lstset{style=listingstyle}
\def\inline{\lstinline[basicstyle=\ttfamily\footnotesize]}

\makeatletter
\xpretocmd\lstinline{\Colorbox{backcolour}\bgroup\appto\lst@DeInit{\egroup}}{}{}
\makeatother

\begin{document}

\maketitle

\section{Projektthema}
Präsenzerkennung im Labor im Rahmen einer Smart Home Umgebung

\paragraph{}
In der Projektarbeit wird zunächst eine individuelle Smart Home Umgebung aufgesetzt. Innerhalb dieser Umgebung sollen diverse kommerzielle, sowie eigens Entwickelte Sensoren Nutzbar sein. Die Kontrolle der Sensoren und Aktoren soll über eine Web-Oberfläche hochschulintern möglich sein.

\paragraph{}
Anhand der Sensoren soll anschließend ein System zur Erkennung und Zählung von anwesenden Personen im Labor entwickelt werden, um einen Überblick über die Auslastung des Raumes zu erhalten. 
Dabei wird ein kommerzieller Sensor für die Präsenzerkennung mit dem im Rahmen der Projektarbeit entwickelten Erkennungssystem und einer Kamera verglichen.

\newpage

\section{Einleitung}
\paragraph{}
Intelligente Heimüberwachung und -automatisierung gewinnt stetig an Bedeutung in einer zunehmend vernetzten Gesellschaft.
Jüngste Fortschritte in der Mikrocomputertechnik, deren Kosten und Kabellosen Netzwerken machen es immer erschwinglicher für Privatpersonen ihr eigenes Heim mit Sensoren zu Überwachen.
Neben Bewegungssensoren für die Außenbeleuchtung oder Überwachungskameras gibt es heute eine Vielzahl an Möglichkeiten der Heimüberwachung und -automatisierung. \\
So kann man zum Bielspiel steuerbare Rolläden zusammen mit Temperatur-, Lichtintensitäts- und weiteren Sensoren nutzen um Rolläden automatisch hoch, bzw herunter fahren zu können.

\paragraph{}
Aus diesen Möglichkeiten der Steuerung und Datenerfassung durch Sensoren ist ein breiter Markt an Systemen entstanden, die Technik für das Smart Home bereitstellen.
Diese Technik gliedert sich allgemein in drei Gerätekategorien:

\begin{itemize}
    \item Sensoren, die zur Erfassung von physikalischen Umweltdaten dienen
    \item Aktoren, die zur interaktion mit der Umwelt dienen
    \item Eine Steuerzentrale, auch Gateway genannt, welche gesammelte Daten darstellt und anhand dieser Daten Aktoren steuert
\end{itemize}

Das Zusammenspiel dieser drei Geräte stellt die Intelligenz des Smart Home Systems dar.\\
Auf dem Markt wird die Anzahl solcher Systeme immer größer, was sich in einer besseren Auswahl für den Konsumenten auswirkt.
Allerdings sind diese Systeme in der Regel geschlossene Systeme, die ein eigenes Ökosystem benutzen und nur mit Geräten eines Herstellers funktionieren.
Beispielhaft für ein solches geschlossenes System ist Homematic von der Firma eQ-3. 
Der Hersteller ist einer der Marktführer im Bereich Smart Home in Europa und bietet mit Homematic und dem neuen System Homematic IP zwei umfangreiche Smart Home Systeme an.
Ein Nachteil ist jedoch, dass die Homematic Sensoren und Aktoren nur mit der hauseigenem Smart Home Zentrale (Central Control Unit, CCU) betrieben werden können.\\
Aufgrund von zum Teil deutlichen Preisunterschieden zwischen verschiedenen Herstellern ist es allerdings wünschenswert diese miteinander kombinieren zu können.
Zusätzlich ist es möglich eigene Sensoren sehr preiswert zu entwickeln, die wiederum nicht mit den kommerziellen Sensoren kommunizieren können.
Aus diesem Grund ist ein Ziel dieser Projektarbeit ein Smart Home System aufzusetzen, welches es möglich macht eine Vielzahl verschiedener Produkte verschiedener Hersteller, sowie selbstgebaute Sensoren zu verwenden.
Um die Funktionalität dieses Systems zu testen wird anschließend ein Homematic IP Sensor zur Präsenzerkennung mit eigens entwickelten Sensoren zur Anwesenheitserkennung von Personen im Labor verglichen.

\newpage

\section{Smart Home Umgebung}
\label{blog}
Den Startpunkt des Projekts stellt der Blogeintrag ``Homematic mit node-red über homegear'' \cite{mayer2017smarthomesetup} dar, in dem eine Smart Home Struktur basierend auf einem Raspberry Pi beschrieben wird.
Im Folgendem wird das Aufsetzen der Gateway unter Berücksichtigung des Blogartikels beschrieben.

\subsection{Hardware}
%Für die Hardware der Gateway bietet sich ein Einplatinencomputer wie der Raspberry Pi an.
%Er ist für den Dauereinsatz geeignet, verfügt über ein vollwertiges Linux-Betriebssystem in der Form von Raspbian Stretch und stellt die nötigen Schnittstellen um Funkantennen für die Sensoren/Aktoren anzuschließen zur Verfügung.

Für die Hardware der Gateway wird  der Einplatinencomputer \textit{Raspberry Pi} aufgrund seiner guten Verfügbarkeit und günstigen Preises gewählt.
Da die Gateway im Dauereinsatz betrieben wird, wird das Betriebssystem \textit{Raspbian Stretch lite} gewählt.

Das Betriebssystem basiert auf der Linux-Distribution \textit{Debian Stretch}, ist speziell für den Betrieb auf einem Raspberry Pi konfiguriert  und verzichtet auf eine Desktop Umgebung, wodurch weniger Speicher und Rechenleistung benötigt wird. 
Die Installation des Betriebssystems erfolgt über die bereits auf dem Raspberry Pi vorinstallierte Installationsanwendung \textit{NOOBS}, welche das Betriebssystem herunterlädt und installiert.

\paragraph{}
\label{funkmodul}
Um mit Sensoren von kommerziellen Herstellern kommunizieren zu können wird zusätzlich ein Funkmodul benötigt.
Üblicherweise werden dabei die ISM-Bänder 433MHz und 868MHz verwendet. 
Da Homematic as 868MHz-Band zur Kommunikation nutzt, wird der Bausatz \textit{HM-MOD-RPI-PCB} von dem Hersteller ELV verwendet.
Das Funkmodul wird auf die GPIO-Pins des Raspberry Pis gesteckt und benutzt das UART-Protokoll um mit dem Raspberry Pi zu kommunizieren.
% raspi-config section hier um modul zu aktivieren
Ist das Modul einmal aktiviert, ist es Einsatzfähig.

\subsection{Netzwerk}
Die Netzwerkkonfiguration des Projekets birgt zwei Herausforderungen:
\begin{enumerate}
    \item Erreichbarkeit der Gewonnenen Daten, beziehungsweise Steuerung der Aktoren über das Hochschulintranet
    \item Kommunikation der Selbsgebauten Sensoren mit der Gateway über WLAN
\end{enumerate}
Die Erreichbarkeit der Daten wird sichergestellt, indem der Raspberry Pi dauerhaft über LAN an das Hochschulnetz angeschlossen ist. Zudem benötigt er eine bekannte statische IP-Adresse um auf die Daten zugreifen zu können.
Die statische IP-Adresse wird eingestellt, indem die Datei \inline{/etc/dhcpcd.conf} folgender Abschnitt für den LAN-Adapter eingefügt wird:
\label{staticIP}
\begin{lstlisting}
interface eth0
    static ip_address=141.75.33.126/24
    static routers=10.1.1.1
    static domain_name_servers=10.1.1.1
\end{lstlisting}

Um die später beschriebenen selbstgebauten Sensoren über WLAN mit dem Gateway kommunizieren zu lassen, wurde zunächst versucht, das Hochschulnetzwerk \textit{Eduroam} zu werenden. 
Da dieses jedoch die Sicherheitskonfiguration WPA2 Enterprise nutzt und dieses auf dem benutzten Mikrocontroller \textit{ESP8266} nicht unterstützt wird, muss ein alternatives WLAN-Netzwerk genutzt werden. 
Als Lösung wurde die Funktionalität des Raspberry Pis genutzt, als WLAN-Accesspoint zu dienen. 
Der Raspberry Pi, der per LAN mit dem Hochschulnetzwerk verbunden ist, spannt somit ein unabhängiges, lokales WLAN-Netzwerk auf, welches die WPA2-PSK Verschlüsselung benutzt, die auch von dem ESP8266 unterstützt wird.


\subsubsection{Raspberry Pi als Accesspoint}
Realisiert wird der Accesspiont durch die Softwarepakete \textit{hostapd} und \textit{dnsmasq}, welche durch folgendes Kommando installiert werden:
\begin{lstlisting}[language=bash]
sudo apt install dnsmasq hostapt
\end{lstlisting}
Danach werden beide Pakete für die Konfigurationsphase deaktiviert:
\begin{lstlisting}
sudo systemctl stop dnsmasq
sudo systemctl stop hostapd
\end{lstlisting}


\subsubsection{Raspberry Pi als Server}
Da das Netzwerk als Server agieren soll, wird dem Raspberry Pi eine statische IP-Adresse zugewiesen. Dazu wird in der Datei \inline{/etc/dhcpcd.conf} der WLAN-Adapter \inline{wlan0} folgendermaßen konfiguriert:
\begin{lstlisting}
interface wlan0
    static ip_address=192.168.252.1/8
    nohook wpa_supplicant
\end{lstlisting}
Um die Änderungen zu übernehmen wird der dhcp daemon neu gestartet: 
\begin{lstlisting}
sudo service dhcpcd restart
\end{lstlisting}

\subsubsection{DHCP Server Konfigurieren}
Damit die Verbindung des ESP8266 mit dem Raspberry Pi unkompliziert abläuft wird ein DHCP Server eingerichtet.
Dazu wird folgende Konfiguration in die Datei \inline{/etc/dnsmasq.conf} geschrieben:
\begin{lstlisting}
interface=wlan0
dhcp-range=192.168.252.2,192.168.252.20,255.255.255.0,24h
\end{lstlisting}
Somit werden IP-Adressen für die Microkontroller automatisch vergeben.\\
Anschließend startet man den DHCP Server: \inline{sudo systemctl reload dnsmasq}.

\subsubsection{Accesspoint Konfigurieren}
Zur Konfiguraiton des Accesspoints wird die Datei \inline{/etc/hostapd/hostapd.conf} beschrieben.\\
Wichtig dabei ist eine geeignete SSID und ein geeignetes Passwort für das Netzwerk.
\begin{lstlisting}
interface=wlan0
driver=nl80211
ssid=smartroom
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=smarthome
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
\end{lstlisting}
Anschließend muss der Accesspoint Software noch die Konfigurationsdatei in der Datei\\
\inline{/etc/default/hostapd} bekannt gemacht werden:
\begin{lstlisting}
DAEMON_CONF="/etc/hostapd/hostapd.conf"
\end{lstlisting}

\subsubsection{Starten des Accesspoints}
Nun muss nur der Accesspoint gestartet werden:
\begin{lstlisting}
sudo systemctl unmask hostapd
sudo systemctl enable hostapd
sudo systemctl start hostapd
\end{lstlisting}


\subsection{Software}
Der Aufbau der Smart Home Umgebung auf dem Raspberry Pi gliedert sich in drei Ebenen:
\begin{itemize}
    \item Präsentations- und Logik-ebene
    \item Kommunikations-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 Präsentations- und Logik-ebene dient dabei zur Programmierung der Logik und Darstellung der Erfassten Daten beziehungsweise zur Steuerung der Aktoren.
Die Kommunikations-ebene ist die Schnittstelle zwischen der Präsentations- und Logik-ebene zur 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 zu guter letzt 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{Präsentations- und Logik-ebene}
Die Logik unserer Smart Home Umgebung wird durch die Software \textit{node-red} realisiert, die Präsentation der Daten und die Steuerung der Aktoren durch das die Node-Red Erweiterung \textit{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 kann node-red mit den folgenden Kommandos automatisch ausgeführt werden:
\begin{lstlisting}
sudo systemctl enable nodered.service
sudo service nodered start
\end{lstlisting}
Die Entwicklungsumgebung ist ab diesem Zeitpunkt unter der in \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. 
Es wird nach erfolgter node-red Installation über den Befehl \inline{npm i node-red-dashboard} installiert.
Das Dashboard ist ab dem Zeitpunkt unter dem Port 1883 erreichbar: \inline{https://141.75.33.126:1883}.
% node-red und das node-red-dashboard werden näher in Kapitel \ref{node-red} auf Seite \pageref{node-red} erklärt.

\subsection{Netzwerkebene}
Auf Netzwerkebene wurde das Internet der Dinge-Protokoll \emph{MQTT} mit der Software \emph{Mosquitto} gewählt. 

\paragraph{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 ist und für die Verteilung der Nachrichten zuständig.
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. 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}[hb]
    \centering
    \includestandalone[width=.75\textwidth]{images/pub_sub_arch}
    \caption{Die Architektur von MQTT}
    \label{fig:pub_sub_arch}
\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)}.
Jedes Gerät kann Daten unter beliebigen \emph{Topics} veröffentlichen oder abonnieren, dabei ist diese Topic für jede individuelle Nachricht fest.
Die Organisation der Daten übernimmt der Broker, wie in Abbildung \ref{fig:pub_sub_flow} gezeigt.
%Anhand der Topics werden die beim Broker eintreffenden Nachrichten weitergeleitet.
%wird jeder Nachricht vom Publisher eine feste Topic zugeordnet.
%In der Regel publishen Sensoren ihre aufgenommenen Daten und Aktoren Statusmeldungen.
%Ebenso kann jedes Gerät beliebig viele Topics abonnieren, was subscriben genannt wird.
%
\begin{figure}[ht]
    \centering
    \includestandalone[width=.75\textwidth]{images/pub_sub_flow}
    \caption{Der Publish/Subscribe Prozess von MQTT}
    \label{fig:pub_sub_flow}
\end{figure}

Ein Client sendet eine Abonnement-Nachricht an den Broker.
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{/ohm/bb/104/sensor}, 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 weiterleitet.

\paragraph{Mosquitto} eine Open-Source Implementation des MQTT-Protokolls und wird in diesem Projekt aufgrund der einfachen Verfügbarkeit als Debian-Paket benutzt.
Es ist ein Projekt der Eclipse Foundation und da die Software in C geschrieben ist, sehr 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.

\subsection{Interface-ebene}
Die letzte Ebene dient der Kommunikation mit den kommerziellen Sensoren.
Da jeder Hersteller von Smart Home 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 - also den Funk-Sendern und -Empfängern gekoppelt.
%Dazu wird das in \ref{funkmodul} auf Seite \pageref{funkmodul} erwähnte Funkmodul benutzt.
%Es bedient die entsprechenden Funk Kanäle der Sensoren und Aktoren, benötigt aber noch Software um die Protokolle der verschiedenen Hersteller verstehen zu können.

\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 Internet der Dinge Geräte zentral zu kontrollieren und managen.
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 Smart Home Umgebung inklusive Interface 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.
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}
Homematic BidCos Geräte werden bei korrekter Funktion des Moduls über das Komandozeilen-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 Smart-Home 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 Smart-Home Umgebung entfernen.
Im Gegensatz zu YAHM wird an piVCCU immer noch aktiv gearbeitet, weshalb die Entscheidung auf piVCCU gefallen ist.

\subsubsection{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 XX genauer erläutert.

Um piVCCU vollständig in die Smart-Home 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 RadMatic auch unter piVCCU installierbar.
Die Nutzung von RedMatic bedeutet, dass eine zweite, eigenständige node-red Installation in der Smart-Home 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 nicht ins Gewicht, solange die Smart-Home Umgebung sich auf einzelne Räume der Hochschule beschränkt.
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.

\newpage
\bibliographystyle{plain}
\bibliography{references}
\end{document}