Hoe MeteoA weerdata verzamelt, controleert en levert

Van sensor naar dashboard in minder dan twee minuten — een transparante uitleg van onze datafusie, kwaliteitscontrole en leveringsarchitectuur.

Kort antwoord

MeteoA combineert een lokaal geïnstalleerd weerstation op uw locatie met KNMI-referentiedata via de EDR API. Elke 10 minuten worden ruwe sensorwaarden opgehaald, genormaliseerd naar een uniform schema, gecontroleerd op drie kwaliteitsniveaus en opgeslagen in maandelijkse Parquet-bestanden. Het dashboard toont altijd de meest recente waarden, aangevuld met historische grafieken en configureerbare alarmen.

Stap 1 — Dataverzameling: lokaal station + KNMI

MeteoA werkt met twee databronnen die parallel worden verwerkt:

Lokale weerstations (Ecowitt)

MeteoA installeert Ecowitt-weerstations (WS90, HP2553 en gelijkwaardige modellen) op de locatie van de klant. De stations communiceren via WiFi, 4G of LoRaWAN met de Ecowitt-cloud. MeteoA haalt elke 10 minuten historische observaties op via de Ecowitt historische data-API (dag-voor-dag requests) in metrische eenheden. Dit is bewust geen real-time push-API: de historiëke aanpak is robuuster bij tijdelijke verbindingsuitval en levert volledige datasets zonder gaten.

Ondersteunde sensorgroepen per station:

KNMI referentiedata (EDR API)

Parallel haalt MeteoA 10-minuut observaties op van het dichtstbijzijnde KNMI automatische weerstation via de KNMI Environmental Data Retrieval (EDR) API. Dit is een moderne OGC-standaard API die tijdreeksdata levert per stationsID. MeteoA past een retry-logica toe met vertraging voor verwerkingsachterstand bij KNMI (typisch 5–15 minuten).

KNMI-data wordt in hetzelfde uniforme schema opgeslagen als lokale data, waardoor directe vergelijking per tijdstap mogelijk is.

Stap 2 — Normalisatie naar uniform schema

Ruwe sensorwaarden van Ecowitt en KNMI gebruiken verschillende veldnamen, eenheden en precisies. MeteoA normaliseert alle brondata naar een gestandaardiseerd schema met vaste veldnamen:

VeldEenheidBeschrijving
temp_out°CBuitenluchttemperatuur
humidity_out%Relatieve buitenluchtvochtigheid
precip_ratemm/uActuele neerslagintensiteit
precip_dailymmDagelijkse cumulatieve neerslag
wind_speedm/sGemiddelde windsnelheid (10 min)
wind_gustm/sMaximale windstoot (10 min)
wind_dir°Windrichting (meteorologisch)
pressure_relhPaZeeniveau-gereduceerde luchtdruk
solar_radW/m²Globale zonnestraling
wbgt°CWet Bulb Globe Temperature (indien Trofic)

Ontbrekende waarden worden als null opgeslagen, nooit als nul of als placeholder. Dit voorkomt analysefoutén bij optelling of middeling.

Stap 3 — Kwaliteitscontrole (drie lagen)

MeteoA past drie opeenvolgende QC-lagen toe op elke 10-minuut observatie:

Laag 1 — Fysische plausibiliteit

Elke waarde wordt getoetst aan fysisch haalbare grenzen. Voorbeelden: temperatuur buiten −40 tot +60°C, vochtigheid 0–100%, windsnelheid 0–100 m/s. Waarden buiten deze grenzen worden als QC_FAIL_RANGE gemarkeerd.

Laag 2 — Temporele consistentie

Stap-voor-stap veranderingen worden gecontroleerd op onwaarschijnlijke sprongen. Een temperatuursprong van meer dan 10°C binnen 10 minuten duidt op een sensorstoring en genereert een QC_FAIL_STEP vlag. Drempelwaarden zijn per parameter configureerbaar.

Laag 3 — Ruimtelijke vergelijking met KNMI

Het lokale station wordt per tijdstap vergeleken met de KNMI-referentie. Een structurele afwijking boven een configureerbare drempel (standaard: >5°C voor temperatuur, >20% voor neerslag) genereert een QC_FLAG_SPATIAL en een automatisch sensoralarm aan de klant. Dit onderscheidt een echte lokale afwijking (bijv. stedelijk warmte-eiland) van een sensorprobleem.

Stap 4 — Opslag in Parquet-bestanden

Gekwalificeerde data wordt opgeslagen in maandelijkse Apache Parquet-bestanden per station. Dit formaat is sterk gecomprimeerd, snel leesbaar voor analyse, en compatibel met pandas, DuckDB, en vrijwel alle data-science tools. Historische backfill gaat tot 90 dagen (Ecowitt basis) of 365 dagen (Ecowitt Pro) terug, afhankelijk van het sensorabonnement.

Nieuwe stations krijgen standaard geen automatische backfill van 730 dagen — dit voorkomt onnodige API-belasting. Backfill kan handmatig worden geactiveerd per station.

Stap 5 — Dashboard en leveringsfrequentie

Het dashboard wordt aangedreven door een GitHub Actions cron-workflow die elke 10 minuten wordt uitgevoerd. De workflow doorloopt alle actieve stations, voert stappen 1–4 uit, en schrijft de bijgewerkte data naar een publiek beschikbaar stations_summary.json dat door het Leaflet.js-dashboard wordt geladen.

Doorlooptijd van sensor naar zichtbaar dashboard: gemiddeld <2 minuten na elke 10-minuut meetcyclus.

📡 Sensor (Ecowitt / KNMI)
☁️ Cloud API (Ecowitt hist. / KNMI EDR)
🔄 Normalisatie + QC (3 lagen)
🗄️ Parquet opslag
📊 Live dashboard

Sensorklassen en nauwkeurigheid

SensortypeModel (voorbeeld)Nauwkeurigheid temp.Toepassing
All-in-one consumentEcowitt HP2553±1,0°CPilot, oriëntatie
Semi-professioneelEcowitt WS90±0,5°CLandbouw, bouw
Trofic hittestressMeteoA Trofic±0,3°C + WBGTBouwplaats, evenement
KNMI referentieVaisala HMP155±0,2°CReferentie/QC

MeteoA vs. alleen KNMI

Alleen KNMIMeteoA (lokaal + KNMI)
Ruimtelijke resolutie40–50 km tussen stationsOp uw exacte locatie
Update frequentie10 minuten (publiek)10 minuten
Sectorspecifieke parametersStandaard setWBGT, bladnat, bodemvocht op aanvraag
Alarmen en notificatiesNiet beschikbaarConfigureerbaar per drempelwaarde
QC vergelijkingIntern KNMILokaal én KNMI-kruiscontrole
Juridische documentatieNiet op maatExporteerbaar CSV/PDF per station
KostenGratis (publieke data)€500–1.000/jaar beheerd

Open vragen?

Wilt u meer weten over de technische architectuur, kalibratieprocedures of integratie met uw eigen datasystemen? Neem contact op — wij delen onze methodologie graag in detail.

Stel uw vraag