← Terug naar projects
6 min
P1 Meter Monitor: automatische energiemonitoring en rapportage

P1 Meter Monitor: automatische energiemonitoring en rapportage

Een Python-service in Docker die metingen verzamelt van een P1 slimme meter, opslaat in een QuestDB tijdreeksdatabase, en maandelijks een verbruiksrapport verstuurt inclusief teruglevering van zonnepanelen en vergelijking met de vorige maand.
  • Python
  • Docker
  • QuestDB

Inhoudsopgave

  1. Het probleem met bestaande opties
  2. Hoe het werkt
  3. Rapporten en queries
  4. Deployment
  5. Wat ik heb geleerd

De meeste huishoudens in Nederland hebben inmiddels een slimme meter met een P1-poort: een gestandaardiseerde data-interface die real-time elektriciteits- en gasmetingen beschikbaar maakt. Met een kleine dongle zoals de HomeWizard P1 wordt die data toegankelijk als JSON API op je lokale netwerk. De metingen zijn er, maar zonder iets dat ze verzamelt en opslaat, gaan ze verloren. Ik wilde een systeem dat stilletjes elk datapunt zou verzamelen, opslaan in een echte tijdreeksdatabase, en me eens per maand zou vertellen wat mijn huishouden daadwerkelijk had verbruikt, hoeveel er via de zonnepanelen was teruggeleverd aan het net, en hoe dat zich verhoudt tot de maand ervoor.

Het probleem met bestaande opties

Er zijn genoeg apps voor energiemonitoring, maar de meeste komen met compromissen die ik niet wilde. Sommige vereisen cloudaccounts en sturen je data naar externe servers. Andere bieden dashboards maar geen gestructureerde rapportage. De HomeWizard-app zelf toont live metingen en wat geschiedenis, maar geeft geen maandelijks overzicht per tarief dat zowel import als export bevat, en je kunt de ruwe data niet zelf bevragen. Met zonnepanelen op het dak wilde ik specifiek bijhouden hoeveel stroom er wordt teruggeleverd aan het net, uitgesplitst naar normaal- en daltarief, omdat dat direct invloed heeft op wat je betaalt onder de salderingsregeling.

Wat ik wilde was simpel: een zelf-gehoste oplossing die op regelmatige intervallen metingen verzamelt, lokaal opslaat, en rapporten genereert die ik daadwerkelijk kan gebruiken. Geen cloudafhankelijkheid, geen abonnement, volledige controle over de data.

Hoe het werkt

Het systeem heeft twee hoofdcomponenten die in Docker draaien: een collector en een reporter.

De collector bevraagt de HTTP API van de P1-meter op een instelbaar interval (standaard elke 60 seconden) en schrijft elke meting naar QuestDB, een tijdreeksdatabase die is geoptimaliseerd voor precies dit soort data: veel schrijfbewerkingen, chronologisch geordend. Elke meting bevat het huidige stroomverbruik, cumulatieve import- en exporttotalen opgesplitst per normaal- en daltarief, en gasverbruik. Voor huishoudens met zonnepanelen leggen de exportmetingen precies vast hoeveel stroom er per tarief wordt teruggeleverd aan het net.

De reporter draait op een schema via APScheduler. Op de eerste van elke maand bevraagt hij de opgeslagen data, berekent het verbruik en de productie per tarief, bepaalt het nettoverbruik, en verstuurt een HTML-e-mail met een volledig overzicht. Elk maandrapport bevat automatisch een vergelijking met de vorige maand, met het verschil in elektriciteits- en gasverbruik zowel in absolute getallen als in percentages, kleurgecodeerd groen of rood zodat je in een oogopslag ziet of je meer of minder hebt verbruikt. Er is ook een optionele wekelijkse CSV-export voor wie zelf analyses wil doen in een spreadsheet.

Rapporten en queries

Het maandrapport wordt als HTML-e-mail verstuurd in het Nederlands, passend bij de tariefstructuur waarover het rapporteert (normaal- en daltarief). Het toont precies hoeveel kilowattuur er per tarief is verbruikt en teruggeleverd, het nettoverbruik na aftrek van zonnepaneelproductie, gasverbruik, en gemiddeld en piekvermogen. De vergelijking met de vorige maand laat zien of je elektriciteits- en gasverbruik omhoog of omlaag is gegaan, wat vooral nuttig is om seizoenspatronen te herkennen of het effect te zien van veranderingen zoals extra isolatie of andere verwarmingsgewoontes. Het idee is dat je een keer per maand een e-mail krijgt en direct weet waar je staat.

Het rapport bevat ook twee grafieken: een dagelijks verbruiksoverzicht voor de periode met elektriciteit en gas als aparte lijnen, en een jaaroverzicht als staafdiagram dat de huidige maand in context plaatst naast eerdere maanden.

Voor alles buiten het standaardrapport is de webconsole van QuestDB beschikbaar op het lokale netwerk. De ruwe data staat in een enkele p1_meter_data-tabel, dus eigen queries draaien is eenvoudig. Wil je je dagverbruik over de afgelopen week weten, of zien hoeveel je zonnepanelen afgelopen dinsdag hebben opgewekt? Een paar regels SQL volstaan.

Rapporten kunnen ook handmatig worden gegenereerd via de command line. Je kunt voorgedefinieerde periodes opgeven zoals month, this-week of yesterday, of een aangepast datumbereik meegeven. De CLI kan het rapport als e-mail versturen of naar een CSV-bestand schrijven.

Deployment

Alles draait in Docker Compose. Configuratie zit in een enkel .env-bestand: de API-URL van de meter, SMTP-gegevens voor e-mailbezorging, en de ontvangers van de rapporten. Het systeem starten is een docker compose up -d en het begint direct met verzamelen.

Voor productiegebruik is er een apart Compose-bestand dat een kant-en-klare image uit het GitHub Container Registry haalt in plaats van lokaal te bouwen. Een CI/CD-workflow publiceert automatisch nieuwe images bij elke push. Backup- en restorscripts beheren het QuestDB-datavolume, zodat er niets verloren gaat als een container opnieuw moet worden aangemaakt.

Wat ik heb geleerd

Dit project bevestigde iets dat ik steeds opnieuw merk: de beste infrastructuur is het soort dat je vergeet dat het draait. De collector schrijft al maanden elke minuut metingen weg zonder dat ik er iets aan hoef te doen. De maandelijkse e-mail komt gewoon binnen. Ik gebruik het systeem alleen als ik daadwerkelijk de data wil bekijken.

QuestDB bleek uitstekend te passen. Het is licht genoeg om naast de collector te draaien op bescheiden hardware, en het SQL-dialect ondersteunt tijdreeksaggregaties standaard. Samplen per dag, week of maand is een enkele clause, geen handmatige GROUP BY op losse datumdelen.

Dat de e-mailtemplates in het Nederlands zijn, was een bewuste keuze. Energietarieven in Nederland volgen een specifieke structuur, en het rapport daaromheen bouwen maakte het direct bruikbaar in plaats van generiek. Het is eenvoudig genoeg om aan te passen voor andere talen of tariefmodellen, maar beginnen met iets concreets en specifieks bleek praktischer dan vanaf dag een universeel proberen te zijn.

De repository is te vinden onderaan deze pagina, inclusief volledige installatie-instructies en voorbeeldqueries.

Heb je feedback of vragen over dit project? Of ben je op zoek naar hulp bij softwareontwikkeling? Neem gerust contact op.