diff --git a/src/contents/5-elozmenyek.tex b/src/contents/5-elozmenyek.tex
index bbcd5eeb27369fd1145680792069938bb513335a..cefe09cccf90cc605a5df2ed2693a46bdecd4b10 100644
--- a/src/contents/5-elozmenyek.tex
+++ b/src/contents/5-elozmenyek.tex
@@ -30,27 +30,27 @@ sorolni:
 	      rendszerek.
 \end{enumerate}
 Az előbbi kategória esetében szükséges egy szakember ismerete, aki a felmért
-igények alapján ad ajánlatot, illetve hoz döntést, hogy a rendszer mely
-elemeket fogja tartalmazni. A telepítés szintúgy egy szakember feladata. Az
-ilyen termékeknél nem szempont az ``onboarding" élmény a végfelhasználó számára,
+igények alapján ad ajánlatot, illetve hoz döntést, hogy a rendszer mely elemeket
+fogja tartalmazni. A telepítés szintúgy egy szakember feladata. Az ilyen
+termékeknél nem szempont az ``onboarding'' élmény a végfelhasználó számára,
 ellenben az utóbbi kategóriával. A DIY rendszereknél a beszerelés kezdetétől
 fogva a végfelhasználóra van bízva a rendszer. A két kategória alapján
 választottam 2-2 terméket vizsgálatra, melyeket \aref{tab:analyzed-systems}.
-táblázatban jegyeztem le. Bár a Homey termékcsalád nem elsősorban biztonsági
+táblázatban jegyeztem le. Bár a Homey termékcsalád elsősorban nem biztonsági
 rendszer - hanem komplett okosotthon megoldás -, mégis lehetőség van
-objektumvédelemre programozni. Itt már bizonyára homályos a határ, hogy mit
+objektumvédelemre programozni. Emiatt az egyedi megközelítés miatt vettem hozzá
+a vizsgálandó rendszerek közé. Itt már bizonyára homályos a határ, hogy mit
 nevezhetünk riasztórendszernek és okosotthon rendszernek, ezért ezeket mind a
 DIY kategória alá sorolom.
 
-A két kategória közötti megkülönböztetést azért tartom fontosnak, mert
-- megfigyelésem szerint - a hagyományos rendszerek sok esetben nem adnak
-lehetőséget bármiféle integrációs lehetőségre, illetve elavult megoldásokat
-kínálnak arra. Egy ilyen rendszerrel potenciálisan nehezebb interfészelni egy
-modern okosotthon megoldás keretében, mint az újabb DIY rendszerek esetében,
-melyek előtérbe helyezik annak fontosságát, vagy már eleve okosotthon
-rendszerként üzemelnek. Ennek ellenére a DIY rendszereknek is megvannak a
-hátrányai. Ezeken szeretnék a következőkben végigjárni, mérlegelni a két
-megközelítés között.
+A két kategória közötti megkülönböztetést azért tartom lényegesnek, mert
+megfigyeléseim alapján a hagyományos rendszerek sokszor nem teszik lehetővé
+az integrációt, vagy elavult módszerekkel valósítják meg azokat. Egy ilyen
+rendszerrel potenciálisan nehezebb interfészelni egy modern okosotthon megoldás
+keretében, mint az újabb DIY rendszerek esetében, melyek előtérbe helyezik annak
+fontosságát, vagy már eleve okosotthon rendszerként üzemelnek. Ennek ellenére
+a DIY rendszereknek is megvannak a hátrányai. Ezeken szeretnék a következőkben
+végigjárni, mérlegelni a két megközelítés között.
 
 \paragraph{}
 \begin{table}[htbp!]
@@ -233,7 +233,7 @@ lehetővé teszi, hogy a felhasználók igényeik szerint fokozatosan bővítsé
 rendszert. Ezt a skálázódást általában szoftveresen vezérelt regisztrációs
 folyamat, és gyakran licencalapú árképzés kíséri, amely az új elemek
 beemelésével arányos plusz költségeket jelenthet. A gyártók rendszerint
-„freemium” modellekkel operálnak, ahol az alapszolgáltatások ingyenesek, de a
+``freemium'' modellekkel operálnak, ahol az alapszolgáltatások ingyenesek, de a
 professzionális funkciókért fizetni kell.
 
 A \emph{hagyományos rendszerek} ezzel szemben hardveres szinten lineárisan
@@ -394,15 +394,15 @@ módszere és az azt körbefoglaló folyamat sok ponton hibára tud futni.
 \paragraph{} Az elemzett kereskedelmi megoldások alapján jól kirajzolódik a
 ``hagyományos'' és a ``DIY'' rendszerek közötti technológiai, gazdasági és
 filozófiai különbség. Míg az ipari, szakember által telepített rendszerek
-megbízhatóságukkal, zártságukkal és hosszú távú stabilitásukkal tűnnek ki, addig
-a DIY rendszerek rugalmasságot, gyors telepíthetőséget és széleskörű integrációs
-lehetőségeket kínálnak -- gyakran a felhasználói élmény rovására. Manapság
-a hagyományos rendszerek jobban rendezkedtek be ipari alkalmazásra, mint egy
-háztartáson belül. A DIY rendszerek átvették az otthoni riasztórendszerek
-körében a népszerűséget nagyrészt a könnyű telepítési folyamatuk és az
-alacsony belépési költségük miatt. A kutatás során megismert legfontosabb
-tulajdonságokat, jellemzőket, \aref{tab-kereskedelmi-osszesites}. táblázatban
-összesítettem.
+megbízhatóságukkal, zártságukkal és hosszú távú stabilitásukkal tűnnek ki,
+addig a DIY rendszerek rugalmasságot, gyors telepíthetőséget és széleskörű
+integrációs lehetőségeket kínálnak -- gyakran a felhasználói élmény rovására.
+Manapság a hagyományos rendszerek túlnyomórészt ipari alkalmazásra rendezkedtek
+be, mint egy háztartáson belüli üzemre. A DIY rendszerek átvették az otthoni
+riasztórendszerek körében a népszerűséget nagyrészt a könnyű telepítési
+folyamatuk és az alacsony belépési költségük miatt. A kutatás során megismert
+legfontosabb tulajdonságokat, jellemzőket, \aref{tab-kereskedelmi-osszesites}.
+táblázatban összesítettem.
 
 \begin{table}[htbp!]
 	\begin{tblr}{
@@ -479,8 +479,8 @@ besorolni. A dolgozat során ezen a speciális biztonságtechnikai funkción bel
 
 \paragraph{} A behatolásjelző rendszerek alapvető feladata, hogy \textsl{``[...]
 függetlenül képesek legyenek nem csak a [behatolást észelni egy] adott
-ponton vagy bejárati úton, hanem bármely mozgást [észleljenek] a megfigyelt
-területen.''} \cite{bizt-rendszerek} A detektálás során a rendszer a
+ponton vagy bejárati úton, hanem bármely mozgást [detektáljanak] a megfigyelt
+területen.''} \cite{bizt-rendszerek} Az üzem alatt a rendszer a
 behatolásról vagy mozgásról különböző módon gyűjt információt. Ezt a
 megvalósításban szenzorokkal teszi, nevezetesen: PIR mozgásérzékelők, ajtó-,
 ablak nyitásérzékelők, ablak-törésérzékelők. A szenzor által kiváltott behatolás
@@ -488,7 +488,8 @@ ablak nyitásérzékelők, ablak-törésérzékelők. A szenzor által kiváltot
 csatornán. Hagyományosan a rendszer tartalmaz egy szirénát, ami a behatoló
 elrettentésének funkcióját tölti be. Ez gyakran elegendő ahhoz, hogy elriassza
 a cselekvőt, amivel a későbbi behatolásra tett kísérleteket megelőzheti,
-illetve csökkentheti a behatolás során okozott vagyoni és személyi károkat.
+illetve csökkentheti a behatolás során okozott további vagyoni és személyi károk
+bekövetkezésének valószínűségét.
 \cite{bizt-rendszerek}
 
 A következőekben definiáljuk a behatolásjelző rendszer komponenseit és végigjárok azok
@@ -508,9 +509,8 @@ hatástalanítás-kísérletei ellen, ami akár azonnali riasztást is kiváltha
 felület a rendszer bizonyos funkcióinak működtetésére. Tipikusan a rendszer élesítése és hatástalanítása
 ezen a felületen történik. Ebből az egységből egy vagy több is
 lehet a rendszerben. A kezelő azonosítására alkalmas kell, hogy legyen, hiszen egy
-esetleges behatoló (vagy bármilyen nemkívánatos fél) nem befolyásolhatja a rendszer
-működését. Az azonosítás vagy egyben a rendszer
-hatástalanítása általában egy előre beprogramozott PIN kód megadásával történik. \cite{bizt-rendszerek}
+esetleges behatoló (vagy bármilyen nemkívánatos fél) nem válthatja ki a rendszer
+hatástalanodását. Az azonosítás általában egy előre beprogramozott PIN kód megadásával történik. \cite{bizt-rendszerek}
 \\
 \textbf{Szirénák}: Hang- vagy fényjelző eszközök, melyek a behatolás
 pillanatában aktiválódnak. Szerepük kettős; a környék számára ad jelzést, hogy
@@ -565,14 +565,16 @@ szenzort helyezünk ugyanarra a célterületre.
 \end{table}
 \\
 \textbf{Kábelezés vagy rádiókapcsolat}: A központi egységet és az egyes
-szenzorokat, kezelőegységeket és a szirénát összeköttető vezetékek vagy vezeték
-nélküli kommunikációs csatorna. Szükséges úgy kialakítani a kábelek vezetését,
+szenzorokat, kezelőegységeket és a szirénát összeköttető vezetékes vagy
+vezeték nélküli kommunikációs csatorna és/vagy tápellátás. Értelemszerűen
+vezeték nélküli tápellátás fizikailag nem kivitelezhető -- illetve ennek
+kérdésével nem foglalkozunk. Szükséges úgy kialakítani a kábelek vezetését,
 hogy azt ne lehessen vandalizálni. Hasonlóan, a központi egység helyét úgy
 kell megválasztani, hogy az ahhoz hozzáférést megelőzze olyan terület, melyet
-a rendszer szenzorai figyelnek. A szenzorok legtöbb esetben el vannak látva
-vandalizmus elleni védelemmel, mely a szenzor dobozának felnyitására riasztást
-vált ki. A védelem egy normál esetben zárt állapotú nyomógombbal valósítható
-meg.
+a rendszer szenzorai megfigyelés alatt tartanak. A szenzorok legtöbb esetben
+el vannak látva vandalizmus elleni védelemmel, miszerint a szenzor dobozának
+felnyitása riasztást vált ki. A védelem egy normál esetben zárt állapotú
+nyomógombbal valósítható meg.
 
 \subsection{Informatikai biztonság}
 \label{inf-bizt}
diff --git a/src/contents/6-tervezes.tex b/src/contents/6-tervezes.tex
index 52c2d9b0504947a66a33497f652b48e70817a62e..2c0f06cc69f15a4f6476246e809b891546c2ba2f 100644
--- a/src/contents/6-tervezes.tex
+++ b/src/contents/6-tervezes.tex
@@ -6,10 +6,10 @@
 	vetett megkötéseinket figyelembe véve. Miután konkretizáltam a projekt kereteit,
 	a megvalósítandó rendszer tervezésével foglalkozom. A mikrokontroller az ESP32
 	hardver platfomon, Rust szoftveres környezetben valósul meg. Az okosotthon
-	integrációhoz a rendszer vezetékes hálózaton MQTT protokollon fog kommunikálni.
-	A választott technológiákkal ismerkedem és  megindoklom
-	a választásaimat helyesség, biztonság, a fejlesztés kényelmessége és a későbbi
-	bővíthetőség szempontjai alapján.
+	integrációhoz a rendszer vezetékes hálózaton MQTT protokollon fog kommunikálni
+	a Home Assistant okosotthon szoftverrel. A választott technológiákkal ismerkedem
+	és megindoklom a választásaimat helyesség, biztonság, a fejlesztés kényelmessége
+	és a későbbi bővíthetőség szempontjai alapján.
 }
 \section{Döntések}
 \label{dontesek}
@@ -290,15 +290,16 @@ iratkozhat fel, illetve küldhet üzenetet. A protokoll megköveteli azt az
 architektúrai elemet, hogy a kliensek között legyen egyetlen szerver, elnevezés
 szerint a ``broker''. A broker fogadja a kliensek csatlakozási, feliratkozási,
 üzenetküldési, leválasztási és egyéb kérelmeit. Nyilván tartja a klienseket,
-azok jogosultságait és a topic-ok továbbítását végzi. Számos implementációja van
-mind kliens oldali és broker oldali szerepeknek. \cite{mqtt-vs-coap}
+azok jogosultságait és a topic-on közzétett üzenetek továbbítását végzi.
+Számos implementációja van mind kliens oldali és broker oldali szerepeknek.
+\cite{mqtt-vs-coap}
 
 Az architektúra előnye, hogy a komplex feldolgozás feladata az a broker-re van
 hagyva és egy kliens működtetése minimális erőforrásokat igényel. További előnye
 más megoldásokkal szemben, hogy beépített Quality of Service (QoS) megoldást
 kínál az átvitt üzenetek fogadásának és célba érkezésének garanciájához. A TCP
 önmaga ilyen garanciát nem tud adni -- csak integritás és rendezettséget --
-illetve csomagok újraküldéssel tud próbálkozni de ez még nem garancia az adott
+illetve csomagok újraküldésével tud próbálkozni de ez még nem garancia az adott
 üzenet célba érkezésére, hiszen alacsonyabb absztrakciós szinten tartózkodik.
 Ezért ez a feladat magasabb egy szintű protokollra marad. \cite{tcp} Az MQTT
 három szinten definiál QoS-t:
@@ -306,7 +307,7 @@ három szinten definiál QoS-t:
 \begin{itemize}
 	\item \textbf{QoS 0} (``At most once delivery''): Az üzenetek átviteléről kvázi
 	      nincs garancia, tehát itt nincs semmilyen újraküldésre tett kísérlet.
-	\item \textbf{QoS 1} (``At least one delivery''): Az üzenetküldést jóvá kell hagyni,
+	\item \textbf{QoS 1} (``At least one delivery''): Az üzenetküldés sikerességét jóvá kell hagyni,
 	      ellenben az üzenet újra küldésre kerül. Ez a szint garantálja hogy
 	      az üzenet célba fog érni, de lehetséges, hogy többször is.
 	\item \textbf{QoS 2} (``Exactly once delivery''): Az üzenetküldés maga egy
@@ -383,25 +384,27 @@ ha nincs mozgás legalább 10 percen át, akkor kapcsolódjon le a lámpa.
 Az MQTT egy első osztályú integráció a Home Assistantban. Az MQTT minden QoS
 szintjét támogatja, illetve a többi integrációhoz képest sokkal általánosabb
 interfészt ad. Ez kimagaslóan jobb élményt ad a végfelhasználó számára,
-mert egységes  és konzisztens marad a frontend. A fejlesztő számára is jobb
+mert egységes és konzisztens marad a frontend. A fejlesztő számára is jobb
 élmény, mert az intgrációt így nem szükséges a Home Assistant forráskódján át
 implementálni Pythonban. MQTT-n keresztül lehetőség van entitások és eszközök
 telepítésére manuális konfigurációval vagy az úgynevezett ``MQTT-discovery''
-segítségével. Mindkét esetben az eszközöknek és entitásoknak van egy deklaratív
-leíró sémája, ami tartalmaz meta-adatokat és leírást azok működtetésére.
-Manuális konfiguráció esetén ezt a Home Assistantban YAML formátumban kell
-megadni, autodiscovery során pedig egy előre meghatározott MQTT topic-on kell
-küldeni JSON formátumban a rendszer felé. Látható, hogy az utóbbi esetben
-az azt támogató eszköz végfelhasználói onbarding élménye sokkal kényelmeseb.
-Például, az eszköz első indítása után az autodiscovery üzenet küldésével a Home
-Assistant frontend felületén azonnal látni fog a felhasználó egy jóváhagyandó
-üzenetet, hogy az készen áll a használatra. Jóváhagyás után a meghirdetett
-entitások importálásra kerülnek a Home Assistantba. \cite{hass-mqtt} Célom úgy
-megvalósítani a saját rendszert, hogy az alapból támogassa az autodiscovery-t.
-Így \aref{kereskedelmi}. fejezetben megismert DIY rendszereknél is potenciálisan
-jobb élményt tudna nyújtani, hiszen a kommunikáció vezetékes médiumon történne,
-ahol az Ethernet csatlakoztatásával azonnal a hálózatra kerül az eszköz. Ez
-elméletben kényelmesebb, mint például a WiFi konfigurációja. Ennek realitását
-szintén a gyakorlatban fogjuk tudni megállapítani.
+vagy ``autodiscovery'' segítségével. Mindkét esetben az eszközöknek és
+entitásoknak van egy deklaratív leíró sémája, ami tartalmaz meta-adatokat
+és leírást azok működtetésére. Manuális konfiguráció esetén ezt a Home
+Assistantban YAML formátumban kell megadni, autodiscovery során pedig egy
+előre meghatározott MQTT topic-on kell küldeni JSON formátumban a rendszer
+felé. Látható, hogy az utóbbi esetben az azt támogató eszköz végfelhasználói
+onbarding élménye sokkal kényelmeseb. Például, az eszköz első indítása után
+az autodiscovery üzenet küldésével a Home Assistant frontend felületén azonnal
+látni fog a felhasználó egy jóváhagyandó üzenetet, hogy az készen áll a
+használatra. Jóváhagyás után a meghirdetett entitások importálásra kerülnek a
+Home Assistantba. \cite{hass-mqtt} Célom úgy megvalósítani a saját rendszert,
+hogy az alapból támogassa az autodiscovery-t. Így \aref{kereskedelmi}.
+fejezetben megismert DIY rendszereknél is potenciálisan jobb élményt tudna
+nyújtani, hiszen a kommunikáció vezetékes médiumon történne, ahol az Ethernet
+csatlakoztatásával azonnal a hálózatra kerül az eszköz, egyúton megjelenne a
+felhasználó Home Assistant felületén. Ez elméletben kényelmesebb, mint például
+a WiFi konfigurációja. Ennek realitását szintén a gyakorlatban fogjuk tudni
+megállapítani.
 
 \clearpage % Ez azért kell, hogy nehogy képek átcsússzanak a következő fejezethez
diff --git a/src/contents/7-eredmenyek.tex b/src/contents/7-eredmenyek.tex
index 79f61944d3a4986b5406f35c7696bdde3ae9b68c..87da737a98c2ce81979a978dc64c74d554dd4c0e 100644
--- a/src/contents/7-eredmenyek.tex
+++ b/src/contents/7-eredmenyek.tex
@@ -107,9 +107,9 @@ szükséges és kényelmi beállítások. Ezek közül megemlítendő:
 \end{itemize}
 
 Ezek után nekiláttam a perifériák vezérlésének implementálásához. A \verb|main|
-függvény valahány utasítása az a perifériák inicializálását végzi, utána az
+függvény valahány utasítása a perifériák inicializálását végzi, utána az
 egyes feladatkörök elindítása több szálon (thread). A legnagyobb kihívás
-itt az ethernet vezérlő működésre bírása volt. Ahogy \aref{hardware}. fejezetben
+itt az Ethernet vezérlő működésre bírása volt. Ahogy \aref{hardware}. fejezetben
 is említettem, végül a Wiznet W5500 típusú SPI interfész alapú chip vezérlését
 kellett implelentáljam. A fizikai réteg inicializálása egyszerűen történik, mely
 így néz ki a forráskódban:
@@ -216,12 +216,13 @@ fn mqtt_task(
 
 Az \mintinline{rust}/msg/ változó az MQTT kliens fogadott eseményeit
 fogja tartalmazni, ami lehet a csatlakozás esemény, lecsatlakozás esemény,
-feliratkozott topic-ra érkezett üzenet. A \mintinline{rust}/handle_mqt_message/
+feliratkozott topic-ra érkezett üzenet. A \mintinline{rust}/handle_mqtt_message/
 függvény kezeli a beérkezett üzeneteket feliratkozott topic-ra. Az eszköz
-lényegében egyetlen dologra kíváncsi: a firmware frissítésre -- Over the
-Air Update (OTA). Ezt egy erre dedikált MQTT topic-on tudja megkapni, az új
-firmware tartalmát ide lehet publikálni bináris formátumban. Ennek a kezelése a
-legbonyolultabb az egész firmware kódjában -- nem is az alapfeladat része, így
+lényegében két dologra kíváncsi: a rendszer élesítése/hatástalanítás
+műveleteire, illetve a firmware frissítésre -- Over the Air Update (OTA). Az
+üzeneteket az ezekre dedikált MQTT topic-on tudja megkapni szövegesen, és az új
+firmware tartalmát ide lehet publikálni bináris formátumban. Az utóbbi kezelése
+a legbonyolultabb az egész firmware kódjában -- nem is az alapfeladat része, így
 csak egy kivonatát mutatom itt be:
 
 %TC: ignore
@@ -474,13 +475,14 @@ Lényegében három dolog történik:
 	      (alarm panel és mozgásérzékelők) a segéd struktúrákkal, majd JSON formátumba konvertáljuk,
 	      és azonnal el is küldjük a Home Assistant számára az autodiscovery protokoll szerint.
 	\item Az entitások elérhetőségét (availability) egyetlen közös topic-ra állítottuk az előző lépésben (hiszen mindegyik
-	      a központi egység elérhetőségétől függ), így egyetlen üzenetet kiküldve ``online'' állapotba hozzuk.
+	      a központi egység elérhetőségétől függ), így egyetlen üzenetet kiküldve ``online'' állapotba hozzuk. Ha
+	      az entitás rendelkezik az annak vezérlésére alkalmas topic-kal (alarm panel), arra feliratkozunk.
 	\item Feliratkozunk a firmware frissítés (OTA) topic-jára -- melynek működését láttuk az előző fejezetben.
 \end{enumerate}
 
-Ezzel még nem vagyunk kész, hiszen a szenzorok állapotát még nem küldjük és a
-riasztópanel parancsait még nem fogadjuk. Ezek implementációját így oldottam
-meg:
+Ezzel még nem vagyunk kész, hiszen a szenzorok állapotát még nem küldjük és
+a riasztópanel parancsait még nem dolgozzuk fel. Ezek implementációját így
+oldottam meg:
 
 \noindent\extlink{https://github.com/akosnad/rusty-esp-alarm/blob/1d3073a0cbd3b98af0f6a14bdf625732938f78e2/src/scheduler.rs\#L168}{scheduler.rs}
 \begin{minted}[linenos,firstnumber=168]{rust}
@@ -566,12 +568,12 @@ hosszútávú tesztelésre. A dolgozat írásakor a rendszer nagyjából 8 hóna
 \begin{itemize}
 	\item Az első 2 hónap alatt ha elég sokáig futott a firmware (nagyjából
 	      4-5 nap hossza), hirtelen nem reagált semmire. A hiba egy deadlock
-	      szituációból adódott, melyet kijavítottam. A hiba bekövetkezése és az eltelt idő látszólagos
+	      szituációból adódott. A hiba bekövetkezése és az eltelt idő látszólagos
 	      korrelációja valójában hamis volt, mert a deadlock bekövetkezéséhez
 	      két eseménynek kellett egyszerre történnie: a riasztó élesedése és
 	      egy mozgásérzékelő jelet észlelése. Javítás után a hiba nem jelentkezett többször.
 	\item Az MQTT broker leállása és újraindulása után a firmware nem csatlakozott
-	      újra, így használhatatlan maradt a manuális újraindításig. Ez azért volt,
+	      újra, így használhatatlan maradt a manuális újraindításig. Ez azért jelentkezett,
 	      mert csak az Ethernet link megszakadását kezeltem le. Ha a link
 	      sértetlen maradt, és csak a socket szakadt meg, azt figyelmen kívül
 	      hagyta az implementáció. Javítás után teszteltem a hibatűrést.
@@ -580,11 +582,12 @@ hosszútávú tesztelésre. A dolgozat írásakor a rendszer nagyjából 8 hóna
 	      is képes volt visszacsatlakozni az eszköz. A hibát kijavítottnak tekintettem.
 \end{itemize}
 
-Összesítve a hibák sűrűsége alacsony volt, de azok kritikusak. Itt látszik jól
-a Rust erőssége és az aranymondás róla igazolódik: \textsl{``Ha a kód lefordul,
-	akkor biztos lehetsz benne, hogy az úgy működni fog.''} \cite{rust-compiles-1}
-\cite{rust-compiles-2} \cite{rust-compiles-3} Bizonyos keretekig ez az állítás
-igaz; a fordító garantálja azt a működést amit enged, hogy leforduljon. Azt,
-hogy a programozó logikai hibát vétett, azt már nem tudja kijavítani helyette.
+Összesítve a hibák sűrűsége alacsony volt, de azok kritikus logikai hibák. Itt
+látszik jól a Rust erőssége és az aranymondás róla igazolódik: \textsl{``Ha
+	a kód lefordul, akkor biztos lehetsz benne, hogy az úgy működni fog.''}
+\cite{rust-compiles-1} \cite{rust-compiles-2} \cite{rust-compiles-3} Bizonyos
+keretekig ez az állítás igaz; a fordító garantálja azt a működést amit enged,
+hogy leforduljon. Azt, hogy a programozó logikai hibát vétett, azt már nem tudja
+kijavítani helyette.
 
 \clearpage % Ez azért kell, hogy nehogy képek átcsússzanak a következő fejezethez
diff --git a/src/contents/8-osszefoglalas.tex b/src/contents/8-osszefoglalas.tex
index 1bbcdc13aac993ba2a612b70ab034bc905c21de5..8731c3abf2317a3f04baabcfe6fb5e9eafb11836 100644
--- a/src/contents/8-osszefoglalas.tex
+++ b/src/contents/8-osszefoglalas.tex
@@ -4,7 +4,8 @@
 
 \chapterintro{
 	Az utolsó fejezetben refletálok a dolgozat kitűzött céljára az eredmények
-	fényében. A projekt továbbhaladásához kifejtem a következő lépéseket.
+	fényében. A projekt továbbhaladásához kifejtem a következő lépéseket és
+	visszatekintek a szerzett tapasztalatokra.
 }
 
 \section{Feladat}
@@ -14,7 +15,7 @@
 	\item Megismerkedtem a biztonságtechnika alapjaival, melyről \aref{bizt-kerd}. fejezetben
 	      írtam le a szükséges megszerzett tudást.
 	\item Kiválasztottam kereskedelmi riasztórendszereket (\ref{tab:analyzed-systems}. táblázat),
-	      melyek architektúrai felismerését megismertem (\ref{kereskedelmi-arch}. fejezet). Összevetettem
+	      melyek architektúrai felépítését megismertem (\ref{kereskedelmi-arch}. fejezet). Összevetettem
 	      azok integrációs lehetőség (\ref{kereskedelmi-integralhatosag}. fejezet), gazdasági elköteleződés (\ref{koltseg}. fejezet),
 	      megbízhatóság és felhasználói élmény (\ref{kereskedelmi-megbizhatosag}. fejezet) szempontjai alapján. Az eredményeket
 	      \aref{tab-kereskedelmi-osszesites}. táblázatban gyűjöttem össze.
@@ -45,6 +46,22 @@ következtetést kell levonnom, hogy a jövőben több kutatást kell végeznem
 az adott hardverről, és több alternatívát is érdemes összehasonlítani a
 megválasztás előtt, hogy biztos lehessek annak megbízhatóságában.
 
+\section{Jövőbeli tervek}
+\label{jovo}
+
+\paragraph{} A megvalósított rendszer egy stabil alapot biztosít további
+fejlesztésekhez. A jövőben szeretném a funkcionalitást bővíteni például
+többféle érzékelő támogatásával, mint ajtó- és ablaknyitás-érzékelők és egyéb
+szenzorok integrálásával minél általánosabb módon. Hosszútávú terveim között
+szerepel a rendszer eseménykezelésének finomítása, például riasztási prioritások
+és naplózási funkciók bevezetése, valamint egy önálló webes felület ezek
+megtekintésére és a szenzorok konfigurálására.
+
+A dolgozaton túl az első célom, hogy a rendszer támogassa az érzékelők zónákba
+sorolását, valamint az egyes zónák önálló élesítését és hatástalanítását. Ezzel
+lehetőség nyílna például csak bizonyos területek védelmére, miközben a ház más
+részei szabadon használhatók maradnának.
+
 \section{Személyes tapasztalatok}
 
 \paragraph{} A dolgozat elkészítése során számos új ismerettel gazdagodtam
@@ -67,18 +84,12 @@ fejlesztési projekteket. Összességében a dolgozat elkészítése rendkívül
 és motiváló tapasztalatot jelentett számomra, amely tovább erősítette az
 érdeklődésemet a beágyazott rendszerek és a biztonságtechnika iránt.
 
-\section{Jövőbeli tervek}
-\label{jovo}
+\section{Köszönetnyilvánítás}
 
-\paragraph{} A megvalósított rendszer egy stabil alapot biztosít további
-fejlesztésekhez. A jövőben szeretném a funkcionalitást bővíteni például
-többféle érzékelő támogatásával, mint ajtó- és ablaknyitás-érzékelők és egyéb
-szenzorok integrálásával minél általánosabb módon. Hosszútávú terveim között
-szerepel a rendszer eseménykezelésének finomítása, például riasztási prioritások
-és naplózási funkciók bevezetése, valamint egy önálló webes felület ezek
-megtekintésére és a szenzorok konfigurálására.
-
-A dolgozaton túl az első célom, hogy a rendszer támogassa az érzékelők zónákba
-sorolását, valamint az egyes zónák önálló élesítését és hatástalanítását. Ezzel
-lehetőség nyílna például csak bizonyos területek védelmére, miközben a ház más
-részei szabadon használhatók maradnának.
+\paragraph{} Köszönöm mindazoknak akik lehetővé tették vagy segítették a
+munkámat, első sorban szüleimnek a támogatást és a lehetőséget arra, hogy
+otthonomban tudtam a projektet hosszú távon üzemeltetni. Köszönöm Tihanyi
+Attila Tanár Úrnak, egyben témavezetőmnek a szerteágazó tudását és szakértelmét.
+Nemcsak inspirációt adott a hardver világához, hanem a mérnöki gondolkodásomat
+alakította ki. Köszönöm a barátaimnak a kitartó jelenlétüket mellettem, akik
+végig kísértek a tanulmányaim során.