Zo zoek je systematisch naar een probleem

In het vorige hoofdstuk hebben we veelvoorkomende fouten leren herkennen. We weten nu bijvoorbeeld dat een ontbrekende sensormeting kan worden veroorzaakt door voeding, bedrading, een verkeerd I²C-adres of een ongeschikte bibliotheek.

Maar een lijst met mogelijke oorzaken is nog geen foutzoekmethode.

Wanneer je bij ieder probleem tien mogelijke oplossingen probeert, kan het project uiteindelijk weer werken zonder dat je begrijpt waarom. Bij een volgende storing begin je dan opnieuw.

Systematisch foutzoeken werkt anders.

We gaan niet direct op zoek naar een oplossing. We proberen eerst zo precies mogelijk vast te stellen waar het werkelijke gedrag begint af te wijken van onze verwachting.

Daarvoor gebruiken we steeds dezelfde cirkel:

Observeren → afbakenen → hypothese maken → testen → beoordelen → vastleggen

Deze methode werkt niet alleen voor onze ESP32, BME280, WiFi en MQTT. Je kunt hem toepassen op vrijwel ieder technisch project.

Foutzoeken is geen gokken

Stel dat de temperatuur niet in Home Assistant verschijnt.

We kunnen dan meteen:

de ESP32 opnieuw opstarten;

alle bedrading vervangen;

de code opnieuw uploaden;

de broker herstarten;

een andere bibliotheek installeren;

Home Assistant opnieuw starten.

Misschien werkt het daarna. Maar welke handeling heeft het probleem opgelost?

En belangrijker: wat was er werkelijk fout?

Bij systematisch foutzoeken stellen we eerst vragen:

Verschijnt de temperatuur in de seriële monitor?

Is WiFi verbonden?

Is MQTT verbonden?

Meldt de code een geslaagde publicatie?

Ziet een algemene MQTT-client het bericht?

Luistert Home Assistant naar exact hetzelfde topic?

Iedere vraag verdeelt het probleem in kleinere delen.

Ons doel is niet om zo snel mogelijk iets willekeurigs te veranderen. Ons doel is om met iedere test nieuwe informatie te verkrijgen.

De foutzoekcirkel

Tijdens deze gids zijn drie vragen steeds teruggekomen:

Wat verwacht je?
Wat gebeurt er werkelijk?
Hoe kun je het verschil verklaren en testen?

Voor systematisch foutzoeken breiden we dit uit tot zes stappen.

1. Observeren

Beschrijf het zichtbare gedrag zonder meteen een oorzaak te noemen.

2. Afbakenen

Bepaal welk deel van het systeem aantoonbaar werkt en waar het gedrag voor het eerst afwijkt.

3. Een hypothese maken

Formuleer één mogelijke verklaring die bij de waarnemingen past.

4. Een test kiezen

Kies een controle die onderscheid maakt tussen mogelijke verklaringen.

5. Het resultaat beoordelen

Vergelijk de uitkomst met je voorspelling en bepaal wat je nu weet.

6. Vastleggen

Noteer wat je hebt getest, wat het resultaat was en welke conclusie je daaruit trekt.

Na de test begint de cirkel opnieuw. Iedere ronde maakt het probleem kleiner.

Stap 0 — Maak de situatie veilig

Voordat we meten of onderdelen verplaatsen, controleren we of het veilig is om verder te werken.

Koppel de voeding direct los wanneer:

een onderdeel ongewoon warm wordt;

je rook of een brandlucht waarneemt;

er mogelijk kortsluiting is;

een voedingsspanning verkeerd is aangesloten;

beschadigde bedrading zichtbaar is;

metalen delen elkaar ongewenst raken.

Ga niet verder testen door de ESP32 steeds opnieuw kort aan te sluiten.

Bij een mogelijke elektrische fout onderzoeken we de spanningsloze schakeling eerst visueel en met geschikte metingen.

Maak daarnaast een gewoonte van de volgende werkwijze:

Schakel de voeding uit.

Breng de wijziging aan.

Controleer de verbindingen.

Schakel de voeding weer in.

Observeer het resultaat.

Veiligheid is geen afzonderlijk onderdeel van foutzoeken. Het is de voorwaarde waaronder we kunnen foutzoeken.

Stap 1 — Beschrijf het probleem precies

Een uitspraak als:

Het werkt niet.

vertelt ons bijna niets.

We weten dan niet:

wat “het” is;

welk gedrag werd verwacht;

wat er werkelijk gebeurde;

of het ooit heeft gewerkt;

wat er vlak daarvoor veranderde.

Een bruikbare probleembeschrijving bevat minimaal:

de verwachte situatie;

de werkelijke situatie;

het moment waarop het probleem ontstaat;

de onderdelen die nog wel werken.

Bijvoorbeeld:

De BME280 wordt gevonden en toont iedere twee seconden geldige meetwaarden in de seriële monitor. WiFi krijgt een IP-adres en MQTT meldt dat de verbinding is gelukt. De code meldt dat de temperatuur is gepubliceerd, maar Home Assistant toont geen waarde.

Deze beschrijving verkleint het zoekgebied direct.

We hoeven waarschijnlijk niet te beginnen bij:

de USB-kabel;

de voeding van de BME280;

SDA en SCL;

het I²C-adres;

de WiFi-inloggegevens.

Die onderdelen hebben al aantoonbaar iets gedaan.

Feiten en aannames scheiden

Maak twee korte lijsten.

Wat weet ik?

Hier noteer je alleen waarnemingen.

Bijvoorbeeld:

de voedingsled brandt;

de seriële monitor toont BME280 gevonden;

de temperatuur is 21,8 °C;

WiFi toont IP-adres 192.168.1.74;

MQTT meldt gelukt;

publish() geeft true terug.

Wat neem ik aan?

Hier noteer je dingen die je nog niet onafhankelijk hebt gecontroleerd.

Bijvoorbeeld:

Home Assistant gebruikt dezelfde broker;

het topic is correct overgenomen;

het ontvangen IP-adres is geldig binnen het netwerk;

het BME280-moduletype klopt;

de meetwaarde is nauwkeurig;

de broker bewaart retained berichten.

Deze scheiding is waardevol. Veel langdurige fouten blijven bestaan doordat een aanname onbewust als feit wordt behandeld.

Beschrijf gedrag, geen oordeel

Vergelijk:

De WiFi is slecht.

met:

De ESP32 verbindt op zijn uiteindelijke plaats drie keer per uur opnieuw en toont een RSSI tussen -79 en -84 dBm.

De tweede beschrijving is meetbaar en controleerbaar.

Vergelijk ook:

De sensor is kapot.

met:

De sensor ontvangt 3,3 volt, maar de I²C-scanner vindt geen apparaat op 0x76 of 0x77. Dezelfde bedrading vindt een tweede BME280 wel op 0x76.

De tweede omschrijving bevat bewijs dat de verdenking ondersteunt.

Stap 2 — Maak het probleem herhaalbaar

Een fout die je bewust kunt oproepen, is meestal gemakkelijker te onderzoeken.

Probeer daarom vast te stellen:

gebeurt het bij iedere start;

gebeurt het alleen na langere tijd;

gebeurt het alleen wanneer WiFi actief wordt;

gebeurt het alleen in de behuizing;

gebeurt het na een MQTT-opdracht;

gebeurt het alleen op een bepaalde plaats;

gebeurt het na het aanraken van een draad;

gebeurt het na het wegvallen van het netwerk?

Noteer de exacte handelingen.

Bijvoorbeeld:

Sluit de ESP32 via USB aan.

Wacht totdat WiFi verbonden is.

Schakel de MQTT-broker uit.

Wacht twintig seconden.

Schakel de broker weer in.

De ESP32 verbindt opnieuw, maar ontvangt geen opdrachten.

Dat is een herhaalbaar scenario.

Nu kunnen we testen of het abonnement na herstel opnieuw wordt ingesteld.

Verander tijdens het reproduceren nog niets

Wanneer de fout optreedt, is de neiging groot om meteen een draad aan te drukken of reset te gebruiken.

Probeer eerst vast te leggen:

wat de seriële monitor toont;

welke leds branden;

wat de laatste geldige meetwaarde was;

welke status WiFi en MQTT melden;

of de ESP32 opnieuw is opgestart;

wat de andere systemen op dat moment zien.

Een reset kan belangrijke informatie wissen en de fout tijdelijk laten verdwijnen.

Intermitterende fouten

Sommige problemen treden slechts af en toe op.

Maak ze dan meetbaar door bij te houden:

hoe vaak het gebeurt;

na hoeveel tijd;

onder welke omstandigheden;

wat direct voorafging aan de fout;

hoe lang de fout duurt;

hoe het systeem herstelt.

In plaats van:

MQTT valt soms weg.

schrijf je bijvoorbeeld:

Tijdens een test van twee uur werd MQTT vier keer verbroken. WiFi bleef iedere keer verbonden. De MQTT-client herstelde binnen tien seconden en abonneerde zich opnieuw.

Dat vertelt ons dat de storing waarschijnlijk niet begint bij WiFi en dat de herstelcode werkt.

Stap 3 — Teken de keten

Bij een groter project helpt het om de route van informatie zichtbaar te maken.

Voor onze temperatuursensor is dat:

Omgeving → BME280 → I²C → ESP32-code → WiFi → MQTT-client → broker → topic → Home Assistant

Voor de voeding is een andere keten relevant:

USB-voeding → kabel → ontwikkelbord → spanningsregelaar → 3V3 → BME280 → GND

Voor een inkomende opdracht gebruiken we:

Home Assistant → broker → MQTT-abonnement → callback → code → actie

Eén project bevat dus meerdere ketens.

Kies de keten die hoort bij het probleem dat je onderzoekt.

Zoek het laatste bevestigde punt

Bij iedere stap vragen we:

Kan ik aantonen dat de informatie tot hier correct aankomt?

Stel dat:

de BME280 geldige waarden geeft;

de ESP32 de waarden in de seriële monitor toont;

WiFi een IP-adres heeft;

MQTT verbonden is;

MQTT Explorer het temperatuurtopic ontvangt;

Home Assistant niets toont.

Dan ligt de grens tussen:

MQTT-broker → Home Assistant

We hoeven de BME280 niet meer los te halen. Het probleem bevindt zich verderop in de keten.

Zoek het eerste afwijkende punt

Het laatste werkende punt en het eerste niet-werkende punt vormen samen ons zoekgebied.

Bijvoorbeeld:

Het zoekgebied is nu klein:

topic in Home Assistant;

payloadformaat;

template;

verbinding van Home Assistant met de broker;

configuratie van de entiteit.

Dat is afbakenen.

Stap 4 — Deel het systeem in blokken

Een ingewikkeld project wordt overzichtelijker wanneer we het opdelen in functionele blokken.

Voor ons project kunnen we bijvoorbeeld deze blokken gebruiken:

voeding;

ESP32 en opstarten;

sensor en I²C;

verwerking in de code;

WiFi;

MQTT;

ontvanger.

Test ieder blok zoveel mogelijk afzonderlijk.

Blok 1 — Voeding

Vragen:

krijgt de ESP32 voeding;

blijft de 3,3-voltvoeding stabiel;

bereikt GND alle onderdelen;

start het bord onverwacht opnieuw op?

Middelen:

voedingsled;

multimeter;

seriële opstartmeldingen;

test zonder externe onderdelen;

bekende goede kabel en voeding.

Blok 2 — ESP32 en opstarten

Vragen:

wordt de ESP32 door de computer herkend;

draait de verwachte codeversie;

begint setup();

bereikt het programma loop()?

Middelen:

herkenbare opstarttekst;

teller in loop();

resetknop;

eenvoudige testcode;

vergelijking van bord en poort.

Blok 3 — Sensor en I²C

Vragen:

krijgt de BME280 3,3 volt;

ziet de I²C-scanner een apparaat;

klopt het adres;

geeft de bibliotheek geldige waarden?

Middelen:

multimeter;

I²C-scanner;

minimale sensorcode;

tweede bekende sensor;

korte jumperdraden.

Blok 4 — Verwerking in de code

Vragen:

worden de waarden in de juiste variabelen opgeslagen;

zijn ze geldig;

wordt de juiste voorwaarde bereikt;

wordt de publicatiefunctie aangeroepen?

Middelen:

seriële meldingen;

tijdelijke vaste testwaarde;

teller;

controle van isnan();

één berekening tegelijk.

Blok 5 — WiFi

Vragen:

is 2,4 GHz beschikbaar;

klopt de SSID;

ontvangt de ESP32 een IP-adres;

blijft de verbinding stabiel?

Middelen:

WiFi.status();

WiFi.localIP();

WiFi.RSSI();

test dicht bij het accesspoint;

tweede apparaat op hetzelfde netwerk.

Blok 6 — MQTT

Vragen:

is de broker bereikbaar;

klopt de authenticatie;

is de client-ID uniek;

lukt publiceren;

wordt opnieuw geabonneerd?

Middelen:

mqttClient.state();

brokerlog;

MQTT Explorer;

een eenvoudig testtopic;

andere MQTT-client met dezelfde gegevens.

Blok 7 — Ontvanger

Vragen:

luistert de ontvanger naar het juiste topic;

begrijpt hij het payloadformaat;

gebruikt hij dezelfde broker;

wordt de beschikbaarheid correct verwerkt?

Middelen:

luisteren op werkplaats/sensor/#;

topic kopiëren;

ruwe payload bekijken;

tijdelijke handmatige publicatie;

configuratie van de entiteit controleren.

Stap 5 — Vereenvoudig het project

Wanneer een project uit veel onderdelen bestaat, kan een kleine minimale test meer duidelijkheid geven dan het volledige programma.

Vereenvoudigen betekent:

verwijder onderdelen die niet nodig zijn voor de test;

schakel functies tijdelijk uit;

gebruik vaste testwaarden;

test één verbinding;

maak het gedrag zichtbaar.

Het doel is niet om het volledige project opnieuw te bouwen. We willen één gerichte vraag beantwoorden.

Voorbeeld: alleen de sensor testen

Als je wilt weten of de BME280 werkt, heb je WiFi en MQTT niet nodig.

Gebruik tijdelijk alleen:

ESP32;

BME280;

I²C;

seriële monitor.

Werkt de sensor in deze minimale opstelling wel, dan ligt het probleem waarschijnlijk niet in de basisbedrading of sensorbibliotheek.

Voorbeeld: MQTT zonder sensor testen

Als MQTT niet duidelijk werkt, publiceer dan tijdelijk een vaste tekst:

mqttClient.publish(

"werkplaats/sensor/test",

"hallo",

false

);

Komt hallo bij de broker aan? Dan werkt de MQTT-route. Het probleem kan daarna worden gezocht bij de meetwaarde, omzetting of publicatievoorwaarde.

Dit is krachtiger dan voortdurend echte sensordata proberen te publiceren, omdat we één mogelijke bron van fouten tijdelijk verwijderen.

Voorbeeld: ontvanger zonder ESP32 testen

Publiceer met MQTT Explorer of een ander hulpmiddel handmatig:

21.8

op:

werkplaats/sensor/temperatuur

Verschijnt de waarde nu wel in Home Assistant?

Zo ja, dan begrijpt Home Assistant het topic en de payload. Het probleem bevindt zich waarschijnlijk vóór de ontvanger.

Zo nee, dan hoeven we de ESP32-code nog niet te wijzigen. De configuratie van de ontvanger verdient eerst aandacht.

Vereenvoudigen is geen permanente oplossing

Een minimale testopstelling is een diagnosemiddel.

Zodra je het probleem hebt gevonden, bouw je de volledige functionaliteit stap voor stap opnieuw op. Test na iedere toevoeging of het gedrag correct blijft.

Stap 6 — Formuleer een hypothese

Een hypothese is een concrete, testbare verklaring voor wat je waarneemt.

Een goede hypothese heeft deze vorm:

Ik vermoed dat [oorzaak], omdat [waarneming]. Als dat klopt, verwacht ik bij [test] het volgende resultaat.

Bijvoorbeeld:

Ik vermoed dat Home Assistant naar een verkeerd topic luistert, omdat MQTT Explorer de temperatuur wel ontvangt. Als dat klopt, moet een handmatige publicatie op het door Home Assistant gebruikte topic wel zichtbaar worden.

Of:

Ik vermoed dat de BME280 adres 0x77 gebruikt, omdat de voeding aanwezig is maar bme.begin(0x76) mislukt. Als dat klopt, moet de I²C-scanner een apparaat op 0x77 vinden.

Een hypothese is geen zekerheid. Het is een verklaring die we bewust gaan proberen te weerleggen of ondersteunen.

Een vage hypothese helpt weinig

Deze hypothese is te breed:

Er is iets met WiFi.

Deze is beter:

Ik vermoed dat het 2,4GHz-signaal op de definitieve plaats te zwak is, omdat de ESP32 dicht bij de router wel verbindt en op zijn bestemming een RSSI lager dan -80 dBm toont.

Nu weten we welke meting en vergelijking relevant zijn.

Rangschik hypothesen

Wanneer meerdere oorzaken mogelijk zijn, begin dan meestal met een hypothese die:

goed bij de waarnemingen past;

veel voorkomt;

eenvoudig te testen is;

veilig kan worden gecontroleerd;

geen grote wijzigingen vereist.

Als de ESP32 niet op de computer verschijnt, test je eerder een bekende datakabel dan dat je direct de bootloader vervangt.

Dat betekent niet dat de eenvoudige oorzaak altijd juist is. Het betekent dat de test efficiënt informatie oplevert.

Stap 7 — Kies een onderscheidende test

Een goede test vertelt ons meer dan alleen “het werkte” of “het werkte niet”.

De test moet bij voorkeur twee of meer mogelijke verklaringen van elkaar onderscheiden.

Stel:

de BME280 wordt niet gevonden;

mogelijke oorzaken zijn voeding, bedrading, adres of sensortype.

Een controle met de multimeter beantwoordt:

Ontvangt de module ongeveer 3,3 volt?

De I²C-scanner beantwoordt daarna:

Reageert er een apparaat op de bus en op welk adres?

De bibliotheektest beantwoordt vervolgens:

Is het gevonden apparaat een BME280 die door deze bibliotheek wordt herkend?

Iedere test onderzoekt een ander deel.

Een test heeft een voorspelling nodig

Voordat je de test uitvoert, schrijf je op wat je verwacht als de hypothese klopt.

Bijvoorbeeld:

Hypothese: SDA en SCL zijn verwisseld.
Test: sluit SDA op GPIO 21 en SCL op GPIO 22 aan en voer de I²C-scanner opnieuw uit.
Verwachting: als de hypothese klopt, verschijnt nu adres 0x76 of 0x77.

Zonder voorspelling is de verleiding groter om iedere uitkomst achteraf passend te verklaren.

Verander één variabele tegelijk

Als je tegelijk:

SDA en SCL verwisselt;

het adres verandert;

de bibliotheek vervangt;

een andere sensor aansluit;

en het daarna werkt, weet je niet welke hypothese juist was.

Verander daarom één factor en houd de rest gelijk.

Dat is niet altijd letterlijk mogelijk. Soms moet een volledige module worden vervangen. Noteer dan precies wat er samen verandert.

Gebruik een bekende goede referentie

Een referentie helpt om onderdelen te vergelijken.

Voorbeelden:

een bekende werkende USB-datakabel;

een tweede BME280;

een eenvoudige testsketch;

een multimeter waarvan je de instelling kent;

een MQTT-client die op dezelfde broker werkt;

een tweede ESP32 met dezelfde code.

Stel dat sensor A niet wordt gevonden en sensor B op dezelfde bedrading wel. Dan wordt een defect of afwijkend type bij sensor A waarschijnlijker.

Een vergelijking bewijst niet automatisch de precieze interne fout, maar verkleint het zoekgebied.

Stap 8 — Meet op grenspunten

De beste meetpunten liggen vaak tussen twee blokken.

Op zo’n grenspunt kun je controleren of de uitvoer van het ene blok correct aankomt bij het volgende.

Voor onze keten zijn bruikbare grenspunten:

3V3 en GND op de sensormodule;

het I²C-adres in de scanner;

de meetwaarde in de seriële monitor;

het IP-adres na WiFi;

het resultaat van mqttClient.connect();

het resultaat van mqttClient.publish();

het bericht in MQTT Explorer;

de uiteindelijke waarde in Home Assistant.

Waarom grenspunten zo nuttig zijn

Stel dat de temperatuur correct in MQTT Explorer staat, maar niet in Home Assistant.

Dan weten we dat de waarde deze grens heeft bereikt:

Broker → MQTT Explorer

De fout zit niet meer bij de sensor of WiFi.

Stel dat publish() false teruggeeft. Dan bereikt de waarde de broker mogelijk niet en zoeken we eerder bij de MQTT-verbinding of payload.

Door op grenspunten te meten, hoeven we niet het hele systeem tegelijk te begrijpen.

Stap 9 — Halveer het zoekgebied

Bij een lange keten kun je tijd besparen door ongeveer in het midden te testen.

Stel dat een meetwaarde niet bij Home Assistant aankomt:

BME280 → ESP32 → WiFi → MQTT → broker → Home Assistant

Kijk eerst in MQTT Explorer.

Bericht staat in MQTT Explorer

Dan werkt het eerste grote deel:

BME280 → ESP32 → WiFi → MQTT → broker

Zoek verder tussen broker en Home Assistant.

Bericht staat niet in MQTT Explorer

Kijk vervolgens in de seriële monitor.

Meetwaarde staat wel in de seriële monitor

Dan werken de sensor en lokale code. Zoek verder bij WiFi, MQTT en publiceren.

Meetwaarde staat niet in de seriële monitor

Zoek eerder bij voeding, I²C, sensor en sensorcode.

Met enkele tests hebben we het zoekgebied steeds ongeveer gehalveerd.

Dit wordt soms een binaire zoekstrategie genoemd. Je hoeft de naam niet te onthouden. Het principe is belangrijker:

Test niet altijd vanaf het allereerste begin; kies een punt dat het probleem in twee grote delen verdeelt.

Stap 10 — Gebruik de seriële monitor als meetinstrument

De seriële monitor is een van onze belangrijkste foutzoekhulpmiddelen.

Gebruik hem niet alleen om eindwaarden te tonen. Laat ook belangrijke overgangen zien.

Bijvoorbeeld:

Serial.println("BME280 starten");

Serial.println("WiFi-poging gestart");

Serial.println("WiFi verbonden");

Serial.println("MQTT-poging gestart");

Serial.println("MQTT verbonden");

Serial.println("Temperatuur publiceren");

Zo ontstaat een tijdlijn van wat de ESP32 doet.

Toon niet alles voortdurend

Te veel meldingen kunnen een nieuw probleem veroorzaken:

de uitvoer wordt onoverzichtelijk;

belangrijke regels verdwijnen snel uit beeld;

voortdurend printen kost tijd;

timing kan veranderen;

gevoelige gegevens kunnen zichtbaar worden.

Kies daarom meldingen die een vraag beantwoorden.

Niet iedere uitvoering van loop() hoeft te tonen dat WiFi nog verbonden is. Een melding bij verandering van toestand is vaak nuttiger.

Geef meldingen context

Deze melding is weinig bruikbaar:

Fout

Deze is beter:

MQTT verbinden mislukt, foutcode: -2

Nog beter is:

MQTT verbinden met 192.168.1.50:1883 mislukt,

foutcode: -2

WiFi-status: verbonden

Toon nooit wachtwoorden in de seriële monitor.

Voeg een teller toe

Een teller helpt bepalen of code blijft draaien:

unsigned long loopCounter = 0;

void loop() {

loopCounter++;

if (loopCounter % 100000 == 0) {

Serial.println("Hoofdloop actief");

}

}

Gebruik zo’n teller tijdelijk en met mate. Een tijdgestuurde statusmelding is vaak beter leesbaar:

const unsigned long statusInterval = 30000;

unsigned long lastStatus = 0;

void loop() {

if (millis() - lastStatus >= statusInterval) {

lastStatus = millis();

Serial.println("Programma actief");

}

}

Markeer het begin van een codeversie

Voeg bij het opstarten een herkenbare versie toe:

Serial.println("Werkplaats-sensor versie 1.3");

Zo weet je zeker welke code op het bord draait.

Dit voorkomt dat je een fout onderzoekt in code die nooit naar deze ESP32 is geüpload.

Stap 11 — Gebruik de multimeter gericht

Een multimeter vertelt alleen iets wanneer je weet:

welke grootheid je meet;

tussen welke punten;

welke waarde je verwacht;

wat een afwijkende waarde betekent.

Voorbeeld: voeding van de BME280

Vraag:

Bereikt de 3,3-voltvoeding de sensor?

Instelling:

gelijkspanning.

Meetpunten:

zwart op GND van de BME280;

rood op de voedingspin van de BME280.

Verwachting:

ongeveer 3,3 V

Je meet ongeveer 3,3 volt

De voeding bereikt de module. Zoek verder bij I²C, adres of sensoridentificatie.

Je meet ongeveer 0 volt

Zoek bij:

draad naar 3V3;

draad naar GND;

breadboardrail;

onderbroken verbinding;

voeding van de ESP32.

Je meet een negatieve waarde

De meetpennen of verwachte polariteit zijn waarschijnlijk omgewisseld.

Voorbeeld: GPIO-uitgang

Vraag:

Verandert GPIO 23 elektrisch wanneer de code HIGH en LOW schrijft?

Meetpunten:

zwart op GND;

rood op GPIO 23.

Gebruik langere intervallen zodat de waarde rustig kan worden afgelezen.

Verwachting:

bij HIGH ongeveer 3,3 volt;

bij LOW ongeveer 0 volt.

Als dit klopt maar de led niet reageert, zoek je na de GPIO:

weerstand;

led;

richting;

GND-verbinding.

Continuïteit alleen zonder spanning

Met de continuïteitstest kun je onderzoeken of twee punten elektrisch verbonden zijn.

Gebruik deze stand alleen bij een spanningsloze schakeling.

Controleer bijvoorbeeld:

of een jumperdraad intern heel is;

welke breadboardgaatjes verbonden zijn;

of GND de module bereikt;

of een voedingsrail halverwege is onderbroken.

Een pieptoon bewijst dat er een geleidende verbinding is. Hij bewijst niet dat die verbinding ook naar het juiste punt loopt.

Stap 12 — Controleer de aannames tussen code en werkelijkheid

Een microcontrollerproject heeft altijd twee beschrijvingen:

de fysieke schakeling;

de softwarematige schakeling in onze code.

Die moeten overeenkomen.

Vergelijk bijvoorbeeld:

Een fout ontstaat vaak doordat één kant is aangepast en de andere niet.

Controleer namen teken voor teken

Bij WiFi, bestanden en MQTT zijn namen vaak hoofdlettergevoelig of exact.

Controleer:

werkplaats/sensor/temperatuur

tegen:

werkplaats/sensor/Temperatuur

Controleer ook:

Arduino_Secrets.h

tegen een bestand met een afwijkende naam of extensie.

Niet “ongeveer hetzelfde”, maar exact hetzelfde.

Stap 13 — Kijk naar wat er vlak vóór de fout veranderde

Wanneer een project eerder werkte, is de wijzigingsgeschiedenis belangrijk.

Vraag:

welke code is aangepast;

welk onderdeel is toegevoegd;

is de voeding veranderd;

is het project in een behuizing geplaatst;

is een bibliotheek bijgewerkt;

is het WiFi-wachtwoord gewijzigd;

is de broker verhuisd;

zijn toegangsrechten aangepast;

is Home Assistant bijgewerkt;

is de ESP32 op een andere plaats gezet?

De laatste wijziging is niet automatisch de oorzaak. Hij geeft wel een logisch startpunt.

Maak wijzigingen klein

Werk tijdens de ontwikkeling in kleine, testbare stappen.

Bijvoorbeeld:

BME280 lokaal uitlezen.

WiFi toevoegen en testen.

WiFi-uitval testen.

MQTT toevoegen.

MQTT-publicatie testen.

MQTT-ontvangst toevoegen.

Herstel na brokeruitval testen.

Home Assistant koppelen.

Wanneer het project na stap 6 niet meer werkt, hoeven we niet alle onderdelen vanaf stap 1 te verdenken. We vergelijken stap 5 en 6.

Bewaar werkende versies

Bewaar een codeversie waarvan je weet dat deze werkt.

Geef hem een herkenbare naam of gebruik versiebeheer.

Noteer bijvoorbeeld boven in de code:

/*

Versie 1.2

- BME280 werkt

- WiFi herstelt automatisch

- MQTT-publicatie getest

*/

Een werkende versie is een referentie, geen reden om alle nieuwe code weg te gooien. Vergelijk gericht welke wijziging nieuw gedrag heeft veroorzaakt.

Stap 14 — Beoordeel de test eerlijk

Na iedere test vergelijken we het resultaat met de voorspelling.

Stel:

Hypothese: de BME280 gebruikt adres 0x77.

Test:

Voer de I²C-scanner uit.

Uitkomst:

De scanner vindt 0x76.

Dan is de hypothese niet ondersteund.

Verander niet alsnog het adres naar 0x77 “om het toch even te proberen”. De meting heeft juist aangetoond welk adres reageert.

Een test kan ook onbeslist zijn

Soms levert een test onvoldoende informatie op.

Bijvoorbeeld:

De voedingsled brandt.

Daaruit weten we dat er ergens voeding aanwezig is. We weten nog niet:

of de 3,3-voltregelaar goed werkt;

of de BME280 voeding ontvangt;

of de spanning stabiel blijft;

of de USB-kabel data ondersteunt.

Noteer dan:

De test bevestigt alleen dat het bord zichtbaar voeding ontvangt. Een spanningsmeting op de sensormodule is nog nodig.

Dat is beter dan een te brede conclusie.

Correlatie is nog geen oorzaak

Stel dat het project werkt nadat je de ESP32 opnieuw hebt geüpload.

Mogelijke verklaringen zijn:

de nieuwe code heeft iets opgelost;

de upload veroorzaakte een reset;

een draad is tijdens het aansluiten bewogen;

het accesspoint was inmiddels weer beschikbaar;

de broker was opnieuw gestart.

Herhaal waar mogelijk een gerichte test. Druk bijvoorbeeld alleen op reset zonder opnieuw te uploaden.

Stap 15 — Leg de bevindingen vast

Een eenvoudig diagnoseformulier voorkomt dat je in cirkels blijft werken.

Gebruik bijvoorbeeld:

Probleem

Wat werkt niet zoals verwacht?

Temperatuur verschijnt niet in Home Assistant.

Verwachting

Wat had er moeten gebeuren?

Iedere tien seconden moet een nieuwe temperatuur

op werkplaats/sensor/temperatuur verschijnen.

Waarneming

Wat gebeurt er werkelijk?

De BME280 toont 21,8 °C in de seriële monitor.

WiFi en MQTT melden verbonden.

Home Assistant blijft onbekend tonen.

Laatste bevestigde punt

MQTT Explorer ontvangt 21.8 op het juiste topic.

Hypothese

Home Assistant luistert naar een afwijkend topic.

Test

Vergelijk het topic teken voor teken en publiceer

handmatig 22.0 op het topic uit Home Assistant.

Verwachte uitkomst

Als de ontvangerconfiguratie verder klopt,

moet Home Assistant 22,0 °C tonen.

Werkelijke uitkomst

Handmatige publicatie verschijnt niet.

In Home Assistant staat Werkplaats met hoofdletter.

Conclusie

De topicnaam komt niet overeen.

Aanpassing

state_topic gewijzigd naar

werkplaats/sensor/temperatuur.

Controle na de aanpassing

Nieuwe ESP32-metingen verschijnen iedere tien seconden.

Dit formulier maakt je redenering zichtbaar. Het helpt ook wanneer je later iemand anders om hulp vraagt.

Een volledig praktijkvoorbeeld

We lopen de methode nu door met een probleem uit ons project.

De situatie

De BME280 is aangesloten. De ESP32 hoort de meetwaarden via MQTT te publiceren.

Home Assistant toont echter geen temperatuur.

Eerste reactie

We veranderen nog niets.

We openen de seriële monitor en noteren:

BME280 gevonden.

Temperatuur: 21.8 °C

WiFi: verbonden

MQTT: verbonden

werkplaats/sensor/temperatuur = 21.8 gepubliceerd

Wat weten we?

de ESP32 draait de verwachte code;

de BME280 wordt gevonden;

de temperatuur wordt uitgelezen;

WiFi is verbonden;

MQTT meldt verbonden;

de code roept publish() aan;

publish() meldt succes.

Wat weten we nog niet?

heeft de broker het bericht beschikbaar gemaakt;

luistert Home Assistant naar hetzelfde topic;

gebruikt Home Assistant dezelfde broker;

verwacht Home Assistant een eenvoudig getal of JSON;

klopt de configuratie van de entiteit?

De keten

BME280

↓

ESP32-code

↓

WiFi

↓

MQTT-client

↓

Broker

↓

Home Assistant

We testen ongeveer in het midden bij de broker.

Test 1 — MQTT Explorer

We verbinden MQTT Explorer met dezelfde broker en abonneren ons op:

werkplaats/sensor/#

We zien:

werkplaats/sensor/temperatuur = 21.8

Conclusie na test 1

De route tot en met de broker werkt.

Het zoekgebied wordt:

Broker → Home Assistant

We hoeven de sensorbedrading niet te veranderen.

Hypothese 1

Home Assistant luistert naar een afwijkend topic.

Test 2 — Topics vergelijken

ESP32-code:

werkplaats/sensor/temperatuur

Home Assistant:

werkplaats/sensor/temperature

De laatste woorden verschillen.

Voorspelling

Als dit de oorzaak is, moet Home Assistant na het aanpassen van het topic de waarde ontvangen.

Aanpassing

We wijzigen alleen het topic in Home Assistant.

Resultaat

De temperatuur verschijnt.

Eindcontrole

We wachten op meerdere nieuwe publicaties en controleren:

verandert de tijd van de laatste update;

blijft de waarde binnenkomen;

reageert de beschikbaarheidsstatus;

werkt het opnieuw na een MQTT-herverbinding?

Pas nu beschouwen we de fout als opgelost.

Wat hebben we niet gedaan?

We hebben niet:

de BME280 vervangen;

SDA en SCL verwisseld;

de ESP32 opnieuw geprogrammeerd;

het WiFi-wachtwoord aangepast;

de broker herstart;

alle bibliotheken opnieuw geïnstalleerd.

Geen van die handelingen paste bij het afgebakende zoekgebied.

Een tweede praktijkvoorbeeld: de sensor wordt niet gevonden

Waarneming

De seriële monitor toont:

BME280 niet gevonden.

WiFi en MQTT starten verder wel.

Keten

3V3 → module → I²C → bibliotheek

Test 1 — Voedingsspanning meten

We meten tussen VCC en GND op de BME280-module:

3,29 V

De voeding bereikt de module.

Test 2 — I²C-scanner

De scanner vindt:

Apparaat gevonden op adres 0x77

De fysieke I²C-communicatie werkt.

Codecontrole

De code bevat:

const uint8_t bmeAddress = 0x76;

Hypothese

De sensor wordt gezocht op een ander adres dan waarop hij reageert.

Test

We veranderen alleen:

const uint8_t bmeAddress = 0x77;

Resultaat

De code toont:

BME280 gevonden.

en geldige meetwaarden.

Eindconclusie

De sensor, voeding en bedrading waren goed. Alleen het ingestelde I²C-adres kwam niet overeen met de module.

Een derde praktijkvoorbeeld: de ESP32 start opnieuw bij WiFi

Waarneming

De BME280 wordt uitgelezen. Zodra WiFi probeert te verbinden, verschijnt de opstarttekst opnieuw.

Belangrijke aanwijzing

De fout ontstaat bij een gebeurtenis die extra stroom kan vragen.

Hypothese

De voeding of USB-kabel veroorzaakt een spanningsdip tijdens de WiFi-piek.

Test 1

We koppelen alle externe onderdelen los en gebruiken dezelfde USB-kabel.

De ESP32 start nog steeds opnieuw.

Test 2

We gebruiken een korte, bekende datakabel en dezelfde USB-poort.

De ESP32 blijft nu stabiel en WiFi verbindt.

Controle

We sluiten de BME280 opnieuw aan. Het project blijft werken.

Conclusie

De oude USB-kabel kon de ESP32 zichtbaar voeden, maar de spanning bleef tijdens WiFi-gebruik niet voldoende stabiel.

Ook hier zou het aanpassen van WiFi-code de werkelijke oorzaak niet hebben opgelost.

Wanneer je denkt dat je de fout hebt gevonden

Een project dat één keer werkt, is nog niet automatisch hersteld.

Voer na de aanpassing drie controles uit.

1. Herhaal het oorspronkelijke scenario

Kun je de omstandigheden waarin de fout ontstond opnieuw uitvoeren zonder dat het probleem terugkomt?

2. Test de normale werking

Werken de andere functies nog steeds?

Een oplossing voor WiFi mag bijvoorbeeld niet verhinderen dat de sensor wordt uitgelezen.

3. Test herstel na een storing

Schakel waar veilig mogelijk tijdelijk uit:

WiFi;

de MQTT-broker;

de sensorverbinding.

Controleer of het systeem zich gedraagt zoals ontworpen en na herstel weer verdergaat.

Controleer of de oplossing logisch past

Stel jezelf de vraag:

Verklaart deze gevonden oorzaak alle oorspronkelijke waarnemingen?

Als een nieuw WiFi-wachtwoord het probleem oplost, moet dat passen bij het feit dat er eerder geen IP-adres werd ontvangen.

Als het oorspronkelijke probleem alleen een onjuiste temperatuur was terwijl WiFi normaal werkte, is een WiFi-wachtwoord geen geloofwaardige verklaring.

Wanneer je vastloopt

Systematisch werken betekent niet dat je ieder probleem alleen moet oplossen.

Wanneer je hulp vraagt, geef dan:

het exacte bord;

de aangesloten onderdelen;

een duidelijk schema of foto;

de relevante code;

de volledige foutmelding;

wat je verwacht;

wat je waarneemt;

welke tests je al hebt uitgevoerd;

de uitkomsten van die tests;

welke wijziging vlak voor de fout is aangebracht.

Zeg bijvoorbeeld:

De BME280 ontvangt 3,29 volt en de I²C-scanner vindt 0x76. bme.begin(0x76) geeft toch false. De module is verkocht als BME280, maar ik heb het chiptype nog niet onafhankelijk bevestigd.

Dan kan iemand gericht meedenken over:

een verkeerd geleverd BMP280-model;

een ongeschikte bibliotheek;

een afwijkende of defecte module.

Stel één vraag tegelijk

Niet:

Kun je mijn volledige project repareren?

Maar bijvoorbeeld:

Hoe kan ik vaststellen of deze module werkelijk een BME280 is wanneer de I²C-scanner hem wel vindt, maar de BME280-bibliotheek hem weigert?

Een scherpe vraag levert meestal een scherper antwoord op.

Een vaste foutzoekvolgorde

Wanneer je niet weet waar je moet beginnen, gebruik dan deze volgorde.

1. Veiligheid

wordt iets warm;

is er kortsluiting;

klopt de voedingsspanning?

2. Voeding

krijgt de ESP32 voeding;

bereikt 3,3 volt de sensor;

is GND verbonden;

blijft de spanning stabiel?

3. Opstarten

start de ESP32;

draait de juiste code;

verschijnt de opstartmelding;

blijft het bord actief?

4. Hardwareverbinding

kloppen de pinnen;

zitten de draden in de juiste rijen;

maken de draden goed contact;

komt de schakeling overeen met het schema?

5. Lokale functie

werkt de led zonder netwerk;

vindt de I²C-scanner de sensor;

verschijnen meetwaarden in de seriële monitor?

6. Netwerk

verbindt WiFi;

verschijnt een IP-adres;

is het signaal voldoende;

herstelt de verbinding?

7. Dienst

is MQTT verbonden;

is de client-ID uniek;

lukt publiceren;

is opnieuw geabonneerd?

8. Ontvanger

komt het bericht op de broker aan;

klopt het topic;

klopt het payloadformaat;

gebruikt de ontvanger dezelfde broker?

9. Timing en langdurige werking

blokkeert delay() andere taken;

wordt mqttClient.loop() vaak genoeg uitgevoerd;

ontstaat de fout pas na langere tijd;

werkt herstel na uitval?

Deze volgorde voorkomt dat je Home Assistant gaat aanpassen terwijl de sensor niet eens wordt uitgelezen.

De foutzoekchecklist

Gebruik deze korte checklist tijdens ieder project.

Observeren

Wat verwacht ik?

Wat gebeurt er werkelijk?

Welke foutmelding verschijnt?

Wanneer ontstaat de fout?

Is de fout herhaalbaar?

Wat werkt nog wel?

Afbakenen

Wat is de relevante keten?

Wat is het laatste bevestigde werkende punt?

Wat is het eerste afwijkende punt?

Kan ik het systeem in kleinere blokken verdelen?

Kan ik ongeveer in het midden van de keten testen?

Hypothese

Welke oorzaak past bij alle waarnemingen?

Welke aannames heb ik nog niet gecontroleerd?

Is er een eenvoudiger waarschijnlijke verklaring?

Welke andere oorzaak zou hetzelfde gedrag geven?

Test

Welke meting onderscheidt de mogelijke oorzaken?

Wat verwacht ik als mijn hypothese klopt?

Kan ik één variabele tegelijk veranderen?

Kan ik een bekende goede referentie gebruiken?

Kan ik het probleem in een minimale opstelling testen?

Beoordelen

Kwam de uitkomst overeen met de voorspelling?

Wat heeft de test werkelijk bewezen?

Welke oorzaken kan ik nu uitsluiten?

Welke oorzaken blijven mogelijk?

Moet ik een nieuwe hypothese maken?

Vastleggen

Wat heb ik veranderd?

Waarom heb ik dat veranderd?

Wat was het resultaat?

Is de oorspronkelijke fout verdwenen?

Blijft de rest van het project werken?

Kan het systeem na een storing herstellen?

Wat je uit dit hoofdstuk kunt meenemen

Systematisch foutzoeken betekent niet dat je iedere mogelijke fout al kent.

Het betekent dat je een onbekend probleem kleiner kunt maken.

Daarbij heb je ontdekt dat:

een precieze probleembeschrijving het zoekgebied verkleint;

waarnemingen en aannames niet hetzelfde zijn;

een herhaalbare fout gemakkelijker te onderzoeken is;

een project als een keten van blokken kan worden bekeken;

het laatste werkende punt en het eerste afwijkende punt samen het zoekgebied vormen;

een minimale testopstelling één gerichte vraag kan beantwoorden;

een hypothese concreet en testbaar moet zijn;

een test vooraf een voorspelde uitkomst nodig heeft;

één wijziging tegelijk duidelijk maakt wat werkelijk verschil maakt;

grenspunten goede plaatsen zijn om te meten;

het halveren van de keten sneller kan zijn dan steeds vooraan beginnen;

de seriële monitor en multimeter meetinstrumenten zijn;

fysieke bedrading en code met elkaar moeten overeenkomen;

een wijzigingsgeschiedenis helpt bij nieuwe fouten;

een geslaagde test niet meer bewijst dan wat daadwerkelijk is gemeten;

een oplossing opnieuw onder de oorspronkelijke omstandigheden moet worden gecontroleerd;

het vastleggen van tests voorkomt dat je hetzelfde blijft proberen.

De kern van de methode blijft eenvoudig:

Observeren → afbakenen → hypothese maken → meten → één ding veranderen → opnieuw testen

Wanneer je deze werkwijze beheerst, hoef je niet ieder antwoord uit je hoofd te kennen.

Je kunt het antwoord stap voor stap vinden.

In het volgende hoofdstuk bekijken we hoe AI daarbij kan helpen. AI kan mogelijke verklaringen aandragen, code uitleggen en tests voorstellen. Maar wij blijven controleren of die suggesties passen bij ons bord, onze schakeling en onze werkelijke waarnemingen.