diff --git a/.github/workflows/thesis_ci.yml b/.github/workflows/thesis_ci.yml new file mode 100644 index 0000000..e708f5a --- /dev/null +++ b/.github/workflows/thesis_ci.yml @@ -0,0 +1,52 @@ +name: Thesis CI + +on: + push: + paths: + - 'docs/BT/CTU_FEL_THESIS/**' + - '.github/workflows/thesis_ci.yml' + +permissions: + contents: write + +jobs: + build_latex: + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v4 + + - name: Compile Thesis PDF + uses: docker://texlive/texlive:latest + with: + entrypoint: /bin/sh + args: -c "apt-get update && apt-get install -y make && cd docs/BT/CTU_FEL_THESIS && make pdf || true" + + - name: Rename Output + run: | + # Find the pdf generated by make in the thesis directory + cd docs/BT/CTU_FEL_THESIS + # The makefile produces $(BASENAME)_v$(VERSION).pdf - use sort -V for version sorting + PDF_FILE=$(find . -maxdepth 1 -name "bachelor_thesis_Yuan_v*.pdf" | sort -V | tail -n 1) + BUILD_DATE=$(date +%Y-%m-%d) + OUTPUT_NAME="袁伟泽_本科毕业论文_${BUILD_DATE}.pdf" + if [ -n "$PDF_FILE" ]; then + cp "$PDF_FILE" "$GITHUB_WORKSPACE/${OUTPUT_NAME}" + echo "OUTPUT_NAME=${OUTPUT_NAME}" >> $GITHUB_ENV + echo "Found and moved $PDF_FILE to ${OUTPUT_NAME}" + else + echo "No PDF found!" + # Debug output + ls -la + exit 1 + fi + + - name: Release + uses: softprops/action-gh-release@v2 + with: + tag_name: thesis-latest + name: Latest Thesis Build + files: ${{ env.OUTPUT_NAME }} + draft: false + prerelease: false + make_latest: false diff --git a/.gitignore b/.gitignore index 96dedb8..bea1971 100644 --- a/.gitignore +++ b/.gitignore @@ -42,7 +42,9 @@ certs/** sensors/certs/ # Docs: keep only docs/README tracked -docs/BT/ +docs/BT/* +!docs/BT/CTU_FEL_THESIS/ + # PDF converter working files docs/pdf2md/input/ diff --git a/README.md b/README.md index bc7e8c5..34e3bdb 100644 --- a/README.md +++ b/README.md @@ -106,3 +106,5 @@ This project was developed under the supervision of [Prof. Miroslav Husák](http Czech Technical University in Prague, Faculty of Electrical Engineering [![GitHub](https://img.shields.io/badge/GitHub-@IYUANWEIZE-181717?logo=github)](https://github.com/IYUANWEIZE) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/README.zh-CN.md b/README.zh-CN.md index 543157f..222a3fb 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -106,3 +106,5 @@ cd broker/emqx && docker compose up -d 捷克理工大学电气工程学院 [![GitHub](https://img.shields.io/badge/GitHub-@IYUANWEIZE-181717?logo=github)](https://github.com/IYUANWEIZE) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/broker/README.md b/broker/README.md index 81bab41..78d17d4 100644 --- a/broker/README.md +++ b/broker/README.md @@ -66,3 +66,5 @@ See [`../certs/README.md`](../certs/README.md) for certificate generation instru - [EMQX Documentation](https://www.emqx.io/docs/en/latest/) - [Mosquitto Documentation](https://mosquitto.org/documentation/) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/broker/README.zh-CN.md b/broker/README.zh-CN.md index 9c1efba..f144d8f 100644 --- a/broker/README.zh-CN.md +++ b/broker/README.zh-CN.md @@ -66,3 +66,5 @@ docker compose up -d - [EMQX 文档](https://www.emqx.io/docs/zh/latest/) - [Mosquitto 文档](https://mosquitto.org/documentation/) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/broker/emqx/docker-compose.yml b/broker/emqx/docker-compose.yml index a7291e2..0fa8e9f 100644 --- a/broker/emqx/docker-compose.yml +++ b/broker/emqx/docker-compose.yml @@ -25,3 +25,5 @@ services: EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__FAIL_IF_NO_PEER_CERT: "true" # Authentication EMQX_ALLOW_ANONYMOUS: "false" + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/broker/mosquitto/docker-compose.yml b/broker/mosquitto/docker-compose.yml index f645f37..5080900 100644 --- a/broker/mosquitto/docker-compose.yml +++ b/broker/mosquitto/docker-compose.yml @@ -10,3 +10,5 @@ services: - ./config:/mosquitto/config - ./data:/mosquitto/data - ./log:/mosquitto/log + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/certs/README.md b/certs/README.md index b8bf2a0..29c138b 100644 --- a/certs/README.md +++ b/certs/README.md @@ -85,3 +85,5 @@ For deployment examples, see: - [broker/emqx/docker-compose.yml](../broker/emqx/docker-compose.yml) - EMQX mTLS configuration - [esphome/*.yaml](../esphome/) - ESP32 client certificate configuration - [sensors/brokers.example.yml](../sensors/brokers.example.yml) - Simulator TLS configuration + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/certs/README.zh-CN.md b/certs/README.zh-CN.md index 18468ce..e024469 100644 --- a/certs/README.zh-CN.md +++ b/certs/README.zh-CN.md @@ -84,3 +84,5 @@ openssl x509 -in ha/ha.pem -noout -subject -dates - [broker/emqx/docker-compose.yml](../broker/emqx/docker-compose.yml) - EMQX mTLS 配置 - [esphome/*.yaml](../esphome/) - ESP32 客户端证书配置 - [sensors/brokers.example.yml](../sensors/brokers.example.yml) - 模拟器 TLS 配置 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/.version b/docs/BT/CTU_FEL_THESIS/.version new file mode 100644 index 0000000..15aa8cc --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/.version @@ -0,0 +1 @@ +25.9 diff --git a/docs/BT/CTU_FEL_THESIS/Makefile b/docs/BT/CTU_FEL_THESIS/Makefile new file mode 100644 index 0000000..cdbfda2 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/Makefile @@ -0,0 +1,36 @@ +# Thesis build with auto-versioning +BASENAME = bachelor_thesis_Yuan +VERSION_FILE = .version +VERSION = $(shell cat $(VERSION_FILE) 2>/dev/null || echo "1.0") +JOBNAME = $(BASENAME)_v$(VERSION) + +.PHONY: all pdf bump clean + +# 默认: bump + pdf +all: bump pdf + +pdf: + lualatex -interaction=nonstopmode -jobname=$(JOBNAME) thesis-final.tex + biber $(JOBNAME) + lualatex -interaction=nonstopmode -jobname=$(JOBNAME) thesis-final.tex + lualatex -interaction=nonstopmode -jobname=$(JOBNAME) thesis-final.tex + @if grep -q "^!" $(JOBNAME).log 2>/dev/null; then \ + echo "❌ LaTeX errors found:"; \ + grep "^!" $(JOBNAME).log; \ + exit 1; \ + else \ + echo "✅ Output: $(JOBNAME).pdf"; \ + fi + +bump: + @if [ ! -f $(VERSION_FILE) ]; then echo "1.0" > $(VERSION_FILE); fi + @NEW_VER=$$(awk 'BEGIN{printf "%.1f", '$(VERSION)'+0.1}'); \ + echo "$$NEW_VER" > $(VERSION_FILE); \ + echo "📌 Version: $(VERSION) → $$NEW_VER" + +clean: + latexmk -C + rm -f $(BASENAME)_v*.aux $(BASENAME)_v*.bbl $(BASENAME)_v*.bcf \ + $(BASENAME)_v*.blg $(BASENAME)_v*.log $(BASENAME)_v*.out \ + $(BASENAME)_v*.run.xml $(BASENAME)_v*.lof $(BASENAME)_v*.lot \ + $(BASENAME)_v*.toc $(BASENAME)_v*.pdf \ No newline at end of file diff --git a/docs/BT/CTU_FEL_THESIS/README.md b/docs/BT/CTU_FEL_THESIS/README.md new file mode 100644 index 0000000..7148218 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/README.md @@ -0,0 +1,98 @@ +# CTU/FEL Thesis Template (LuaLaTeX) + +This folder is the canonical LaTeX thesis template for this repo. + +## What to compile + +- Main entry (use this): `thesis-final.tex` +- Template class (layout + title pages): `bachelorthesis.cls` + +Chapters live in `chapters/` and are included from `thesis-final.tex`. + +## Build (local) + +This template uses **LuaLaTeX + biblatex/biber**. + +From this folder: + +```bash +lualatex thesis-final.tex +biber thesis-final +lualatex thesis-final.tex +lualatex thesis-final.tex +``` + +If you use `latexmk` (recommended), `latexmkrc` is provided: + +```bash +latexmk -lualatex thesis-final.tex +``` + +Tip: `latexmkrc` sets a default main file, so in this folder you can also just run: + +```bash +latexmk -lualatex +``` + +## Draft vs print layout + +Default is **draft-friendly oneside** (no left/right margin swapping). + +For final double-sided printing with binding margins, change the first line of `thesis-final.tex` to: + +```tex +\documentclass[print]{bachelorthesis} +``` + +## Acronyms / glossary + +- Acronyms are defined in `acronyms.tex`. +- The template uses **no-index glossaries**, so you do **not** need `makeglossaries`. +- Add an acronym via `\newacronym{...}{...}{...}` and use it in text with `\gls{...}`. + +## Overleaf + +1) Upload this folder as a project. +2) Set **Main file** to `thesis-final.tex`. +3) Set **Compiler** to **LuaLaTeX**. +4) Set **Bibliography** to **Biber**. + +If you see errors like `output.bbl not found`, `Empty bibliography`, or many `Citation '...' undefined`, it usually means **biber did not run**. Use “Recompile from scratch”. + +## Clean + +If you use `latexmk`: + +```bash +latexmk -c # keep PDF +latexmk -C # remove PDF too +``` + +If your build artifacts are named `output.*` (common when compiling with `-jobname=output`, as Overleaf sometimes does), clean them explicitly: + +```bash +latexmk -C -jobname=output thesis-final.tex +``` + +If you accidentally created `acronyms.*` artifacts by running latexmk on `acronyms.tex`, clean them explicitly: + +```bash +latexmk -C acronyms.tex +``` + +Or manual: + +```bash +rm -f *.aux *.bbl *.bcf *.blg *.run.xml *.toc *.lof *.lot *.out *.log \ + *.fls *.fdb_latexmk *.synctex.gz + +# If you also have Overleaf-style artifacts: +rm -f output.* +``` + +## Notes + +- Some Czech words remain where they are official names. +- Logo/image assets are optional; missing assets should not break compilation. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/acronyms.tex b/docs/BT/CTU_FEL_THESIS/acronyms.tex new file mode 100644 index 0000000..cf0583f --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/acronyms.tex @@ -0,0 +1,66 @@ +% ============================================================================ +% Acronyms / Abbreviations for Bachelor Thesis +% Domain-specific technical terms only (common terms like CPU, RAM, LED omitted) +% ============================================================================ + +% --- Communication Protocols --- +\newacronym{mqtt}{MQTT}{Message Queuing Telemetry Transport} +\newacronym{ble}{BLE}{Bluetooth Low Energy} + +% --- Security and Cryptography --- +\newacronym{tls}{TLS}{Transport Layer Security} +\newacronym{mtls}{mTLS}{mutual Transport Layer Security} +\newacronym{ecc}{ECC}{Elliptic Curve Cryptography} +\newacronym{rsa}{RSA}{Rivest--Shamir--Adleman} +\newacronym{ecdh}{ECDH}{Elliptic Curve Diffie--Hellman} +\newacronym{ecdhe}{ECDHE}{Elliptic Curve Diffie--Hellman Ephemeral} +\newacronym{ecdsa}{ECDSA}{Elliptic Curve Digital Signature Algorithm} +\newacronym{eddsa}{EdDSA}{Edwards-curve Digital Signature Algorithm} +\newacronym{ca}{CA}{Certificate Authority} +\newacronym{acl}{ACL}{Access Control List} +\newacronym{crl}{CRL}{Certificate Revocation List} +\newacronym{csr}{CSR}{Certificate Signing Request} +\newacronym{ztna}{ZTNA}{Zero Trust Network Access} + +% --- IoT and Smart Home --- +\newacronym{iot}{IoT}{Internet of Things} +\newacronym{ha}{HA}{Home Assistant} +\newacronym{haos}{HAOS}{Home Assistant Operating System} +\newacronym{hacs}{HACS}{Home Assistant Community Store} +\newacronym{ota}{OTA}{Over-The-Air} +\newacronym{lwt}{LWT}{Last Will and Testament} +\newacronym{emqx}{EMQX}{Erlang MQTT Broker} + +% --- Hardware Interfaces --- +\newacronym{pir}{PIR}{Passive Infrared} +\newacronym{adc}{ADC}{Analog-to-Digital Converter} +\newacronym{pwm}{PWM}{Pulse Width Modulation} +\newacronym{gpio}{GPIO}{General Purpose Input/Output} +\newacronym{i2c}{I2C}{Inter-Integrated Circuit} +\newacronym{mems}{MEMS}{Micro-Electro-Mechanical Systems} +\newacronym{nvs}{NVS}{Non-Volatile Storage} + +% --- Embedded Systems --- +\newacronym{mcu}{MCU}{Microcontroller Unit} +\newacronym{dram}{DRAM}{Dynamic Random Access Memory} +\newacronym{iram}{IRAM}{Instruction Random Access Memory} +\newacronym{espidf}{ESP-IDF}{Espressif IoT Development Framework} +\newacronym{espnn}{ESP-NN}{Espressif Neural Network Library} + +% --- Machine Learning --- +\newacronym{tflite}{TFLite}{TensorFlow Lite} +\newacronym{cnn}{CNN}{Convolutional Neural Network} +\newacronym{smv}{SMV}{Signal Magnitude Vector} + +% --- Network Performance --- +\newacronym{qos}{QoS}{Quality of Service} +\newacronym{rtt}{RTT}{Round-Trip Time} +\newacronym{bbr}{BBR}{Bottleneck Bandwidth and Round-trip propagation time} +\newacronym{fq}{FQ}{Fair Queueing} + +% --- Virtualization --- +\newacronym{vps}{VPS}{Virtual Private Server} +\newacronym{vcpu}{vCPU}{virtual Central Processing Unit} +\newacronym{esxi}{ESXi}{Elastic Sky X integrated} + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/bachelorthesis.cls b/docs/BT/CTU_FEL_THESIS/bachelorthesis.cls new file mode 100644 index 0000000..88fe8ea --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/bachelorthesis.cls @@ -0,0 +1,314 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{bachelorthesis}[2025/10/02 v4.2 (Bachelor variant, LuaLaTeX-ready)] + +\RequirePackage{iftex} + +\newif\if@literature \@literaturefalse +\DeclareOption{literature}{\@literaturetrue} + +\newif\if@statement \@statementfalse +\DeclareOption{statement}{\@statementtrue} + +\newif\if@print \@printfalse +\DeclareOption{print}{\@printtrue} + +\newif\if@bibtexbackend \@bibtexbackendfalse +\DeclareOption{bibtex}{\@bibtexbackendtrue} +\DeclareOption{biber}{\@bibtexbackendfalse} + +\ProcessOptions\relax + +% Page layout depends on whether this is a statement or the full thesis +\if@statement + \LoadClass[twoside,a4paper,11pt]{article} + \RequirePackage[margin=2cm, bottom=2.5cm, top=2cm, right=2cm]{geometry} + + % Delimiter between front and main matter + \newcommand{\mainmatter}{ + \newpage + \pagenumbering{arabic} + } +\else + % For on-screen drafts, a constant left/right margin is often preferred. + % Use `\documentclass[print]{bachelorthesis}` for final double-sided printing. + \if@print + \LoadClass[11pt,twoside,a4paper]{book} + % Inner margin for binding, slightly smaller outer margin. + \RequirePackage[inner=3cm,outer=2cm,top=3cm,bottom=2cm]{geometry} + \else + \LoadClass[11pt,oneside,a4paper]{book} + % Constant margins for PDF reading. + \RequirePackage[margin=2cm,left=3cm,top=3cm,bottom=2cm]{geometry} + \fi +\fi + +\RequirePackage{graphicx} +\RequirePackage{tabularx} + +% LuaLaTeX/XeLaTeX: native UTF-8 + font handling +\ifPDFTeX + % pdfTeX users should load inputenc/fontenc in the document preamble if needed. +\else + \RequirePackage{fontspec} + \defaultfontfeatures{Ligatures=TeX} +\fi + +\RequirePackage{microtype} + +% Institution defaults +\newcommand\University{Czech Technical University in Prague} +\newcommand\Faculty{Faculty of Electrical Engineering} +\newcommand\Department{Department of Microelectronics} + +% Thesis metadata (defaults can be overridden in the document) +\newcommand\ThesisType{Thesis} +\newcommand\StudyProgram{Electrical Engineering and Computer Science} +\newcommand\StudyBranch{Electrical Engineering and Computer Science} + +% Used on statement pages +\newcommand\Address{Technick{\'a}~2, 160 00 Prague 6, Czech Republic} + +% User overrides +\newcommand{\university}[1]{\renewcommand\University{#1}} +\newcommand{\faculty}[1]{\renewcommand\Faculty{#1}} +\newcommand{\department}[1]{\renewcommand\Department{#1}} +\newcommand{\thesistype}[1]{\renewcommand\ThesisType{#1}} +\newcommand{\studyprogram}[1]{\renewcommand\StudyProgram{#1}} +\newcommand{\studybranch}[1]{\renewcommand\StudyBranch{#1}} + +% Supervisor/affiliation metadata +\def \@supervisor{Unknown} +\newcommand{\supervisor}[1]{\def\@supervisor{#1}} + +\def \@authorAffiliation{Unknown} +\newcommand{\authorAffiliation}[1]{\def\@authorAffiliation{#1}} + +\def \@supervisorAffiliation{Unknown} +\newcommand{\supervisorAffiliation}[1]{\def\@supervisorAffiliation{#1}} + +% Default value; usually overridden in the main document. +\def \@placeyear{Prague 2026} +\newcommand{\placeyear}[1]{\def\@placeyear{#1}} + +% Convenience references +\newcommand{\figref}[1]{\figurename~\ref{#1}} +\newcommand{\tabref}[1]{Table~\ref{#1}} +\newcommand{\secref}[1]{Section~\ref{#1}} + +% Title pages +\renewcommand\maketitle{\par + % Pick the appropriate title page variant + \if@literature + \@literaturetitle + \else + \if@statement + \@statementtitle + \else + \@fullthesis + \fi + \fi + + \global\let\thanks\relax + \global\let\maketitle\relax + \global\let\@maketitle\relax + \global\let\@thanks\@empty + \global\let\@author\@empty + \global\let\@date\@empty + \global\let\@title\@empty + \global\let\title\relax + \global\let\author\relax + \global\let\date\relax + \global\let\and\relax +} + +% Title page: full thesis +\def\@fullthesis{% + \frontmatter + \begin{center} + {\LARGE\bfseries + \University}\\[3mm] + {\Large\sffamily + \Faculty}\\[2mm] + {\large\sffamily + \Department}\\[15mm] + \IfFileExists{images/LogoCVUT.pdf}{\includegraphics[width=60mm]{images/LogoCVUT}}{} + \vspace{20mm} + + {\LARGE\bfseries\@title}\\[8mm] + {\Large\sffamily \ThesisType}\\[10mm] + {\Large\emph{\@author}}\\[45mm] + {\large + Study program: \StudyProgram\\[3mm] + Supervisor: \@supervisor\\ + } + \vfill + \@placeyear\\ + \end{center} + \thispagestyle{empty} + + % Page 2 + \newpage + \rule{0pt}{0pt} + \vfill + \begin{description} + \item[Thesis Supervisor:] ~\\ + \@supervisor\\ + \@supervisorAffiliation + \end{description} + Copyright {\copyright} {\@date} {\@author} + + % Declaration removed - use separate declaration.tex file with CTU-required wording +} + +% Title page: statement +\def\@statementtitle{% + \pagenumbering{Roman} + \begin{center} + {\LARGE\sffamily + \University\\ + \Faculty\\ + \Department\\ + \vspace{50mm} + \IfFileExists{images/LogoCVUT.pdf}{\includegraphics[width=130mm]{images/LogoCVUT}}{} + \vfill + {\LARGE\bfseries \MakeUppercase{\ThesisType} STATEMENT} + } + \end{center} + \thispagestyle{empty} + + % Page 2 + \newpage + \if@print + ~\thispagestyle{empty} + \newpage + \fi + + \begin{center} + {\Large\sffamily + \University\\ + \Faculty\\ + \Department + \vfill + + {\sffamily\bfseries\@title}\\ + \bigskip + by\\ + \bigskip + {\large\emph{\@author}}\\ + \vfill + + {\large + Study program: \StudyProgram\\ + Field of study: \StudyBranch + }\\ + + \vspace{1cm} + Thesis statement document + \vspace{1cm} + \@placeyear + } + \end{center} + \thispagestyle{empty} + + \frontmatter + \newpage + + % Page 3 - author and supervisor + \pagenumbering{roman} + + {\small + \noindent The thesis was written at the \Department, \Faculty of the Czech Technical University in Prague. + + \vspace{.5cm} + \noindent\hbox to 3cm{\hbox{Author:}\hss}\parbox[t]{8cm}{ + \textbf{\@author}\\ + \@authorAffiliation} + + \vspace{.5cm} + \noindent\hbox to 3cm{\hbox{Supervisor:}\hss}\parbox[t]{8cm}{% + \textbf{\@supervisor}\\ + \@supervisorAffiliation} + + \vspace{1cm} + \noindent\hbox to 3cm{\hbox{Reviewers:}\hss}\parbox[t]{8cm}{% + \vrule width 5cm height 0pt depth 0.5pt\\[.5cm] + \vrule width 5cm height 0pt depth 0.5pt\\[.5cm] + \vrule width 5cm height 0pt depth 0.5pt + } + + \bigskip\bigskip + \noindent This thesis statement was distributed on ................ + + \bigskip + \noindent The defence of the thesis will be held on ............................ at .......................... in the meeting room No. ............... . + + \bigskip + \noindent Those interested may get acquainted with the thesis at the Dean Office of the Faculty of Electrical Engineering of the CTU in Prague, at the Department for Science and Research, \Address. + + \vfill + \begin{center} + \bigskip\bigskip + ............................................................................\\ + \medskip + Chairman of the Board for the Defence of the Thesis\\ + \Department\\ + \Faculty\\ + \University\\ + \Address + \end{center} + } + \newpage +} + +\def\@literaturetitle{% + \begin{center} + {\Large\sffamily + \University\\ + \Faculty\\ + \Department\\ + \vspace{30mm} + \IfFileExists{images/LogoCVUT.pdf}{\includegraphics[width=50mm]{images/LogoCVUT}}{} + \vspace{20mm} + {\Large\bfseries LIST OF PERSONAL PUBLICATIONS} + \vspace{30mm} + \textit{\@author} + \vspace{10mm} + \@placeyear + \vfill + {\footnotesize Automatically generated list} + } + \end{center} + \thispagestyle{empty} + + % Page 2 + \newpage + \pagenumbering{arabic} +} + +% Biblatex (fullcite helper) +\if@bibtexbackend + \RequirePackage[style=ieee,backend=bibtex]{biblatex} +\else + \RequirePackage[style=ieee,backend=biber]{biblatex} +\fi +\DeclareBibliographyCategory{fullcited} +\newcommand{\bibentry}[1]{\fullcite{#1}\addtocategory{fullcited}{#1}} + +\RequirePackage[nottoc]{tocbibind} +\RequirePackage{setspace} + +% Hyperlinks: keep link styling subtle +\RequirePackage{xcolor} +\RequirePackage{hyperref} +\hypersetup{colorlinks=true,citecolor=black,linkcolor=black,urlcolor=black} + +% PDF metadata +\makeatletter +\AtBeginDocument{% + \hypersetup{% + pdftitle={\@title}, + pdfauthor={\@author}, + pdfsubject={\ThesisType}, + }% +} +\makeatother diff --git a/docs/BT/CTU_FEL_THESIS/chapters/Declaration.pdf b/docs/BT/CTU_FEL_THESIS/chapters/Declaration.pdf new file mode 100644 index 0000000..fcae020 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/chapters/Declaration.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/chapters/abstract.tex b/docs/BT/CTU_FEL_THESIS/chapters/abstract.tex new file mode 100644 index 0000000..97b7839 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/abstract.tex @@ -0,0 +1,33 @@ +\chapter*{Abstract} +\addcontentsline{toc}{chapter}{Abstract} + +This thesis investigates the use of server-based architectures and Unix-like operating systems for sensor monitoring and control in smart home environments. The objective is to demonstrate how an open-source, self-hosted system can provide secure, scalable, and transparent management of distributed sensor devices without reliance on proprietary cloud services. + +The proposed system integrates physical sensor nodes based on ESP32 and ESP32-S3 microcontrollers—the latter implementing edge computing algorithms for real-time fall detection—with a Python-based sensor simulator used to emulate a large number of devices for scalability testing. Communication between IoT components is primarily realized using the MQTT protocol with mutual Transport Layer Security (mTLS), complemented by native API integrations within the Home Assistant platform for device management and automation. An EMQX broker deployed on a remote server acts as the central messaging component. Home Assistant serves as the control and visualization layer and is deployed using the official Home Assistant Operating System (HAOS), a Linux-based environment, running as a virtual machine on an ESXi hypervisor. + +Security is implemented using elliptic curve cryptography (ECC) certificates, with emphasis on practical deployment on resource-constrained IoT devices and on leveraging hardware features available on the ESP32-S3 platform. Basic experimental measurements are performed to observe connection establishment characteristics and message delivery behavior under load. + +Scalability experiments demonstrate that the proposed architecture is capable of handling over 1,000 concurrent device connections under realistic conditions, with the design supporting larger deployments. A qualitative comparison with selected commercial smart home platforms highlights trade-offs between ease of deployment, flexibility, and data sovereignty. The results indicate that Unix-based, open-source solutions represent a viable alternative for smart home sensor control, particularly in scenarios requiring customization and full control over data processing. + +\vspace{5mm} +\noindent\textbf{Keywords:} smart home, IoT, MQTT, mTLS, ECC, ECDSA, X25519, ESPHome, Home Assistant, ESP32-S3, edge computing, fall detection + +% ============================================================================ +\newpage +\chapter*{Abstrakt} +\addcontentsline{toc}{chapter}{Abstrakt} + +Tato bakalářská práce se zabývá využitím serverově orientované architektury a operačních systémů typu Unix pro monitoring a řízení senzorů v prostředí chytré domácnosti. Cílem je ukázat, že open-source řešení s vlastním hostingem (self-hosted) může zajistit bezpečnou, škálovatelnou a transparentní správu distribuovaných senzorových zařízení bez závislosti na proprietárních cloudových službách. + +Navržený systém kombinuje fyzické uzly postavené na mikrokontrolérech ESP32 a ESP32-S3—přičemž druhý jmenovaný implementuje algoritmy edge computingu pro detekci pádu v reálném čase—s Python simulátorem senzorů, který umožňuje emulovat velké množství zařízení pro účely ověření škálovatelnosti. Komunikace mezi IoT komponentami je primárně realizována pomocí protokolu MQTT s oboustranným zabezpečením Transport Layer Security (mTLS), doplněná o nativní API integrace v rámci platformy Home Assistant určené pro správu zařízení a automatizaci. Centrálním prvkem messagingu je broker EMQX nasazený na vzdáleném serveru. Home Assistant plní roli řídicí a vizualizační vrstvy a je provozován jako oficiální Home Assistant Operating System (HAOS), založený na Linuxu, ve virtuálním stroji na hypervizoru ESXi. + +Bezpečnost je zajištěna certifikáty využívajícími eliptickou kryptografii (ECC) s důrazem na praktickou implementaci v IoT zařízeních s omezenými zdroji a na využití hardwarových vlastností platformy ESP32-S3. Jsou provedeny základní experimenty zaměřené na charakteristiky navazování spojení a chování doručování zpráv při zátěži. + +Experimenty škálovatelnosti ukazují, že navržená architektura je za realistických podmínek schopna obsloužit více než 1000 současně připojených zařízení, přičemž návrh podporuje i větší nasazení. Kvalitativní srovnání s vybranými komerčními platformami chytré domácnosti zdůrazňuje kompromisy mezi jednoduchostí nasazení, flexibilitou a suverenitou dat. Výsledky naznačují, že unixová open-source řešení představují životaschopnou alternativu pro řízení senzorů v chytré domácnosti, zejména v případech vyžadujících přizpůsobení a plnou kontrolu nad zpracováním dat. + +\vspace{5mm} +\noindent\textbf{Klíčová slova:} chytrá domácnost, IoT, MQTT, mTLS, ECC, ECDSA, X25519, ESPHome, Home Assistant, ESP32-S3, edge computing, detekce pádu + +% ============================================================================ +\newpage +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/acknowledgements.tex b/docs/BT/CTU_FEL_THESIS/chapters/acknowledgements.tex new file mode 100644 index 0000000..d87f916 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/acknowledgements.tex @@ -0,0 +1,12 @@ +\chapter*{Acknowledgements} +\addcontentsline{toc}{chapter}{Acknowledgements} + +I would like to express my sincere gratitude to my supervisor, Prof.~Ing.~Miroslav Hus{\'a}k, CSc., for the initial discussions that helped shape the topic and scope of this thesis, as well as for his valuable high-level guidance. + +I would also like to acknowledge the Faculty of Electrical Engineering and the Czech Technical University as a whole for providing an academic environment in which I was able to develop not only foundational theoretical knowledge and practical skills, but also the ability to think independently, adapt, and grow---competencies essential for future professional development and for functioning in society. + +Finally, I am deeply grateful to my family for their patience, encouragement, and rock-solid support throughout my studies and my life. Their support has been a constant source of strength and motivation, without which this work would not have been possible. + +\newpage + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/appendix.tex b/docs/BT/CTU_FEL_THESIS/chapters/appendix.tex new file mode 100644 index 0000000..ce86e00 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/appendix.tex @@ -0,0 +1,927 @@ +% ============================================================================ +% APPENDIX - Reorganized +% ============================================================================ +% Order follows the three-layer network architecture for logical flow: +% 1. Certificate Generation (Security Infrastructure) +% 2. Home Assistant Reference (Controller Layer) +% 3. ESPHome Configuration (Sensor Layer) +% 4. EMQX Broker Deployment (Communication Layer) +% 5. Python Simulator (Testing Tools) +% 6. Simulator Output (Testing Results) +% 7. Scalability Screenshots (Evaluation Data) +% ============================================================================ + +\noindent\textbf{Source Code Availability:} The complete source code, configuration files, and documentation for this thesis project are available at: +\begin{center} +\url{https://github.com/yuanweize/SmartHome_Server} +\end{center} +\noindent The GitHub repository may be updated with additional documentation and improvements; feedback and suggestions are welcome. +\noindent A snapshot of the repository at the time of submission (06-01-2026) is also attached to this thesis in the CTU DSpace archive system\footnote{\url{https://dspace.cvut.cz/}}. + +% ============================================================================ +\chapter{Certificate Generation} +\label{app:certs} + +This appendix documents the certificate generation procedure used to establish the mutual TLS (mTLS) authentication implemented in this thesis. The system utilizes \textbf{ECDSA with NIST P-256} (\texttt{prime256v1}) for certificate signatures, as this algorithm is fully supported by the ESP-IDF's Mbed~TLS implementation for X.509 certificate parsing and verification~\cite{esp_tls_2024}. During TLS~1.3 handshake, \textbf{X25519} is automatically negotiated for ephemeral key exchange when supported by both endpoints. + +All certificates are organized in subdirectories: \texttt{ca/}, \texttt{server/}, \texttt{client/}, and \texttt{ha/}. + +\section{Certificate Authority (Root CA)} +\label{app:ca-gen} + +The Root CA is self-signed and valid for 10 years (3650 days). + +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Create directory structure +mkdir -p ca server client ha + +# Generate CA private key (ECDSA P-256) +openssl ecparam -name prime256v1 -genkey -noout -out ca/ca.key + +# Generate self-signed CA certificate +openssl req -new -x509 -sha256 -days 3650 \ + -key ca/ca.key -out ca/ca.pem \ + -subj "/CN=SmartHome Root CA/O=CTU FEL/C=CZ" +\end{lstlisting} + + +\section{Server Certificate (EMQX Broker)} +\label{app:server-cert} + +The server certificate is signed by the Root CA, valid for 5 years (1825 days). The Common Name (\texttt{CN}) must match the actual MQTT broker domain name. + +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Generate server private key (ECDSA P-256) +openssl ecparam -name prime256v1 -genkey -noout -out server/server.key + +# Generate Certificate Signing Request (CSR) +openssl req -new -key server/server.key -out server/server.csr \ + -subj "/CN=mqtt.example.com/O=SmartHome/OU=Broker" + +# Sign server certificate with CA +openssl x509 -req -sha256 -days 1825 \ + -in server/server.csr \ + -CA ca/ca.pem -CAkey ca/ca.key -CAcreateserial \ + -out server/server.pem +\end{lstlisting} + + +\section{Client Certificate (IoT Devices)} +\label{app:client-cert} + +The client certificate for ESP32 devices is signed by the Root CA and valid for 1 year (365 days). A unique \texttt{CN} per device is recommended for device identification. + +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Generate client private key (ECDSA P-256) +openssl ecparam -name prime256v1 -genkey -noout -out client/client.key + +# Generate CSR +openssl req -new -key client/client.key -out client/client.csr \ + -subj "/CN=esp-client/O=SmartHome/OU=Sensors" + +# Sign client certificate with CA +openssl x509 -req -sha256 -days 365 \ + -in client/client.csr \ + -CA ca/ca.pem -CAkey ca/ca.key -CAcreateserial \ + -out client/client.pem +\end{lstlisting} + + +\section{Home Assistant Client Certificate} +\label{app:ha-cert} + +The Home Assistant controller requires a separate client certificate for mTLS authentication with the MQTT broker. This certificate is valid for 5 years (1825 days) to match the server certificate lifecycle. + +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Generate HA client private key (ECDSA P-256) +openssl ecparam -name prime256v1 -genkey -noout -out ha/ha.key + +# Generate CSR +openssl req -new -key ha/ha.key -out ha/ha.csr \ + -subj "/CN=homeassistant/O=SmartHome/OU=Controller" + +# Sign HA client certificate with CA +openssl x509 -req -sha256 -days 1825 \ + -in ha/ha.csr \ + -CA ca/ca.pem -CAkey ca/ca.key -CAcreateserial \ + -out ha/ha.pem +\end{lstlisting} + +% ============================================================================ + +\chapter{Home Assistant Reference} +\label{app:homeassistant} + +Home Assistant is the open-source home automation platform used as the central controller in this thesis. This appendix provides essential reference information for reproducing the experimental setup. + +\section{Official Resources} +\label{app:ha-resources} + +\begin{itemize} + \item \textbf{Official Website:} \url{https://www.home-assistant.io/} + \item \textbf{Installation Guide:} \url{https://www.home-assistant.io/installation/} + \item \textbf{MQTT Integration:} \url{https://www.home-assistant.io/integrations/mqtt/} + \item \textbf{MQTT Discovery:} \url{https://www.home-assistant.io/integrations/mqtt/#mqtt-discovery} + \item \textbf{GitHub Repository:} \url{https://github.com/home-assistant/core} +\end{itemize} + +\section{Deployment Method} +\label{app:ha-deployment} + +This thesis deploys \textbf{Home Assistant Operating System (HAOS) 16.3} as a virtual machine on VMware ESXi 8.0.0, using the official OVA appliance image\footnote{\url{https://github.com/home-assistant/operating-system/releases/download/16.3/haos_ova-16.3.ova}}. Unlike Home Assistant Container (Docker), HAOS provides native support for Supervisor and Add-ons such as Node-RED for visual automation workflows, file editors, and integrated backup management. + +The installation follows the official alternative installation guide\footnote{\url{https://www.home-assistant.io/installation/alternative/}}, which recommends minimum resources of 2~GB RAM, 32~GB storage, and 2~vCPUs. The deployment in this thesis exceeds these requirements to accommodate additional Add-ons. + +\subsection{Host Server Specifications} +The ESXi hypervisor runs on the following hardware: +\begin{itemize} + \item \textbf{CPU:} Intel Core i5-1135G7 @ 2.40~GHz (4 cores, 11th Gen Tiger Lake) + \item \textbf{Memory:} 31.75~GB DDR4 + \item \textbf{Storage:} 913.75~GB VMFS6 datastore (689.67~GB used) + \item \textbf{ESXi Version:} 8.0.0 (Build 20513097, standalone) + \item \textbf{Install Date:} February 12, 2023 +\end{itemize} + +\subsection{HAOS Virtual Machine Configuration} +The Home Assistant VM was deployed by importing the official \texttt{haos\_ova-16.3.ova} appliance directly into ESXi. The VM is configured with resources exceeding the minimum requirements (2~vCPU, 2~GB RAM, 32~GB storage) to support additional Add-ons: +\begin{itemize} + \item \textbf{Guest OS:} Other (64-bit) + \item \textbf{VM Compatibility:} ESXi 5.5 virtual machine + \item \textbf{VMware Tools:} Installed (open-vm-tools) + \item \textbf{vCPUs:} 4 + \item \textbf{Memory:} 4~GB + \item \textbf{Hostname:} \texttt{homeassistant} + \item \textbf{Network:} Bridged adapter (DHCP) +\end{itemize} + +Figure~\ref{fig:haos-esxi} shows the ESXi management interface with the HAOS virtual machine configuration. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/haos_esxi.png}{% + \includegraphics[width=0.95\linewidth]{images/haos_esxi.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/haos\_esxi.png} + }}% +} +\caption{HAOS virtual machine running on VMware ESXi 8.0.0} +\label{fig:haos-esxi} +\end{figure} + +% ============================================================================ + +\chapter{ESPHome Configuration Files} +\label{app:esphome} + +This appendix contains the ESPHome configuration files used for the ESP32 sensor nodes. ESPHome generates optimized C++ firmware from YAML configurations and supports direct Home Assistant integration. + +\section{Secrets Configuration Template} +\label{app:esphome-secrets} + +Sensitive credentials are stored in a separate \texttt{secrets.yaml} file (excluded from version control). The following template shows the required fields: + +\begin{lstlisting}[language=yaml,basicstyle=\small\ttfamily,breaklines=true] +# esphome/secrets.example.yaml +# Copy to secrets.yaml and fill in actual values + +# Wi-Fi credentials +wifi_ssid: "YOUR_WIFI_SSID" +wifi_password: "YOUR_WIFI_PASSWORD" + +# OTA update password +ota_password: "CHANGE_ME" + +# Native API encryption keys (32-byte base64) +api_key_esp32s3: "CHANGE_ME_BASE64" +api_key_esp32: "CHANGE_ME_BASE64" + +# MQTT broker (mTLS) +mqtt_broker: "mqtt.example.com" +mqtt_port: 8883 + +# TLS certificates (PEM format, use |- for multiline) +mqtt_ca_cert: |- + -----BEGIN CERTIFICATE----- + ... (CA certificate content) + -----END CERTIFICATE----- +mqtt_client_cert: |- + -----BEGIN CERTIFICATE----- + ... (Client certificate content) + -----END CERTIFICATE----- +mqtt_client_key: |- + -----BEGIN PRIVATE KEY----- + ... (Client private key content) + -----END PRIVATE KEY----- +\end{lstlisting} + +\section{ESP32-S3 Edge Intelligence Node} +\label{app:esp32s3-config} + +The ESP32-S3 node (Node~A) implements edge computing for fall detection using MPU6050 IMU data. Key features include TLS~1.3 support, 10Hz sensor sampling with 1Hz MQTT reporting, and dual-threshold fall detection algorithm. + +\begin{lstlisting}[language=yaml,basicstyle=\small\ttfamily,breaklines=true] +# esphome/esp32s3.yaml (excerpt) +esphome: + name: smarthome-esp32s3 + friendly_name: "Edge Compute Node ESP32-S3 (Node A)" + +esp32: + board: esp32-s3-devkitc-1 + framework: + type: esp-idf + sdkconfig_options: + # Certificate signatures: ECDSA P-256 + CONFIG_MBEDTLS_ECP_DP_SECP256R1_ENABLED: "y" + CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED: "y" + CONFIG_MBEDTLS_ECDSA_DETERMINISTIC: "y" + # Key exchange: X25519 + CONFIG_MBEDTLS_ECP_DP_CURVE25519_ENABLED: "y" + CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED: "y" + # TLS 1.3 (prioritizes X25519 by default) + CONFIG_MBEDTLS_SSL_PROTO_TLS1_3: "y" + +ota: + - platform: esphome + password: !secret ota_password + +api: + encryption: + key: !secret api_key_esp32s3 + +wifi: + ssid: !secret wifi_ssid + password: !secret wifi_password + fast_connect: true + +mqtt: + broker: !secret mqtt_broker + port: !secret mqtt_port + certificate_authority: !secret mqtt_ca_cert + client_certificate: !secret mqtt_client_cert + client_certificate_key: !secret mqtt_client_key + +logger: + hardware_uart: USB_CDC + +globals: + - id: fall_detected_time + type: unsigned long + restore_value: no + initial_value: '0' + +i2c: + sda: GPIO5 + scl: GPIO4 + scan: true + id: bus_a + +sensor: + - platform: wifi_signal + name: "WiFi RSSI" + update_interval: 10s + + - platform: uptime + name: "System Uptime" + + # MPU6050 IMU with calibration offsets + - platform: mpu6050 + i2c_id: bus_a + address: 0x68 + accel_x: + name: "Acceleration X" + id: acc_x + filters: + - offset: -0.877 + - throttle: 0.3s + accel_y: + name: "Acceleration Y" + id: acc_y + filters: + - offset: -0.145 + - throttle: 0.3s + accel_z: + name: "Acceleration Z" + id: acc_z + filters: + - offset: -0.564 + - throttle: 0.3s + gyro_x: + name: "Angular Velocity X" + id: gyro_x + filters: + - offset: 2.53 + - throttle: 0.3s + gyro_y: + name: "Angular Velocity Y" + id: gyro_y + filters: + - offset: -2.68 + - throttle: 0.3s + gyro_z: + name: "Angular Velocity Z" + id: gyro_z + filters: + - offset: 2.44 + - throttle: 0.3s + update_interval: 0.1s # 10Hz internal sampling + + - platform: bmp085 + i2c_id: bus_a + address: 0x77 + temperature: { name: "Indoor Temperature" } + pressure: { name: "Indoor Pressure" } + update_interval: 5s + + # Edge computing: G-force calculation + - platform: template + name: "Resultant G-Force" + unit_of_measurement: "G" + update_interval: 0.1s + filters: + - throttle: 0.3s + lambda: |- + float ax = id(acc_x).state; + float ay = id(acc_y).state; + float az = id(acc_z).state; + if (isnan(ax) || (ax==0 && ay==0 && az==0)) return 0.0; + return sqrt(ax*ax + ay*ay + az*az) / 9.80665; + + # Angular velocity magnitude for fall detection + - platform: template + name: "Angular Velocity Magnitude" + unit_of_measurement: "deg/s" + id: omega_mag + update_interval: 0.1s + filters: + - throttle: 0.3s + lambda: |- + float wx = id(gyro_x).state; + float wy = id(gyro_y).state; + float wz = id(gyro_z).state; + if (isnan(wx)) return 0.0; + return sqrt(wx*wx + wy*wy + wz*wz); + +binary_sensor: + # Fall detection: dual-threshold algorithm (Huynh et al. 2015) + - platform: template + name: "Fall Detection Alert" + device_class: safety + id: fall_alert + lambda: |- + const float UFT_ACC = 2.4; // G threshold + const float UFT_GYRO = 240.0; // deg/s threshold + const unsigned long HOLD_MS = 5000; + float ax = id(acc_x).state; + float ay = id(acc_y).state; + float az = id(acc_z).state; + if (isnan(ax)) return id(fall_alert).state; + float smv = sqrt(ax*ax + ay*ay + az*az) / 9.80665; + float omega = id(omega_mag).state; + unsigned long now = millis(); + + if ((smv > UFT_ACC) && (omega > UFT_GYRO)) { + id(fall_detected_time) = now; + return true; + } + if (id(fall_detected_time) > 0 && + (now - id(fall_detected_time)) < HOLD_MS) { + return true; + } + return false; +\end{lstlisting} + +\subsection{ESP32-S3 Firmware Compilation Output} +\label{app:esp32s3-firmware} + +Figure~\ref{fig:esphome-s3-mem} shows the memory usage summary generated during firmware compilation for the ESP32-S3 node. The compiled firmware occupies approximately 1014~KB of flash storage, with RAM utilization at 11.78\% (38.5~KB of 327~KB available). The firmware image is transferred to the device via OTA update over WiFi, completing in approximately 4 seconds. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/esphome32s3_mem.png}{% + \includegraphics[width=0.95\linewidth]{images/esphome32s3_mem.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/esphome32s3\_mem.png} + }}% +} +\caption{ESPHome firmware compilation output for ESP32-S3 showing memory allocation summary: Flash code (751~KB), Flash data (167~KB), DRAM (99.5~KB), IRAM (16~KB), and OTA upload progress.} +\label{fig:esphome-s3-mem} +\end{figure} + +\subsection{ESP32-S3 Runtime Log} +\label{app:esp32s3-runtime} + +Figure~\ref{fig:esphome-s3-log} demonstrates the ESP32-S3 node operating in real-time, displaying sensor readings (accelerometer X/Y/Z axes, gyroscope data) and network connection details including WiFi SSID, BSSID, signal strength, and IP address assignment. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/esphomeS3.png}{% + \includegraphics[width=0.95\linewidth]{images/esphomeS3.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/esphomeS3.png} + }}% +} +\caption{ESP32-S3 runtime log showing sensor data reporting (MPU6050 accelerometer/gyroscope readings) and network connection status (WiFi SSID, MAC address, IP configuration).} +\label{fig:esphome-s3-log} +\end{figure} + +\section{ESP32 Environment Sensing Node} +\label{app:esp32-config} + +The ESP32 node (Node~B) focuses on environmental monitoring with TCS34725 color sensor, MQ-2 smoke detector, and SR602 motion sensor. Local automation rules trigger visual alerts via RGB LED. + +\begin{lstlisting}[language=yaml,basicstyle=\small\ttfamily,breaklines=true] +# esphome/esp32.yaml (excerpt) +esphome: + name: smarthome-esp32 + friendly_name: "Environment Node ESP32 (Node B)" + +esp32: + board: esp32doit-devkit-v1 + framework: + type: esp-idf + sdkconfig_options: + # Same TLS configuration as ESP32-S3 + CONFIG_MBEDTLS_ECP_DP_SECP256R1_ENABLED: "y" + CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED: "y" + CONFIG_MBEDTLS_ECDSA_DETERMINISTIC: "y" + CONFIG_MBEDTLS_ECP_DP_CURVE25519_ENABLED: "y" + CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED: "y" + CONFIG_MBEDTLS_SSL_PROTO_TLS1_3: "y" + +ota: + - platform: esphome + password: !secret ota_password + +api: + encryption: + key: !secret api_key_esp32 + +wifi: + ssid: !secret wifi_ssid + password: !secret wifi_password + fast_connect: true + +mqtt: + broker: !secret mqtt_broker + port: !secret mqtt_port + certificate_authority: !secret mqtt_ca_cert + client_certificate: !secret mqtt_client_cert + client_certificate_key: !secret mqtt_client_key + +i2c: + sda: GPIO33 + scl: GPIO32 + scan: true + id: bus_b + +switch: + - platform: gpio + pin: GPIO25 + name: "Color Sensor LED" + id: tcs_led + +sensor: + - platform: tcs34725 + i2c_id: bus_b + red_channel: { name: "RGB Red" } + green_channel: { name: "RGB Green" } + blue_channel: { name: "RGB Blue" } + illuminance: { name: "Ambient Lux" } + color_temperature: { name: "Color Temperature" } + gain: 4x + integration_time: 24ms + update_interval: 1s + + - platform: adc + pin: GPIO34 + name: "Smoke Concentration" + attenuation: 12db + update_interval: 0.2s + filters: + - sliding_window_moving_average: + window_size: 3 + send_every: 1 + - delta: 0.01 + # Local automation: smoke alert + on_value_range: + - above: 2.5 + then: + - light.turn_on: + id: status_light + red: 100% + green: 0% + blue: 0% + effect: "Pulse" + - below: 2.4 + then: + - light.turn_off: status_light + +binary_sensor: + - platform: gpio + pin: GPIO23 + name: "Motion Detected" + device_class: motion + on_press: + then: + - light.turn_on: + id: status_light + red: 30% + green: 50% + blue: 70% + on_release: + then: + - delay: 5s + - light.turn_off: status_light + +light: + - platform: rgb + name: "Status Indicator" + id: status_light + red: output_r + green: output_g + blue: output_b + effects: + - pulse: + name: "Pulse" + transition_length: 0.5s + update_interval: 0.5s + +output: + - platform: ledc + pin: GPIO26 + id: output_r + - platform: ledc + pin: GPIO27 + id: output_g + - platform: ledc + pin: GPIO14 + id: output_b +\end{lstlisting} + +% ============================================================================ + +\chapter{EMQX Docker Deployment} +\label{app:emqx-docker} + +This appendix provides the Docker Compose configuration used to deploy the EMQX broker with mTLS enabled on port 8883. + +When running high-scale experiments, the container may require an increased file descriptor limit (\texttt{ulimit -n}); a common default is 1024. The following Compose configuration raises \texttt{nofile} to support large numbers of concurrent connections. + +\begin{lstlisting}[language=yaml,basicstyle=\small\ttfamily,breaklines=true] +# broker/emqx/docker-compose.yml +services: + emqx: + image: emqx/emqx:latest + container_name: emqx + restart: always + + # Increase file descriptor limit for high concurrency + ulimits: + nofile: + soft: 65535 + hard: 65535 + + ports: + # Dashboard (localhost only for security) + - "127.0.0.1:18083:18083" + # MQTTS (TLS) + - "8883:8883" + + volumes: + - ./data:/opt/emqx/data + - ./log:/opt/emqx/log + - ./certs:/opt/emqx/certs + + environment: + # TLS Listener Configuration + EMQX_LISTENERS__SSL__DEFAULT__BIND: "8883" + EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__CACERTFILE: >- + /opt/emqx/certs/ca.pem + EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__CERTFILE: >- + /opt/emqx/certs/server.pem + EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__KEYFILE: >- + /opt/emqx/certs/server.key + + # mTLS Enforcement + EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__VERIFY: "verify_peer" + EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__FAIL_IF_NO_PEER_CERT: "true" + + # Disable anonymous access (recommended with mTLS) + EMQX_ALLOW_ANONYMOUS: "false" +\end{lstlisting} + +% ============================================================================ + +\chapter{Python Simulator Architecture} +\label{app:simulator} + +This appendix presents key excerpts from the Python sensor simulator. The complete source code is available in the project repository. For flowchart reference, see Figure~\ref{fig:simulator-flowchart}. + +\section{Environment Setup and Execution} +\label{app:sim-setup} + +The following commands demonstrate how to set up and run the simulator for reproducibility. Tested on Python 3.10+ (macOS/Linux). + +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Clone repository and navigate to sensors directory +git clone https://github.com/yuanweize/SmartHome_Server.git +cd SmartHome_Server/sensors + +# Create and activate Python virtual environment +python3 -m venv .venv +source .venv/bin/activate # Linux/macOS +# .venv\Scripts\activate # Windows + +# Install dependencies +pip install -r requirements.txt +# Required: paho-mqtt>=1.6,<2.0 PyYAML>=6.0 +# Optional: matplotlib (for handshake benchmark plots) + +# Copy and configure broker settings +cp brokers.example.yml brokers.yml +# Edit brokers.yml with actual broker host, TLS paths, etc. +\end{lstlisting} + +\noindent\textbf{Basic Usage:} +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# Dry-run test (no MQTT connection) +python sensor_simulator.py --config brokers.yml --dry-run + +# Connect with Home Assistant discovery enabled +python sensor_simulator.py --config brokers.yml --ha-discovery + +# Scalability test: 1000 devices, 4 parallel workers, QoS 0 +python sensor_simulator.py --config brokers.yml \ + --devices 1000 --workers 4 --qos 0 +\end{lstlisting} + +\noindent\textbf{Commands Used in Thesis Experiments:} +\begin{lstlisting}[language=bash,basicstyle=\small\ttfamily,breaklines=true] +# 100-device baseline test +python sensor_simulator.py --config brokers.yml \ + --devices 100 --workers 1 --qos 0 + +# 1000-device scalability test +python sensor_simulator.py --config brokers.yml \ + --devices 1000 --workers 2 --qos 0 + +# 5000-device stress test +python sensor_simulator.py --config brokers.yml \ + --devices 5000 --workers 3 --qos 0 + +# MQTT connection latency benchmark (includes TCP + TLS + MQTT CONNECT) +# Performs 200 connect/disconnect cycles with 3 warmup connections +python sensor_simulator.py --config brokers.yml \ + --handshake-samples 200 --handshake-out handshake_metrics \ + --handshake-only +\end{lstlisting} + +\section{Core Data Structures} +\label{app:data-structures} + +\begin{lstlisting}[language=Python,basicstyle=\small\ttfamily,breaklines=true] +# smarthome_sim/entities.py +@dataclass +class EntityDef: + """Entity definition from configuration.""" + id: str + kind: str # sensor | binary_sensor | switch | light + model: str # drift | uniform | sine | motion + interval: float = 5.0 + min: Optional[float] = None + max: Optional[float] = None + # ... additional fields omitted (name, unit, precision, etc.) + +# smarthome_sim/broker.py +@dataclass +class Broker: + """MQTT broker configuration with mTLS support.""" + host: str + port: int = 1883 + tls: bool = False + ca_file: Optional[str] = None # CA certificate path + cert_file: Optional[str] = None # Client certificate path + key_file: Optional[str] = None # Client private key path + # ... additional fields omitted (inline PEM, keepalive, etc.) +\end{lstlisting} + +\section{mTLS Connection (Excerpt)} +\label{app:mtls-flow} + +\begin{lstlisting}[language=Python,basicstyle=\small\ttfamily,breaklines=true] +# smarthome_sim/broker.py +def _configure_tls(self, client: mqtt.Client) -> None: + """Configure TLS/mTLS on the MQTT client.""" + # ... PEM materialization logic omitted ... + + client.tls_set( + ca_certs=ca_path, + certfile=cert_path, # Client cert for mTLS + keyfile=key_path, # Client key for mTLS + cert_reqs=ssl.CERT_REQUIRED, + tls_version=ssl.PROTOCOL_TLS_CLIENT, + ) +\end{lstlisting} + +\section{Simulation Loop (Excerpt)} +\label{app:sim-loop} + +\begin{lstlisting}[language=Python,basicstyle=\small\ttfamily,breaklines=true] +# smarthome_sim/simulator.py +def run(self) -> None: + """Main simulation loop using heap-based scheduler.""" + self._publish_discovery() # HA MQTT Discovery + + heap = [] # Priority queue: (next_time, device_id, entity_index) + # ... initialization omitted ... + + while not self._stop: + next_t, device_id, idx = heapq.heappop(heap) + time.sleep(max(0, next_t - time.monotonic())) + + self._step_entity(device_id, ...) # Update state + self._publish_state(device_id, ...) # Publish to MQTT + + heapq.heappush(heap, (time.monotonic() + interval, device_id, idx)) +\end{lstlisting} + +\section{Sensor Value Models (Excerpt)} +\label{app:value-gen} + +\begin{lstlisting}[language=Python,basicstyle=\small\ttfamily,breaklines=true] +# smarthome_sim/simulator.py - Supported generation models +if ent.model == "uniform": + value = random.uniform(min_v, max_v) +elif ent.model == "sine": + value = mid + amp * math.sin(2*math.pi*time.time()/period) +elif ent.model == "drift": # Random walk with bounds + value = current + random.gauss(0, 0.05) +elif ent.model == "motion": # Binary sensor with hold time + # ... motion event logic omitted ... +\end{lstlisting} + +% ============================================================================ + +\chapter{Simulator Terminal Output} +\label{app:simulator-terminal} + +This appendix provides a sample terminal output from the Python sensor simulator, demonstrating the connection establishment, discovery publishing, and message flow during operation. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/simpy.png}{% + \includegraphics[width=0.90\linewidth]{images/simpy.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/simpy.png} + }}% +} +\caption{Python sensor simulator terminal output showing configuration loading, mTLS connection establishment to the MQTT broker, Home Assistant discovery payload publishing, and periodic state updates for simulated sensor entities.} +\label{fig:simulator-terminal-output} +\end{figure} + +% ============================================================================ + +\chapter{Scalability Test Screenshots} +\label{app:scalability-screenshots} + +This appendix documents the scalability testing process described in Section~\ref{subsec:scalability}. Each test configuration was monitored for approximately 5 minutes to capture steady-state resource utilization across the EMQX broker, broker host system, and Home Assistant. + +% ---------------------------------------------------------------------------- +\section{Test Configuration: 100 Devices} +\label{app:scale-100} + +\begin{figure}[htbp] +\centering +\IfFileExists{images/broker_100_dash.png}{% + \includegraphics[width=0.85\linewidth]{images/broker_100_dash.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/broker\_100\_dash.png} + }}% +} +\caption{EMQX Dashboard during 100-device test showing connection count and message throughput.} +\label{fig:broker-100-dash} +\end{figure} + +\begin{figure}[htbp] +\centering +\IfFileExists{images/broker_100.png}{% + \includegraphics[width=0.85\linewidth]{images/broker_100.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/broker\_100.png} + }}% +} +\caption{Broker host system metrics during 100-device test showing CPU utilization at 3.72\%.} +\label{fig:broker-100-metrics} +\end{figure} + +\begin{figure}[htbp] +\centering +\IfFileExists{images/HAOS_100.png}{% + \includegraphics[width=0.85\linewidth]{images/HAOS_100.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/HAOS\_100.png} + }}% +} +\caption{Home Assistant OS \texttt{top} output during 100-device test showing CPU utilization at 1.1\%.} +\label{fig:haos-100} +\end{figure} + +% ---------------------------------------------------------------------------- +\section{Test Configuration: 1,000 Devices} +\label{app:scale-1000} + +\begin{figure}[htbp] +\centering +\IfFileExists{images/broker_1000_dash.png}{% + \includegraphics[width=0.85\linewidth]{images/broker_1000_dash.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/broker\_1000\_dash.png} + }}% +} +\caption{EMQX Dashboard during 1,000-device test showing $\sim$1,618 messages/sec throughput.} +\label{fig:broker-1000-dash} +\end{figure} + +\begin{figure}[htbp] +\centering +\IfFileExists{images/broker_1000.png}{% + \includegraphics[width=0.85\linewidth]{images/broker_1000.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/broker\_1000.png} + }}% +} +\caption{Broker host system metrics during 1,000-device test showing CPU utilization at 4.03\%.} +\label{fig:broker-1000-metrics} +\end{figure} +\clearpage +\begin{figure}[htbp] +\centering +\IfFileExists{images/HAOS_1000.png}{% + \includegraphics[width=0.85\linewidth]{images/HAOS_1000.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/HAOS\_1000.png} + }}% +} +\caption{Home Assistant OS \texttt{top} output during 1,000-device test showing CPU utilization at 1.4\%.} +\label{fig:haos-1000} +\end{figure} + + +%%----------------------------------------------------------------------------- +\chapter{mTLS Handshake Benchmark Data} +\label{app:handshake-metrics} + +This appendix provides the complete benchmark data for the mTLS handshake latency measurements discussed in Section~\ref{subsec:handshake-latency}. The benchmark was performed using the Python sensor simulator's handshake benchmark mode. + +\section*{Test Configuration} + +\begin{itemize} + \item \textbf{Source}: FARM (Frankfurt, Germany) --- Python 3.11.2 + paho-mqtt 1.6 + \item \textbf{Target}: NUE (Nuremberg, Germany) --- EMQX 6.0.0 broker with mTLS + \item \textbf{Network RTT}: 6.4\,ms average (via \texttt{mtr}) + \item \textbf{TLS Stack}: ECDSA P-256 (signature) + X25519 (key exchange) + \item \textbf{Protocol}: TLS 1.3 with mutual authentication + \item \textbf{Samples}: 800 connection attempts, 0 failures + \item \textbf{Test Date}: 2026-01-07 +\end{itemize} + +\section*{Summary Statistics} + +\begin{lstlisting}[language={}, basicstyle=\ttfamily\small, commentstyle=\color{gray}\itshape, morecomment={[l]{//}}, frame=single, breaklines=true] +{ + "n": 800, // Sample count (successful connections) + "min": 67.84, // Minimum latency observed (ms) + "max": 104.07, // Maximum latency observed (ms) + "mean": 80.50, // Arithmetic mean: sum(x_i) / n + "stdev": 7.49, // Sample standard deviation (statistics.stdev) + "sem": 0.265, // Standard error of mean: stdev / sqrt(n) + "p50": 80.55, // Median: 50th percentile + "p90": 91.61, // 90th percentile (linear interpolation) + "p95": 92.82, // 95th percentile + "p99": 96.79, // 99th percentile (tail latency) + "ci95_mean_normal_approx": // 95% CI for true mean (z=1.96): + [79.98, 81.02] // mean +/- 1.96 * sem +} +\end{lstlisting} + +\textbf{Percentile method}: Linear interpolation between closest ranks, as implemented in \texttt{utils.percentile\_sorted()}. + +\section*{Command Used} + +\begin{lstlisting}[language=bash, basicstyle=\ttfamily\small, frame=single, breaklines=true] +python sensors/sensor_simulator.py --config sensors/brokers.yml \ + --handshake-samples 800 --handshake-out sensors/handshake_metrics \ + --handshake-only +\end{lstlisting} + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/architecture.tex b/docs/BT/CTU_FEL_THESIS/chapters/architecture.tex new file mode 100644 index 0000000..18db96c --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/architecture.tex @@ -0,0 +1,267 @@ +\chapter{System Architecture} +\label{ch:architecture} + +This chapter presents the architecture of the implemented smart home system. The design emphasizes local-first control, secure cross-network communication, and integration of heterogeneous device types---including custom ESP32-based sensors, a Python-based simulator for virtual entity emulation also can use for load generation for benchmarking, and commercial IoT devices. + +% ============================================================================ +% 3.1 Architecture Overview +% ============================================================================ +\section{Architecture Overview} +\label{sec:arch-overview} + +The system follows a distributed architecture with components spanning local and cloud-hosted infrastructure, connected through secure communication channels. Figure~\ref{fig:system-arch} illustrates the high-level topology. + +\begin{figure}[H] +\centering +% tighten caption spacing (local to this figure) +\setlength{\abovecaptionskip}{0pt} % default is often ~10pt +\setlength{\belowcaptionskip}{0pt} + +\IfFileExists{images/system_architecture.drawio.png}{% + \scalebox{1}[0.90]{% + \includegraphics[width=\linewidth]{images/system_architecture.drawio.png}% +} +}{% + \fbox{\parbox{0.9\textwidth}{\centering + Missing figure: \texttt{images/system\_architecture.drawio.png} + }}% +} +\caption{Overall system architecture and communication paths.} +\label{fig:system-arch} +\end{figure} + +The architecture aligns with the three-layer IoT reference model introduced in Section~\ref{sec:smarthome-overview}: + +\begin{itemize} + \item \textbf{Application Layer:} Home Assistant platform providing automation engine, device management, user dashboards, and optional data persistence. + + \item \textbf{Network Layer:} MQTT messaging over mTLS for wide-area communication; ESPHome Native API for low-latency local control~\cite{esphome_2024}; cloud APIs for commercial device integration. + + \item \textbf{Perception Layer:} Physical sensor nodes (ESP32, ESP32-S3), commercial IoT devices (Xiaomi air purifier), and the Python simulator generating virtual device telemetry. +\end{itemize} + + +% ============================================================================ +% 3.2 System Components +% ============================================================================ +\section{System Components} +\label{sec:system-components} + +Table~\ref{tab:system-components} summarizes the principal components of the implemented system, their deployment locations, and roles. + +\begin{table}[htbp] +\centering +\caption{System components and deployment topology.} +\label{tab:system-components} +\small +\resizebox{\linewidth}{!}{% +\begin{tabular}{@{}llll@{}} +\toprule +\textbf{Component} & \textbf{Location} & \textbf{Platform} & \textbf{Role} \\ +\midrule +Web Gateway & VPS (Frankfurt) & Debian / Nginx & Bastion; HA TLS reverse proxy \\ +EMQX Broker & VPS (Nuremberg) & Debian / OpenResty & MQTT routing \\ +Home Assistant & Local (Prague) & HAOS on ESXi & Automation hub \\ +ESP32 / ESP32-S3 & Local (Prague) & ESPHome & Sensor \& actuator \\ +Xiaomi Air Purifier & Local (Prague) & Commercial & Air quality \\ +Python Simulator & Network-connected host & Cross-platform & Virtual entities; load testing \\ +HA Companion App\footnote{\url{https://companion.home-assistant.io/}} & Mobile & iOS / Android & Mobile client / Sensor \\ +\bottomrule +\end{tabular} +} +\end{table} + +\subsection{Custom Sensor Nodes} +\label{subsec:custom-nodes} + +Two ESP32-based sensor nodes are deployed using ESPHome firmware. These nodes collect environmental data (temperature, humidity, ambient light) and expose actuators (LED indicators, relays). Communication with Home Assistant occurs via two paths: + +\begin{itemize} + \item \textbf{ESPHome Native API~\cite{esphome_2024}:} Used for local-network communication, providing low-latency bidirectional control without broker dependency. + \item \textbf{MQTT over mTLS~\cite{mqtt_oasis_2019}:} Used for wide-area messaging when the controller or devices span different networks, ensuring encrypted and authenticated communication. +\end{itemize} + +The dual-path design balances responsiveness for local automation with security for Internet-exposed scenarios. + +\subsection{Commercial Device Integration} +\label{subsec:commercial-integration} + +Integrations connecting Home Assistant to external systems can be categorized by data flow direction: \emph{inbound integrations} import devices into Home Assistant, while \emph{outbound integrations} expose Home Assistant entities to external platforms. + +\paragraph{Inbound integration (devices to Home Assistant).} +A Xiaomi smart air purifier is integrated via the Xiaomi Home Integration\footnote{\url{https://github.com/XiaoMi/ha_xiaomi_home}}, installed through HACS\footnote{\url{https://hacs.xyz/}}. According to the integration documentation, device state and events are delivered to Home Assistant via subscriptions to Xiaomi's MQTT-based cloud message bus, while control commands are issued via Xiaomi cloud HTTP interfaces. The integration also supports local-control modes under specific conditions (e.g., Xiaomi hub gateway or LAN control), otherwise operation is cloud-mediated. This contrasts with the fully local communication available for ESPHome-based nodes. + +\paragraph{Outbound integration (Home Assistant to voice platforms).} +Home Assistant can expose entities to voice assistant ecosystems. The HomeKit Bridge\footnote{\url{https://www.home-assistant.io/integrations/homekit/}} publishes entities to Apple Home for Siri control. The Google Assistant integration\footnote{\url{https://www.home-assistant.io/integrations/google_assistant/}} exposes entities to Google Home. Home Assistant Cloud (Nabu Casa)\footnote{\url{https://www.nabucasa.com/}} simplifies connectivity for Google Assistant and Amazon Alexa without manual cloud configuration. + +Including these integrations serves two purposes: +\begin{itemize} + \item It validates Home Assistant's role as a unifying platform capable of aggregating heterogeneous device ecosystems under a single interface. + \item It provides a concrete example of vendor cloud dependency, illustrating the privacy and availability trade-offs discussed in Section~\ref{sec:problem}. +\end{itemize} + +\subsection{Python Simulator} +\label{subsec:simulator-arch} + +The Python-based sensor simulator emulates large numbers of virtual devices as Home Assistant entities by publishing telemetry to the MQTT broker, subscribing to command topics, and supporting Home Assistant MQTT Discovery. This provides a controllable and repeatable way to validate message flows, automations, and dashboard behavior without requiring additional physical hardware. + +Building on this entity-emulation capability, the simulator also serves as a scalable load generator for stress testing, enabling experiments with thousands of virtual entities under reproducible configurations. + +The simulator supports: +\begin{itemize} + \item Configurable device count and entity types (sensors, binary sensors, switches, lights). + \item Multiple data models (drift, uniform, sine wave, motion events). + \item Home Assistant MQTT Discovery for automatic entity registration. + \item mTLS client authentication matching the security requirements of the broker. +\end{itemize} + +% ============================================================================ +% 3.3 Communication Architecture +% ============================================================================ +\section{Communication Architecture} +\label{sec:comm-arch} + +The communication design addresses three goals: (i) low latency for interactive local control, (ii) security for Internet-exposed messaging, and (iii) scalability for benchmarking with large device populations. + +\subsection{Topic Namespace Design} +\label{subsec:topic-namespace} + +Building on the MQTT topic hierarchy introduced in Section~\ref{subsec:mqtt-characteristics}, the system implements a consistent naming convention. Device telemetry and commands follow the pattern: + +\begin{verbatim} +{base_topic}/device_{id}/{entity}/state +{base_topic}/device_{id}/{entity}/set +\end{verbatim} + +Home Assistant MQTT Discovery publishes configuration payloads under the \texttt{homeassistant/} prefix~\cite{homeassistant_2024}, enabling automatic device registration. + +Table~\ref{tab:system-subscriptions} shows representative MQTT subscriptions captured from the EMQX broker during system operation, illustrating the topic namespace in practice. + +\begin{table}[htbp] +\centering +\caption{MQTT subscriptions observed during system operation (EMQX dashboard).} +\label{tab:system-subscriptions} +\small +\resizebox{\linewidth}{!}{% +\begin{tabular}{llcl} +\toprule +\textbf{Client} & \textbf{Subscription Topic} & \textbf{QoS} & \textbf{Purpose} \\ +\midrule +ESP32 & \texttt{smarthome-esp32/switch/led/command} & 0 & Actuator command \\ +ESP32-S3 & \texttt{smarthome-esp32s3/sensor/temperature/state} & 0 & Sensor telemetry \\ +Simulator & \texttt{smarthome/sim/device\_1/heater/set} & 0 & Virtual actuator \\ +Home Assistant & \texttt{homeassistant/sensor/+/config} & 0 & MQTT Discovery \\ +\bottomrule +\end{tabular} +} +\end{table} + +\subsection{Communication Paths} +\label{subsec:comm-paths} + +Three distinct communication paths serve different deployment scenarios: + +\begin{itemize} + \item \textbf{ESPHome Native API~\cite{esphome_2024}:} ESP32 nodes on the same LAN as Home Assistant use the native API protocol, providing sub-second response times without Internet dependency. + + \item \textbf{MQTT over mTLS~\cite{mqtt_oasis_2019}:} The simulator and devices outside the local network connect to the EMQX broker on port 8883 with mutual TLS authentication. This path also serves as a fallback for ESPHome devices in distributed deployments. + + \item \textbf{Cloud APIs:} Commercial devices (e.g., Xiaomi air purifier) integrate via vendor infrastructure. In the Xiaomi Home Integration, state is delivered via Xiaomi's MQTT-based message bus and commands are sent through vendor HTTP interfaces; local-control modes are optional and deployment-dependent. +\end{itemize} + +Table~\ref{tab:comm-paths} summarizes the characteristics of each path. + +\begin{table}[htbp] +\centering +\caption{Communication path characteristics.} +\label{tab:comm-paths} +\begin{tabular}{llll} +\toprule +\textbf{Path} & \textbf{Latency} & \textbf{Security} & \textbf{Dependency} \\ +\midrule +ESPHome Native API~\cite{esphome_2024} & Low (LAN) & API encryption & Local network \\ +MQTT over mTLS~\cite{mqtt_oasis_2019} & Medium (WAN) & mTLS mutual auth & Self-hosted broker \\ +Cloud APIs & Variable (WAN) & Vendor TLS & Vendor cloud \\ +\bottomrule +\end{tabular} +\end{table} + +% ============================================================================ +% 3.4 Security Architecture +% ============================================================================ +\section{Security Architecture} +\label{sec:security-arch} + +The security architecture implements defense-in-depth across transport, network, and application layers. + +\subsection{Transport Layer Security} +\label{subsec:transport-security} + +All MQTT communications between the simulator, ESPHome devices (when using MQTT), and the EMQX broker employ mutual TLS (mTLS) on port 8883. The certificate hierarchy consists of: + +\begin{itemize} + \item A self-signed Certificate Authority (CA) issuing all certificates. + \item Server certificate for the EMQX broker, verified by clients against the CA. + \item Client certificates for each device and simulator instance, verified by the broker. +\end{itemize} + +Certificates use ECDSA with NIST P-256 for signatures and X25519 for ephemeral key exchange, based on the hybrid TLS approach analyzed in Section~\ref{subsubsec:hybrid-tls}. The complete certificate generation procedure is documented in Appendix~\ref{app:certs}. This choice provides strong security with minimal computational overhead on resource-constrained ESP32 devices. + +\subsection{Network Layer Security} +\label{subsec:network-security} + +To avoid direct exposure of administrative interfaces to the public Internet, the system employs a layered access architecture: + +\begin{itemize} + \item \textbf{MQTT (port 8883):} Clients connect directly to the EMQX broker in Nuremberg using mTLS; no reverse proxy is involved. + \item \textbf{EMQX Dashboard:} A co-located OpenResty instance on the same host handles TLS termination (Let's Encrypt) and reverse proxying for the broker's web interface. + \item \textbf{Home Assistant Dashboard:} A Nginx gateway in Frankfurt terminates TLS (Let's Encrypt) and proxies requests to the internal Home Assistant instance in Prague via Tailscale. +\end{itemize} + +Tailscale\footnote{\url{https://tailscale.com/blog/how-tailscale-works/}}, a mesh VPN built on WireGuard~\cite{donenfeld_wireguard_2017}, interconnects external VPS nodes and the internal network. Access Control Lists (ACLs) enforce least-privilege principles, as shown in Table~\ref{tab:tailscale-acl}. + +\begin{table}[htbp] +\centering +\caption{Tailscale ACL rules for network segmentation.} +\label{tab:tailscale-acl} +\begin{tabular}{lll} +\toprule +\textbf{Source Tag} & \textbf{Destination} & \textbf{Purpose} \\ +\midrule +\texttt{tag:user} & \texttt{*:*} & Full access (owner devices) \\ +\texttt{tag:bastion} & \texttt{tag:ha-gateway:8123} & Web gateway to HA dashboard only \\ +\texttt{tag:node} & \texttt{tag:node:*} & Inter-node communication \\ +\bottomrule +\end{tabular} +\end{table} + +This configuration ensures the web gateway can only reach Home Assistant on port 8123, while owner-controlled nodes (\texttt{tag:user}) retain full access for administration. + +\subsection{Application Layer Security} +\label{subsec:app-security} + +Home Assistant uses token-based authentication with configurable session timeouts~\cite{homeassistant_2024}. For third-party integrations such as Xiaomi Home, the integration uses OAuth~2.0 login and stores user/device metadata (including tokens and certificates) in Home Assistant configuration files. + +ESP32 nodes store credentials in encrypted Non-Volatile Storage (NVS) partitions provided by the ESP-IDF framework~\cite{esp_idf_nvs_2024}, protecting against casual firmware extraction. + +% ============================================================================ +% 3.5 Design Rationale +% ============================================================================ +\section{Design Rationale} +\label{sec:design-rationale} + +This section motivates the principal architectural decisions and relates each choice to the system goals outlined in this chapter (local-first operation, secure cross-network communication, and heterogeneous device integration). + +\paragraph{Hybrid local--cloud topology.} +Hosting the MQTT broker on a public VPS rather than locally reflects the experimental requirement for cross-network benchmarking. This enables the simulator to connect from arbitrary locations while maintaining mTLS-authenticated connectivity~\cite{mqtt_oasis_2019}. For production deployments, a local broker would reduce latency and eliminate external dependencies. + +\paragraph{Dual communication paths for ESP32 nodes.} +Supporting both ESPHome Native API~\cite{esphome_2024} and MQTT allows the system to optimize for latency locally while retaining flexibility for distributed deployments. The native API provides lowest latency on shared LANs; MQTT extends connectivity across network boundaries. + +\paragraph{Inclusion of commercial devices.} +Integrating the Xiaomi air purifier demonstrates that an open-source platform can coexist with vendor ecosystems, aggregating heterogeneous sources into a unified interface. This also illustrates cloud dependency trade-offs analyzed in Chapter~\ref{ch:evaluation}. + +\paragraph{Simulator for scalability testing.} +Physical deployment of thousands of sensors is impractical for a thesis project. The Python simulator provides a controlled, repeatable method to stress-test the broker and controller, producing quantitative data presented in Chapter~\ref{ch:evaluation}. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/background.tex b/docs/BT/CTU_FEL_THESIS/chapters/background.tex new file mode 100644 index 0000000..ee52903 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/background.tex @@ -0,0 +1,327 @@ +\chapter{Theoretical Background} +\label{ch:background} + +This chapter provides the theoretical foundation for understanding smart home systems, communication protocols, and security mechanisms employed in this thesis. + +% ============================================================================ +% 2.1 Smart Home Systems Overview +% ============================================================================ +\section{Smart Home Systems Overview} +\label{sec:smarthome-overview} + +A smart home system consists of interconnected devices that monitor and control various aspects of a residential environment. These systems are commonly described using a three-layer IoT reference architecture~\cite{iot_architecture_2019, khan_iot_smarthome_2018}: + +\begin{itemize} + \item \textbf{Application Layer:} Software platforms that process sensor data, execute automation rules, and provide user interfaces for monitoring and control. + + \item \textbf{Network Layer:} Communication infrastructure that enables data transmission between devices. Common wireless technologies include Wi-Fi (IEEE~802.11), Zigbee (IEEE~802.15.4), and Bluetooth Low Energy (BLE)~\cite{smarthome_survey_2020}. Prior work has explored Wi-Fi-based smart home implementations using microcontrollers and mobile applications~\cite{bhatnagar_wifi_smarthome_2018}. + + \item \textbf{Perception Layer:} Sensors and actuators that interact with the physical environment, including temperature sensors, motion detectors, smart switches, and lighting controls. +\end{itemize} + +The evolution of smart home technology has been driven by advances in microcontroller capabilities, wireless communication standards, and cloud computing infrastructure~\cite{smarthome_survey_2020}. Modern systems increasingly emphasize edge computing, where data processing occurs locally rather than in centralized cloud servers~\cite{edge_computing_iot_2016}. + +% ============================================================================ +% 2.2 MQTT Protocol +% ============================================================================ +\section{MQTT Protocol} +\label{sec:mqtt} + +Message Queuing Telemetry Transport (MQTT) is a lightweight publish-subscribe messaging protocol designed for constrained devices and low-bandwidth networks~\cite{mqtt_oasis_2019}. Developed by IBM in 1999, MQTT has become an established standard for IoT communications due to its low protocol overhead and simple implementation~\cite{mqtt_iot_survey_2017}. + +Comparative studies have demonstrated MQTT's advantages over HTTP for IoT applications, including reduced network overhead and lower energy consumption~\cite{mqtt_performance_2018}. + +Unlike traditional request-response protocols, MQTT employs a publish-subscribe model with a central broker: + +\begin{itemize} + \item \textbf{Publishers} send messages to specific topics without knowledge of subscribers. + \item \textbf{Subscribers} register interest in topics and receive all messages published to those topics. + \item \textbf{Broker} acts as an intermediary, routing messages from publishers to subscribers based on topic matching. +\end{itemize} +\begin{figure}[htbp] + \centering + \IfFileExists{images/MQTT_PublishSubscribeArchitecture.pdf}{% + \includegraphics[width=0.95\textwidth]{images/MQTT_PublishSubscribeArchitecture.pdf}% + }{% + \fbox{\parbox{0.9\textwidth}{\centering + Missing figure: \texttt{images/MQTT\_PublishSubscribeArchitecture.pdf} + }}% + } + \caption{MQTT Publish-subscribe Architecture~\cite{emqx_pubsub_2023}} + \label{fig:mqtt-pubsub} +\end{figure} + +This decoupled architecture enables scalable many-to-many communication patterns suitable for IoT deployments. + +\subsection{MQTT Protocol Characteristics} +\label{subsec:mqtt-characteristics} + +MQTT is designed for reliable messaging in constrained and bandwidth-limited IoT environments, emphasizing low protocol overhead and a broker-mediated publish--subscribe model~\cite{mqtt_oasis_2019,mqtt_iot_survey_2017}. Key characteristics include: + +\begin{itemize} + \item \textbf{Lightweight control packets:} A compact fixed header and small message framing reduce bandwidth and parsing overhead compared to many request--response protocols. + \item \textbf{Decoupled communication:} Publishers and subscribers do not need direct knowledge of each other, improving scalability and simplifying multi-producer/multi-consumer deployments. + \item \textbf{Topic-based addressing and filtering:} Hierarchical topics and wildcard subscriptions enable flexible routing and selective consumption of device telemetry and control streams. + \item \textbf{Session semantics:} Keep-alive, retained messages, and Last Will and Testament (LWT) support robustness in the presence of intermittent connectivity~\cite{mqtt_oasis_2019}. +\end{itemize} + +MQTT topics use a hierarchical structure with forward slash separators, enabling flexible subscription patterns through single-level (\texttt{+}) and multi-level (\texttt{\#}) wildcards~\cite{mqtt_oasis_2019}: + +\begin{table}[htbp] + \centering + \small + \setlength{\tabcolsep}{4pt} + \renewcommand{\arraystretch}{1.15} + \caption{MQTT topic hierarchy and wildcard subscription patterns.} + \label{tab:mqtt-topic-examples} + \begin{tabular}{lll} + \toprule + \textbf{Concept} & \textbf{Example} & \textbf{Notes} \\ + \midrule + State topic & \texttt{smarthome/bathroom/temperature/state} & leaf topic \\ + Single-level wildcard & \texttt{smarthome/bedroom/+/state} & one level \\ + Multi-level wildcard & \texttt{smarthome/\#} & any depth \\ + \bottomrule + \end{tabular} +\end{table} + +This hierarchical organization facilitates logical grouping of devices and supports pattern-based subscriptions for efficient message filtering. + +\subsection{Quality of Service Levels} +\label{subsec:qos} + +MQTT defines three Quality of Service (QoS) levels to balance reliability against overhead: + +\begin{table}[htbp] + \centering + \caption{Comparison of MQTT Quality of Service (QoS) Levels~\cite{mqtt_oasis_2019}} + \label{tab:mqtt-qos} + \begin{tabular}{lp{8cm}l} + \toprule + \textbf{QoS Level} & \textbf{Description} & \textbf{Overhead} \\ + \midrule + 0 (At most once) & Fire and forget. No guarantee of delivery. & Lowest \\ + 1 (At least once) & Guaranteed delivery, duplicates possible. Requires PUBACK. & Medium \\ + 2 (Exactly once) & Guaranteed delivery, no duplicates. Four-step handshake. & Highest \\ + \bottomrule + \end{tabular} +\end{table} + +QoS 0 provides the lowest overhead but no delivery guarantees. QoS 1 ensures delivery through acknowledgment but may result in duplicates. QoS 2 guarantees exactly-once delivery at the cost of additional message exchanges. + + + +% ============================================================================ +% 2.3 Transport Layer Security +% ============================================================================ +\section{Transport Layer Security} +\label{sec:tls} + +Transport Layer Security (TLS) provides cryptographic security for communications over computer networks. In IoT contexts, TLS protects against eavesdropping, tampering, and impersonation attacks~\cite{iot_security_survey_2019}. + +Standard TLS authenticates only the server to the client, verifying the server's identity through certificate validation. Mutual TLS (mTLS) extends this by requiring both parties to present certificates: + +\begin{enumerate} + \item Client initiates connection with ClientHello message. + \item Server responds with certificate and requests client certificate. + \item Client presents its certificate for server verification. + \item Both parties complete key exchange and establish encrypted session. +\end{enumerate} + +\begin{figure}[htbp] + \centering + % Source image: Cloudflare Learning Center (see citation in caption). + \IfFileExists{images/how_tls_works-what_is_mutual_tls.png}{% + \includegraphics[width=0.95\linewidth]{images/how_tls_works-what_is_mutual_tls.png}% + }{% + \fbox{\parbox{0.92\textwidth}{\centering + Missing figure: \texttt{images/how\_tls\_works-what\_is\_mutual\_tls.png} + }}% + } + \caption{Mutual TLS (mTLS) authentication concept and handshake overview~\cite{cloudflare_mtls_2024}} + \label{fig:mtls-sequence} +\end{figure} + +mTLS provides stronger security guarantees for IoT deployments by ensuring that only authorized devices can connect to the message broker. +\subsection{ECC vs RSA Cryptography} +\label{subsec:ecc-rsa} + +Elliptic Curve Cryptography (ECC) offers equivalent security to RSA with significantly smaller key sizes, making it particularly suitable for resource-constrained IoT devices. According to NIST recommendations, a 128-bit security level corresponds to an RSA key size of 3072 bits, whereas an ECC key requires only 256 bits~\cite{NIST_SP_800_57}. + +\begin{table}[H] +\centering +\caption{Comparison of ECC and RSA Key Sizes~\cite{NIST_SP_800_57}} +\label{tab:ecc-rsa} +\begin{tabular}{lcc} +\toprule + \textbf{Security Strength} & \textbf{ECC Key Size} & \textbf{RSA Key Size} \\ +\midrule +80-bit & 160 bits & 1024 bits \\ +112-bit & 224 bits & 2048 bits \\ +128-bit & \textbf{256 bits} & 3072 bits \\ +\bottomrule +\end{tabular} +\end{table} + +The computational efficiency of ECC becomes evident when analyzing performance on specific microcontroller platforms. Benchmarks reported by Oryx Embedded\footnote{\url{https://www.oryx-embedded.com/benchmark/espressif/}} for ESP32 (Xtensa LX6) and ESP32-S3 (Xtensa LX7) at 240~MHz show substantial latency differences across public-key algorithms~\cite{oryx_crypto_benchmark_esp32, oryx_crypto_benchmark_esp32s3}. + +\begin{table}[H] +\centering +\caption{Digital Signature Performance on ESP32 platforms~\cite{oryx_crypto_benchmark_esp32, oryx_crypto_benchmark_esp32s3}} +\label{tab:crypto-signature-benchmark} +\begin{tabular}{lcccccc} +\toprule +\textbf{Algorithm} & \multicolumn{3}{c}{\textbf{ESP32 (LX6)}} & \multicolumn{3}{c}{\textbf{ESP32-S3 (LX7)}} \\ +\cmidrule(lr){2-4} \cmidrule(lr){5-7} +& Sign & Verify & Total & Sign & Verify & Total \\ +\midrule +RSA-3072 (HW) & 465 ms & 314 ms & 779 ms & 315 ms & 57 ms & 372 ms \\ +ECDSA P-256 (HW) & 62 ms & 57 ms & 119 ms & 67 ms & 60 ms & 127 ms \\ +Ed25519 (SW) & \textbf{29 ms} & \textbf{28 ms} & \textbf{57 ms} & \textbf{26 ms} & \textbf{24 ms} & \textbf{50 ms} \\ +\bottomrule +\end{tabular} +\end{table} + +\begin{table}[H] +\centering +\caption{Key Exchange Performance on ESP32 Platforms~\cite{oryx_crypto_benchmark_esp32, oryx_crypto_benchmark_esp32s3}} +\label{tab:crypto-keyexchange-benchmark} +\begin{tabular}{lcccccc} +\toprule +\textbf{Algorithm} & \multicolumn{3}{c}{\textbf{ESP32 (LX6)}} & \multicolumn{3}{c}{\textbf{ESP32-S3 (LX7)}} \\ +\cmidrule(lr){2-4} \cmidrule(lr){5-7} +& Keygen & Shared & Total & Keygen & Shared & Total \\ +\midrule +ECDH P-256 (HW) & 54 ms & 54 ms & 108 ms & 63 ms & 62 ms & 125 ms \\ +X25519 (SW) & \textbf{17 ms} & \textbf{16 ms} & \textbf{33 ms} & \textbf{14 ms} & \textbf{15 ms} & \textbf{29 ms} \\ +\bottomrule +\end{tabular} +\end{table} + +Notably, Ed25519 and X25519 in pure software outperform NIST P-256 with hardware acceleration by 2--4$\times$. This reflects the Curve25519 design goal of efficient arithmetic on general-purpose CPUs~\cite{bernstein_curve25519_2006}. + +\subsection{Selection of Cryptographic Algorithms for TLS} +\label{subsec:curve25519} + +Based on the performance analysis above, this thesis initially targeted the \textbf{Curve25519} cryptographic suite: \textbf{Ed25519} (EdDSA) for digital signatures and \textbf{X25519} for Elliptic Curve Diffie--Hellman (ECDH) key exchange. The selection was motivated by three primary factors: + +\begin{itemize} + \item \textbf{Efficiency on embedded CPUs:} The reported benchmarks show that Ed25519 and X25519 complete faster than the NIST P-256 alternatives on both ESP32 and ESP32-S3 (Tables~\ref{tab:crypto-signature-benchmark} and \ref{tab:crypto-keyexchange-benchmark}). + \item \textbf{Implementation hardening:} X25519 is specified with a Montgomery-ladder construction that is commonly implemented in a constant-time style to reduce timing side channels~\cite{rfc7748, bernstein_curve25519_2006}. + \item \textbf{Parameter transparency and deterministic signing:} Curve25519 has been discussed as having more transparent parameter choices, and SafeCurves\footnote{\url{https://safecurves.cr.yp.to/}} highlights ``rigidity'' as a criterion where NIST P-256 is rated negatively due to opaque seeds~\cite{safecurves_2017}. For authentication, Ed25519 (EdDSA) uses deterministic nonce generation as standardized in RFC 8032, reducing reliance on runtime randomness during signing~\cite{rfc8032, bernstein_ed25519_2012}. This design addresses a fundamental weakness in ECDSA, where poor random number generation during signing can leak the private key---a critique extensively documented by Bernstein~\cite{bernstein_ecdsa_blog_2014}. +\end{itemize} + +\subsubsection{Library Limitations and Hybrid Approach} +\label{subsubsec:hybrid-tls} + +During implementation, a practical limitation was encountered: the ESP-IDF framework's underlying TLS library (Mbed~TLS) supports X25519 for ECDH key exchange but does not currently support Ed25519 (EdDSA) for X.509 certificate signatures~\cite{esp_tls_2024}. The ESP-TLS API documentation explicitly lists only \texttt{SECP256R1} and \texttt{SECP384R1} as supported ECDSA curves for certificate operations. This limitation is documented in the Mbed~TLS project issue tracker\footnote{\url{https://github.com/Mbed-TLS/mbedtls/issues/2452}}, where Ed25519 certificate support has been requested as a feature enhancement~\cite{mbedtls_ed25519_issue}. According to the official Mbed~TLS roadmap\footnote{\url{https://mbed-tls.readthedocs.io/en/latest/roadmap/}}, EdDSA support for certificates is planned for future releases~\cite{mbedtls_roadmap_2024}. + +It is worth noting that alternative TLS libraries exist for embedded systems that provide full Curve25519 support. wolfSSL\footnote{\url{https://www.wolfssl.com/}}, a lightweight embedded TLS library, offers complete Ed25519 and X25519 support, including Ed25519-based X.509 certificate signatures~\cite{wolfssl_2024}. The ESP-IDF framework officially supports wolfSSL as an alternative to Mbed~TLS through its component system~\cite{esp_tls_2024}. wolfSSL is designed for resource-constrained environments and supports TLS~1.3 with progressive cipher suites. However, for this thesis, ESPHome was chosen as the firmware framework due to its simplified YAML-based configuration and native Home Assistant integration. ESPHome currently uses Mbed~TLS as its TLS backend and does not expose wolfSSL as a configuration option, making the hybrid approach (P-256 certificates with X25519 key exchange) the practical choice within this framework. For deployments requiring pure Curve25519-based mTLS, switching to native ESP-IDF with wolfSSL would be necessary. + +\paragraph{Hybrid TLS Configuration.} +To address this limitation while maximizing performance, this thesis adopts a \textbf{hybrid cryptographic approach} that combines the strengths of both algorithm families: + +\begin{itemize} + \item \textbf{Certificate signatures:} ECDSA with NIST P-256 (\texttt{prime256v1}), which is fully supported by ESP-TLS for X.509 certificate parsing and verification. + \item \textbf{Key exchange:} X25519, automatically negotiated during TLS~1.3 handshake when the \texttt{supported\_groups} extension includes \texttt{x25519} on both endpoints~\cite{rfc8446}. +\end{itemize} + +This separation is possible because TLS~1.3 decouples the authentication mechanism (certificate signatures) from the key exchange mechanism (ephemeral Diffie--Hellman). As specified in RFC~8446, the signature algorithm used in certificates is independent of the key exchange group negotiated in the handshake~\cite{rfc8446}. + +\paragraph{Performance Analysis of the Hybrid Approach.} +Table~\ref{tab:hybrid-performance} presents the estimated cryptographic latency for a complete mTLS handshake under different configurations. The hybrid approach (P-256 signatures + X25519 key exchange) achieves a favorable balance: it avoids the slow RSA operations while leveraging X25519's efficiency for the latency-critical key exchange phase. + +\begin{table}[H] +\centering +\caption{Estimated TLS Handshake Cryptographic Latency on ESP32-S3~\cite{oryx_crypto_benchmark_esp32s3}} +\label{tab:hybrid-performance} +\begin{tabular}{lccc} +\toprule +\textbf{Configuration} & \textbf{Signature (Verify)} & \textbf{Key Exchange} & \textbf{Total} \\ +\midrule +RSA-3072 + ECDH P-256 & 57 ms & 125 ms & 182 ms \\ +ECDSA P-256 + ECDH P-256 & 60 ms & 125 ms & 185 ms \\ +\textbf{ECDSA P-256 + X25519 (Hybrid)} & 60 ms & \textbf{29 ms} & \textbf{89 ms} \\ +Ed25519 + X25519 (Ideal)\textsuperscript{*} & 24 ms & 29 ms & 53 ms \\ +\bottomrule +\end{tabular} +\begin{tablenotes} +\small +\item \textsuperscript{*}Theoretical; Ed25519 certificate signatures not supported by ESP-TLS. +\end{tablenotes} +\end{table} + +The hybrid configuration reduces total cryptographic latency by approximately 52\% compared to the pure P-256 configuration (89~ms vs 185~ms), primarily due to X25519's 4$\times$ faster key exchange. Certificate verification occurs only once per connection establishment, whereas the session key derived from ECDH protects all subsequent application data. For battery-powered IoT devices that employ deep-sleep modes and wake periodically to transmit sensor data, each wake cycle requires re-establishing the TLS connection~\cite{esp_sleep_modes_2024}. Therefore, optimizing key exchange latency directly reduces the energy consumed during these frequent reconnection events. + +% ============================================================================ +% 2.4 Home Assistant and ESPHome +% ============================================================================ + +\section{Home Assistant and ESPHome} +\label{sec:ha-esphome} + +\textbf{Home Assistant}\footnote{\url{https://www.home-assistant.io/}} is an open-source home automation platform designed to run on local hardware~\cite{homeassistant_2024}. The platform is distributed as Docker containers built on Alpine Linux base images, providing a lightweight footprint suitable for embedded systems and single-board computers~\cite{ha_docker_base_2024}. Key features include: + +\begin{itemize} + \item \textbf{Integration Support:} Extensive integration ecosystem covering a wide range of commercial and DIY devices and services. + \item \textbf{Local Control:} Local-first operation with optional cloud connectivity, enabling continued functionality even when external services are unavailable. + \item \textbf{Automation Engine:} Flexible automation via YAML configuration and a visual editor, supporting complex rule-based behaviors. + \item \textbf{Dashboard System:} Customizable dashboards for real-time monitoring, control, and status visualization across devices. +\end{itemize} + +In addition, Home Assistant supports MQTT Discovery, which allows devices to be automatically registered by publishing configuration messages to predefined discovery topics. + +For ESP32-based devices, firmware development and integration with Home Assistant are facilitated by the ESPHome framework. + + \textbf{ESPHome}\footnote{\url{https://esphome.io/}} is a firmware framework that generates custom firmware from YAML configuration files~\cite{esphome_2024}. It supports a range of microcontroller platforms, including ESP8266, ESP32 variants, RP2040, and select LibreTiny-based chipsets. Its declarative configuration style is conceptually similar to earlier Wi-Fi-based appliance control systems that emphasized simplified device programming~\cite{xiao_wifi_iot_2018}. Key capabilities include: + +\begin{itemize} + \item \textbf{Sensor Support:} Native drivers for hundreds of sensor types. + \item \textbf{Native API:} Low-latency direct communication with Home Assistant. + \item \textbf{MQTT Support:} Full MQTT client with TLS/mTLS capability. + \item \textbf{OTA Updates:} Over-the-air firmware updates via WiFi. + \item \textbf{Local Automation:} On-device automation without external dependencies. +\end{itemize} + +The declarative YAML configuration approach reduces development complexity while maintaining flexibility through lambda expressions for custom logic. + +Beyond built-in integrations, Home Assistant supports community-developed components distributed via the Home Assistant Community Store (HACS)\footnote{\url{https://hacs.xyz/}}. This mechanism enables integration of devices from vendors who do not provide official Home Assistant support, including official manufacturer-provided integrations such as the Xiaomi Home Integration\footnote{\url{https://github.com/XiaoMi/ha_xiaomi_home}}. Such extensibility allows users to aggregate heterogeneous device ecosystems under a single local-first platform, contrasting with commercial solutions that typically rely on vendor-specific cloud infrastructure. +% ============================================================================ +% 2.5 Edge Computing and Unix-like Systems +% ============================================================================ +\section{Edge Computing and Unix-like Systems} +\label{sec:edge-unix} + +Edge computing moves parts of data processing closer to the data source, reducing latency and upstream bandwidth requirements and enabling continued operation when cloud connectivity is degraded~\cite{edge_computing_iot_2016}. + +\begin{table}[htbp] + \centering + \caption{Comparison between Cloud Computing and Edge Computing in IoT Contexts~\cite{edge_computing_iot_2016}} + \label{tab:edge-vs-cloud} + \begin{tabular}{lll} + \toprule + \textbf{Feature} & \textbf{Cloud Computing} & \textbf{Edge Computing} \\ + \midrule + \textbf{Latency} & High (WAN-dependent) & Low (near real-time) \\ + \textbf{Bandwidth} & High usage (raw data) & Low usage (processed data) \\ + \textbf{Privacy} & Data leaves premises & Data stays local \\ + \textbf{Processing Power} & Elastic (scalable) & Constrained (MCU/CPU) \\ + \textbf{Dependency} & Internet connection & Local power \\ + \bottomrule + \end{tabular} +\end{table} + +In smart home deployments, a central architectural choice is whether integration logic and data processing are executed in a vendor-operated cloud or on user-controlled infrastructure. + +This thesis adopts a \emph{server-based} design and implements the main software components---MQTT broker, Home Assistant, and the sensor simulator---on Unix-like systems within a controlled local environment. The motivation is not peak performance alone, but operational robustness and measurability, which are central for benchmarking and reproducible evaluation. Additionally, the open-source tooling and active community support lower the barrier for individual deployment and learning: + +\begin{itemize} + \item \textbf{Operational maturity:} The process model, service supervision, and standard administration tooling support repeatable deployments and recovery workflows~\cite{kerrisk_2010}. + \item \textbf{Security ecosystem:} Linux platforms provide widely deployed TLS stacks and cryptographic libraries, simplifying secure broker deployments and certificate management~\cite{openssl_2024}. + \item \textbf{Observability for evaluation:} System-level tooling enables measurement of CPU scheduling, memory pressure, filesystem behavior, and network throughput, which is required to relate application metrics to underlying bottlenecks~\cite{gregg_systems_performance_2020}. +\end{itemize} + +In the experimental setup, the MQTT broker runs on a Debian-based server, and Home Assistant is deployed via the Home Assistant Operating System (HAOS), a Linux-based operating system built using Buildroot and optimized to host Home Assistant~\cite{haos_buildroot_2024}. The sensor simulator is implemented in Python, enabling cross-platform execution, controllable entity emulation, and reproducible benchmarking across diverse host environments. + + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/conclusion.tex b/docs/BT/CTU_FEL_THESIS/chapters/conclusion.tex new file mode 100644 index 0000000..fd915b5 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/conclusion.tex @@ -0,0 +1,80 @@ +\chapter{Conclusion} +\label{ch:conclusion} + +This chapter summarizes the thesis contributions, acknowledges limitations, and suggests directions for future work. + +% ============================================================================ +% 7.1 Summary of Contributions +% ============================================================================ +\section{Summary of Contributions} +\label{sec:summary} + +This thesis presented the design and implementation of a smart home sensor control system utilizing servers and Unix-like operating systems. The primary contributions are: + +\begin{enumerate} + \item \textbf{Distributed Architecture Design:} A geographically distributed system architecture was designed with components spanning multiple locations (Nuremberg, Frankfurt, Prague, Hong Kong), demonstrating practical deployment of cross-region IoT infrastructure with secure communications. + + \item \textbf{Dual Hardware Node Implementation:} Two ESP32-based sensor nodes were implemented demonstrating different IoT paradigms: + \begin{itemize} + \item ESP32-S3 edge intelligence node performing local signal processing (vibration analysis, acoustic event detection) + \item ESP32 environment sensing node with safety monitoring capabilities (smoke detection, occupancy sensing) + \end{itemize} + + \item \textbf{Virtual Entity Simulation Framework:} A Python-based sensor simulator was developed for virtual entity emulation and load generation, enabling integration testing and scalability benchmarking beyond physical hardware limitations. + + \item \textbf{Security Implementation:} Mutual TLS authentication was implemented using a hybrid cryptographic approach: ECDSA P-256 for certificate signatures (due to ESP-IDF library constraints) combined with X25519 for key exchange, balancing compatibility with performance~\cite{oryx_crypto_benchmark_esp32s3, esp_tls_2024}. + + \item \textbf{Commercial Platform Comparison:} A qualitative comparison with commercial solutions (Xiaomi Mi Home) was conducted based on published documentation, highlighting trade-offs between convenience and data sovereignty. +\end{enumerate} + +The implemented system successfully demonstrates that open-source smart home solutions can provide comparable functionality to commercial alternatives while maintaining complete user control over data and system behavior. + +% ============================================================================ +% 7.2 Limitations +% ============================================================================ +\section{Limitations} +\label{sec:limitations} + +The following limitations should be acknowledged: + +\begin{itemize} + \item \textbf{Setup Complexity:} The system requires significant technical expertise for initial deployment, including certificate generation, server configuration, and network setup. This barrier limits accessibility for non-technical users. + + \item \textbf{Hardware Scale:} Only two physical sensor nodes were implemented. Production deployments with hundreds of devices may encounter unforeseen challenges. + + \item \textbf{Voice Integration:} No voice control interface was implemented, limiting comparison with voice-centric commercial platforms. + + \item \textbf{Limited Commercial Testing:} Direct integration testing with Amazon Alexa and Google Home devices was not performed due to availability constraints; comparison relied on published documentation. + + \item \textbf{Scalability Validation:} While the simulator supports large device counts, detailed CPU utilization measurements under load were not completed within the thesis timeline. +\end{itemize} + +% ============================================================================ +% 7.3 Future Work +% ============================================================================ +\section{Future Work} +\label{sec:future} + +Several directions for future research and development are identified: + +\begin{enumerate} + \item \textbf{Matter Protocol Integration:} Implementing Matter protocol support would enable interoperability with an expanding ecosystem of compatible devices while maintaining local control principles. + + \item \textbf{Machine Learning at the Edge:} The ESP32-S3's vector instructions could be leveraged for more sophisticated edge AI applications, such as anomaly detection or predictive maintenance. + + \item \textbf{Automated Certificate Management:} Implementing automated certificate lifecycle management (issuance, renewal, revocation) would reduce operational overhead for larger deployments. + + \item \textbf{Energy Monitoring:} Extending the system to include power consumption monitoring and optimization would provide additional value for energy-conscious users. + + \item \textbf{User Interface Improvements:} Developing simplified setup wizards and mobile applications could reduce the technical barrier for non-expert users. + + \item \textbf{Custom Enclosure Fabrication:} The modular hardware design is well-suited for 3D-printed enclosures, enabling rapid customization for specific deployment environments. Recent work has demonstrated the feasibility of FDM-based enclosure prototyping for IoT sensor nodes, reducing fabrication time from weeks to hours while allowing iterative design refinement~\cite{dhawale_3dprint_enclosure_2022, osa_3dprint_iot_2025}. + + \item \textbf{Redundancy and Failover:} Implementing MQTT broker clustering and Home Assistant high-availability would improve system resilience for critical applications. + + \item \textbf{Cryptographic Library Contributions:} As noted in Section~\ref{subsubsec:hybrid-tls}, the current ESP-IDF Mbed~TLS implementation lacks Ed25519 support for X.509 certificate signatures. Should the opportunity arise, contributing to the upstream Mbed~TLS project to address this limitation~\cite{mbedtls_ed25519_issue} would benefit the broader embedded systems community and enable pure Curve25519-based mTLS deployments on ESP32 platforms. +\end{enumerate} + +The growing adoption of local-first smart home solutions and the emergence of interoperability standards like Matter suggest a promising trajectory for open-source home automation. Continued development in this area has the potential to democratize smart home technology while preserving user privacy and autonomy. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/declaration.tex b/docs/BT/CTU_FEL_THESIS/chapters/declaration.tex new file mode 100644 index 0000000..9fc38f5 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/declaration.tex @@ -0,0 +1,20 @@ +\chapter*{Declaration} +\addcontentsline{toc}{chapter}{Declaration} + +I hereby declare that this bachelor's thesis is the product of my own independent work and that I have clearly stated all information sources used in the thesis according to Methodological Instruction No. 1/2009 -- ``On maintaining ethical principles when working on a university final project, CTU in Prague''. + +\vspace{30mm} + +\noindent In Prague on \makebox[4cm]{\dotfill} + +% \vspace{20mm} + +\hfill\parbox{6cm}{% + \centering + \makebox[5cm]{\dotfill}\\ + Weize Yuan +} + +\newpage + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/document_23_filename_1.pdf b/docs/BT/CTU_FEL_THESIS/chapters/document_23_filename_1.pdf new file mode 100644 index 0000000..977443b Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/chapters/document_23_filename_1.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/chapters/evaluation.tex b/docs/BT/CTU_FEL_THESIS/chapters/evaluation.tex new file mode 100644 index 0000000..d90a522 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/evaluation.tex @@ -0,0 +1,212 @@ +\chapter{Evaluation and Results} +\label{ch:evaluation} + +This chapter presents the evaluation methodology and experimental results, including performance metrics, security analysis, reliability assessment, and comparison with commercial solutions. + +% ============================================================================ +% 5.1 Test Environment +% ============================================================================ +\section{Test Environment} +\label{sec:test-env} + +The evaluation was conducted using the production deployment described in Chapter~\ref{ch:architecture}, specifically the system components summarized in Table~\ref{tab:system-components}. To facilitate cross-network benchmarking, the Python simulator was deployed on a VPS in Hong Kong (2~vCPU x86\_64, 2\,GB RAM, Debian~12), providing geographic separation from the European infrastructure and enabling realistic wide-area network latency measurements. + +% ============================================================================ +% 5.2 Performance Metrics +% ============================================================================ +\section{Performance Metrics} +\label{sec:performance} + +Network path latencies were measured using \texttt{mtr} with approximately 200 samples per path. Table~\ref{tab:network-latency} presents the measured round-trip times for key communication paths in the deployed system. + +\begin{table}[htbp] +\centering +\caption{Network Path Latency Measurements (RTT)} +\label{tab:network-latency} +\begin{tabular}{llccc} +\toprule +\textbf{Path} & \textbf{Description} & \textbf{Avg (ms)} & \textbf{Best (ms)} & \textbf{Worst (ms)} \\ +\midrule +HKG $\rightarrow$ NUE & Simulator to EMQX broker & 171.1 & 170.7 & 174.8 \\ +FARM $\rightarrow$ NUE & SSL termination to broker & 6.4 & 6.3 & 6.6 \\ +NUE $\rightarrow$ HAOS & Broker to Home Assistant & 8.4 & 8.0 & 9.4 \\ +FARM $\rightarrow$ HAOS & SSL termination to HA & 7.7 & 7.6 & 8.2 \\ +HAOS $\rightarrow$ ESP32 & Native API (LAN) & 0.3 & 0.2 & 0.4 \\ +\bottomrule +\end{tabular} +\end{table} + +The end-to-end latency for MQTT messages from the Hong Kong simulator to Home Assistant in Prague comprises the HKG--NUE path ($\sim$171\,ms) plus the NUE--HAOS path ($\sim$8\,ms), totaling approximately 180\,ms. In contrast, Native API connections within the local network achieve sub-millisecond latency, validating the dual-connection architecture design decision for local device responsiveness. + +\subsection{TLS Handshake Performance} +\label{subsec:tls-handshake} + +The deployed system uses X25519 for key exchange. Due to ESP-IDF / ESP-TLS constraints on X.509 certificate signature algorithms, the deployed certificate chain uses ECDSA with NIST P-256 (\texttt{prime256v1}) for authentication, while retaining X25519 for ECDHE key exchange during TLS~1.3 handshake. As established in Section~\ref{subsec:ecc-rsa}, NIST SP 800-57 confirms that 256-bit ECC provides equivalent security to 3072-bit RSA with significantly smaller key sizes~\cite{NIST_SP_800_57}. + +To contextualize the cost of cryptographic primitives during connection establishment, this thesis references the third-party microbenchmark published by Oryx Embedded for ESP32-S3 (Xtensa LX7 @ 240\,MHz), generated with CycloneCRYPTO 2.5.0 and compiled with GCC at optimization level \texttt{-O3}~\cite{oryx_crypto_benchmark_esp32s3}. The report lists ECDH (X25519) at approximately 14\,ms for public key generation and 15\,ms for shared secret computation. These figures are used as indicative reference points; absolute timings depend on the specific TLS stack, build configuration, and hardware acceleration availability. + +\subsection{Hybrid TLS Configuration Verification} +\label{subsec:hybrid-verification} + +To validate the hybrid cryptographic approach described in Section~\ref{subsubsec:hybrid-tls}, the deployed TLS configuration was tested using OpenSSL's diagnostic client. Table~\ref{tab:tls-verification} summarizes the negotiated parameters observed during mTLS handshake with the production EMQX broker. + +\begin{table}[htbp] +\centering +\caption{TLS Handshake Verification Results} +\label{tab:tls-verification} +\begin{tabular}{ll} +\toprule +\textbf{Parameter} & \textbf{Negotiated Value} \\ +\midrule +Protocol & TLS 1.3 \\ +Cipher Suite & \texttt{TLS\_AES\_256\_GCM\_SHA384} \\ +Key Exchange (Peer Temp Key) & X25519, 253 bits \\ +Signature Algorithm & \texttt{ecdsa\_secp256r1\_sha256} \\ +Server Certificate & ECDSA P-256 (prime256v1) \\ +Client Certificate & ECDSA P-256 (prime256v1) \\ +Certificate Verification & OK \\ +\bottomrule +\end{tabular} +\end{table} + +The verification confirms that the hybrid configuration operates as designed: certificates are signed using ECDSA P-256 (\texttt{ecdsa\_secp256r1\_sha256}), while key exchange utilizes X25519. This result demonstrates that TLS~1.3 successfully decouples the certificate signature algorithm from the key exchange mechanism, enabling optimization of each independently~\cite{rfc8446}. + +A comparative test was conducted by explicitly restricting the key exchange group to P-256: +\begin{verbatim} +openssl s_client -connect mqtt.eurun.top:8883 \ + -tls1_3 -groups P-256 +\end{verbatim} +This test confirmed fallback behavior: when X25519 is excluded from the \texttt{supported\_groups} extension, the handshake successfully negotiates ECDH with P-256 instead (\texttt{Peer Temp Key: ECDH, prime256v1, 256 bits}). This demonstrates the system's backward compatibility while preferring X25519 when available. + +\begin{figure}[H] +\centering +\includegraphics[width=0.95\textwidth]{images/25519.png} +\caption{TLS handshake with X25519 key exchange (default configuration).}\vspace{-0.5em} +\label{fig:tls-x25519} +\end{figure} + +\begin{figure}[H] +\centering +\includegraphics[width=0.95\textwidth]{images/p256.png} +\caption{TLS handshake with P-256 key exchange (fallback test using \texttt{-groups P-256}).}\vspace{-0.5em} +\label{fig:tls-p256} +\end{figure} + +\subsection{mTLS Connection Latency Benchmark} +\label{subsec:handshake-latency} + +To empirically measure the end-to-end mTLS connection establishment latency, the Python simulator's handshake benchmark mode (Python 3.11.2, paho-mqtt 1.6) was executed from the FARM host (Frankfurt, Germany) to an EMQX 6.0.0 broker (Nuremberg, Germany). This path exhibits a network RTT of approximately 6.4\,ms (Table~\ref{tab:network-latency}), minimizing the impact of network propagation delay on the measurement. + +Table~\ref{tab:handshake-latency} summarizes the measured mTLS handshake latency over 800 connection samples. The complete benchmark methodology and raw data are provided in Appendix~\ref{app:handshake-metrics}. + +\begin{table}[htbp] +\centering +\caption{mTLS Handshake Latency Benchmark (FARM $\rightarrow$ NUE, $n=800$)} +\label{tab:handshake-latency} +\begin{tabular}{lccccccccc} +\toprule +\textbf{Mean} & \textbf{P50} & \textbf{P90} & \textbf{P95} & \textbf{P99} & \textbf{Min} & \textbf{Max} & \textbf{Std} & \textbf{95\% CI} \\ +\midrule +80.50 & 80.55 & 91.61 & 92.82 & 96.79 & 67.84 & 104.07 & 7.49 & [79.98, 81.02] \\ +\bottomrule +\end{tabular} +\begin{tablenotes} +\small +\item All values in milliseconds (ms). P$n$ denotes the $n$th percentile; Std = standard deviation; 95\% CI = 95\% confidence interval for the mean. +\end{tablenotes} +\end{table} + +The measured mean latency of 80.50\,ms represents the complete mTLS connection establishment time from an x86\_64 host, including network round-trips and cryptographic operations. This benchmark primarily validates the network path stability and the EMQX broker's mTLS configuration---it does not reflect ESP32 client performance due to fundamental differences in hardware capability (x86 vs.\ Xtensa LX7) and TLS stack (OpenSSL vs.\ MbedTLS). + +For ESP32-S3 performance estimation, Table~\ref{tab:hybrid-performance} provides cryptographic primitive timings (approximately 89\,ms for handshake-related operations). Combined with network RTT, total connection latency for ESP32 clients on similar paths would be approximately 100--120\,ms---well within acceptable bounds for IoT reconnection scenarios. + +The P99 latency of 96.79\,ms confirms that even worst-case connection times remain under 100\,ms, which is suitable for IoT applications requiring responsive reconnection behavior. The narrow 95\% confidence interval ($\pm$0.52\,ms) and zero connection failures across 800 samples demonstrate excellent measurement repeatability and connection reliability. + +\subsection{Scalability Testing} +\label{subsec:scalability} + +The Python simulator was used to evaluate system scalability by progressively increasing the number of simulated devices. Each test configuration was monitored for approximately 5 minutes to capture steady-state resource utilization. Monitoring screenshots from EMQX Dashboard, broker system metrics, and Home Assistant are provided in Appendix~\ref{app:scalability-screenshots}. + +\begin{table}[htbp] +\centering +\caption{Scalability Test Results} +\label{tab:scalability} +\begin{tabular}{lccc} +\toprule +\textbf{Devices} & \textbf{Messages/sec} & \textbf{Broker CPU (\%)} & \textbf{HA CPU (\%)} \\ +\midrule +100 & $\sim$229 & 3.72 & 1.1 \\ +1,000 & $\sim$1,618 & 4.03 & 1.4 \\ +\bottomrule +\end{tabular} +\end{table} + +The test results demonstrate that the EMQX broker handles 1,000 concurrent simulated devices with minimal resource impact---CPU utilization increased by only 0.31 percentage points (from 3.72\% to 4.03\%) when scaling from 100 to 1,000 devices, while message throughput increased proportionally from 229 to 1,618 messages per second. Home Assistant CPU utilization remained low at 1.1--1.4\%, indicating substantial headroom for additional devices. + +Testing beyond 1,000 devices was limited by the simulator host's computational capacity (2~vCPU VPS). At 5,000 devices, the simulator process itself reached 100\% CPU utilization, making further scalability measurements unreflective of broker or Home Assistant limits. Nevertheless, the observed linear relationship between device count and message throughput, combined with near-constant broker CPU utilization, suggests the architecture can support significantly larger deployments. EMQX documentation reports theoretical limits of over 100 million concurrent connections in clustered configurations\footnote{\url{https://www.emqx.com/en/blog/reaching-100m-mqtt-connections-with-emqx-5-0}}~\cite{emqx_2024}. + + +% ============================================================================ +% 5.3 Security and Reliability +% ============================================================================ +\section{Security and Reliability} +\label{sec:security-reliability} + +The implemented security architecture addresses common IoT threat vectors through transport layer protection. All MQTT communications are encrypted using TLS 1.2/1.3, preventing eavesdropping and tampering~\cite{rfc8446}. Mutual TLS (mTLS) authentication ensures that only devices with valid client certificates can connect to the broker, mitigating unauthorized access and device impersonation attacks~\cite{cloudflare_mtls_2024}. + +The current implementation uses a single Certificate Authority for all certificates. While suitable for small deployments, production systems should consider intermediate CAs, automated certificate rotation, and CRL distribution. + +The system demonstrated stable operation during the development and testing period. ESP32 nodes exhibited resilient behavior, automatically reconnecting after WiFi disconnections or broker restarts. The dual-connection architecture proved valuable during internet outages, maintaining local control capability through Native API while MQTT connectivity was disrupted. + +% ============================================================================ +% 5.4 Comparison with Commercial Solutions +% ============================================================================ +\section{Comparison with Commercial Solutions} +\label{sec:comparison} + +This section compares the implemented system with commercial smart home platforms, analyzing trade-offs between different approaches. + +Xiaomi's Mi Home platform employs a cloud-centric architecture where device states are synchronized via cloud-based MQTT subscription and commands are transmitted through HTTP APIs\footnote{\url{https://www.home-assistant.io/integrations/xiaomi_miio/}}. Strengths include competitive device pricing, intuitive mobile application, and wide device ecosystem. Limitations include cloud dependency for most features (though local control is available for some devices via gateway or LAN protocols), regional server restrictions, and limited customization options. The Xiaomi Air Purifier integrated in this thesis demonstrates interoperability through Home Assistant's Xiaomi Miio integration. + +Voice-controlled platforms from Amazon and Google process commands through cloud-based speech recognition. Research has documented privacy implications of voice assistant data collection~\cite{voice_assistant_privacy_2019}. The Matter protocol initiative aims to improve cross-platform compatibility~\cite{matter_spec_2022}. Due to device availability constraints, analysis relies on published documentation and academic studies. + +\subsection{Comparative Analysis} +\label{subsec:comparative} + +Table~\ref{tab:platform-comparison} presents a comparison across key evaluation criteria. + +\begin{table}[htbp] +\centering +\caption{Platform Comparison Matrix} +\label{tab:platform-comparison} +\begin{threeparttable} +\begin{tabular}{lcccc} +\toprule +\textbf{Criterion} & \textbf{This System} & \textbf{Xiaomi} & \textbf{Alexa} & \textbf{Google} \\ +\midrule +Data Storage & Local & Cloud & Cloud & Cloud \\ +Privacy Control & Full & Limited & Limited & Limited \\ +Customization & High & Low & Medium & Medium \\ +Setup Complexity & Medium & Low & Low & Low \\ +Offline Capability & Full & Partial & Minimal & Minimal \\ +Vendor Independence & Full & None & None & None \\ +\bottomrule +\end{tabular} +\begin{tablenotes} +\small +\item Premium features may require subscription on commercial platforms +\end{tablenotes} +\end{threeparttable} +\end{table} + +The fundamental architectural difference lies in data storage location. Commercial platforms transmit sensor data to cloud servers, where it may be analyzed for service improvement, used for targeted advertising, or subject to data breaches. The implemented system maintains all data locally. + +Vendor dependency creates sustainability risks, as demonstrated by historical platform discontinuations. Open-source solutions eliminate this dependency by enabling community maintenance independent of any single vendor's business decisions. + +The comparison reveals a fundamental trade-off between convenience and control. The self-hosted approach has higher upfront complexity but offers greater control and learning value. Open-source frameworks like ESPHome can significantly lower the entry barrier compared to writing custom firmware~\cite{esphome_2024,homeassistant_2024}. Commercial ecosystems minimize initial setup complexity but introduce stronger vendor dependency~\cite{iot_vendor_lockin_2021}. + +The growing availability of Matter-compatible devices may reduce the technical barrier to local-first smart home deployments, potentially expanding adoption beyond technically sophisticated users. + + + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/implementation.tex b/docs/BT/CTU_FEL_THESIS/chapters/implementation.tex new file mode 100644 index 0000000..86ecdc8 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/implementation.tex @@ -0,0 +1,450 @@ +\chapter{Implementation} +\label{ch:implementation} + +This chapter details the implementation of all system components, including hardware sensor nodes, software simulator, MQTT broker configuration, and integration with Home Assistant. + +% ============================================================================ +% 4.1 Hardware Implementation +% ============================================================================ +\section{Hardware Implementation} +\label{sec:hardware} + +Two ESP32-based sensor nodes were implemented to demonstrate different IoT paradigms: edge intelligence and traditional environment sensing. The ESP32 platform was selected for its combination of dual-core processing, WiFi connectivity, and extensive peripheral support~\cite{esp32_datasheet_2024}. + +\subsection{ESP32-S3 Edge Intelligence Node} +\label{subsec:esp32s3} + +The ESP32-S3 node serves as an edge computing platform, performing local signal processing to reduce cloud dependency and enable real-time responses~\cite{esp32s3_datasheet_2024}. + +\begin{figure}[htbp] + \centering + \IfFileExists{images/ESP32-S3-WROOM-1.drawio.png}{% + \includegraphics[width=0.95\linewidth,height=0.4\textheight,keepaspectratio]{images/ESP32-S3-WROOM-1.drawio.png}% + }{% + \fbox{\parbox{0.95\linewidth}{\centering + Missing figure: \texttt{images/ESP32-S3-WROOM-1.drawio.png} + }}% + } + \caption{ESP32-S3 edge intelligence node with labeled sensor components.} + \label{fig:esp32s3-hardware} +\end{figure} + +\begin{table}[htbp] +\centering +\caption{ESP32-S3 Node Sensor Configuration} +\label{tab:esp32s3-sensors} +\begin{tabular}{llll} +\toprule +\textbf{Sensor} & \textbf{Model} & \textbf{Measurement} & \textbf{Interface} \\ +\midrule +Barometric & BMP180 & Temperature, Pressure & I2C \\ +Motion & MPU6050 (GY-521) & 6-axis Accelerometer/Gyro & I2C \\ +Acoustic & KY-037 & Sound Level & ADC \\ +\bottomrule +\end{tabular} +\end{table} + +The BMP180 barometric sensor and MPU6050 inertial measurement unit share the same I2C bus (GPIO4 for SCL, GPIO5 for SDA). This is possible because the I2C protocol supports multiple devices on a single two-wire bus through 7-bit addressing---each device responds only to its unique address (BMP180: \texttt{0x77}, MPU6050: \texttt{0x68})~\cite{i2c_spec_2021}. The shared-bus architecture reduces GPIO consumption from four pins to two while enabling bidirectional communication with both sensors. + +Table~\ref{tab:esp32s3-pinout} details the complete GPIO assignments and sensor module connections for the ESP32-S3 node. Each sensor module exposes multiple pins, but only a subset is required for basic operation; unused pins either provide redundant functionality or optional features not utilized in this implementation. + +\begin{table}[htbp] +\centering +\caption{ESP32-S3 Node Pin Connections and Sensor Module Details} +\label{tab:esp32s3-pinout} +\resizebox{\linewidth}{!}{% +\begin{tabular}{lllll} +\toprule +\textbf{Module} & \textbf{Pin} & \textbf{ESP32-S3 GPIO} & \textbf{Function} & \textbf{Notes} \\ +\midrule +\multirow{7}{*}{MPU6050\footnotemark[1]} + & VCC & 3V3 & Power (2.375--3.46\,V) & --- \\ + & GND & GND & Ground & --- \\ + & SCL & GPIO4 & I2C Clock & Shared with BMP180 \\ + & SDA & GPIO5 & I2C Data & Shared with BMP180 \\ + & XDA/XCL & --- & Aux I2C & --- \\ + & AD0 & --- & Address select & Unconnected = 0x68 \\ + & INT & --- & Interrupt & --- \\ +\midrule +\multirow{4}{*}{BMP180\footnotemark[2]} + & VIN & 3V3 & Power (1.8--3.6\,V) & --- \\ + & GND & GND & Ground & --- \\ + & SCL & GPIO4 & I2C Clock & Shared with MPU6050 \\ + & SDA & GPIO5 & I2C Data & Shared with MPU6050 \\ +\midrule +\multirow{4}{*}{KY-037\footnotemark[3]} + & VCC & 3V3 & Power (3.3--5\,V) & --- \\ + & GND & GND & Ground & --- \\ + & AO & GPIO6 & Analog output & Continuous sound level \\ + & DO & --- & Digital output & Threshold via potentiometer \\ +\bottomrule +\end{tabular}% +} +\end{table} +\footnotetext[1]{\url{https://invensense.tdk.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf}} +\footnotetext[2]{\url{https://cdn-shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf}} +\footnotetext[3]{\url{https://www.espboards.dev/sensors/ky-037/}} + +The firmware execution flow is depicted in Figure~\ref{fig:esp32s3-flowchart}. Upon boot, the device loads TLS configuration from \texttt{sdkconfig} and connects to WiFi. The subsequent MQTT connection triggers an mTLS handshake using ECDSA P-256 for certificate verification and X25519 for ephemeral key exchange (TLS~1.3). Sensor acquisition operates at differentiated rates: MPU6050 at 10\,Hz for fall detection, BMP180 at 0.2\,Hz for environmental monitoring, and KY-037 at 5\,Hz for acoustic sampling. Calibrated inertial data feeds the edge computing pipeline, which computes SMV and angular velocity for threshold-based fall detection. + +\begin{figure}[H] + \centering + \setlength{\abovecaptionskip}{2pt} + \setlength{\belowcaptionskip}{0pt} + \IfFileExists{images/ESP32S3_FC.png}{% + \includegraphics[width=\linewidth,height=0.92\textheight,keepaspectratio]{images/ESP32S3_FC.png}% + }{% + \fbox{\parbox{0.95\linewidth}{\centering + Missing figure: \texttt{images/ESP32S3_FC.png} + }}% + } + \caption{ESP32-S3 firmware execution flowchart: initialization with mTLS handshake (ECDSA P-256 + X25519), multi-rate sensor acquisition, edge computing for fall detection, and MQTT state publishing. The complete firmware listing is provided in Appendix~\ref{app:esp32s3-config}.} + \label{fig:esp32s3-flowchart} +\end{figure} + +The ESP32-S3's vector instruction set enables efficient implementation of edge computing algorithms. Table~\ref{tab:esp32s3-algorithms} summarizes the implemented edge algorithms, including a threshold-based fall detection algorithm adapted from Huynh et al.~\cite{huynh2015fall}. + +\begin{table}[htbp] +\centering +\caption{ESP32-S3 Edge Computing Algorithms} +\label{tab:esp32s3-algorithms} +\begin{tabular}{lll} +\toprule +\textbf{Algorithm} & \textbf{Formula} & \textbf{Purpose} \\ +\midrule +Resultant G-Force & $\text{SMV} = \sqrt{a_x^2 + a_y^2 + a_z^2}$ & Impact detection \\ +Dynamic Vibration & $|G - 1.0|$ & Motion isolation \\ +Angular Velocity Mag. & $\omega = \sqrt{\omega_x^2 + \omega_y^2 + \omega_z^2}$ & Rotation detection \\ +Acoustic Peak & ADC threshold & Sound event \\ +\bottomrule +\end{tabular} +\end{table} + +The fall detection algorithm implements a dual-threshold approach adapted from Huynh et al.~\cite{huynh2015fall}, which combines accelerometer and gyroscope data to distinguish falls from normal activities. A fall event is detected only when both the Signal Magnitude Vector (SMV) exceeds $2.4\,\text{G}$ and the angular velocity magnitude exceeds $240\,^{\circ}/\text{s}$. In the original study (36 subjects, 702 movements), this dual-sensor approach achieved 96.3\% sensitivity and 96.2\% specificity, compared to 82.72\% specificity with accelerometer-only detection---the gyroscope data significantly reduces false positives from high-acceleration activities such as running. + +It should be noted that gyroscope utility depends on the detection methodology. Casilari et al.~\cite{casilari2020gyroscope} evaluated CNN-based classification on the SisFall dataset and found that accelerometer-only input outperformed combined accelerometer-gyroscope input. This suggests that threshold-based algorithms benefit from explicit rotational velocity checks, whereas deep learning architectures can implicitly extract discriminative features from acceleration signals alone. + +For this implementation, the threshold-based approach was selected for several practical reasons. First, it provides computational efficiency suitable for the ESPHome framework, which does not natively support neural network inference. Second, the explicit dual-threshold logic offers interpretable detection decisions, facilitating debugging and parameter tuning. Third, the algorithm requires minimal memory footprint compared to CNN models. + +Nevertheless, the ESP32-S3 platform offers significant potential for future enhancement through its vector instruction extensions and the ESP-NN optimized neural network kernels\footnote{\url{https://github.com/espressif/esp-nn}}~\cite{esp_nn_2024}. According to Espressif's benchmarks\footnote{\url{https://github.com/espressif/esp-tflite-micro\#performance-comparison}}, TensorFlow Lite Micro with ESP-NN achieves a 42$\times$ speedup on ESP32-S3 compared to unoptimized execution, reducing the inference time for a person detection model from 2300\,ms to just 54\,ms~\cite{tflite_micro_espressif_2024}. This performance demonstrates that the CNN-based fall detection approach recommended by Casilari et al. is feasible on ESP32-S3 hardware. Such an upgrade would require migrating from ESPHome to the native ESP-IDF framework with TFLite Micro integration, potentially achieving higher detection accuracy with accelerometer-only input while eliminating the gyroscope sensor cost. This represents a promising direction for future development. + +Figure~\ref{fig:fall-detection-flowchart} illustrates the real-time fall detection algorithm executed on the ESP32-S3. Each sensor cycle computes SMV from tri-axial accelerometer readings and angular velocity magnitude from gyroscope data; both values must exceed their thresholds simultaneously to trigger a fall event, minimizing false positives from high-impact activities. + +\begin{figure}[htbp] + \centering + \IfFileExists{images/Fall_FC.png}{% + \includegraphics[width=0.85\linewidth,height=0.75\textheight,keepaspectratio]{images/Fall_FC.png}% + }{% + \fbox{\parbox{0.75\linewidth}{\centering Fall Detection Flowchart (Fall\_FC.png not found)}} + } + \caption{Fall detection algorithm flowchart: dual-threshold decision logic using SMV ($>2.4\,\text{G}$) and angular velocity ($>240\,^{\circ}/\text{s}$) for robust fall event classification.} + \label{fig:fall-detection-flowchart} +\end{figure} + +\subsubsection{MPU6050 Sensor Calibration} +\label{subsubsec:mpu6050-calibration} + +MEMS inertial sensors such as the MPU6050 exhibit systematic bias errors---defined as the average output when no input is applied~\cite{ieee_inertial_terminology_2019}---that must be compensated through calibration. The calibration procedure follows standard zero-offset compensation: the sensor is placed on a level surface in a stationary state, and the deviation from expected values is measured over multiple samples~\cite{mpu6050_datasheet_2013}. + +Table~\ref{tab:mpu6050-calibration} presents the calibration parameters derived from stationary measurements. For the accelerometer, the X and Y axes should read zero when level, while the Z-axis should read $-g \approx -9.807\,\text{m/s}^2$ (with the sensor chip facing upward). For the gyroscope, all three axes should read zero when stationary. + +\begin{table}[htbp] +\centering +\caption{MPU6050 Calibration Parameters from Stationary Measurements} +\label{tab:mpu6050-calibration} +\begin{tabular}{llrrrr} +\toprule +\textbf{Axis} & \textbf{Type} & \textbf{Expected} & \textbf{Raw} & \textbf{Offset} & \textbf{Calibrated} \\ +\midrule +$a_x$ & Accel. & $0\,\text{m/s}^2$ & $+0.853$ & $-0.877$ & $-0.024$ \\ +$a_y$ & Accel. & $0\,\text{m/s}^2$ & $-0.173$ & $-0.145$ & $-0.318$ \\ +$a_z$ & Accel. & $-9.807\,\text{m/s}^2$ & $-9.243$ & $-0.564$ & $-9.807$ \\ +$\omega_x$ & Gyro. & $0\,^{\circ}/\text{s}$ & $-2.55$ & $+2.53$ & $-0.02$ \\ +$\omega_y$ & Gyro. & $0\,^{\circ}/\text{s}$ & $+2.45$ & $-2.68$ & $-0.23$ \\ +$\omega_z$ & Gyro. & $0\,^{\circ}/\text{s}$ & $-2.91$ & $+2.44$ & $-0.47$ \\ +\bottomrule +\end{tabular} +\end{table} + +The gyroscope bias is particularly critical for the fall detection algorithm, as uncalibrated values would introduce a constant offset of approximately $4.6\,^{\circ}/\text{s}$ to the angular velocity magnitude calculation ($\omega = \sqrt{\omega_x^2 + \omega_y^2 + \omega_z^2}$). After calibration, the residual error is reduced to approximately $0.5\,^{\circ}/\text{s}$---negligible compared to the $240\,^{\circ}/\text{s}$ detection threshold. The calibration offsets are applied as ESPHome filter configurations, adding the offset value to each raw reading before further processing. + +\clearpage +\subsection{ESP32 Environment Sensing Node} +\label{subsec:esp32} + +The standard ESP32 node focuses on environmental monitoring and safety detection with local automation capabilities. + +\begin{figure}[htbp] + \centering + \IfFileExists{images/ESP32.drawio.png}{% + \includegraphics[width=0.9\linewidth,height=0.4\textheight,keepaspectratio]{images/ESP32.drawio.png}% + }{% + \fbox{\parbox{0.95\linewidth}{\centering + Missing figure: \texttt{images/ESP32.drawio.png} + }}% + } + \caption{ESP32 environment sensing node with labeled sensor components.} + \label{fig:esp32-hardware} +\end{figure} + +\begin{table}[htbp] +\centering +\caption{ESP32 Node Sensor Configuration} +\label{tab:esp32-sensors} +\begin{tabular}{llll} +\toprule +\textbf{Sensor} & \textbf{Model} & \textbf{Measurement} & \textbf{Interface} \\ +\midrule +Color/Light & TCS34725 & RGB, Lux & I2C \\ +Gas & MQ-2 & Smoke/Combustible gas & ADC \\ +Motion & SR602 & PIR presence & GPIO \\ +Indicator & RGB LED & Status feedback & PWM \\ +\bottomrule +\end{tabular} +\end{table} + +\textbf{Power Supply Considerations.} +Unlike other sensors that operate on 3.3\,V logic levels, the MQ-2 gas sensor requires a dedicated 5\,V supply connected to the VIN pin. This requirement stems from the sensor's internal tin dioxide (SnO$_2$) heating element, which must maintain a specific operating temperature for accurate gas detection. According to the manufacturer datasheet, the heater voltage ($V_H$) must be $5.0\,\text{V} \pm 0.1\,\text{V}$, with a heater resistance of $29\,\Omega \pm 3\,\Omega$ and power consumption up to 950\,mW~\cite{mq2_datasheet_2014}. Supplying only 3.3\,V would result in insufficient heater temperature, causing unreliable gas concentration readings. The analog output (AO) pin, however, remains 3.3\,V tolerant and connects directly to the ESP32's ADC input (GPIO34). + +Table~\ref{tab:esp32-pinout} details the complete GPIO assignments for the ESP32 environment sensing node. +\clearpage + +\begin{table}[htbp] +\centering +\caption{ESP32 Node Pin Connections and Sensor Module Details} +\label{tab:esp32-pinout} +\resizebox{\linewidth}{!}{% +\begin{tabular}{lllll} +\toprule +\textbf{Module} & \textbf{Pin} & \textbf{ESP32 GPIO} & \textbf{Function} & \textbf{Notes} \\ +\midrule +\multirow{6}{*}{TCS34725\footnotemark[4]} + & VIN & 3V3 & Power (2.7--3.6\,V) & --- \\ + & GND & GND & Ground & --- \\ + & SCL & GPIO32 & I2C Clock & Address 0x29 (fixed) \\ + & SDA & GPIO33 & I2C Data & --- \\ + & LED & GPIO25 & White LED control & Illumination for color sensing \\ + & INT & --- & Interrupt & --- \\ +\midrule +\multirow{4}{*}{MQ-2\footnotemark[5]} + & VCC & VIN (5V) & Heater power & $V_H = 5.0\,\text{V} \pm 0.1\,\text{V}$ \\ + & GND & GND & Ground & --- \\ + & AO & GPIO34 & Analog output & 0--3.3\,V proportional to gas \\ + & DO & --- & Digital output & Threshold via comparator \\ +\midrule +\multirow{3}{*}{SR602 PIR} + & VCC & 3V3 & Power (3.3--5\,V) & --- \\ + & GND & GND & Ground & --- \\ + & OUT & GPIO23 & Digital output & High on motion detection \\ +\midrule +\multirow{4}{*}{RGB LED} + & R & GPIO26 & Red channel & LEDC PWM (8-bit) \\ + & G & GPIO27 & Green channel & LEDC PWM (8-bit) \\ + & B & GPIO14 & Blue channel & LEDC PWM (8-bit) \\ + & GND & GND & Ground & --- \\ +\bottomrule +\end{tabular}% +} +\end{table} +\footnotetext[4]{\url{https://cdn-shop.adafruit.com/datasheets/TCS34725.pdf}} +\footnotetext[5]{\url{https://www.winsen-sensor.com/d/files/semiconductor/mq-2.pdf}} + + +The ESP32 node employs an identical mTLS configuration to the ESP32-S3 (Section~\ref{subsec:esp32s3}). As shown in Figure~\ref{fig:esp32-flowchart}, this node emphasizes on-device automation rather than edge analytics. The MQ-2 smoke sensor triggers threshold-based alerts at 5\,Hz sampling, while the SR602 PIR sensor operates in interrupt-driven mode. Both sensors directly control the RGB LED indicator without cloud dependency. + +\clearpage +\begin{figure}[p] + \centering + \IfFileExists{images/ESP32_FC.png}{% + \includegraphics[width=\linewidth,height=0.88\textheight,keepaspectratio]{images/ESP32_FC.png}% + }{% + \fbox{\parbox{0.95\linewidth}{\centering + Missing figure: \texttt{images/ESP32_FC.png} + }}% + } + \caption{ESP32 firmware execution flowchart: initialization with mTLS handshake, sensor acquisition, local automation rules for smoke detection and motion response, and MQTT state publishing. The complete firmware listing is provided in Appendix~\ref{app:esp32-config}.} + \label{fig:esp32-flowchart} +\end{figure} +\clearpage + +Local automation rules execute directly on the device: when the MQ-2 sensor voltage exceeds 2.5V, the RGB LED activates red pulsing effect and publishes an alert message to MQTT; SR602 motion detection triggers green LED illumination for visual feedback. Both nodes employ the dual-path communication design described in Section~\ref{sec:comm-arch}, with \texttt{discovery: true} enabling automatic entity registration in Home Assistant through the MQTT discovery protocol. The complete ESPHome configuration listings for both nodes, including TLS configuration and edge computing lambda expressions, are provided in Appendix~\ref{app:esphome}. + +% ============================================================================ +% 4.2 Software and Server Implementation +% ============================================================================ +\section{Software and Server Implementation} +\label{sec:software} + +The deployed system is operated as a hybrid-cloud infrastructure comprising four distinct nodes that span public cloud locations and a private home network. The nodes are interconnected using a Tailscale mesh VPN that implements a Zero Trust Network Access (ZTNA) model, enabling service exposure without assigning a public IP address to the local controller. + +\subsection{Server Environment and Virtualization} +\label{subsec:server-env} + +The hybrid-cloud infrastructure comprises four nodes spanning public cloud locations and a private home network (Table~\ref{tab:host-runtime}). The deployment demonstrates portability across heterogeneous hardware, including both x86\_64 and ARM64 architectures. + +\begin{table}[htbp] +\centering +\caption{Deployment Host Runtime Summary} +\label{tab:host-runtime} +\resizebox{\linewidth}{!}{% +\begin{tabular}{lllll} +\toprule +\textbf{Node} & \textbf{Location} & \textbf{Role} & \textbf{OS / Kernel} & \textbf{Arch / Resources} \\ +\midrule +NUE & Nuremberg, DE & EMQX broker (Docker) & Debian 13 / 6.12.57 & x86\_64, 4 vCPU, 8 GB \\ +FARM & Frankfurt, DE & SSL termination, bastion & Debian 12 / 6.1.0-41 & arm64, 4 vCPU, 24 GB \\ +HKG & Hong Kong, CN & Stress testing & Debian 12 / 6.1.0-39 & x86\_64, 2 vCPU, 2 GB \\ +HAOS & Prague, CZ & Home Assistant (ESXi VM) & HAOS / 6.12.51-haos & x86\_64, 4 vCPU, 4 GB \\ +\bottomrule +\end{tabular}% +} +\end{table} + +Internet-facing nodes (NUE, FARM, HKG) enable BBR congestion control with FQ queueing to improve throughput stability~\cite{cardwell_bbr_2016}, while the local controller (HAOS) uses the default cubic/fq\_codel configuration. For large-scale experiments, open-file limits were raised to $10^6$ on public nodes, and TCP keepalive was set to 10\,s on HKG for rapid detection of broken connections. + +\subsection{EMQX Broker Deployment} +\label{subsec:emqx} + +EMQX\footnote{\url{https://www.emqx.io/}} was selected as the MQTT broker for its performance characteristics and native mTLS support~\cite{emqx_2024}. The broker is hosted on the NUE node, exposing a single Internet-facing endpoint on port 8883 with mutual TLS authentication. The management dashboard is bound to loopback and published through OpenResty reverse proxy. + +The broker was deployed using Docker (Docker Compose) to ensure reproducible configuration across environments. In high-concurrency scenarios, the Linux per-process file descriptor limit inside the container can become a bottleneck (a common default is 1024). Therefore, the deployment explicitly increases the \texttt{nofile} limit via Compose \texttt{ulimits} (Appendix~\ref{app:emqx-docker}). This adjustment is required to support large numbers of simultaneous MQTT/TLS connections. + +\subsection{Python Sensor Simulator} +\label{subsec:simulator} + +The Python sensor simulator (\texttt{smarthome\_sim} package) provides virtual entity emulation for testing Home Assistant integration without physical hardware. Key features include configurable device counts, Home Assistant discovery payloads, mTLS connectivity, and multi-process execution. The simulator also supports load generation for scalability benchmarking as a secondary function, with results presented in Chapter~\ref{ch:evaluation}. Key code excerpts demonstrating the mTLS connection handling and entity simulation logic are provided in Appendix~\ref{app:simulator}. A sample terminal output showing the simulator in operation is presented in Appendix~\ref{app:simulator-terminal}. + +Figure~\ref{fig:simulator-flowchart} illustrates the high-level workflow of the Python simulator, from configuration loading through entity publishing. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/py_chartflow.png}{% + \includegraphics[width=0.80\linewidth]{images/py_chartflow.png}% +}{% + \fbox{\parbox{0.85\linewidth}{\centering + Missing figure: \texttt{images/py\_chartflow.png} + }}% +} +\caption{Python sensor simulator workflow: configuration loading, mTLS connection establishment, Home Assistant discovery publishing, and event-driven simulation loop with heap-based scheduling.} +\label{fig:simulator-flowchart} +\end{figure} + +ESPHome configurations are maintained as YAML files supporting custom logic through lambda expressions for edge computing calculations. The complete ESPHome configuration files for both sensor nodes are provided in Appendix~\ref{app:esphome}. +\clearpage +% ============================================================================ +% 4.3 Home Assistant Integration +% ============================================================================ +\section{Home Assistant Integration} +\label{sec:ha-integration} + +Home Assistant's MQTT discovery feature enables automatic entity registration without manual configuration. Devices publish JSON payloads to designated discovery topics containing entity metadata, state topics, and device information. This mechanism reduces deployment friction and ensures consistent entity configuration across restarts. Home Assistant dashboards provide real-time visualization of sensor data and control interfaces, including sensor readings with historical graphs, device connectivity status, automation trigger history, and alert notifications. + +\begin{figure}[htbp] + \centering + \IfFileExists{images/ha_dashboard.png}{% + \includegraphics[width=0.95\linewidth]{images/ha_dashboard.png}% + }{% + \fbox{\parbox{0.95\linewidth}{\centering + Missing figure: \texttt{images/ha\_dashboard.png} + }}% + } + \caption{Home Assistant dashboard displaying real-time sensor data and device controls.} + \label{fig:ha-dashboard} +\end{figure} + +\clearpage +% ============================================================================ +% 4.4 Data Pipeline and Automation +% ============================================================================ +\section{Data Pipeline and Automation} +\label{sec:data-pipeline} + +InfluxDB\footnote{\url{https://www.influxdata.com/}} serves as the time-series database for long-term sensor data retention~\cite{influxdb_2024}. Home Assistant's native integration automatically writes entity state changes, enabling historical analysis, trend detection, and anomaly identification. Figure~\ref{fig:influxdb-query} demonstrates a query result showing one hour of G-force measurements from the ESP32-S3 fall detection sensor, with data points aggregated at regular intervals. Grafana\footnote{\url{https://grafana.com/}} connects to InfluxDB as a data source, providing advanced visualization capabilities including multi-sensor overlay comparisons, statistical aggregations, threshold-based alerting, and custom time range analysis (Figure~\ref{fig:grafana-sensors}). + +\begin{figure}[H] + \centering + \setlength{\abovecaptionskip}{2pt} + \setlength{\belowcaptionskip}{0pt} + \IfFileExists{images/influxdb.png}{% + \includegraphics[width=0.85\linewidth]{images/influxdb.png}% + }{% + \fbox{\parbox{0.85\linewidth}{\centering + Missing figure: \texttt{images/influxdb.png} + }}% + } + \caption{InfluxDB query result showing G-force sensor data over a one-hour period, demonstrating time-series data retention for historical analysis.} + \label{fig:influxdb-query} +\end{figure} + +\begin{figure}[H] + \centering + \setlength{\abovecaptionskip}{2pt} + \setlength{\belowcaptionskip}{0pt} + \IfFileExists{images/grafana.png}{% + \includegraphics[width=0.85\linewidth]{images/grafana.png}% + }{% + \fbox{\parbox{0.85\linewidth}{\centering + Missing figure: \texttt{images/grafana.png} + }}% + } + \caption{Grafana dashboard displaying real-time sensor data: barometric pressure (hPa), G-force magnitude, and MQ-2 smoke sensor analog voltage (V).} + \label{fig:grafana-sensors} +\end{figure} + +Native Home Assistant automations handle event-driven responses using YAML configuration, demonstrating integration between hardware sensors and mobile notifications. Node-RED\footnote{\url{https://nodered.org/}} provides visual flow-based programming for complex automation scenarios requiring multi-branch conditional logic, data transformation, or external API integration. Figure~\ref{fig:nodered-flow} illustrates the fall detection notification flow implemented in Node-RED. + +\begin{figure}[H] + \centering + \setlength{\abovecaptionskip}{2pt} + \setlength{\belowcaptionskip}{0pt} + \IfFileExists{images/node-red.png}{% + \includegraphics[width=0.9\linewidth]{images/node-red.png}% + }{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/node-red.png} + }}% + } + \caption{Node-RED flow for fall detection notification: sensor state triggers iOS push notification and persistent HA alert.} + \label{fig:nodered-flow} +\end{figure} +% \clearpage +Figure~\ref{fig:fall-detection-demo} demonstrates the complete fall detection pipeline in operation. The ESP32-S3 node continuously computes the Signal Magnitude Vector (SMV) from three-axis accelerometer data and the angular velocity magnitude from three-axis gyroscope data. When both computed values exceed their respective thresholds ($\text{SMV} > 2.4\,\text{G}$ and $\omega > 240\,^{\circ}/\text{s}$), the binary sensor state transitions to \texttt{unsafe}, triggering the Node-RED automation to deliver notifications via iOS push and Home Assistant persistent notification. + +\begin{figure}[H] + \centering + \setlength{\abovecaptionskip}{2pt} + \setlength{\belowcaptionskip}{0pt} + \IfFileExists{images/red.png}{% + \includegraphics[width=0.77\linewidth]{images/red.png}% + }{% + \fbox{\parbox{0.77\linewidth}{\centering + Missing figure: \texttt{images/red.png} + }}% + } + \caption{Fall detection demonstration: (P1)~sensor data computation on ESP32-S3 dashboard, (P2)~iOS critical notification, and (P3)~Home Assistant persistent alert.} + \label{fig:fall-detection-demo} +\end{figure} + +% \clearpage +\subsection{Backup Strategy} +\label{subsec:backup} + +Home Assistant provides built-in backup functionality supporting both local and cloud storage destinations. The deployed system implements a two-tier backup strategy: local backups are created every three days with 14 retained copies (covering approximately six weeks of recovery points), while cloud backups to Google Drive are performed daily with 30-day retention. This configuration ensures rapid recovery from local storage for recent issues while maintaining off-site protection against hardware failures or local disasters. + +\begin{figure}[htbp] + \centering + \IfFileExists{images/backup_SET.png}{% + \includegraphics[width=0.9\linewidth]{images/backup_SET.png}% + }{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/backup\_SET.png} + }}% + } + \caption{Home Assistant backup configuration interface showing local and cloud backup schedules.} + \label{fig:backup-config} +\end{figure} + +While this approach does not constitute a full 3-2-1 backup strategy (three copies, two media types, one off-site), it provides practical data protection appropriate for a demonstration deployment. The combination of local and cloud storage destinations addresses the most common failure scenarios: accidental configuration changes can be recovered from local backups within seconds, while storage device failures are protected by cloud redundancy. + + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/chapters/introduction.tex b/docs/BT/CTU_FEL_THESIS/chapters/introduction.tex new file mode 100644 index 0000000..058dcaf --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/chapters/introduction.tex @@ -0,0 +1,100 @@ +\chapter{Introduction} +\label{ch:introduction} + +% ============================================================================ +% 1.1 Background and Motivation +% ============================================================================ +\section{Background and Motivation} +\label{sec:background} + +The concept of smart homes has evolved significantly over the past decade, transforming from a futuristic vision into a widely deployed class of residential systems. Smart home systems integrate various sensors, actuators, and control platforms to provide automated environmental monitoring, security surveillance, and energy management capabilities~\cite{smarthome_survey_2020}. + +At the core of modern smart home architectures lie servers and Unix-like operating systems that provide the computational infrastructure for data processing, storage, and decision-making. These systems handle the aggregation of sensor data from potentially hundreds of devices, execute automation rules, and provide user interfaces for monitoring and control. + +The proliferation of Internet of Things (IoT) devices has created new challenges in terms of scalability, security, and interoperability~\cite{iot_architecture_2019}. Commercial smart home platforms such as Amazon Alexa, Google Home, and Xiaomi Mi Home offer convenient solutions but often rely on cloud connectivity and raise concerns about data privacy and ecosystem dependency~\cite{voice_assistant_privacy_2019,iot_vendor_lockin_2021}. + +% ============================================================================ +% 1.2 Problem Statement +% ============================================================================ +\section{Problem Statement} +\label{sec:problem} + +Despite the availability of numerous commercial smart home solutions, several challenges remain inadequately addressed: + +\begin{itemize} + \item \textbf{Data Sovereignty:} Commercial platforms typically transmit sensor data to cloud servers, limiting user control over personal information and raising privacy concerns. + + \item \textbf{Vendor Lock-in:} Proprietary ecosystems restrict device interoperability and create dependency on specific manufacturers, as evidenced by platform discontinuations that render devices unusable~\cite{iot_vendor_lockin_2021}. + + \item \textbf{Security Vulnerabilities:} Many IoT devices lack adequate security measures, with unencrypted communications and weak authentication mechanisms being common issues~\cite{iot_security_survey_2019}. + + \item \textbf{Scalability Limitations:} Consumer-grade solutions often struggle to handle large numbers of devices or high-frequency sensor data streams. + + \item \textbf{Latency and Availability:} Reliance on remote cloud processing and wide-area networks can introduce variable end-to-end latency and reduce system availability during internet outages, which motivates local-first and edge-oriented designs~\cite{edge_computing_iot_2016}. + + \item \textbf{Limited Customization:} Commercial ecosystems are typically designed for common household scenarios, making it difficult to implement specialized requirements (e.g., custom sensors, non-standard automation logic, or constrained network environments) without relying on vendor-specific extensions. +\end{itemize} + +This thesis addresses these challenges by designing and implementing an open-source smart home system that prioritizes local data processing, secure communications, and scalable architecture. + +% ============================================================================ +% 1.3 Research Objectives +% ============================================================================ +\section{Research Objectives} +\label{sec:objectives} + +The primary objectives of this thesis are threefold: + +\begin{enumerate} + \item \textbf{Analytical Objective:} Analyze the role of servers and Unix-like systems in smart home sensor monitoring and control, examining the architectural patterns and communication protocols employed in modern IoT deployments. + + \item \textbf{Design Objective:} Design and implement a model smart home system using the MQTT protocol and Home Assistant platform, demonstrating integration of both real hardware sensors (ESP32/ESP32-S3) and Python-based simulated devices that appear as Home Assistant entities, with the simulator additionally enabling scalable load generation for benchmarking. + + \item \textbf{Evaluation Objective:} Compare the implemented solution with commercial alternatives in terms of scalability, performance, privacy, and reliability, supported by representative measurements and qualitative system characterization. +\end{enumerate} + +% ============================================================================ +% 1.4 Thesis Organization +% ============================================================================ +\section{Thesis Organization} +\label{sec:organization} + +The remainder of this thesis is organized as follows: + +\textbf{Chapter~\ref{ch:background}} introduces the theoretical background, covering smart home systems, the MQTT protocol, transport layer security, Home Assistant and ESPHome, edge computing, and the role of Unix-like systems in IoT infrastructure. + +\textbf{Chapter~\ref{ch:architecture}} presents the system architecture and overall design choices, with emphasis on the communication flow, deployment topology, and security considerations. + +\textbf{Chapter~\ref{ch:implementation}} describes the implementation of hardware sensor nodes, the Python-based simulator, Home Assistant integration, and supporting data pipeline and automation components. + +\textbf{Chapter~\ref{ch:evaluation}} presents empirical evaluation covering performance characteristics, scalability, security considerations, system reliability, and a comparative analysis with commercial smart home platforms. + +\textbf{Chapter~\ref{ch:conclusion}} summarizes the contributions, outlines limitations, and suggests directions for future work. + +% ============================================================================ +% 1.5 Thesis Contributions Overview +% ============================================================================ +\clearpage +\section{Thesis Contributions Overview} +\label{sec:scope-of-work} + +Figure~\ref{fig:contribution-overview} illustrates the system architecture developed in this thesis. The implementation builds upon a rich ecosystem of open-source technologies spanning messaging infrastructure (EMQX), home automation (Home Assistant, Node-RED), embedded firmware frameworks (ESPHome, mbedTLS), time-series data management (InfluxDB, Grafana), containerization and deployment (Docker, Nginx), and secure networking (Tailscale). Green-shaded components indicate areas where the author performed design, development, or integration work. + +\begin{figure}[htbp] +\centering +\IfFileExists{images/Architecture.drawio.png}{% + \includegraphics[width=0.95\linewidth]{images/Architecture.drawio.png}% +}{% + \fbox{\parbox{0.9\linewidth}{\centering + Missing figure: \texttt{images/Architecture.drawio.png}\\[1em] + \textbf{Suggested content:}\\[0.5em] + \textit{Green boxes} = Work performed in this thesis\\[0.5em] + \textit{Blue boxes} = Open-source platforms utilized + }}% +} +\caption{System architecture overview. Green: work performed in this thesis; Blue: open-source platforms utilized.} +\label{fig:contribution-overview} +\end{figure} + + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/CTU_FEL_THESIS/images/25519.png b/docs/BT/CTU_FEL_THESIS/images/25519.png new file mode 100644 index 0000000..daf4fde Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/25519.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/38_An_NC.pdf b/docs/BT/CTU_FEL_THESIS/images/38_An_NC.pdf new file mode 100644 index 0000000..d927e44 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/38_An_NC.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/images/Architecture.drawio.png b/docs/BT/CTU_FEL_THESIS/images/Architecture.drawio.png new file mode 100644 index 0000000..b9a77bb Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/Architecture.drawio.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/ESP32-S3-WROOM-1.drawio.png b/docs/BT/CTU_FEL_THESIS/images/ESP32-S3-WROOM-1.drawio.png new file mode 100644 index 0000000..fcde46b Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/ESP32-S3-WROOM-1.drawio.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/ESP32.drawio.png b/docs/BT/CTU_FEL_THESIS/images/ESP32.drawio.png new file mode 100644 index 0000000..0513116 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/ESP32.drawio.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/ESP32S3_FC.png b/docs/BT/CTU_FEL_THESIS/images/ESP32S3_FC.png new file mode 100644 index 0000000..b129117 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/ESP32S3_FC.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/ESP32_FC.png b/docs/BT/CTU_FEL_THESIS/images/ESP32_FC.png new file mode 100644 index 0000000..7f82771 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/ESP32_FC.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/ESPHome.png b/docs/BT/CTU_FEL_THESIS/images/ESPHome.png new file mode 100644 index 0000000..6785790 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/ESPHome.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/F3-DP-2020-Garg-Ashish-Garg_Ashish_Diploma_Thesis.pdf b/docs/BT/CTU_FEL_THESIS/images/F3-DP-2020-Garg-Ashish-Garg_Ashish_Diploma_Thesis.pdf new file mode 100644 index 0000000..ff4b9ef Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/F3-DP-2020-Garg-Ashish-Garg_Ashish_Diploma_Thesis.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/images/Fall_FC.png b/docs/BT/CTU_FEL_THESIS/images/Fall_FC.png new file mode 100644 index 0000000..acad3a0 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/Fall_FC.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/HAOS_100.png b/docs/BT/CTU_FEL_THESIS/images/HAOS_100.png new file mode 100644 index 0000000..89b5676 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/HAOS_100.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/HAOS_1000.png b/docs/BT/CTU_FEL_THESIS/images/HAOS_1000.png new file mode 100644 index 0000000..beee58b Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/HAOS_1000.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/HA_dashboard copy.png b/docs/BT/CTU_FEL_THESIS/images/HA_dashboard copy.png new file mode 100644 index 0000000..50bebf4 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/HA_dashboard copy.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/HA_dashboard.png b/docs/BT/CTU_FEL_THESIS/images/HA_dashboard.png new file mode 100644 index 0000000..f801f4e Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/HA_dashboard.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/LogoCVUT.pdf b/docs/BT/CTU_FEL_THESIS/images/LogoCVUT.pdf new file mode 100644 index 0000000..4b07160 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/LogoCVUT.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/images/MQTT_PublishSubscribeArchitecture.pdf b/docs/BT/CTU_FEL_THESIS/images/MQTT_PublishSubscribeArchitecture.pdf new file mode 100644 index 0000000..a00d759 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/MQTT_PublishSubscribeArchitecture.pdf differ diff --git a/docs/BT/CTU_FEL_THESIS/images/backup_SET.png b/docs/BT/CTU_FEL_THESIS/images/backup_SET.png new file mode 100644 index 0000000..83ef018 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/backup_SET.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/broker_100.png b/docs/BT/CTU_FEL_THESIS/images/broker_100.png new file mode 100644 index 0000000..b7786ee Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/broker_100.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/broker_1000.png b/docs/BT/CTU_FEL_THESIS/images/broker_1000.png new file mode 100644 index 0000000..19d8a34 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/broker_1000.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/broker_1000_dash.png b/docs/BT/CTU_FEL_THESIS/images/broker_1000_dash.png new file mode 100644 index 0000000..1add8f6 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/broker_1000_dash.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/broker_100_dash.png b/docs/BT/CTU_FEL_THESIS/images/broker_100_dash.png new file mode 100644 index 0000000..f1d3176 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/broker_100_dash.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/broker_5000.png b/docs/BT/CTU_FEL_THESIS/images/broker_5000.png new file mode 100644 index 0000000..2892a0a Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/broker_5000.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/esphome32s3_mem.png b/docs/BT/CTU_FEL_THESIS/images/esphome32s3_mem.png new file mode 100644 index 0000000..f27452a Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/esphome32s3_mem.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/esphomeS3.png b/docs/BT/CTU_FEL_THESIS/images/esphomeS3.png new file mode 100644 index 0000000..f5c17d4 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/esphomeS3.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/grafana.png b/docs/BT/CTU_FEL_THESIS/images/grafana.png new file mode 100644 index 0000000..cc77160 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/grafana.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/haos_esxi.png b/docs/BT/CTU_FEL_THESIS/images/haos_esxi.png new file mode 100644 index 0000000..e4cb57b Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/haos_esxi.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/how_tls_works-what_is_mutual_tls.png b/docs/BT/CTU_FEL_THESIS/images/how_tls_works-what_is_mutual_tls.png new file mode 100644 index 0000000..6c8f95f Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/how_tls_works-what_is_mutual_tls.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/influxdb.png b/docs/BT/CTU_FEL_THESIS/images/influxdb.png new file mode 100644 index 0000000..b59237d Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/influxdb.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/metrics.png b/docs/BT/CTU_FEL_THESIS/images/metrics.png new file mode 100644 index 0000000..55e633c Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/metrics.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/metrics1.png b/docs/BT/CTU_FEL_THESIS/images/metrics1.png new file mode 100644 index 0000000..ab2f5ba Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/metrics1.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/node-red.png b/docs/BT/CTU_FEL_THESIS/images/node-red.png new file mode 100644 index 0000000..6468b24 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/node-red.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/p256.png b/docs/BT/CTU_FEL_THESIS/images/p256.png new file mode 100644 index 0000000..154a191 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/p256.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/py_chartflow.png b/docs/BT/CTU_FEL_THESIS/images/py_chartflow.png new file mode 100644 index 0000000..70018c5 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/py_chartflow.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/red.png b/docs/BT/CTU_FEL_THESIS/images/red.png new file mode 100644 index 0000000..801380f Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/red.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/simpy.png b/docs/BT/CTU_FEL_THESIS/images/simpy.png new file mode 100644 index 0000000..6a2c0c2 Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/simpy.png differ diff --git a/docs/BT/CTU_FEL_THESIS/images/system_architecture.drawio.png b/docs/BT/CTU_FEL_THESIS/images/system_architecture.drawio.png new file mode 100644 index 0000000..656502a Binary files /dev/null and b/docs/BT/CTU_FEL_THESIS/images/system_architecture.drawio.png differ diff --git a/docs/BT/CTU_FEL_THESIS/latexmkrc b/docs/BT/CTU_FEL_THESIS/latexmkrc new file mode 100644 index 0000000..857cd32 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/latexmkrc @@ -0,0 +1,25 @@ +# latexmk configuration (LuaLaTeX) +# When running latexmk without explicit file args (e.g., `latexmk -C`), +# use the thesis main file by default. +@default_files = ('thesis-final.tex'); + +$pdf_mode = 4; # 4 = lualatex + +# Better diagnostics +$interaction = 'nonstopmode'; +$lualatex = 'lualatex -file-line-error -interaction=nonstopmode %O %S'; + +# latexmk's `-pdf` flag normally selects the `pdflatex` rule. To avoid +# accidentally compiling with pdfTeX (pdflatex), map that rule to LuaLaTeX too. +$pdflatex = $lualatex; + +# Keep output visible; suppressing it makes debugging harder. +$silent = 0; + +# Bibliography +$bibtex_use = 2; # 2 = biber (biblatex backend) + +# Glossaries +# This template uses \makenoidxglossaries, so no external makeglossaries step. + +$clean_ext .= ' acn acr alg glo glg gls glsdefs ist loa lol lot out run.xml bbl blg bcf bbl-SAVE-ERROR'; diff --git a/docs/BT/CTU_FEL_THESIS/literature.bib b/docs/BT/CTU_FEL_THESIS/literature.bib new file mode 100644 index 0000000..f7d565e --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/literature.bib @@ -0,0 +1,634 @@ +% ============================================================================ +% Bibliography Database for Bachelor Thesis +% Topic: Smart Home, MQTT, IoT, Home Assistant +% ============================================================================ + +% ---------------------------------------------------------------------------- +% MQTT Protocol +% ---------------------------------------------------------------------------- + +@misc{mqtt_oasis_2019, + author = {{OASIS}}, + title = {{MQTT} Version 5.0}, + year = {2019}, + howpublished = {OASIS Standard}, + url = {https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html}, + note = {Accessed: 2025-11-03} +} + +@article{mqtt_iot_survey_2017, + author = {Naik, Nitin}, + title = {Choice of Effective Messaging Protocols for {IoT} Systems: {MQTT}, {CoAP}, {AMQP} and {HTTP}}, + journal = {IEEE International Systems Engineering Symposium (ISSE)}, + year = {2017}, + pages = {1--7}, + doi = {10.1109/SysEng.2017.8088251} +} + +@inproceedings{mqtt_performance_2018, + author = {Yokotani, Tetsuya and Sasaki, Yuya}, + title = {Comparison with {HTTP} and {MQTT} on Required Network Resources for {IoT}}, + booktitle = {International Conference on Control, Electronics, Renewable Energy and Communications (ICCEREC)}, + year = {2016}, + pages = {1--6}, + doi = {10.1109/ICCEREC.2016.7814989} +} + +@misc{emqx_pubsub_2023, + author = {{EMQX Team}}, + title = {Introduction to {MQTT} Publish-Subscribe Pattern}, + year = {2023}, + howpublished = {EMQX Blog}, + url = {https://www.emqx.com/en/blog/mqtt-5-introduction-to-publish-subscribe-model}, + note = {Accessed: 2025-11-08} +} + +% ---------------------------------------------------------------------------- +% Smart Home and IoT +% ---------------------------------------------------------------------------- + +@article{smarthome_survey_2020, + author = {Sovacool, Benjamin K. and Del Rio, Dylan D. Furszyfer}, + title = {Smart Home Technologies in {Europe}: A Critical Review of Concepts, Benefits, Risks and Policies}, + journal = {Renewable and Sustainable Energy Reviews}, + volume = {120}, + year = {2020}, + pages = {109663}, + doi = {10.1016/j.rser.2019.109663} +} + +@article{iot_architecture_2019, + author = {Sethi, Pallavi and Sarangi, Smruti R.}, + title = {{Internet of Things}: Architectures, Protocols, and Applications}, + journal = {Journal of Electrical and Computer Engineering}, + year = {2017}, + volume = {2017}, + pages = {1--25}, + doi = {10.1155/2017/9324035} +} + +@inproceedings{edge_computing_iot_2016, + author = {Shi, Weisong and Cao, Jie and Zhang, Quan and Li, Youhuizi and Xu, Lanyu}, + title = {Edge Computing: Vision and Challenges}, + booktitle = {IEEE Internet of Things Journal}, + year = {2016}, + volume = {3}, + number = {5}, + pages = {637--646}, + doi = {10.1109/JIOT.2016.2579198} +} + +% ---------------------------------------------------------------------------- +% Security +% ---------------------------------------------------------------------------- + +@article{iot_security_survey_2019, + author = {Neshenko, Nataliia and Bou-Harb, Elias and Crichigno, Jorge and Kaddoum, Georges and Ghani, Nasir}, + title = {Demystifying {IoT} Security: An Exhaustive Survey on {IoT} Vulnerabilities and a First Empirical Look on Internet-Scale {IoT} Exploitations}, + journal = {IEEE Communications Surveys \& Tutorials}, + year = {2019}, + volume = {21}, + number = {3}, + pages = {2702--2733}, + doi = {10.1109/COMST.2019.2910750} +} + +@techreport{NIST_SP_800_57, + author = {{National Institute of Standards and Technology}}, + title = {Recommendation for Key Management: Part 1 -- General}, + institution = {NIST}, + year = {2020}, + type = {Special Publication}, + number = {800-57 Part 1 Rev. 5}, + doi = {10.6028/NIST.SP.800-57pt1r5}, + note = {Defines security strength equivalences for cryptographic algorithms; Table 2 (pp. 54--55) used for ECC vs RSA key-size equivalence} +} + +@misc{openssl_2024, + author = {{OpenSSL Software Foundation}}, + title = {{OpenSSL}: Cryptography and {SSL/TLS} Toolkit}, + year = {2024}, + howpublished = {\url{https://www.openssl.org/}}, + note = {Accessed: 2025-11-15; widely deployed open-source TLS implementation} +} + +@misc{cloudflare_mtls_2024, + author = {{Cloudflare}}, + title = {What is mutual {TLS} ({mTLS})?}, + year = {2024}, + howpublished = {Cloudflare Learning Center}, + url = {https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/}, + note = {Accessed: 2025-11-22} +} + +% ---------------------------------------------------------------------------- +% Home Assistant and Open Source +% ---------------------------------------------------------------------------- + +@misc{homeassistant_2024, + author = {{Home Assistant}}, + title = {Home Assistant Documentation}, + year = {2024}, + howpublished = {\url{https://www.home-assistant.io/docs/}}, + note = {Accessed: 2025-11-05} +} + +@misc{haos_buildroot_2024, + author = {{Home Assistant}}, + title = {Home Assistant Operating System}, + year = {2024}, + howpublished = {GitHub repository documentation}, + url = {https://github.com/home-assistant/operating-system}, + note = {Accessed: 2025-11-28} +} + +@misc{ha_docker_base_2024, + author = {{Home Assistant}}, + title = {Home Assistant Base Images (Docker)}, + year = {2024}, + howpublished = {GitHub repository documentation}, + url = {https://github.com/home-assistant/docker-base}, + note = {Accessed: 2025-12-02} +} + +@misc{influxdb_2024, + author = {{InfluxData}}, + title = {{InfluxDB}: Open Source Time Series Database}, + year = {2024}, + howpublished = {Official product documentation}, + url = {https://docs.influxdata.com/influxdb/v2/}, + note = {Accessed: 2025-12-08; purpose-built time-series database for high-performance IoT data storage and querying} +} + +% ---------------------------------------------------------------------------- +% Espressif hardware datasheets +% ---------------------------------------------------------------------------- + +@misc{esp32_datasheet_2024, + author = {{Espressif Systems}}, + title = {ESP32 Datasheet}, + year = {2024}, + howpublished = {Technical datasheet}, + url = {https://documentation.espressif.com/esp32_datasheet_en.pdf}, + note = {Accessed: 2025-11-12} +} + +@misc{esp32s3_datasheet_2024, + author = {{Espressif Systems}}, + title = {ESP32-S3 Datasheet}, + year = {2024}, + howpublished = {Technical datasheet}, + url = {https://documentation.espressif.com/esp32-s3_datasheet_en.pdf}, + note = {Accessed: 2025-11-12} +} + +@misc{esphome_2024, + author = {{ESPHome}}, + title = {{ESPHome} Documentation}, + year = {2024}, + howpublished = {\url{https://esphome.io/}}, + note = {Accessed: 2025-11-18} +} + +@misc{emqx_2024, + author = {{EMQ Technologies}}, + title = {Reaching 100{M} {MQTT} Connections with {EMQX} 5.0}, + year = {2022}, + howpublished = {\url{https://www.emqx.com/en/blog/reaching-100m-mqtt-connections-with-emqx-5-0}}, + note = {Accessed: 2025-11-25. Test achieved 100M concurrent connections on 23-node cluster (3 core + 20 replicant nodes) using c6g.metal instances.} +} + +% ---------------------------------------------------------------------------- +% Commercial Platforms +% ---------------------------------------------------------------------------- + +@article{voice_assistant_privacy_2019, + author = {Edu, Jide S. and Such, Jose M. and Suarez-Tangil, Guillermo}, + title = {Smart Home Personal Assistants}, + journal = {ACM Computing Surveys}, + year = {2021}, + volume = {53}, + number = {6}, + pages = {1--36}, + doi = {10.1145/3412383}, + note = {Subtitle: {A Security and Privacy Review}. Published online 2020-12-06; published in print 2021-11-30.} +} + +@inproceedings{iot_vendor_lockin_2021, + author = {Alrawi, Omar and Lever, Chaz and Antonakakis, Manos and Monrose, Fabian}, + title = {{SoK}: Security Evaluation of Home-Based {IoT} Deployments}, + booktitle = {2019 {IEEE} Symposium on Security and Privacy ({SP})}, + year = {2019}, + pages = {1362--1380}, + doi = {10.1109/SP.2019.00013} +} + +% ---------------------------------------------------------------------------- +% Matter Protocol +% ---------------------------------------------------------------------------- + +@misc{matter_spec_2022, + author = {{Connectivity Standards Alliance}}, + title = {Matter Specification Version 1.0}, + year = {2022}, + howpublished = {\url{https://csa-iot.org/all-solutions/matter/}}, + note = {Accessed: 2025-12-15} +} + +% ---------------------------------------------------------------------------- +% Unix/Linux and performance engineering +% ---------------------------------------------------------------------------- + +@book{kerrisk_2010, + author = {Kerrisk, Michael}, + title = {The Linux Programming Interface: A Linux and {UNIX} System Programming Handbook}, + year = {2010}, + publisher = {No Starch Press}, + isbn = {9781593272203} +} + +@book{gregg_systems_performance_2020, + author = {Gregg, Brendan}, + title = {Systems Performance: Enterprise and the Cloud}, + edition = {2}, + year = {2020}, + publisher = {Addison-Wesley} +} + +@article{cardwell_bbr_2016, + author = {Cardwell, Neal and Cheng, Yuchung and Gunn, C. Stephen and Hassas Yeganeh, Soheil and Jacobson, Van}, + title = {{BBR}: Congestion-Based Congestion Control}, + journal = {ACM Queue}, + year = {2016}, + volume = {14}, + number = {5}, + doi = {10.1145/3012426.3022184}, + url = {https://queue.acm.org/detail.cfm?id=3022184}, + note = {Accessed: 2025-12-28} +} + +% ---------------------------------------------------------------------------- +% Hardware & Cryptography Benchmarks (Critical for Section 2.3 & 5.x) +% ---------------------------------------------------------------------------- + +@misc{oryx_crypto_benchmark_esp32s3, + author = {{Oryx Embedded}}, + title = {Crypto Benchmark on {ESP32-S3} {MCU} (Xtensa LX7 @ 240 {MHz})}, + year = {2024}, + howpublished = {Technical Benchmark Report (CycloneCRYPTO 2.5.0)}, + url = {https://www.oryx-embedded.com/benchmark/espressif/crypto-esp32-s3.html}, + note = {Accessed: 2025-12-18. Benchmark generated with CycloneCRYPTO 2.5.0 and GCC -O3 on ESP32-S3 @ 240MHz. Selected figures: ECDH (X25519) 14 ms (pubkey) / 15 ms (shared secret) (software); RSA-2048 490 ms (sign, software) / 118 ms (sign, hardware); ECDSA (secp256r1) 67 ms (sign, hardware) / 60 ms (verify, hardware); Ed25519 26 ms (sign, software) / 24 ms (verify, software).} +} + +@misc{oryx_crypto_benchmark_esp32, + author = {{Oryx Embedded}}, + title = {Crypto Benchmark on {ESP32} {MCU} (Xtensa LX6 @ 240 {MHz})}, + year = {2024}, + howpublished = {Technical Benchmark Report (CycloneCRYPTO 2.5.0)}, + url = {https://www.oryx-embedded.com/benchmark/espressif/crypto-esp32.html}, + note = {Accessed: 2025-12-22. Ed25519: 29 ms sign / 28 ms verify (software); ECDSA P-256: 62 ms / 57 ms (hardware); RSA-3072: 465 ms / 314 ms (hardware).} +} + +@misc{safecurves_2017, + author = {Bernstein, Daniel J. and Lange, Tanja}, + title = {{SafeCurves}: Choosing Safe Curves for Elliptic-Curve Cryptography}, + year = {2017}, + howpublished = {Cryptographic research website}, + url = {https://safecurves.cr.yp.to/}, + note = {Accessed: 2025-11-30. Evaluates ECC curves against security criteria including rigidity, twist safety, and completeness. NIST P-256 fails the rigidity test.} +} + +@misc{bernstein_ecdsa_blog_2014, + author = {Bernstein, Daniel J.}, + title = {How to Design an Elliptic-Curve Signature System}, + year = {2014}, + month = mar, + howpublished = {The cr.yp.to blog}, + url = {https://blog.cr.yp.to/20140323-ecdsa.html}, + note = {Accessed: 2025-12-05. Critiques ECDSA design decisions; discusses DSA standardization by NSA/NIST and explains Ed25519's deterministic nonce derivation.} +} + +% dd +@inproceedings{bernstein_ed25519_2012, + author = {Bernstein, Daniel J. and Duif, Niels and Lange, Tanja and Schwabe, Peter and Yang, Bo-Yin}, + title = {High-Speed High-Security Signatures}, + booktitle = {Journal of Cryptographic Engineering}, + year = {2012}, + volume = {2}, + number = {2}, + pages = {77--89}, + doi = {10.1007/s13389-012-0027-1}, + note = {The foundational paper for the Ed25519 signature algorithm.} +} + +@misc{bernstein_curve25519_2006, + author = {Bernstein, Daniel J.}, + title = {Curve25519: New Diffie-Hellman Speed Records}, + year = {2006}, + howpublished = {Cryptology ePrint Archive / technical report}, + url = {https://cr.yp.to/ecdh/curve25519-20060209.pdf}, + note = {Accessed: 2025-12-12. Introduces Curve25519 and its efficient Montgomery-ladder-based scalar multiplication.} +} + +@misc{rfc7748, + author = {Langley, Adam and Hamburg, Mike and Turner, Sean}, + title = {Elliptic Curves for Security}, + year = {2016}, + howpublished = {RFC 7748}, + url = {https://www.rfc-editor.org/rfc/rfc7748}, + note = {Accessed: 2025-11-10. Specifies X25519/X448 and discusses implementation considerations for secure, constant-time scalar multiplication.} +} + +@misc{rfc8032, + author = {Josefsson, Simon and Liusvaara, Ilari}, + title = {Edwards-Curve Digital Signature Algorithm ({EdDSA})}, + year = {2017}, + howpublished = {RFC 8032}, + url = {https://www.rfc-editor.org/rfc/rfc8032}, + note = {Accessed: 2025-11-14. Specifies Ed25519/Ed448 and the deterministic nonce generation used by EdDSA.} +} + +@misc{rfc8446, + author = {Rescorla, Eric}, + title = {The Transport Layer Security ({TLS}) Protocol Version 1.3}, + year = {2018}, + howpublished = {RFC 8446}, + url = {https://www.rfc-editor.org/rfc/rfc8446}, + note = {Accessed: 2025-12-01. Defines TLS 1.3, including optional certificate-based client authentication used by mutual TLS deployments.} +} + +% ---------------------------------------------------------------------------- +% Network Tunneling (Critical for Chapter 3 - Tailscale) +% ---------------------------------------------------------------------------- + +% dd +@inproceedings{donenfeld_wireguard_2017, + author = {Donenfeld, Jason A.}, + title = {{WireGuard}: Next Generation Kernel Network Tunnel}, + booktitle = {Network and Distributed System Security Symposium (NDSS)}, + year = {2017}, + publisher = {Internet Society}, + doi = {10.14722/ndss.2017.23160}, + note = {The underlying protocol used by Tailscale.} +} + +% ---------------------------------------------------------------------------- +% Third-party Integrations (Critical for Chapter 3 - Voice Assistants & Commercial Devices) +% ---------------------------------------------------------------------------- + + + +@misc{esp_idf_nvs_2024, + author = {{Espressif Systems}}, + title = {Non-Volatile Storage Library ({NVS})}, + year = {2024}, + howpublished = {ESP-IDF Programming Guide}, + url = {https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/storage/nvs_flash.html}, + note = {Accessed: 2025-11-19. Provides encrypted key-value storage for ESP32 credentials.} +} + + + +% ---------------------------------------------------------------------------- +% Thesis Assignment Required References +% ---------------------------------------------------------------------------- + +@inproceedings{bhatnagar_wifi_smarthome_2018, + author = {Bhatnagar, Harsh Vardhan and Kumar, Praveen and Rawat, Seema and Choudhury, Tanupriya}, + title = {Implementation model of {Wi-Fi} based Smart Home System}, + booktitle = {2018 International Conference on Advanced Computation and Communication Engineering (ICACCE)}, + year = {2018}, + doi = {10.1109/ICACCE.2018.8441703}, + publisher = {IEEE}, + note = {Discusses Wi-Fi-based smart home architecture using microcontrollers and mobile applications.} +} + +@inproceedings{khan_iot_smarthome_2018, + author = {Khan, Aftab and Al-Zahrani, Saad and Fahad, Mohammad and Saad, Abdullah}, + title = {Design of an {IoT} Smart Home System}, + booktitle = {2018 15th Learning and Technology Conference (L\&T)}, + year = {2018}, + pages = {1--5}, + doi = {10.1109/LT.2018.8368484}, + publisher = {IEEE}, + note = {Presents IoT-based smart home design with sensor integration and remote monitoring.} +} + +@inproceedings{xiao_wifi_iot_2018, + author = {Xiao, Zheng and Liu, Deng and Cao, Dongsheng and Wang, Xinggang}, + title = {Home Appliance Control System in Smart Home based on {WiFi} {IoT}}, + booktitle = {2018 IEEE 3rd Advanced Information Technology, Electronic and Automation Control Conference (IAEAC)}, + year = {2018}, + doi = {10.1109/IAEAC.2018.8577217}, + publisher = {IEEE}, + note = {Proposes a WiFi-based IoT architecture for home appliance control.} +} + +% ---------------------------------------------------------------------------- +% ESP-IDF and Mbed TLS +% ---------------------------------------------------------------------------- + +@misc{esp_tls_2024, + author = {{Espressif Systems}}, + title = {{ESP-TLS}: {TLS} Library for {ESP-IDF}}, + year = {2024}, + howpublished = {ESP-IDF Programming Guide}, + url = {https://docs.espressif.com/projects/esp-idf/en/v5.5.2/esp32/api-reference/protocols/esp_tls.html}, + note = {Accessed: 2025-12-11. Documents supported ECDSA curves (SECP256R1, SECP384R1) and TLS configuration options.} +} + +@misc{wolfssl_2024, + author = {{wolfSSL Inc.}}, + title = {wolfSSL Embedded {SSL/TLS} Library}, + year = {2024}, + howpublished = {Product Documentation}, + url = {https://www.wolfssl.com/products/wolfssl/}, + note = {Accessed: 2025-12-14. Lightweight TLS library supporting TLS~1.3, Curve25519, Ed25519, and post-quantum cryptography; designed for embedded and resource-constrained environments.} +} + +@misc{mbedtls_ed25519_issue, + author = {{Mbed TLS Contributors}}, + title = {Add support for {Ed25519} in {X.509} certificates}, + year = {2019}, + howpublished = {GitHub Issue \#2452}, + url = {https://github.com/Mbed-TLS/mbedtls/issues/2452}, + note = {Accessed: 2025-12-21. Feature request for Ed25519 certificate signature support in Mbed TLS.} +} + +@misc{mbedtls_roadmap_2024, + author = {{Mbed TLS Project}}, + title = {Mbed {TLS} Roadmap}, + year = {2024}, + howpublished = {Mbed TLS Documentation}, + url = {https://mbed-tls.readthedocs.io/en/latest/project/roadmap/}, + note = {Accessed: 2025-11-26. Official project roadmap indicates EdDSA (Ed25519) support planned for future releases.} +} + +@misc{esp_sleep_modes_2024, + author = {{Espressif Systems}}, + title = {{ESP-IDF} Sleep Modes}, + year = {2024}, + howpublished = {ESP-IDF Programming Guide}, + url = {https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html}, + note = {Accessed: 2025-12-27. Documents Light-sleep and Deep-sleep power saving modes; Wi-Fi/Bluetooth must be disabled before entering deep sleep, requiring connection re-establishment upon wake.} +} + +% ---------------------------------------------------------------------------- +% Fall Detection Algorithms +% ---------------------------------------------------------------------------- + +@article{huynh2015fall, + author = {Huynh, Quoc T. and Nguyen, Uyen D. and Irazabal, Lucia B. and Ghassemian, Nazanin and Tran, Binh Q.}, + title = {Optimization of an Accelerometer and Gyroscope-Based Fall Detection Algorithm}, + journal = {Journal of Sensors}, + year = {2015}, + volume = {2015}, + pages = {1--8}, + doi = {10.1155/2015/452078}, + note = {Proposes optimized threshold values: UFT\_acc = 2.4 G, UFT\_gyro = 240°/s. Achieves 96.3\% sensitivity and 96.2\% specificity.} +} + +@article{casilari2020gyroscope, + author = {Casilari, Eduardo and Álvarez-Marco, Moisés and García-Lagos, Francisco}, + title = {A Study of the Use of Gyroscope Measurements in Wearable Fall Detection Systems}, + journal = {Symmetry}, + year = {2020}, + volume = {12}, + number = {4}, + pages = {649}, + doi = {10.3390/sym12040649}, + note = {CNN-based study using SisFall dataset. Concludes that gyroscope data does NOT improve deep learning fall detection; accelerometer-only achieves better results.} +} + +@misc{tflite_micro_espressif_2024, + author = {{Espressif Systems}}, + title = {{ESP-TFLite-Micro}: {TensorFlow} Lite Micro for {Espressif} Chipsets}, + year = {2024}, + url = {https://github.com/espressif/esp-tflite-micro}, + note = {Accessed: 2025-12-04. Person Detection benchmark: ESP32-S3 achieves 54ms inference with ESP-NN (vs 2300ms without).} +} + +@misc{esp_nn_2024, + author = {{Espressif Systems}}, + title = {{ESP-NN}: Optimised Neural Network Functions for {Espressif} Chipsets}, + year = {2024}, + url = {https://github.com/espressif/esp-nn}, + note = {Accessed: 2025-12-09. Provides assembly-optimized kernels for ESP32-S3 vector instructions, achieving up to 10x speedup for convolution operations.} +} + +@techreport{ieee_inertial_terminology_2019, + author = {{IEEE}}, + title = {{IEEE} Standard for Inertial Sensor Terminology}, + institution = {Institute of Electrical and Electronics Engineers}, + year = {2019}, + number = {IEEE Std 528-2019}, + doi = {10.1109/IEEESTD.2019.8863799}, + note = {Revision of IEEE Std 528-2001. Defines terminology for inertial sensors including bias, scale factor, and noise parameters.} +} + +@manual{mpu6050_datasheet_2013, + author = {{InvenSense Inc.}}, + title = {{MPU-6000} and {MPU-6050} Product Specification Revision 3.4}, + year = {2013}, + organization = {InvenSense Inc.}, + url = {https://invensense.tdk.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf}, + note = {Accessed: 2026-01-02. Specifies accelerometer zero-g output tolerance of $\pm$80\,mg and gyroscope zero-rate output of $\pm$20\,$^{\circ}$/s, indicating the need for individual sensor calibration.} +} + +@manual{mq2_datasheet_2014, + author = {{Zhengzhou Winsen Electronics}}, + title = {{MQ-2} Semiconductor Smoke Sensor}, + year = {2015}, + organization = {Zhengzhou Winsen Electronics Technology Co., Ltd.}, + url = {https://www.winsen-sensor.com/d/files/semiconductor/mq-2.pdf}, + note = {Manual Version 1.4 (2015-03-10). Heater voltage VH = 5.0\,V $\pm$0.1\,V; heater resistance RH = 29\,$\Omega$ $\pm$3\,$\Omega$; heater power $\leq$950\,mW; preheat time $>$48 hours.} +} + +@book{i2c_spec_2021, + author = {{NXP Semiconductors}}, + title = {{I2C}-bus Specification and User Manual, Rev.\@ 7.0}, + year = {2021}, + publisher = {NXP Semiconductors}, + url = {https://www.nxp.com/docs/en/user-guide/UM10204.pdf}, + note = {Accessed: 2026-01-07. Defines I2C multi-master bus protocol with 7-bit addressing supporting up to 128 devices on shared SDA/SCL lines.} +} + +@article{osa_3dprint_iot_2025, + author = {Osa-Sanchez, Ainhoa and Garcia-Zapirain, Begonya}, + title = {Real-Time Air Quality Monitoring: A Smart {IoT} System Using Low-Cost Sensors and {3-D} Printing}, + journal = {IEEE Journal of Radio Frequency Identification}, + volume = {9}, + year = {2025}, + pages = {65--79}, + doi = {10.1109/JRFID.2025.3541816}, + note = {Demonstrates custom 3D-printed enclosures for portable IoT sensor nodes with Raspberry Pi; validated 95.30\% pollutant detection reliability.} +} + +@article{dhawale_3dprint_enclosure_2022, + author = {Dhawale, Nandkishor M. and Ghewade, Dinkar V. and Patil, Sanket S. and Gangatirkar, Rajiv S. and Inamdar, Neeraj A.}, + title = {An Application of {3D} Printing Technology for Rapid Prototyping of an {IoT} Enabled Sensor Enclosure}, + journal = {International Journal of Innovative Research in Science, Engineering and Technology (IJIRSET)}, + volume = {11}, + number = {2}, + year = {2022}, + pages = {1178--1185}, + doi = {10.15680/IJIRSET.2022.1102038}, + note = {Presents methodology for designing and fabricating custom sensor enclosures using FDM 3D printing, comparing cost-effectiveness with injection moulding for IoT prototyping.} +} +% ---------------------------------------------------------------------------- +% Missing References (Added 2026-01-16) +% ---------------------------------------------------------------------------- + +@misc{cloudflare_mtls_2026, + author = {{Cloudflare}}, + title = {What is mutual {TLS} ({mTLS})?}, + year = {2026}, + howpublished = {Cloudflare Learning Center}, + url = {https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/}, + note = {Accessed: 2026-01-03} +} + +@misc{haos_buildroot_2026, + author = {{Home Assistant}}, + title = {Home Assistant Operating System}, + year = {2026}, + howpublished = {GitHub repository documentation}, + url = {https://github.com/home-assistant/operating-system}, + note = {Accessed: 2026-01-02} +} + +@misc{xiaomi_home_ha_2024, + author = {{Xiaomi}}, + title = {Xiaomi Home Integration for {Home Assistant}}, + year = {2024}, + howpublished = {GitHub repository}, + url = {https://github.com/XiaoMi/ha_xiaomi_home}, + note = {Accessed: 2026-01-03. Imports Xiaomi MIoT devices into Home Assistant via cloud API or local gateway.} +} + +@misc{hacs_2024, + author = {{HACS}}, + title = {{HACS}: Home Assistant Community Store}, + year = {2024}, + howpublished = {\url{https://hacs.xyz/}}, + url = {https://hacs.xyz/}, + note = {Accessed: 2026-01-03. Community-maintained package manager for Home Assistant custom integrations.} +} + +@misc{zeus_smarthome_2021, + author = {{Zeus Integrated}}, + title = {Smart Home Automation}, + year = {2021}, + howpublished = {Commercial website}, + url = {https://zeusintegrated.com/solutions/smart-home-automation}, + note = {Accessed: 2026-01-04. Overview of commercial smart home automation solutions.} +} + +@misc{wolfssl_curve25519_2024, + author = {{wolfSSL Inc.}}, + title = {wolfSSH Now Includes {Curve25519} Support}, + year = {2024}, + howpublished = {wolfSSL Blog}, + url = {https://www.wolfssl.com/wolfssh-now-includes-curve25519-support/}, + note = {Accessed: 2026-01-05. Announces Curve25519 key exchange support in wolfSSH v1.4.17; wolfSSL library provides full Ed25519 and X25519 support for embedded TLS applications.} +} diff --git a/docs/BT/CTU_FEL_THESIS/thesis-final.tex b/docs/BT/CTU_FEL_THESIS/thesis-final.tex new file mode 100644 index 0000000..76a87a9 --- /dev/null +++ b/docs/BT/CTU_FEL_THESIS/thesis-final.tex @@ -0,0 +1,136 @@ +% !TeX program = lualatex +% !TeX spellcheck = en_US +\documentclass{bachelorthesis} +% \documentclass[print]{bachelorthesis} + +% Ensure TeX appends line endings to .aux/.toc writes (prevents corrupted files +% when \endlinechar is changed by external tooling or packages). +\endlinechar=13 +\usepackage[english]{babel} +\usepackage{csquotes} % Required by biblatex + +%% Additional packages for thesis content +\usepackage{booktabs} % Better tables +\usepackage{multirow} % Multi-row cells in tables +\usepackage{listings} % Code listings +\usepackage{xcolor} % Colors for listings +\usepackage{amsmath} % Math support +\usepackage{amssymb} % Math symbols +\usepackage{graphicx} % Figures +\usepackage{tabularx} +\usepackage{array} + +% Typesetting robustness (helps avoid minor overfull \hbox warnings) +\emergencystretch=1em + +%% Code listing style +% Define YAML language for listings +\lstdefinelanguage{yaml}{ + keywords={true,false,null,y,n}, + keywordstyle=\color{blue}\bfseries, + basicstyle=\ttfamily\small, + sensitive=false, + comment=[l]{\#}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{gray}\ttfamily, + stringstyle=\color{teal}\ttfamily, + morestring=[b]', + morestring=[b]", +} +\lstset{ + basicstyle=\ttfamily\small, + breaklines=true, + frame=single, + numbers=left, + numberstyle=\tiny, + tabsize=2 +} + +%% Acronyms +\usepackage[acronym,toc]{glossaries} +\usepackage{threeparttable} % For table notes +\usepackage{float} % Provides the [H] float specifier (exact placement) +\usepackage{pdfpages} % Include external PDF pages +% No external makeglossaries step required (works on Overleaf and locally). +\makenoidxglossaries +\input{acronyms} + +%% Bibliography database +\addbibresource{literature.bib} + +% Note: biblatex requires running biber (latexmk will handle this automatically). + +% Metadata +\university{Czech Technical University in Prague} +\faculty{Faculty of Electrical Engineering} +\department{Department of Microelectronics} + +% Use \csname to avoid any editor/JSON escaping issues with \t... +\csname thesistype\endcsname{Bachelor thesis} +\studyprogram{Electrical Engineering and Computer Science} + +\csname title\endcsname{Application of Servers and Unix-like Systems for Sensor Control in Smart Homes} +\author{Weize Yuan} + +\supervisor{prof. Ing. Miroslav Hus{\'a}k, CSc.} +\supervisorAffiliation{ + Department of Microelectronics\\ + Faculty of Electrical Engineering\\ + Czech Technical University in Prague\\ + Technická 2\\ + 160 00 Prague 6\\ + Czech Republic} + +\placeyear{Prague 2026} +\date{2026} + +\begin{document} + +%% Front matter +\maketitle + +%% Assignment page (official thesis assignment document) +\includepdf[pages=-]{chapters/document_23_filename_1.pdf} + +%% Declaration (required by CTU FEE) +\includepdf[pages=-]{chapters/Declaration.pdf} +% \input{chapters/declaration} % deprecated - use PDF version(the Framework Rules for the Use of Artificial Intelligence at CTU for Academic and Pedagogical Purposes in Bachelor’s and Continuing Master’s Programmes.) + +%% Acknowledgements +\input{chapters/acknowledgements} + +%% Abstract (English + Czech required) +\input{chapters/abstract} + +%% Table of Contents (as per CTU requirements, includes page numbers) +\tableofcontents + +%% List of Acronyms +% Print the list even if you haven't used \gls{...} yet. +\glsaddallunused +\printnoidxglossary[type=\acronymtype,title=List of Acronyms,toctitle=List of Acronyms] + +%% List of Figures and Tables +\listoffigures +\listoftables + +%% Main text +\mainmatter +\input{chapters/introduction} +\input{chapters/background} +\input{chapters/architecture} +\input{chapters/implementation} +\input{chapters/evaluation} +\input{chapters/conclusion} + +%% Appendices +\appendix +\input{chapters/appendix} + +%% Bibliography +\backmatter +\printbibliography[heading=bibintoc,title={Bibliography}] + +\end{document} + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/BT/Review/opponent_report_Koller.pdf b/docs/BT/Review/opponent_report_Koller.pdf new file mode 100644 index 0000000..9ccbea8 Binary files /dev/null and b/docs/BT/Review/opponent_report_Koller.pdf differ diff --git a/docs/BT/Review/supervisor_report.pdf b/docs/BT/Review/supervisor_report.pdf new file mode 100644 index 0000000..3243211 Binary files /dev/null and b/docs/BT/Review/supervisor_report.pdf differ diff --git a/docs/README.md b/docs/README.md index 1d03733..4de9196 100644 --- a/docs/README.md +++ b/docs/README.md @@ -85,3 +85,5 @@ latexmk -C # Remove PDF - [CTU FEL Thesis Template (Overleaf)](https://www.overleaf.com/latex/templates/sablona-pro-psani-disertacni-prace-na-cvut-fel/ptpvbxhsjdmg) - [LaTeX Wikibook](https://en.wikibooks.org/wiki/LaTeX) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/README.zh-CN.md b/docs/README.zh-CN.md index bdba50c..8e6a7a5 100644 --- a/docs/README.zh-CN.md +++ b/docs/README.zh-CN.md @@ -85,3 +85,5 @@ latexmk -C # 删除 PDF - [CTU FEL 论文模板 (Overleaf)](https://www.overleaf.com/latex/templates/sablona-pro-psani-disertacni-prace-na-cvut-fel/ptpvbxhsjdmg) - [LaTeX 教程](https://en.wikibooks.org/wiki/LaTeX) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/pdf2md/README.md b/docs/pdf2md/README.md index aceb8d8..ca1301d 100644 --- a/docs/pdf2md/README.md +++ b/docs/pdf2md/README.md @@ -69,3 +69,5 @@ Cache is stored in `.cache.json`. Use `--force` to bypass. ## Output Converted Markdown files are saved to `output/` with the same name as the source PDF. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/pdf2md/convert.py b/docs/pdf2md/convert.py index ec0f3ad..5365cd5 100644 --- a/docs/pdf2md/convert.py +++ b/docs/pdf2md/convert.py @@ -231,3 +231,5 @@ def main(): if __name__ == "__main__": main() + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/README_ESPTFLITE.md b/docs/thesis_doc/README_ESPTFLITE.md index 00c91ee..9df5532 100644 --- a/docs/thesis_doc/README_ESPTFLITE.md +++ b/docs/thesis_doc/README_ESPTFLITE.md @@ -126,3 +126,5 @@ As per the upstream repository policy, the tflite-lib is copied into the compone This component and the examples are provided under Apache 2.0 license, see [LICENSE](LICENSE.md) file for details. TensorFlow library code and third_party code contains their own license specified under respective [repos](https://github.com/tensorflow/tflite-micro). + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/README_LATEX.md b/docs/thesis_doc/README_LATEX.md index 02d03d4..cd469c2 100644 --- a/docs/thesis_doc/README_LATEX.md +++ b/docs/thesis_doc/README_LATEX.md @@ -321,3 +321,5 @@ latexmk -C # 连 PDF 一起删 我可以继续帮你做两类“最快提分”的事情： 1) 按你论文主题，给你一个 **章节大纲 + 每章应该放的图/表/实验指标清单**（非常实用）。 2) 你把你要放的第一张架构图/一段实验结果贴出来，我帮你直接写成论文里可用的 Figure/Table + 英文段落。 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/espressif/esp32-s3-wroom-1_wroom-1u_datasheet_cn.md b/docs/thesis_doc/sources/espressif/esp32-s3-wroom-1_wroom-1u_datasheet_cn.md index d55f53c..02a7bf6 100644 --- a/docs/thesis_doc/sources/espressif/esp32-s3-wroom-1_wroom-1u_datasheet_cn.md +++ b/docs/thesis_doc/sources/espressif/esp32-s3-wroom-1_wroom-1u_datasheet_cn.md @@ -3011,3 +3011,5 @@ TFPD05H08750011。 2021-10-29 v0.6 全面更新，针对芯片版本 revision 1 2021-07-19 v0.5.1 预发布，针对芯片版本 revision 0 乐鑫信息科技 52 ESP32-S3-WROOM-1 & WROOM-1U 技术规格书 v1.7 反馈文档意见 免责声明和版权公告 本文档中的信息，包括供参考的 URL 地址，如有变更，恕不另行通知。 本文档可能引用了第三方的信息，所有引用的信息均为"按现状"提供，乐鑫不对信息的准确性、真实性做任何保证。 乐鑫不对本文档的内容做任何保证，包括内容的适销性、是否适用于特定用途，也不提供任何其他乐鑫提案、规格书或样 品在他处提到的任何保证。 乐鑫不对本文档是否侵犯第三方权利做任何保证，也不对使用本文档内信息导致的任何侵犯知识产权的行为负责。本文档 在此未以禁止反言或其他方式授予任何知识产权许可，不管是明示许可还是暗示许可。 Wi-Fi 联盟成员标志归 Wi-Fi 联盟所有。蓝牙标志是 Bluetooth SIG 的注册商标。 文档中提到的所有商标名称、商标和注册商标均属其各自所有者的财产，特此声明。 版权归 © 2025 乐鑫信息科技（上海）股份有限公司。保留所有权利。 www.espressif.com + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/espressif/esp32-s3_datasheet_en.md b/docs/thesis_doc/sources/espressif/esp32-s3_datasheet_en.md index a4ae782..5ba65e5 100644 --- a/docs/thesis_doc/sources/espressif/esp32-s3_datasheet_en.md +++ b/docs/thesis_doc/sources/espressif/esp32-s3_datasheet_en.md @@ -3315,3 +3315,5 @@ Date Version Release notes • Updated to chip revision 1 by swapping pin 53 and 2021-07-09 v0.5 Preliminary version Espressif Systems 86 ESP32-S3 Series Datasheet v2.1 Submit Documentation Feedback Disclaimer and Copyright Notice Information in this document, including URL references, is subject to change without notice. ALL THIRD PARTY'S INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES TO ITS AUTHENTICITY AND ACCURACY. NO WARRANTY IS PROVIDED TO THIS DOCUMENT FOR ITS MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, NOR DOES ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No licenses express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. The Wi-Fi Alliance Member logo is a trademark of the Wi-Fi Alliance. The Bluetooth logo is a registered trademark of Bluetooth SIG. All trade names, trademarks and registered trademarks mentioned in this document are property of their respective owners, and are hereby acknowledged. Copyright © 2025 Espressif Systems (Shanghai) Co., Ltd. All rights reserved. www.espressif.com + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/espressif/esp32-s3_technical_reference_manual_cn.md b/docs/thesis_doc/sources/espressif/esp32-s3_technical_reference_manual_cn.md index c7281d8..df36807 100644 --- a/docs/thesis_doc/sources/espressif/esp32-s3_technical_reference_manual_cn.md +++ b/docs/thesis_doc/sources/espressif/esp32-s3_technical_reference_manual_cn.md @@ -136057,3 +136057,5 @@ ENA/RAW/ST 寄存器的配置见表 39.7-4。 2021-07-09 v0.1 首次预发布 乐鑫信息科技 1435 ESP32-S3 TRM (版本 1.7) 反馈文档意见 免责声明和版权公告 本文档中的信息，包括供参考的 URL 地址，如有变更，恕不另行通知。 本文档可能引用了第三方的信息，所有引用的信息均为"按现状"提供，乐鑫不对信息的准确性、真实性做任何保证。 乐鑫不对本文档的内容做任何保证，包括内容的适销性、是否适用于特定用途，也不提供任何其他乐鑫提案、规格书或样 品在他处提到的任何保证。 乐鑫不对本文档是否侵犯第三方权利做任何保证，也不对使用本文档内信息导致的任何侵犯知识产权的行为负责。本文档 在此未以禁止反言或其他方式授予任何知识产权许可，不管是明示许可还是暗示许可。 Wi-Fi 联盟成员标志归 Wi-Fi 联盟所有。蓝牙标志是 Bluetooth SIG 的注册商标。 文档中提到的所有商标名称、商标和注册商标均属其各自所有者的财产，特此声明。 版权归 © 2025 乐鑫信息科技（上海）股份有限公司。保留所有权利。 www.espressif.com + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/espressif/esp32_datasheet_en.md b/docs/thesis_doc/sources/espressif/esp32_datasheet_en.md index 658d502..186759c 100644 --- a/docs/thesis_doc/sources/espressif/esp32_datasheet_en.md +++ b/docs/thesis_doc/sources/espressif/esp32_datasheet_en.md @@ -2944,3 +2944,5 @@ Date Version Release notes 2016.08 V1.0 First release. Espressif Systems 77 ESP32 Series Datasheet v5.2 Submit Documentation Feedback Disclaimer and Copyright Notice Information in this document, including URL references, is subject to change without notice. ALL THIRD PARTY'S INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES TO ITS AUTHENTICITY AND ACCURACY. NO WARRANTY IS PROVIDED TO THIS DOCUMENT FOR ITS MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, NOR DOES ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No licenses express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. The Wi-Fi Alliance Member logo is a trademark of the Wi-Fi Alliance. The Bluetooth logo is a registered trademark of Bluetooth SIG. All trade names, trademarks and registered trademarks mentioned in this document are property of their respective owners, and are hereby acknowledged. Copyright © 2025 Espressif Systems (Shanghai) Co., Ltd. All rights reserved. www.espressif.com + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/espressif/esp32_technical_reference_manual_en.md b/docs/thesis_doc/sources/espressif/esp32_technical_reference_manual_en.md index 57dbb85..800863c 100644 --- a/docs/thesis_doc/sources/espressif/esp32_technical_reference_manual_en.md +++ b/docs/thesis_doc/sources/espressif/esp32_technical_reference_manual_en.md @@ -80500,3 +80500,5 @@ Espressif Systems 781 ESP32 TRM (Version 5.6) Submit Documentation Feedback Rev Date Version Release notes Added Chapter ULP Coprocessor. Added Chapter On-Chip Sensors and Analog Signal Processing; Added Section Audio PLL; 2017.05 v1.7 Updated Section eFuse Controller Register Summary; Updated Sections I2S PDM and LCD MODE; Updated Section: Communication Format Supported by GP-SPI Slave. Added Chapter SD/MMC Host Controller; 2017.03 v1.6 Added register IO_MUX_PIN_CTRL in Chapter IO_MUX and GPIO Matrix. 2017.03 v1.5 Added Chapter I2S. Added Chapter SPI; 2017.01 v1.4 Added Chapter UART Controllers. Added Chapter eFuse Controller; Added Chapter RSA Accelerator; 2016.12 v1.3 Added Chapter Random Number Generator; Updated Section I2C Controller Interrupt and Section I2C Controller Registers. Added Chapter PID/MPU/MMU; 2016.11 v1.2 Updated Section IO_MUX and GPIO Matrix Register Summary; Updated Section LED_PWM Register Summary. 2016.09 v1.1 Added Chapter I2C Controller. 2016.08 v1.0 Initial release. Espressif Systems 782 ESP32 TRM (Version 5.6) Submit Documentation Feedback Disclaimer and Copyright Notice Information in this document, including URL references, is subject to change without notice. ALL THIRD PARTY'S INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES TO ITS AUTHENTICITY AND ACCURACY. NO WARRANTY IS PROVIDED TO THIS DOCUMENT FOR ITS MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, NOR DOES ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No licenses express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. The Wi-Fi Alliance Member logo is a trademark of the Wi-Fi Alliance. The Bluetooth logo is a registered trademark of Bluetooth SIG. All trade names, trademarks and registered trademarks mentioned in this document are property of their respective owners, and are hereby acknowledged. Copyright © 2025 Espressif Systems (Shanghai) Co., Ltd. All rights reserved. www.espressif.com + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/docs/thesis_doc/sources/standards/NIST.SP.800-57pt1r5.md b/docs/thesis_doc/sources/standards/NIST.SP.800-57pt1r5.md index d9abfdc..6dd7516 100644 --- a/docs/thesis_doc/sources/standards/NIST.SP.800-57pt1r5.md +++ b/docs/thesis_doc/sources/standards/NIST.SP.800-57pt1r5.md @@ -8275,3 +8275,5 @@ This publication is available free of charge from: https://doi.org/10.6028/NIST. 158 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/esphome/README.md b/esphome/README.md index f84be53..756ab53 100644 --- a/esphome/README.md +++ b/esphome/README.md @@ -91,3 +91,5 @@ mqtt_client_key: | - [ESP32 Datasheet](https://www.espressif.com/en/products/socs/esp32) - [ESP32-S3 Datasheet](https://www.espressif.com/en/products/socs/esp32-s3) - [Certificate Setup](../certs/README.md) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/esphome/esp32s3.yaml b/esphome/esp32s3.yaml index cdcd563..9e47adf 100644 --- a/esphome/esp32s3.yaml +++ b/esphome/esp32s3.yaml @@ -263,3 +263,5 @@ binary_sensor: device_class: sound lambda: |- return (id(sound_adc).state > 0.6); + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/homeassistant/README.md b/homeassistant/README.md index 69a2986..2a57c4a 100644 --- a/homeassistant/README.md +++ b/homeassistant/README.md @@ -94,3 +94,5 @@ Node-RED flow template for fall detection notifications: ## Certificate Setup See [`../certs/README.md`](../certs/README.md) for mTLS certificate generation. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/homeassistant/README.zh-CN.md b/homeassistant/README.zh-CN.md index 7df72f4..25c17fb 100644 --- a/homeassistant/README.zh-CN.md +++ b/homeassistant/README.zh-CN.md @@ -94,3 +94,5 @@ Home Assistant Container 的参考配置： ## 证书配置 mTLS 证书生成请参阅 [`../certs/README.zh-CN.md`](../certs/README.zh-CN.md)。 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/homeassistant/docker-compose.yml b/homeassistant/docker-compose.yml index e7d754a..fb92941 100644 --- a/homeassistant/docker-compose.yml +++ b/homeassistant/docker-compose.yml @@ -9,3 +9,5 @@ services: - "127.0.0.1:8123:8123" environment: - TZ=Europe/Prague + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/Dockerfile b/sensors/Dockerfile index 7ad8d1b..51a9f80 100644 --- a/sensors/Dockerfile +++ b/sensors/Dockerfile @@ -4,4 +4,5 @@ COPY sensors/requirements.txt ./requirements.txt RUN pip install --no-cache-dir -r requirements.txt COPY sensors ./sensors ENV PYTHONUNBUFFERED=1 -ENTRYPOINT ["python", "sensors/sensor_simulator.py"] \ No newline at end of file +ENTRYPOINT ["python", "sensors/sensor_simulator.py"] +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/README.md b/sensors/README.md index 8a307e4..44c7013 100644 --- a/sensors/README.md +++ b/sensors/README.md @@ -296,3 +296,5 @@ MIT License - See [LICENSE](../LICENSE) ## Citation This simulator is part of the bachelor thesis *"Application of Servers and Unix-like Systems for Sensor Control in Smart Homes"* at Czech Technical University in Prague. See the [main README](../README.md) for citation information. + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/README.zh-CN.md b/sensors/README.zh-CN.md index 46829ff..2a04bd6 100644 --- a/sensors/README.zh-CN.md +++ b/sensors/README.zh-CN.md @@ -297,3 +297,5 @@ MIT 许可证 - 详见 [LICENSE](../LICENSE) 本模拟器是捷克理工大学学士论文《服务器与类 Unix 系统在智能家居传感器控制中的应用》的组成部分。引用信息请参阅 [主 README](../README.zh-CN.md)。 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/brokers.example.yml b/sensors/brokers.example.yml index 018ad50..10a4437 100644 --- a/sensors/brokers.example.yml +++ b/sensors/brokers.example.yml @@ -141,3 +141,5 @@ simulation: sensor_entity: temperature delta_per_minute_on: 1.5 delta_per_minute_off: -0.3 + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/docker-compose.yml b/sensors/docker-compose.yml index d415ac0..1a5d3fd 100644 --- a/sensors/docker-compose.yml +++ b/sensors/docker-compose.yml @@ -45,3 +45,5 @@ services: - ./certs:/app/sensors/certs:ro restart: unless-stopped + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/sensor_simulator.py b/sensors/sensor_simulator.py index 571fb5c..b060d0c 100644 --- a/sensors/sensor_simulator.py +++ b/sensors/sensor_simulator.py @@ -60,3 +60,5 @@ def main() -> None: if __name__ == "__main__": main() + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/__init__.py b/sensors/smarthome_sim/__init__.py index 24733e3..0d05a32 100644 --- a/sensors/smarthome_sim/__init__.py +++ b/sensors/smarthome_sim/__init__.py @@ -18,3 +18,5 @@ "load_config", "load_brokers", ] + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/__main__.py b/sensors/smarthome_sim/__main__.py index b70fc94..faef992 100644 --- a/sensors/smarthome_sim/__main__.py +++ b/sensors/smarthome_sim/__main__.py @@ -11,3 +11,5 @@ if __name__ == "__main__": main() + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/benchmark.py b/sensors/smarthome_sim/benchmark.py index 7737a02..dd1963b 100644 --- a/sensors/smarthome_sim/benchmark.py +++ b/sensors/smarthome_sim/benchmark.py @@ -357,3 +357,5 @@ def _do_single_connect( "connect_latency_ms": None, "error": error, }) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/broker.py b/sensors/smarthome_sim/broker.py index 4007688..199565a 100644 --- a/sensors/smarthome_sim/broker.py +++ b/sensors/smarthome_sim/broker.py @@ -181,3 +181,5 @@ def create_client( client.loop_start() return client + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/cli.py b/sensors/smarthome_sim/cli.py index 5812cd0..dc25ff0 100644 --- a/sensors/smarthome_sim/cli.py +++ b/sensors/smarthome_sim/cli.py @@ -235,3 +235,5 @@ def on_sigint(*_): if __name__ == "__main__": main() + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/config.py b/sensors/smarthome_sim/config.py index 50be8d3..6abdd22 100644 --- a/sensors/smarthome_sim/config.py +++ b/sensors/smarthome_sim/config.py @@ -188,3 +188,5 @@ def setup_logging(level: str) -> None: format="%(asctime)s [%(levelname)s] %(message)s", datefmt="%H:%M:%S", ) + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/entities.py b/sensors/smarthome_sim/entities.py index 2f5c412..3a5bcc4 100644 --- a/sensors/smarthome_sim/entities.py +++ b/sensors/smarthome_sim/entities.py @@ -93,3 +93,5 @@ def get_default_entities() -> List[EntityDef]: commandable=True, initial=dict(DEFAULT_LIGHT_STATE) ), ] + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/simulator.py b/sensors/smarthome_sim/simulator.py index 1ba234d..b3f9baf 100644 --- a/sensors/smarthome_sim/simulator.py +++ b/sensors/smarthome_sim/simulator.py @@ -483,3 +483,5 @@ def handle_sigint(*_): c.loop_stop() except Exception: pass + +# [CodeRabbit Audit Trigger 1769364389] diff --git a/sensors/smarthome_sim/utils.py b/sensors/smarthome_sim/utils.py index 6269681..8b1a073 100644 --- a/sensors/smarthome_sim/utils.py +++ b/sensors/smarthome_sim/utils.py @@ -103,3 +103,5 @@ def convert(value: Any, typ: type, default: Any) -> Any: def now_ts() -> int: """Return current Unix timestamp as integer.""" return int(time.time()) + +# [CodeRabbit Audit Trigger 1769364389]