New revised version

.gitignore

 *.orig
 *.pyc
 venv/
+bericht/lennart/old
 camera/venv
 camera/images
 camera/videos

bericht/lennart/arbeit.sty

+%%
+%% LaTeX-Vorlage fuer Projektarbeit
+%% 
+
+
+%% Neue User-Befehle
+%%
+%% \title                Titel der Projektarbeit
+%% \semester       z.B. Wintersemester 2008/2009
+%% \betreuer       Kommagetrennte Liste der Betreuer
+%% \maketitle       Erzeugen der Titelseite
+%% \keywords      Schlüsselwörter angeben
+
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{arbeit}[2014/10/09 Paket fuer Projektarbeiten]
+\RequirePackage{scrpage2}
+\RequirePackage{hyperref}		% Hyperref möglichst spät laden. Vielleicht hier?
+
+% Kopf- und Fußzeilen setzen
+\clearscrheadfoot
+\pagestyle{scrheadings}
+\cfoot{\thepage}
+
+%% Schriftalternativen zu dem Latex-Standard: Computer Modern (CM)
+%%----------------------------------------------------------------
+%% Englaufende Times/Helvetica/Courier laden, aber mit richtigen Skalierungen (siehe l2tabu)
+%\usepackage{mathptmx}
+%\usepackage[scaled=.90]{helvet}
+%\usepackage{courier} % kann auch weggelassen werden
+%% Palatino, genauso wenig englaufend wie CM, aber riesiger Zeilenabstand
+%\usepackage{mathpazo}
+%\usepackage[scaled=.95]{helvet}
+%\usepackage{courier}
+
+%% Neue User-Befehle
+%%------------------
+\newcommand{\keywordsline}{\paragraph{Keywords:} \@keywords}
+\newcommand{\@betreuer}{}
+\newcommand{\betreuer}[1]{\renewcommand{\@betreuer}{#1}}
+\newcommand{\@semester}{}
+\newcommand{\semester}[1]{\renewcommand{\@semester}{#1}}
+\newcommand{\@keywords}{}
+\newcommand{\keywords}[1]{\renewcommand{\@keywords}{#1}}
+
+\AtBeginDocument{
+	\hypersetup{bookmarksnumbered=true,
+	            pdfcreator={Adobe Acrobat Distiller},
+	            pdfproducer={LaTex with hyperref}
+	}
+}
+
+% Eigentliche Ausgabe der Titelseite
+\renewcommand{\@maketitle}
+{%
+	\hypersetup{%
+		pdftitle={\@title},
+		pdfsubject={Projektarbeit \@semester},
+		pdfauthor={\@author},
+		pdfkeywords={\@keywords},
+	}%
+	\begin{center}
+	  \vskip 2em%
+		{\titlefont\huge \@title \par}%
+		\vskip 2em%
+		{\large\textbf{Projektarbeit}\par}%
+		{\large \@author\par}%
+		\vskip 2em%
+		{\large Fakultät Elektrotechnik Feinwerktechnik Informationstechnik, \\
+		Technische Hochschule Nürnberg Georg Simon Ohm,\\
+		Wassertorstraße 10,\\
+		90489 Nürnberg, Germany\\
+		Betreuer: \@betreuer\par}%
+		\vspace*{3em}	%
+	\end{center}%
+}
+
+% Aus scrartcl.cls extrahiert, sorgt fuer richtiges Setzen bei ein-/zweispaltigem Satz
+\renewcommand{\maketitle}{
+  \if@twocolumn
+    \ifnum \col@number=\@ne
+      \@maketitle
+    \else
+      \twocolumn[\@maketitle]%
+    \fi
+  \else
+    \newpage
+    \global\@topnum\z@
+    \@maketitle
+  \fi
+}
+
+% Aus scrartcl.cls genommen und angepasst -> Kursive Schrift
+\renewenvironment{abstract}{%
+  \if@twocolumn\if@abstrt %Zweispaltig
+      \addsec*{\abstractname}
+      \it% Abstract kursiv setzen
+    \fi
+    \it% Abstract kursiv setzen
+  \else% Einspaltig
+    \if@abstrt
+      \small
+      \begin{center}
+        {\normalfont\sectfont\nobreak\abstractname
+          \vspace{-.5em}\vspace{\z@}}%
+      \end{center}
+    \fi
+    \quotation
+  \fi
+}{%
+  \if@twocolumn\else\endquotation\fi
+}
+
+% Wir wollen Latex beim Setzen des Literaturverzeichnisses
+% nicht ganz so pingelig sein lassen, da wir enge Spalten verwenden
+\newcommand{\orig@bibliography}{}
+\let\orig@bibliography\bibliography % Alte Definition in orig@... speichern
+\renewcommand{\bibliography}        % \bibliography neu definieren
+{
+	\tolerance 1414                   % Toleranzwerte setzen (siehe l2tabu)
+	\hbadness 1414                    % ...
+	\emergencystretch 1.5em           % ...
+	\hfuzz 0.3pt                      % ...
+	\widowpenalty=10000               % ...
+	\vfuzz \hfuzz                     % ...
+	\raggedbottom                     % ...
+	\orig@bibliography                % und das Originalkommando aufrufen
+}

bericht/lennart/chapters.tex

+% Hier werden die Kapitel eingebunden
+% Bei Bedarf weitere Kapitel eintragen
+\input{chapters/1_introduction.tex}
+\input{chapters/2_hardware.tex}
+\input{chapters/3_network.tex}
+\input{chapters/4_software.tex}
+\input{chapters/5_fazit.tex}
+\input{chapters/6_ausblick.tex}
+\input{chapters/kamera_personenerkennung.tex}

bericht/lennart/chapters/0_abstract.tex

+In der Projektarbeit wird zunächst eine individuelle Smarthome 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.
+
+Anhand der Sensoren soll anschließend ein System aus Sensoren 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.

bericht/lennart/chapters/1_introduction.tex

+\section{Einleitung}
+\label{sec:intro}
+\paragraph{}
+Intelligente Heim Überwachung und Automatisierung gewinnt stetig an Bedeutung in einer zunehmend vernetzten Gesellschaft.
+Jüngste Fortschritte in der Mikrocomputertechnik, deren Kosten und in der Netzwerktechnik 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 Beispiel steuerbare Rollläden zusammen mit Temperatur-, Lichtintensitäts- und weiteren Sensoren nutzen um diese automatisch hoch, beziehungsweise herunter zu fahren oder Lichter einschalten, sobald sich eine Person in einem dunklen Raum befindet.
+
+\paragraph{}
+Aus diesen Möglichkeiten der Steuerung und Datenerfassung durch Sensoren ist ein breiter Markt an Systemen entstanden, die Technik für das Smarthome bereitstellen.
+Diese Technik gliedert sich allgemein in drei Geräte Kategorien:
+
+\begin{itemize}
+    \item Sensoren, die zur Erfassung von physikalischen Umweltdaten dienen,
+    \item Aktoren, die mit der Umwelt interagieren und
+    \item Steuerzentralen, auch Gateways genannt, welche gesammelte Daten darstellen und anhand dieser Daten Aktoren steuern.
+\end{itemize}
+
+Das Zusammenspiel dieser drei Geräte stellt die Intelligenz des Smarthome 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 in ihrem Aufbau geschlossen und benutzen ein eigenes Ökosystem.
+Sie funktionieren nur mit Geräten eines Herstellers.
+Beispielhaft für ein solches geschlossenes System ist Homematic von der Firma eQ-3. 
+Der Hersteller ist einer der Marktführer im Bereich Smarthome in Europa und bietet mit Homematic und dem neuen System Homematic IP zwei umfangreiche Smarthome Systeme mit einer sehr großen Auswahl an Geräten an.
+Homematic Sensoren und Aktoren können jedoch nur mit der hauseigenem Smarthome Zentrale (Central Control Unit, CCU) betrieben werden.\\
+Aufgrund von zum Teil deutlichen Preisunterschieden zwischen verschiedenen Herstellern ist es 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 Smarthome 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 und einer Kamera, die genutzt wird, um Personen zu zählen, verglichen.
+
+\newpage

bericht/lennart/chapters/2_hardware.tex

+\section{Hardware der Smarthome Umgebung}
+\label{blog}
+Den Startpunkt des Projekts stellt der Blogeintrag ``Homematic mit Node-Red über homegear'' von Patrik Mayer \cite{mayer2017smarthomesetup} dar, in dem eine Smarthome Struktur basierend auf einem Raspberry Pi beschrieben wird.
+Im Folgendem wird das Aufsetzen der Gateway unter Berücksichtigung des Blogartikels beschrieben.
+Begonnen wird mit der Hardware, die für die Gateway benötigt wird und deren Konfiguration.
+
+\paragraph{}
+\label{raspberry-pi}
+Als Basis für die Gateway wird der Einplatinencomputer \emph{Raspberry Pi} aufgrund seiner guten Verfügbarkeit und seines günstigen Preises gewählt.
+Mit LAN, WLAN und diversen weiteren Schnittstellen  wie UART und SPI und dank seiner geringen Größe ist dieser Computer sehr gut geeignet für den Einsatz als Smarthome Zentrale.
+
+Für das Betriebssystem des Raspberry Pi wird Raspbian Stretch Lite gewählt.
+Dies ist ein für den Dauerbetrieb geeignetes Betriebssystem basierend auf der Linux-Distribution Debian Stretch.
+Es ist speziell für den Raspberry Pi konfiguriert und verzichtet auf eine Desktop Umgebung, wodurch der Speicher- und Rechenleistungsverbrauch minimiert wird.
+Die Installation des Betriebssystems erfolgt über die bereits auf dem Raspberry Pi vorinstallierte Installationsanwendung NOOBS, welche das Betriebssystem automatisch auf der SD-Karte des Raspberry Pi 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 das 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.
+Mit dem Befehl \inline{sudo raspi-config} kann UART unter dem Menüpunkt \inline{5 Interfacing Options} und anschließend \inline{P6 Serial} aktiviert werden.
+Ist UART einmal aktiviert, ist das Modul Einsatzfähig.

bericht/lennart/chapters/3_network.tex

+\section{Netzwerkkonfiguration des Raspberry Pi}
+Die Netzwerkkonfiguration des Projektes birgt zwei Herausforderungen:
+\begin{enumerate}
+    \item Erreichbarkeit der gewonnenen Daten, beziehungsweise Steuerung der Aktoren über das Hochschulnetzwerk
+    \item Kommunikation der selbstgebauten 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}
+\lstinputlisting[firstline=1, lastline=16]{code/dhcpcd.tex}
+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.
+
+
+\subsection{Raspberry Pi als Accesspoint}
+Realisiert wird der Accesspiont durch das Softwarepaket \textit{hostapd}, welches durch folgendes Kommando installiert wird:
+\begin{lstlisting}[language=bash]
+sudo apt install hostapd
+\end{lstlisting}
+Danach wird hostapd für die Konfigurationsphase deaktiviert:
+\begin{lstlisting}
+sudo systemctl stop hostapd
+\end{lstlisting}
+
+
+\subsection{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:
+\lstinputlisting[firstline=18, lastline=29]{code/dhcpcd.tex}
+Um die Änderungen zu übernehmen wird der dhcp daemon neu gestartet: 
+\begin{lstlisting}
+sudo service dhcpcd restart
+\end{lstlisting}
+
+
+\subsection{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 erneut: \inline{sudo systemctl reload dnsmasq}.
+
+
+\subsection{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.
+\lstinputlisting{code/hostapd.tex}
+Erkennbar ist die SSID \inline{smartroom} und das Passwort \inline{smarthome}.
+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}
+
+
+\subsection{Starten des Accesspoints}
+Nun muss nur der Accesspoint gestartet werden und die Netzwerkkonfiguration ist abgeschlossen.
+\begin{lstlisting}
+sudo systemctl unmask hostapd
+sudo systemctl enable hostapd
+sudo systemctl start hostapd
+\end{lstlisting}

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

bericht/lennart/chapters/5_fazit.tex

+\section{Fazit der Smarthome Umgebung}
+\label{fazit}
+
+\begin{figure}[p]
+\centering
+\begin{subfigure}[b]{0.8\textwidth}
+    \includegraphics[width=1\linewidth]{images/node-red-homegear.jpg}
+    \caption{}
+    \label{fig:structure-old}
+\end{subfigure}
+\begin{subfigure}[b]{0.8\textwidth}
+    \includestandalone[width=1\textwidth]{standalone/final_structure}
+    \caption{}
+    \label{fig:structure-new}
+\end{subfigure}
+
+\caption{Vergleich der Smarthome Umgebungen: \ref{fig:structure-old} zeigt die von Patrik Mayer \cite{mayer2017smarthomesetup} vorgeschlagene Umgebung, \ref{fig:structure-new} zeigt die in dieser Arbeit umgesetzte Umgebung}%
+\label{fig:structures}
+
+\end{figure}
+
+Die in dem Blogbeitrag ''Homematic mit node-red über homegear'' von Patrik Mayer \cite{mayer2017smarthomesetup} beschriebene Smarthome Umgebung konnte weitestgehend Umgesetzt werden.
+Das grobe Gerüst mit Node-Red, dem Node-Red-dashboard, MQTT als Transport-Protokoll und Homegear um mit kommerziellen Systemen zu kommunizieren konnte übernommen werden.
+Wo die beschriebene Gateway von der aus dem Blogbeitrag abweicht, ist die spezifische Netzwerk Konfiguration die durch die Hochschulumgebung begründet ist.
+Eigens Entwickelte Sensoren können nicht das Hochschulnetzwerk benutzen, da sie die verwendete Verschlüsselung nicht unterstützen.
+Stattdessen dient der Raspberry Pi als Accesspoint für die Sensoren mit einem eigenen WLAN-Netzwerk.
+
+\paragraph{}
+Zusätzlich waren zur Zeit der Veröffentlichung des Blogbeitrags im Jahr 2017 Geräte die das Protokoll Homematic IP nutzen nicht sehr weit Verbreitet.
+Dies hat sich mit der Zeit geändert und Homematic IP ist mittlerweile laut Herstellerseite eines der meistgenutzten Protokolle in Europa.
+Da Homegear dieses Protokoll aufgrund der fehlenden Quelloffenheit nicht unterstützt, wurden verschiedene Alternativen getestet und schließlich die originale Gateway Software von Homematic in Form von piVCCU auf dem Raspberry Pi emuliert.
+Durch Nutzen von piVCCU wird die Kommunikation mit kommerziellen Sensoren zweigeteilt:
+Homematic Sensoren werden über die Homematic Weboberfläche die unter piVCCU läuft angesprochen.
+Verwaltung aller anderen kommerziellen Sensoren übernimmt Homegear.
+
+Die Abbildung \ref{fig:structures} zeigt die Beschriebenen Unterschiede der beiden Smarthome Umgebungen noch einmal vergleichend auf.

bericht/lennart/chapters/6_ausblick.tex

+\section{Ausblick}
+\label{ausblick}
+
+Um die entwickelte Smarthome Umgebung robuster zu gestalten, ist es wünschenswert, den bisher eingeschlagenen Weg über RedMatic abzuschaffen.
+Wie in Abschnitt \ref{pivccu:expansion} auf Seite \pageref{pivccu:expansion} erwähnt, sollte der Nachrichtentransport der CCU statt über eine zweite Node-Red Installation direkt mit Hilfe eines Skriptes mittels TCP/IP an Mosquitto erfolgen.
+Alternativ ist es auch denkbar die piVCCU an Homegear über die Homegear-Schnittstelle XML-RPC anzubinden.
+Dazu ist aber weitere Recherche notwendig.
+Idealerweise implementiert Homegear in der Zukunft das Homematic IP Protokoll und mach das Benutzen von piVCCU überflüssig.
+
+\paragraph{}
+Um die Sicherheit des Systems zu Verbessern, unterstützt MQTT die Nutzung von SSL-Verschlüsselung, wodurch Nachrichten verschlüsselt übertragen werden können.
+Dies erfordert die Nutzung von SSL-Zertifikaten, die auch auf den Sensoren bekannt gemacht werden.
+Außerdem ist es wünschenswert Eduroam für die WLAN-Sensoren zu nutzen.
+Mit der Verbindung der WLAN-Sensoren zu dem vom Raspberry Pi aufgesetztem WLAN-Netzwerk, ist es Nötig, in jedem Raum in dem Sensoren genutzt werden sollen, einen Raspberry Pi an das LAN-Netzwerk der Hochschule anzuschließen.
+Sind die Sensoren jedoch im WLAN-Netz der Hochschule reicht ein Zentraler Computer als Zentrale der Samrthome Umgebung.

bericht/lennart/chapters/kamera_personenerkennung.tex

+\newpage
+\section{Personenerkennung mit Hilfe einer Kamera}
+
+\begin{figure}[p]
+\centering
+\begin{subfigure}[b]{0.8\textwidth}
+    \includegraphics[width=1\linewidth]{images/pi_camera_1.jpg}
+    \caption{}
+    \label{fig:kamera-activate1}
+\end{subfigure}
+\begin{subfigure}[b]{0.8\textwidth}
+    \includegraphics[width=1\textwidth]{images/pi_camera_2.jpg}
+    \caption{}
+    \label{fig:kamera-activate2}
+\end{subfigure}
+\begin{subfigure}[b]{0.8\textwidth}
+    \includegraphics[width=1\textwidth]{images/pi_camera_3.jpg}
+    \caption{}
+    \label{fig:kamera-activate3}
+\end{subfigure}
+
+\caption{Drei Aktivierungsschritte der Praspberry Pi Kamera: \ref{fig:kamera-activate1}: Interfacing Options auswählen, \ref{fig:kamera-activate2}: Camera Options auswählen, \ref{fig:kamera-activate3}: Aktivierung bestätigen}%
+\label{fig:kamera-activate}
+
+\end{figure}
+
+Als ein weiteres Vergleichsmittel zur Personenerkennung im Labor wurde eine 5 Megapixel Kamera für den Raspberry Pi zusammen mit einem Bilderkennungs Skript genutzt.
+Aus Datenschutzgründen ist die Benutzung einer Kamera zwar nicht dauerhaft möglich in der Hochschule, zum Vergleichen der Effektivität mit der in dieser Arbeit entwickelten Präsenzerkennung und dem Präsenzerkennungssensor von Homematic jedoch sehr hilfreich.
+
+Angeschlossen wird die Kamera über ein spezielles Flachbandkabel an den Raspberry Pi.
+Die Aktivierung der Kamera  erfolgt über das Raspberry Pi Software Configuration Tool, das mit dem Befehl \inline{sudo raspi-config} aufgerufen wird.
+Dort wird anschließend wie in Abbildung \ref{fig:kamera-activate} gezeigt die Kamera aktiviert.
+
+Um die von der Kamera aufgenommenen Bilder zu analysieren wird Python zusammen mit den Modulen OpenCV, Numpy, Imutils und imagezmq benutzt.
+Der Sourcecode ist auf dem EFI Git Service unter dem Projekt \inline{heimbsle69869 / smarthome-presence-detect} in dem Ordner \inline{Camera} zu finden.
+Zur Personenerkennung wird das Skript \inline{person_detection.py} genutzt.
+Es nutzt imutils um einen Videostream zu lesen, von dem jeder Frame in ein OpenCV-Array eingelesen wird.
+Anhand dieses Arrays werden durch ein bereits für die Personenerkennung trainierten Tensorflow-Erkennungsmodell mit einer definierbaren Konfidenz Personen erkannt.
+Ändert sich die Anzahl der erkannten Personen von einem Frame auf den anderen, wird die neue Anzahl per MQTT an Node-Red veröffentlicht.
+
+\paragraph{}
+Die Präsenzerkennung mit dieser Methode wird begrenzt duch die Rechenleistung des Rasp\-berry Pi, dem Aufnahmewinkel der Kamera und der Qualität des Trainings des verwendeten Erkennungsmodell.
+Durch die begrenzte Rechenleistung des Raspberry Pi werden die aufgenommenen Frames nur sehr langsam, mit etwa 3-10 Frames pro Sekunde, verarbeitet.
+Die Kamera nimmt mit 30 Frames pro Sekunde auf.
+Dies kann verbessert werden, indem die Frames vom Raspberry Pi über WLAN an einen leistungsfähigeren Computer übertragen werden, auf dem die Analyse stattfindet.
+So konnte die Verarbeitungsgeschwindigkeit auf fast 30 Frames pro Sekunde erhöht werden.
+
+Das verwendete Erkennungsmodell erkennt Personen während des Tests zuverlässig.
+Allerdings werden sehr häufig fälschlicherweise mehr Personen erkannt als sich im Bild befinden.
+Dies könnte mit weiterem Training des Modells verbessert werden.
+
+\paragraph{Fazit Kamera:}
+Die Präsenzerkennung mit Hilfe einer Kamera ist nicht realistisch Anwendbar in einer Hochschulumgebung, da heutige Datenschutzrichlinien die Aufnahme Personenbezogener Daten ohne deren Einwilligung nicht erlauben.
+Sie ist jedoch in Anbetracht der Erkennungsqualität die vielversprechendste Lösung, da mit einem nur grundlegend trainierten Erkennungsmodell bereits sehr gute Ergebnisse erzielt wurden.

bericht/lennart/code/bidcos.tex

+[HomeMatic Wireless Module for Raspberry Pi]
+id = My-HM-MOD-RPI-PCB
+# Uncomment this if you want the HM-MOD-RPI-PCB to be your default communication module.
+default = true
+deviceType = hm-mod-rpi-pcb
+device = /dev/ttyAMA0
+responseDelay = 95
+gpio1 = 18

bericht/lennart/code/dhcpcd.tex

+interface br0
+#eth0
+static ip_address=141.75.33.126/24
+static routers=141.75.33.1
+static domain_name_servers=141.75.40.250
+
+# It is possible to fall back to a static IP if DHCP fails:
+define static profile
+profile static_br0
+static ip_address=192.168.1.23/24
+static routers=192.168.1.1
+static domain_name_servers=192.168.1.1
+
+# fallback to static profile on eth0
+interface br0
+fallback static_br0
+
+interface wlan0
+static ip_address=192.168.252.1/24
+nohook wap_supplicant
+
+define static profile
+profile static_wlan0
+static ip_address=192.168.1.23/24
+static routers=192.168.1.1
+static domain_name_servers=192.168.1.1
+
+interface wlan0
+fallback static_wlan0

bericht/lennart/code/hostapd.tex

+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
+ctrl_interface=/var/run/hostapd
+ctrl_interface_group=0

bericht/lennart/config.tex

+% Details der Arbeit
+\title{Präsenzerkennung im Rahmen einer modularen Smarthome Umgebung}
+
+\author{Sebastian Dohle, Lennart Heimbs, Kevin Holzschuh, Johannes Krug}
+\date{März-September 2019}
+
+\betreuer{Prof.-Dr. Oliver Hofmann, B.-Eng. Martin Wimmer}
+\semester{Sommersemester 2019}
+\keywords{Smarthome, Raspberry Pi, Homematic, Homegear, Node-Red, Präsenz\-erkennung, ESP8266, MQTT}

bericht/lennart/includes.tex

+\usepackage{listings, xcolor, realboxes, xpatch}
+
+\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

bericht/lennart/standalone/final_structure.tex

+% Tikz File final_structure.tex
+\documentclass{standalone}
+\usepackage{tikz, graphicx}
+\usetikzlibrary{decorations.pathreplacing, calc, positioning}
+
+\begin{document}
+\begin{tikzpicture}
+    %\draw[gray,very thin] (-3,-3) grid (12,12);
+    
+    % Frame
+    \coordinate (frame) at (3,1);
+    \filldraw[color=gray!10, fill=gray!10] (frame) rectangle +(4,8.0);
+    \node (text_rpi) at (5,8.5) {\huge Raspberry Pi};
+    
+    %node-red-dashboard
+    \coordinate (nrd) at (3.25,7.1);
+    \filldraw[color=red, fill=red] (nrd) rectangle +(3.5,0.8);
+    \node (text-nrd) at (5,7.5) {Node-Red-dashboard};
+    
+    %node-red
+    \coordinate (nr) at (3.25,6.1);
+    \filldraw[color=red, fill=red] (nr) rectangle +(3.5,0.8);
+    \node (text-nr) at (5,6.5) {Node-Red};
+    
+    %mosquitto
+    \coordinate (mq) at (3.25,4.6);
+    \filldraw[color=yellow, fill=yellow] (mq) rectangle +(3.5,0.8);
+    \node (text-mq) at (5,5) {Mosquitto};
+    
+    %homegear
+    \coordinate (hg) at (3.25,2.1);
+    \filldraw[color=cyan!50, fill=cyan!50] (hg) rectangle +(3.5/2-0.25,1.8);
+    \node (text-hg) at (4,3) {Homegear};
+    
+    %pivccu
+    \coordinate (pi) at (5.25,2.1);
+    \filldraw[color=cyan!50, fill=cyan!50] (pi) rectangle +(3.5/2-0.25,1.8);
+    \node (text-pi) at (6,3) {piVCCU};
+    
+    %ss-dashboard
+    \coordinate (ss-nrd) at (9.8,8-0.5);
+    \node[inner sep=0pt] (img-ss-nrd) at (ss-nrd)
+        {\includegraphics[width=0.2\textwidth]{images/ss_dashboard.jpg}};
+        
+    %ss-nodered
+    \coordinate (ss-nr) at (0.5,7);
+    \node[inner sep=0pt] (img-ss-nr) at (ss-nr)
+        {\includegraphics[width=0.2\textwidth]{images/ss_nodered.jpg}};
+    
+    %ss-homematic
+    \coordinate (ss-hm) at (9.8,3);
+    \node[inner sep=0pt] (img-ss-hm) at (ss-hm)
+        {\includegraphics[width=0.2\textwidth]{images/ss_homematic.jpg}};
+    
+    %esp
+    \coordinate (esp-c) at (0.5,3);
+    \node[inner sep=0pt] (esp) at (esp-c)
+        {\includegraphics[width=0.2\textwidth]{images/esp8266.png}};
+    
+    % arrows
+    \draw[black,thick,<->] (text-nrd) -- (text-nr);
+    \draw[black,thick,<->] (text-nr) -- (text-mq);
+    \draw[black,thick,<->] (text-mq) -- (text-hg);
+    \draw[black,thick,<->] (text-mq) -- (text-pi);
+    
+    \draw[black,thick,->] (esp.12) -- (text-mq.west) node[thick,midway,rotate=36,yshift=2mm,xshift=-1mm]{smarthome-Wifi};
+    \draw[black,thick,->] (img-ss-hm) -- (text-pi.east) node[thick,midway,yshift=2mm,xshift=1mm]{Eduroam};
+    \draw[black,thick,->] (img-ss-nr.-22) -- (text-nr.west) node[thick,midway,yshift=2mm,xshift=-5mm]{Eduroam};
+    \draw[black,thick,->] (img-ss-nrd) -- (text-nrd.east) node[thick,midway,yshift=2mm,xshift=1mm]{Eduroam};
+    
+\end{tikzpicture}
+\end{document}

bericht/lennart/standalone/mqtt_topic.tex

+% Tikz File mqtt_topic.tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{graphicx}
+\usetikzlibrary{decorations.pathreplacing}
+\usetikzlibrary{positioning}
+
+\begin{document}
+\begin{tikzpicture}
+
+    \node[scale=3] (topic_104) at (0, 0) {/104};
+    \node[scale=3] (topic_bb)  [left=-8mm of topic_104] {/bb};
+    \node[scale=3] (topic_gso) [left=-8mm of topic_bb] {gso};
+    \node[scale=3] (topic_us)  [right=-8mm of topic_104] {/ultraschall};
+    \node[scale=3] (topic_wc)  [right=-5mm of topic_us] {/\#};
+    \node[green,scale=1.6]   (ml-wc)     [above=7mm of topic_wc] {Multilevel Wildcard};
+    
+    \draw[blue,decorate,decoration={brace,amplitude=12pt,pre=moveto,pre length=3mm,post=moveto,post length=3mm}] (topic_gso.north west) -- (topic_gso.north east) node[midway, above,yshift=12pt,scale=1.6]{Topic Level};
+    \draw[blue,decorate,decoration={brace,mirror,amplitude=12pt,pre=moveto,pre length=5mm,post=moveto,post length=4mm}] (topic_bb.south west) -- (topic_bb.south east) node[midway, below,yshift=-12pt,scale=1.6]{Topic Level};
+    
+    \draw[->,thick,green] (ml-wc.south) -- (topic_wc.north) ;
+    
+\end{tikzpicture}
+\end{document}

bericht/lennart/standalone/pub_sub_arch.tex

+% Tikz File mqtt_pub_sub.tex
+\documentclass{standalone}
+\usepackage{tikz, graphicx}
+
+\begin{document}
+\begin{tikzpicture}
+    %\draw[help lines] (-7,-5) grid (7,5);
+
+    % Broker
+    \draw (0,0) circle (2);
+    \node[] at (0,-1.5) (broker) {\textbf{Broker}};
+    \node[inner sep=0pt] (broker_pc) at (0,0)
+        {\includegraphics[width=0.1\textwidth]{images/pc.png}};
+    
+    % Publisher
+    \pgfmathsetmacro\xl{-6};
+    \pgfmathsetmacro\xr{-3};
+    \pgfmathsetmacro\w{(\xl+\xr)};
+    \pgfmathsetmacro\y{6};
+    
+    % Text
+    \node[] at (\w/2,-\y/2-0.25) (pubs) {\textbf{MQTT Clients}};
+    
+    % Images
+    \node[inner sep=0pt] (laptop) at (\w/2,\y/3)
+        {\includegraphics[width=0.1\textwidth]{images/laptop.png}};
+    
+    \node[inner sep=0pt] (mcu) at (\w/2,\y/3-\y/3)
+        {\includegraphics[width=0.1\textwidth]{images/muc.png}};
+        
+    \node[inner sep=0pt] (pc) at (\w/2,\y/3-\y/3-\y/3)
+        {\includegraphics[width=0.1\textwidth]{images/pc.png}};
+    
+    \draw (\xl-0.25, \y/2-0.25) -- (\xl-0.25, -\y/2+0.25);  % left
+    \draw (\xl, \y/2) arc (90:180:0.25);                    % top left
+    \draw (\xl, \y/2) -- (\xr, \y/2);                       % top
+    \draw (\xr+0.25, \y/2-0.25) arc (0:90:0.25);            % top right
+    \draw (\xr+0.25, \y/2-0.25) -- (\xr+0.25, -\y/2+0.25);  % right
+    \draw (\xr, -\y/2) arc (270:360:0.25);                  % bottom right
+    \draw (\xl,-\y/2) -- (\xr,-\y/2);                       % bottom
+    \draw (\xl-0.25, -\y/2+0.25) arc (180:270:0.25);        % bottom left
+    
+    % Subscriber
+    \pgfmathsetmacro\xl{3}
+    \pgfmathsetmacro\xr{6}
+    \pgfmathsetmacro\w{(\xl+\xr)};
+    \pgfmathsetmacro\y{6}
+    
+    \node[] at (\w/2,-\y/2-0.25) (subs) {\textbf{MQTT Clients}};
+    
+    % Images
+    \node[inner sep=0pt] (server) at (\w/2,\y/3-1)
+        {\includegraphics[width=0.1\textwidth]{images/server.png}};
+    
+    \node[inner sep=0pt] (sub_mcu) at (\w/2,\y/3-3)
+        {\includegraphics[width=0.1\textwidth]{images/muc.png}};
+    
+    \draw (\xl-0.25, \y/2-0.25) -- (\xl-0.25, -\y/2+0.25);  % left
+    \draw (\xl, \y/2) arc (90:180:0.25);                    % top left
+    \draw (\xl, \y/2) -- (\xr, \y/2);                       % top
+    \draw (\xr+0.25, \y/2-0.25) arc (0:90:0.25);            % top right
+    \draw (\xr+0.25, \y/2-0.25) -- (\xr+0.25, -\y/2+0.25);  % right
+    \draw (\xr, -\y/2) arc (270:360:0.25);                  % bottom right
+    \draw (\xl,-\y/2) -- (\xr,-\y/2);                       % bottom
+    \draw (\xl-0.25, -\y/2+0.25) arc (180:270:0.25);        % bottom left
+    
+    % arrows
+    \draw[ultra thick, ->] (mcu) -- (broker_pc);
+    \draw[ultra thick, ->] (laptop) -- (broker_pc);
+    \draw[ultra thick, ->] (pc) -- (broker_pc);
+    \draw[ultra thick, ->] (sub_mcu) -- (broker_pc);
+    
+    \draw[dashed, ultra thick, <-] (server) -- (broker_pc);
+    \draw[dashed, ultra thick, ->] (broker_pc.10) to (sub_mcu.north west);
+    
+    % legend
+    \draw[dashed, ultra thick, ->] (-4,-4) -- (-1,-4);
+    \node[] (Sub) at (-2.5,-4.25) {Subscribe};
+    
+    \draw[ultra thick, ->] (1,-4) -- (4,-4);
+    \node[] (Pub) at (2.5,-4.25) {Publish};
+    
+\end{tikzpicture}
+\end{document}

bericht/lennart/standalone/pub_sub_flow.tex

+% Tikz File mqtt_pub_sub.tex
+\documentclass{standalone}
+\usepackage{tikz, graphicx}
+
+\begin{document}
+\begin{tikzpicture}
+    %\draw[help lines] (-7,-5) grid (7,5);
+
+    \pgfmathsetmacro\pub{-4};
+    \pgfmathsetmacro\bro{0};
+    \pgfmathsetmacro\sub{4};
+    \pgfmathsetmacro\y{4};
+    
+    \draw[ultra thick] (\pub,\y/2) -- (\pub,\y/-2);
+    \draw[ultra thick] (\bro,\y/2) -- (\bro,\y/-2);
+    \draw[ultra thick] (\sub,\y/2) -- (\sub,\y/-2);
+    
+    \draw[ultra thick, ->] (\sub,1) -- (\bro, 1);
+    \draw[ultra thick, <-] (\sub,-1) -- (\bro, -1);
+    \draw[ultra thick, ->] (\pub,0) -- (\bro, 0);
+    
+    \node at (\pub, \y/2+0.2) {Publisher};
+    \node at (\bro, \y/2+0.2) {Broker};
+    \node at (\sub, \y/2+0.2) {Subscriber};
+    
+    \node at (\sub/2, 1.2) {Subscribe (topic)};
+    \node at (\pub/2, 0.2) {Publish (topic, info)};
+    \node at (\sub/2, -0.8) {Publish (topic, info)};
+    
+\end{tikzpicture}
+\end{document}