De gegevensroute begrijpen | ESP32 en MQTT

In het vorige hoofdstuk heb je verzameld wat je nodig hebt om te beginnen. De ESP32, de sensoren, de voeding, het lokale netwerk en de computer waarop Home Assistant draait, liggen als het ware klaar op de werkbank.

Los van elkaar doen die onderdelen nog niet wat we uiteindelijk willen.

Een temperatuursensor kan een temperatuur meten. Een ESP32 kan die meting uitlezen. Home Assistant kan informatie tonen en bewaren. Maar tussen meten en tonen moet de waarde een route afleggen. Onderweg verandert zij een paar keer van vorm en is ieder onderdeel afhankelijk van duidelijke afspraken.

In dit hoofdstuk installeren en programmeren we nog niets. We brengen eerst de gegevensroute in kaart. Daardoor weet je later niet alleen welke instelling je moet invullen, maar vooral welk deel van het systeem je met die instelling beïnvloedt.

Dat maakt bouwen overzichtelijker. Het maakt foutzoeken ook veel eenvoudiger.

Van een meting naar informatie

In De Werkplaats bouwen we een slimme binnenthermometer. Een sensor meet onder andere de temperatuur en luchtvochtigheid. De ESP32 leest deze waarden uit en toont ze op een kleurendisplay. Via MQTT komen dezelfde gegevens uiteindelijk in Home Assistant terecht.

Op het eerste gezicht lijkt een temperatuur van 19,6 °C onderweg steeds dezelfde waarde. Toch komt die waarde op verschillende plaatsen in een andere vorm voor.

Bij de sensor is zij het resultaat van een fysieke meting. In het programma van de ESP32 kan zij als getal in een variabele staan:

float temperatuur = 19.6;

Op het display wordt dat getal tekst die je kunt lezen:

19,6 °C

Voor MQTT wordt het getal de inhoud van een bericht:

topic: werkplaats/binnenthermometer/temperatuur

payload: 19.6

In Home Assistant wordt de ontvangen waarde de actuele toestand van een entiteit:

entiteit: sensor.werkplaats_binnenthermometer_temperatuur

toestand: 19.6

eenheid: °C

De betekenis blijft gelijk, maar de vorm verandert. Op iedere overgang zijn afspraken nodig. De ESP32 moet weten hoe hij met de sensor communiceert. De MQTT-client moet weten waar de broker bereikbaar is. Home Assistant moet weten bij welke entiteit het bericht hoort.

Veel fouten ontstaan niet in een onderdeel zelf, maar op zo'n overgang.

De route in één regel

Voor de temperatuur ziet de volledige route er vereenvoudigd zo uit:

SHT41 → ESP32 → wifi → MQTT-broker → Home Assistant → dashboard en geschiedenis

De SHT41 is de sensor in onze slimme binnenthermometer. Hij meet temperatuur en relatieve luchtvochtigheid. De ESP32 leest de sensor uit, verwerkt de waarden en publiceert ze via wifi. De MQTT-broker ontvangt de berichten en verdeelt ze. Home Assistant verwerkt de ontvangen gegevens en koppelt ze aan de juiste entiteiten.

Daarnaast zijn er onderdelen die niet rechtstreeks een temperatuur doorgeven, maar wel invloed hebben op het gedrag van het apparaat. De PIR-bewegingssensor kan bijvoorbeeld vaststellen dat er beweging in De Werkplaats is. De ESP32 kan die informatie gebruiken om het kleurendisplay in te schakelen of wakker te houden.

Dat levert een tweede, kortere route op:

PIR-sensor → ESP32 → kleurendisplay

Later kunnen we de bewegingsstatus eventueel ook via MQTT naar Home Assistant sturen:

PIR-sensor → ESP32 → wifi → MQTT-broker → Home Assistant

Eén apparaat kan dus meerdere gegevensroutes bevatten. Ze beginnen niet allemaal bij dezelfde sensor en hoeven niet allemaal op hetzelfde eindpunt uit te komen.

De SHT41: meten, niet verzenden

De SHT41 is de bron van onze temperatuur- en luchtvochtigheidsmetingen. Zijn taak is beperkt:

een meting uitvoeren;
de meetgegevens digitaal beschikbaar maken;
reageren wanneer de ESP32 om een nieuwe meting vraagt.

De sensor heeft geen wifi. Hij kent MQTT en Home Assistant niet. Hij weet ook niet dat hij in De Werkplaats hangt of dat zijn waarde op een dashboard zal verschijnen.

Dat onderscheid is belangrijk. Wanneer de SHT41 niet wordt gevonden of een ongeldige waarde teruggeeft, kan een wijziging in Home Assistant dat niet oplossen. Er bestaat dan immers nog geen bruikbare meting om te versturen.

De kortste test van dit deel van de route is daarom lokaal. Je laat de ESP32 de sensor uitlezen en bekijkt de uitkomst in de Seriële monitor of op het kleurendisplay.

Temperatuur: 19.6 °C

Luchtvochtigheid: 54.2 %

Zie je logische en veranderende waarden, dan weet je dat de eerste korte keten waarschijnlijk werkt:

SHT41 → bedrading → ESP32 → programma → Seriële monitor

Je weet daarmee nog niets over wifi, MQTT of Home Assistant. Dat is geen tekortkoming van de test. Het is juist de kracht ervan: je hebt één deel van de route afzonderlijk gecontroleerd.

De PIR-sensor: een gebeurtenis waarnemen

De SHT41 levert meetwaarden. De PIR-sensor werkt anders. PIR staat voor passive infrared. De sensor reageert op veranderingen in warmtestraling binnen zijn blikveld en kan daardoor beweging waarnemen.

De uitkomst is doorgaans eenvoudiger dan bij de SHT41:

beweging gedetecteerd

of:

geen beweging gedetecteerd

Zo'n verandering noemen we in gewone taal een gebeurtenis. De ESP32 kan daarop reageren door het display aan te zetten. Het display hoeft daarvoor niet te wachten op Home Assistant. Die korte, lokale route blijft dus werken wanneer Home Assistant uitstaat of wanneer wifi tijdelijk wegvalt.

Dat is een bewuste ontwerpkeuze. Een persoon die voor de binnenthermometer staat, verwacht dat het display direct reageert. De omweg via het netwerk zou daarvoor niets toevoegen en alleen extra afhankelijkheden veroorzaken.

Lokaal uitvoeren wat lokaal kan, maakt het systeem vaak sneller en betrouwbaarder.

De ESP32: het actieve middelpunt

De ESP32 brengt de verschillende delen van ons apparaat samen. Hij voert het programma uit en krijgt meerdere taken:

de SHT41 initialiseren;
temperatuur en luchtvochtigheid uitlezen;
controleren of de waarden bruikbaar zijn;
het kleurendisplay bijwerken;
de PIR-sensor bewaken;
bepalen wanneer het display aan of uit moet;
verbinding maken met wifi;
verbinding maken met de MQTT-broker;
meetwaarden omzetten in MQTT-berichten;
de verbindingen bewaken en zo nodig herstellen.

Dat is veel meer dan alleen een sensor uitlezen. Daarom bouwen we het programma later in kleine, herkenbare delen op.

We willen ook duidelijke meldingen kunnen onderscheiden:

SHT41 niet gevonden

Wifi verbonden

MQTT-broker niet bereikbaar

Temperatuur gepubliceerd

Een melding als werkt niet helpt nauwelijks. Een specifieke melding vertelt tot welk punt de route wel of niet is gekomen.

De ESP32 bewaart in ons basisproject geen lange meetgeschiedenis. Hij leest een waarde, toont haar en publiceert haar. Home Assistant wordt later de plaats waar de ontwikkeling in de tijd zichtbaar wordt.

Valt de verbinding met de broker tijdelijk weg, dan kan het display nog steeds een actuele lokale meting tonen. De waarde bereikt Home Assistant op dat moment alleen niet. Eén apparaat kan daardoor tegelijk gedeeltelijk werken en gedeeltelijk niet werken.

Wifi: de lokale weg

Wifi geeft de ESP32 toegang tot het lokale netwerk. Het lokale netwerk is de verbinding tussen apparaten in je woning of werkplaats. Het internet is de verbinding van dat netwerk met systemen daarbuiten.

Die twee worden vaak door elkaar gehaald.

Een ESP32 kan correct met wifi verbonden zijn zonder internettoegang. Zolang de MQTT-broker en Home Assistant in hetzelfde bereikbare lokale netwerk staan, kan onze gegevensroute dan gewoon blijven werken.

Andersom betekent een werkende internetverbinding niet automatisch dat de ESP32 de lokale broker kan bereiken. Mogelijke oorzaken zijn bijvoorbeeld:

een verkeerd brokeradres;
netwerksegmenten die niet met elkaar mogen communiceren;
een firewallregel;
een broker die niet draait;
onjuiste MQTT-inloggegevens.

Wifi vervoert netwerkgegevens, maar begrijpt niet wat temperatuur is. Het maakt ook niet vanzelf een MQTT-verbinding. Daarvoor gebruikt het programma op de ESP32 een MQTT-client.

MQTT: afspraken voor berichtenverkeer

MQTT is een licht protocol voor het uitwisselen van berichten. Een protocol is een verzameling afspraken over hoe systemen met elkaar communiceren.

Een MQTT-bericht heeft in ieder geval twee delen die je vaak zult tegenkomen:

het topic;
de payload.

Het topic beschrijft waar het bericht bij hoort. De payload is de inhoud van het bericht.

Voor onze binnenthermometer kunnen we bijvoorbeeld deze afspraak gebruiken:

topic: werkplaats/binnenthermometer/temperatuur

payload: 19.6

Voor de luchtvochtigheid gebruiken we een ander topic:

topic: werkplaats/binnenthermometer/luchtvochtigheid

payload: 54.2

MQTT-topics zijn hoofdlettergevoelig. Deze twee namen zijn dus niet gelijk:

werkplaats/binnenthermometer/temperatuur

Werkplaats/Binnenthermometer/Temperatuur

Een verkeerd gespeld topic kan technisch volledig geldig zijn. De broker ziet niet dat jij waarschijnlijk iets anders bedoelde. Hij ontvangt en verdeelt het bericht onder de naam die werkelijk is gebruikt.

Daarom kiezen we vooraf een vaste naamstructuur en gebruiken we kleine letters. Consequente namen zijn geen nette afwerking voor later. Ze zijn een onderdeel van een betrouwbare gegevensroute.

De MQTT-client: publiceren en ontvangen

Een client is een programma of apparaat dat verbinding maakt met een MQTT-broker. De ESP32 is een MQTT-client. Home Assistant wordt later ook een MQTT-client.

Een client kan berichten publiceren. Dat betekent dat hij een payload op een topic aanbiedt aan de broker.

Een client kan zich ook op een topic abonneren. Hij vraagt de broker dan om nieuwe berichten op dat topic door te geven.

In ons eerste meetvoorbeeld publiceert de ESP32:

werkplaats/binnenthermometer/temperatuur → 19.6

Home Assistant abonneert zich op hetzelfde topic en ontvangt daardoor de nieuwe waarde.

De twee clients praten niet rechtstreeks met elkaar. Ze maken allebei verbinding met de broker.

Dat is een nuttige scheiding. De ESP32 hoeft niet te weten hoe Home Assistant een dashboard opbouwt. Home Assistant hoeft niet te weten op welke pinnen de SHT41 is aangesloten. Beide hoeven alleen de afgesproken topics en payloads te begrijpen.

De broker: ontvangen en verdelen

De MQTT-broker is het centrale verdeelpunt van de berichten. In deze gids gebruiken we later een lokale Mosquitto-broker.

De broker heeft drie hoofdtaken:

verbindingen van clients aannemen;
gepubliceerde berichten ontvangen;
berichten doorgeven aan clients met een passend abonnement.

Je kunt de broker vergelijken met de verdeelbalie van een magazijn. De ESP32 levert een pakket af met een duidelijk etiket. De broker kijkt welke ontvangers om pakketten met dat etiket hebben gevraagd en geeft het pakket door.

De broker weet niet uit zichzelf dat 19.6 een temperatuur is. Hij weet ook niet welke meeteenheid erbij hoort. Voor de broker zijn topic en payload gegevens die volgens de MQTT-afspraken moeten worden verdeeld.

De broker maakt ook niet vanzelf een entiteit in Home Assistant. Daarvoor moet Home Assistant deelnemen aan het MQTT-verkeer en begrijpen hoe het ontvangen bericht moet worden gebruikt.

Deze scheiding levert later een krachtige testmogelijkheid op. Met een extra MQTT-client kunnen we op het topic meekijken. Ziet die client de temperatuur wel, maar Home Assistant niet, dan weten we dat de route tot en met de broker waarschijnlijk werkt. Het zoekgebied wordt dan kleiner.

Home Assistant: ontvangen, betekenis geven en bewaren

Home Assistant staat aan het einde van onze meetroute, maar vervult daar verschillende taken.

Via de MQTT-integratie maakt Home Assistant verbinding met de broker. Een integratie is een onderdeel dat Home Assistant laat communiceren met een apparaat, protocol of dienst.

Voor onze binnenthermometer kan Home Assistant daarna:

berichten op de afgesproken topics ontvangen;
een bericht koppelen aan de juiste entiteit;
de actuele toestand van die entiteit bijwerken;
eerdere toestanden in de geschiedenis bewaren;
de waarde op een dashboard tonen;
de waarde later gebruiken in een automatisering.

Een entiteit is de digitale voorstelling van één meetwaarde, toestand of bedienbare functie. Eén fysieke binnenthermometer kan daardoor meerdere entiteiten krijgen:

Werkplaats-binnenthermometer

├── temperatuur

├── luchtvochtigheid

├── beweging

├── wifi-signaalsterkte

└── beschikbaarheid

De actuele waarde van een entiteit heet de toestand. Bij de temperatuursensor kan dat 19.6 zijn. Aanvullende eigenschappen, zoals de meeteenheid, geven betekenis aan die toestand.

In het volgende hoofdstuk leren we Home Assistant zelf beter kennen. Daar bekijken we onder andere hoe apparaten, integraties en entiteiten zich tot elkaar verhouden. Voor nu is het voldoende om te weten dat Home Assistant niet zomaar een getal toont. Het moet eerst weten waar het bericht vandaan komt en wat het getal voorstelt.

De terugweg: opdrachten naar de ESP32

Tot nu toe volgden we gegevens van de ESP32 naar Home Assistant. MQTT kan ook de andere kant op werken.

Stel dat je later vanuit Home Assistant de helderheid van het display wilt aanpassen. Home Assistant kan dan een opdracht publiceren:

topic: werkplaats/binnenthermometer/opdracht/helderheid

payload: 60

De ESP32 abonneert zich op dat topic, ontvangt de payload en past de helderheid aan.

De gegevensroute wordt dan:

Home Assistant → MQTT-broker → wifi → ESP32 → kleurendisplay

De broker blijft in het midden staan. Alleen de rol van publiceren en abonneren wisselt.

We gaan die terugweg niet meteen bouwen. Eerst zorgen we dat eenvoudige sensormetingen betrouwbaar van de ESP32 naar Home Assistant lopen. Pas wanneer die basis duidelijk is, voegen we bediening toe. Zo veranderen we steeds één onderdeel tegelijk.

Een actuele waarde is niet automatisch een betrouwbare waarde

Stel dat Home Assistant 19,6 °C toont. Dat ziet eruit als een geldige temperatuur. Toch weet je zonder aanvullende informatie niet of die waarde vijf seconden of vijf uur geleden is ontvangen.

Daarom kijken we later niet alleen naar meetwaarden, maar ook naar de beschikbaarheid van het apparaat en het tijdstip van de laatste update.

Home Assistant kan bijzondere toestanden tonen:

unknown: de entiteit bestaat, maar Home Assistant kent de waarde nog niet;
unavailable: de entiteit is op dat moment niet beschikbaar.

Die toestanden zijn geen rommel die je zo snel mogelijk moet verbergen. Ze vertellen iets over de kwaliteit van de gegevensroute. Een duidelijke melding dat een sensor niet bereikbaar is, is eerlijker dan een oude waarde die eruitziet alsof zij nog actueel is.

Betrouwbaarheid betekent daarom niet alleen dat er meestal een getal verschijnt. Je wilt ook kunnen vaststellen wanneer je dat getal niet meer moet vertrouwen.

Voorspellen wat er bij een storing gebeurt

Bekijk de route nogmaals:

SHT41 → ESP32 → wifi → MQTT-client → broker → MQTT-integratie → entiteit → dashboard

Probeer vóór iedere storing te voorspellen wat je verwacht.

De SHT41 wordt losgekoppeld

De ESP32 kan nog steeds draaien. Wifi en MQTT kunnen zelfs verbonden blijven. Toch is er geen geldige nieuwe temperatuur. Het programma moet die situatie herkennen en niet zomaar een geloofwaardig getal publiceren.

Wifi valt weg

De ESP32 kan de SHT41 lokaal blijven uitlezen en het kleurendisplay bijwerken. De broker is alleen niet bereikbaar. Home Assistant ontvangt daardoor geen nieuwe metingen.

De broker stopt

De ESP32 kan nog met wifi verbonden zijn, maar de MQTT-client verliest zijn brokerverbinding. Het lokale display kan blijven werken. Alle MQTT-clients merken dat de centrale verdeler niet bereikbaar is.

Home Assistant herstart

De ESP32 en broker kunnen blijven werken. Home Assistant toont tijdelijk niets of is niet bereikbaar. Na de herstart moet de MQTT-integratie opnieuw verbinding maken en moeten nieuwe berichten weer bij de entiteiten terechtkomen.

Alleen het internet valt uit

Als de ESP32, broker en Home Assistant allemaal lokaal werken en het lokale netwerk actief blijft, verwachten we dat nieuwe metingen gewoon aankomen. Dat is later een belangrijke controle van onze keuze voor lokale werking.

Een voorspelling dwingt je om precies na te denken over de taak van ieder onderdeel. De waarneming daarna laat zien of je beeld van de route klopt.

De kortste zinvolle controle kiezen

Stel dat de temperatuur in Home Assistant niet verandert wanneer je de SHT41 voorzichtig met je hand verwarmt.

Begin dan niet direct met het aanpassen van MQTT-instellingen. Vraag eerst: waar bevindt de nieuwste bevestigde waarde zich?

Controle 1: Seriële monitor of display

Verandert de temperatuur daar wel, dan werken de sensor, bedrading en uitleescode waarschijnlijk.

Controle 2: MQTT-verkeer

Verschijnen nieuwe waarden op het juiste topic, dan werken ook wifi, de MQTT-client en de route naar de broker waarschijnlijk.

Controle 3: entiteit in Home Assistant

Ziet een andere MQTT-client het bericht, maar verandert de entiteit niet, vergelijk dan topic en configuratie teken voor teken.

Controle 4: dashboard

Heeft de entiteit wel een nieuwe toestand, maar toont de dashboardkaart een oude of andere waarde, dan ligt het probleem ná de entiteit.

Met iedere controle maak je het onbekende deel kleiner. Je hoeft dan niet de hele keten opnieuw op te bouwen.

Een overzicht voor op de werkbank

Onderdeel	Hoofdtaak	Eenvoudige controle	Zegt nog niets over
SHT41	Temperatuur en luchtvochtigheid meten	Logische waarden in de Seriële monitor	Wifi en MQTT
PIR-sensor	Beweging waarnemen	Statuswijziging bij beweging	Publicatie naar Home Assistant
ESP32-code	Uitlezen, beslissen en voorbereiden	Duidelijke seriële meldingen en correct display	Bereikbaarheid van de broker
Wifi	Lokaal netwerkpad bieden	IP-adres en verbindingsstatus	Geldige MQTT-inlog
MQTT-client	Verbinden, publiceren en ontvangen	Verbindingsstatus en publicatiemelding	Verwerking door Home Assistant
MQTT-broker	Berichten ontvangen en verdelen	Bericht zichtbaar met een tweede client	Juiste Home Assistant-entiteit
MQTT-integratie	Home Assistant met de broker verbinden	Integratie verbonden en bericht ontvangen	Juiste dashboardkaart
Entiteit	De actuele toestand vasthouden	Toestand en laatste wijziging bekijken	Correcte weergave op ieder dashboard
Dashboard	Informatie tonen	Kaart vergelijken met de entiteit	Werking van eerdere stappen bij een oude waarde

Gebruik dit overzicht later niet als een verplicht rijtje dat je altijd volledig moet doorlopen. Kies de kortste controle die onderscheid maakt tussen twee mogelijke oorzaken.

Verander steeds één onderdeel tegelijk

Wanneer iets niet werkt, is de verleiding groot om meerdere instellingen tegelijk te veranderen. Je past het wifinetwerk aan, wijzigt het brokeradres, kiest een andere topicnaam en uploadt nieuwe code.

Werkt het daarna, dan weet je niet welke wijziging het probleem heeft opgelost. Werkt het nog steeds niet, dan heb je meerdere nieuwe onzekerheden toegevoegd.

In De Werkplaats gebruiken we daarom steeds dezelfde werkwijze:

beschrijf wat je verwacht;
kijk wat er werkelijk gebeurt;
bepaal het laatste bevestigde punt in de route;
formuleer één mogelijke oorzaak;
wijzig of test één onderdeel;
controleer of de uitkomst bij je voorspelling past;
leg de bevinding kort vast.

Een onverwachte uitkomst is daarbij geen mislukking. Zij vertelt dat een aanname niet klopt of dat de fout zich ergens anders bevindt. Dat is bruikbare informatie.

Een lokale route met bewuste grenzen

Ons doel is dat de basisroute binnen het lokale netwerk blijft:

SHT41 → ESP32 → wifi → lokale MQTT-broker → lokaal Home Assistant

De metingen hoeven daarvoor niet eerst naar een externe clouddienst. Dat heeft praktische voordelen:

de route kan blijven werken wanneer internet uitvalt;
de reactietijd is niet afhankelijk van een server buiten je netwerk;
je bepaalt zelf waar de gegevens worden verwerkt en opgeslagen;
je bent minder afhankelijk van wijzigingen bij een fabrikant.

Lokaal betekent niet automatisch veilig of storingsvrij. Een zwak wachtwoord blijft een zwak wachtwoord. Een instabiele voeding kan nog steeds vreemde storingen veroorzaken. En een lokaal netwerk moet ook zorgvuldig worden beheerd.

Lokale werking geeft je vooral meer controle. Die controle wordt pas waardevol wanneer je begrijpt welke onderdelen gegevens ontvangen, waar ze worden opgeslagen en welke verbindingen werkelijk nodig zijn.

Een eerste denkoefening

Je hoeft voor deze oefening niets aan te sluiten.

Stel je de volgende situatie voor:

het kleurendisplay toont 20,1 °C;
de PIR-sensor schakelt het display correct in;
de ESP32 meldt dat wifi verbonden is;
Home Assistant toont nog steeds 19,6 °C;
een aparte MQTT-client ziet iedere dertig seconden 20.1 op het afgesproken topic.

Waar zou je als eerste zoeken?

De SHT41 levert kennelijk een bruikbare waarde. De ESP32 verwerkt en toont haar. De PIR-route werkt. Wifi en de publicatie naar de broker lijken eveneens te werken, want de aparte client ontvangt het bericht.

Het laatste bevestigde punt is daarmee de broker. Het meest zinvolle zoekgebied ligt tussen de broker, de MQTT-integratie en de Home Assistant-entiteit.

De sensor vervangen of de PIR-bedrading aanpassen zou in deze situatie geen gerichte test zijn.

Dit is de manier waarop we de rest van de gids naar problemen kijken: niet vanuit de plaats waar het gevolg zichtbaar wordt, maar vanuit het laatste punt waarvan we de werking hebben bevestigd.

Wat je uit dit hoofdstuk kunt meenemen

Een meetwaarde legt een route af voordat zij in Home Assistant zichtbaar wordt.
Onderweg verandert dezelfde informatie van fysieke meting in een programmavariabele, MQTT-payload en Home Assistant-toestand.
De SHT41 meet, maar kent wifi, MQTT en Home Assistant niet.
De PIR-sensor kan een korte lokale route gebruiken om het display direct te bedienen.
De ESP32 leest sensoren uit, neemt lokale beslissingen, bereidt berichten voor en bewaakt verbindingen.
Wifi biedt het lokale netwerkpad; een wifiverbinding is nog geen MQTT-verbinding.
Een MQTT-client publiceert berichten en kan zich op topics abonneren.
De broker ontvangt en verdeelt berichten, maar geeft er niet zelf betekenis aan.
Home Assistant ontvangt gegevens via een integratie en koppelt ze aan entiteiten.
Een oude, geloofwaardige waarde is niet automatisch een betrouwbare actuele waarde.
unknown en unavailable zijn bruikbare signalen over de gegevensroute.
Door het laatste bevestigde punt te zoeken, maak je het foutgebied kleiner.
Voorspellen, waarnemen en steeds één onderdeel veranderen maakt het systeem begrijpelijk.

De route ligt nu als een kaart voor ons. We weten welke taak bij de sensor, de ESP32, wifi, MQTT, de broker en Home Assistant hoort. We weten ook dat Home Assistant meer doet dan alleen een getal op een scherm zetten.

In het volgende hoofdstuk leren we Home Assistant zelf kennen. We bekijken hoe de omgeving is opgebouwd en wat begrippen als integratie, apparaat, entiteit, toestand en dashboard in de praktijk betekenen. Daarmee bereiden we het eindpunt van onze gegevensroute voor, voordat we de eerste MQTT-berichten werkelijk gaan versturen.