De privacyvraag: welke data heeft een zonne-monitoring-app eigenlijk nodig?

Hier is een stukje zonne-data: gisteren tussen 06:30 en 08:00 importeerde het huishouden 4,2 kWh van het net. Tussen 11:00 en 16:00 produceerden de panelen meer dan het huishouden verbruikte en ging 9,3 kWh terug naar het net. Tussen 18:00 en 22:00 was het verbruik 2,7 kWh, vooral van het net. Dagtotaal: 24 kWh geproduceerd, 14 kWh verbruikt.

Dat lijkt op een rij in een spreadsheet. Lees het nauwkeurig en het is ook een beschrijving van iemand zijn ochtendritueel, zijn werkdag, wanneer hij thuiskwam, wanneer hij eten kookte, en ongeveer wanneer hij naar bed ging. Een paar weken van deze rijen zullen je vertellen of ze schoolgaande kinderen hebben, of ze van thuis werken, wanneer ze op vakantie gaan, en welke toestellen ze zwaar gebruiken. Niets hiervan staat expliciet in de data, en niets ervan vereist gesofisticeerde analyse om te extraheren.

Dat is, in een notendop, waarom de privacyvraag voor zonne-monitoring-apps belangrijker is dan veel mensen beseffen. Dit artikel gaat over wat een goede app werkelijk nodig heeft om te functioneren, wat hij vaak verzamelt voorbij dat, en welke vragen je zou moeten stellen aan eender welke app waaraan je 25 jaar productie- en verbruiksdata toevertrouwt.

Productiedata tegenover verbruiksdata

Productiedata (hoeveel je panelen opwekken) is op zich vrijwel volledig onschadelijk. Hoeveel zonnestroom je hebt opgewekt zegt niets over je persoonlijke gewoontes. Het zegt iets over je dak, het weer, en eventueel iets over wanneer je niet thuis was en de elektriciteit niet kon gebruiken, maar dat is zwakke afleiding. Voor de meeste praktische doeleinden is productiedata zo neutraal als data kan zijn.

Verbruiksdata (wat het huis aan stroom gebruikt) is de privacy-gevoelige helft van het verhaal. De granulariteit telt hier: uurverbruik is redelijk anoniem, kwartierverbruik onthult levensstijlpatronen, en éénminuut-verbruik kan specifieke toestellen identificeren door hun stroomprofielen. Academisch onderzoek naar slimme-meter-privacy heeft aangetoond dat korte-interval verbruiksdata kan onthullen of je een waterkoker hebt, een oven, een EV-lader, en zelfs welke TV-zenders je kijkt (verschillende displays hebben karakteristiek verschillende stroomopname). De Smart Grid Task Force van de Europese Commissie heeft expliciet aandacht gevraagd voor verbruiks-granulariteit als een privacybezorgdheid in slimme-meter-regelgeving.

Wat dat in de praktijk betekent: een app die alleen je productiedata leest is een laag privacy-risico. Een app die ook je verbruiksdata leest met fijne granulariteit, en die verbruiksdata naar een server uploadt buiten je controle, is een ander verhaal.

Wat een app werkelijk nodig heeft

Laat me beginnen met een eenvoudige vraag: wat heeft een zonne-monitoring-app technisch nodig om zijn primaire functies uit te voeren?

Voor het tonen van je productiedata: API-credentials voor het data-platform (in het geval van PVOutput: een API-sleutel en een system-ID), plus de mogelijkheid om HTTP-requests te doen naar het platform. Dat is letterlijk alles. De app heeft geen toegang nodig tot je locatie, geen toegang tot je contacten, geen toegang tot je foto's, geen toegang tot je apparaten via Bluetooth, en geen tracking-identifier.

Voor het tonen van je verbruiksdata, als die in dezelfde data-stream zit: zelfde als productiedata, geen extra rechten nodig.

Voor het pushen van notificaties (bijvoorbeeld bij grote afwijkingen): notificatie-rechten, ja, maar daar stopt het bij.

Voor multi-system management of cloud-sync van notities: hier wordt het interessant. Hier kan een app reden hebben om met een eigen backend te praten, en hier kan privacy-erosie binnenslippen.

Het minimum dat een app eigenlijk nodig heeft, is heel klein. Veel apps vragen veel meer.

Wat apps vaak verzamelen voorbij wat strikt nodig is

Een paar dingen die in de praktijk gebeuren in monitoring-apps en niet allemaal nodig zijn:

Analytics en crash reporting. Bijna alle apps gebruiken een soort analytics-tool (Mixpanel, Amplitude, Firebase Analytics) en een crash-reporter (Sentry, Crashlytics). Deze tools collecteren typisch: welke schermen je hebt geopend, hoe lang je in de app zit, welke knoppen je hebt aangetikt, je toestel-type en OS-versie, en bij crashes een stack trace plus eventuele variabelen die op het moment van de crash actief waren. Voor de meeste apps is dit ingesteld vanuit goede intenties (begrijpen hoe de app gebruikt wordt om hem te verbeteren), maar het is wel data die buiten je toestel gaat.

Advertising IDs. Vele apps registreren je Apple "Identifier for Advertisers" (IDFA), waarmee adverteerders je kunnen volgen over verschillende apps en websites. iOS heeft sinds versie 14.5 verplicht dat de gebruiker toestemming geeft voor IDFA-toegang, maar een app kan nog altijd vragen, en als je niet oplet kan je makkelijk "Allow" tikken zonder erbij stil te staan.

Cloud-sync van data. Voor synchronisatie tussen je toestellen (iPhone naar iPad bijvoorbeeld) heeft een app twee opties: gebruik de Apple iCloud Key-Value Store of CloudKit (die in jouw iCloud-account zit, niet de developer's), of gebruik een eigen server. De eerste optie houdt je data binnen jouw Apple ecosysteem; de tweede optie betekent dat de app-ontwikkelaar een server beheert die toegang heeft tot je data.

Push-notificaties van de ontwikkelaar. Sommige apps installeren een service om push-notificaties van de developer naar jou te kunnen sturen voor marketing of nieuws. Dit vraagt typisch een persistent device-token dat de developer met je app-installatie kan associëren.

Foto's voor exports of share. Een app die "share" of "export naar foto's" ondersteunt, zal toegang tot je foto-bibliotheek vragen. Dat is op zich oké voor het specifieke moment van delen, maar sommige apps vragen permanente toegang in plaats van een eenmalige.

Geen van deze categorieën is per definitie kwaadwillend, maar elke ervan is een keuze van de ontwikkelaar die jij als gebruiker mag onderzoeken.

De vier kritische vragen om te stellen

Als je een zonne-monitoring-app overweegt, zijn er vier vragen die de meeste privacy-zorgen oplossen of bevestigen:

Vraag 1: heeft de app een eigen backend die jouw data ziet?

De meest privacy-vriendelijke architectuur is een app die rechtstreeks met PVOutput (of je andere data-bron) praat, zonder eigen server in het midden. Jouw data stroomt van PVOutput naar je telefoon, en nergens anders. Dit is wat HelioPeak doet: er is geen heliopeak-server die data verzamelt. De PVOutput-credentials staan in iOS Keychain op je toestel, en de PVOutput-data wordt gecached lokaal.

Andere apps gebruiken een tussen-server, soms voor goede redenen (data-aggregatie voor multi-system features, gedeelde cache, voorspellingsalgoritmes die op de server draaien). Dit is niet automatisch slecht, maar het betekent dat de ontwikkelaar je data op een gegeven moment ziet, en je vertrouwt op hun privacybeleid om die data te beschermen.

Stel deze vraag expliciet in een mail of forumpost. Een ontwikkelaar die er moeite mee heeft een helder antwoord te geven, vertelt je iets.

Vraag 2: welke analytics worden er gebruikt, en kan je ze uitschakelen?

Bijna elke app heeft een vorm van crash-reporting (verstandig) en analytics (begrijpelijk). De goede praktijk is om dit transparant te documenteren en de gebruiker een opt-out te geven. Een uitstekende praktijk is om opt-in te zijn voor analytics (je moet expliciet aanvinken om gebruiksstatistieken te delen).

Vraag specifiek: welke analytics-tools gebruikt de app? Voor crash reporting: dezelfde vraag. En kan je het uitzetten zonder app-functionaliteit te verliezen?

Vraag 3: hoe worden eventuele cloud-features geïmplementeerd?

Voor features zoals multi-device sync van notities of voorkeuren, vraag of de developer Apple iCloud KVS/CloudKit gebruikt (data in jouw account) of een eigen backend (data in de developer's database). Apple's mechanismen zijn altijd te verkiezen voor pure sync, omdat Apple geen toegang heeft tot je data en de developer ook niet.

Vraag 4: welke permissions vraagt de app, en waarvoor?

Apple maakt het je makkelijk om dit te zien: ga naar Instellingen, scroll naar de app, en check welke permissions er staan. Een zonne-monitoring-app zou minimaal moeten vragen: misschien notificaties, misschien achtergrondtaken voor data-refresh. Als hij vraagt naar locatie, contacten, foto's, microphone, of camera zonder duidelijke gerechtvaardigheid in features, is dat een rode vlag.

Wat een goede privacy-implementatie er uitziet

Een paar tekens dat een ontwikkelaar privacy serieus neemt:

Een privacybeleid dat in mensentaal is geschreven. Veel privacybeleiden zijn juridische lapwerk dat alles en niets zegt. Een goed privacybeleid is specifiek: "Wij verzamelen X. Wij delen het met Y voor doel Z. Wij bewaren het Q jaar. Je kan het op deze manier verwijderen." Geen vaag taalgebruik, geen template.

App Store privacy nutrition labels. Apple verplicht elke app om een "Privacy Card" in te vullen die in de App Store getoond wordt. Daarin zie je welke data soorten worden verzameld en gekoppeld aan jou (of niet). Een app met "Data Not Collected" of "Data Not Linked to You" voor alle categorieën, is duidelijk strenger dan een app die "Data Linked to You" rapporteert voor allerlei kategorieën.

Open broncode. Niet alle ontwikkelaars open-sourcen hun apps, en dat is begrijpelijk voor commerciële producten. Maar een ontwikkelaar die op zijn minst de privacy-kritische delen (data-flow, networking) bespreekt of in een blog beschrijft, geeft je veel meer vertrouwen dan een ontwikkelaar die zwijgt.

Geen advertenties. Apps gefinancierd door advertenties zijn structureel afhankelijk van het delen van data met advertentienetwerken. Een app die geen advertenties gebruikt (gratis met IAP, of een eenmalige aankoop) heeft een fundamenteel andere relatie met je data.

Een actieve developer die reageert op privacy-vragen. Een ontwikkelaar die antwoordt op privacy-vragen in een forum, in mail, of in een blog, is een ontwikkelaar die zich verantwoordelijk voelt voor hoe jouw data behandeld wordt.

De fabrikantencloud-vraag

Een aparte categorie is de cloud van de fabrikant van je omvormer. Hier gaat je productie- en verbruiksdata sowieso naartoe als je hardware ondersteunt, ongeacht welke app je daarna gebruikt. SolarEdge, Enphase, Huawei, Fronius, allemaal verzamelen je data en bewaren ze. Dat gebeurt al, en het is een van de structurele redenen om naar een open platform zoals PVOutput te uploaden in parallel: je hebt dan je eigen onafhankelijke kopie.

Voor sommige fabrikanten kan je het cloud-uploaden geheel of gedeeltelijk uitzetten (vooral lokale Modbus-gebaseerde Home Assistant setups die geen cloud nodig hebben). Voor andere is het opgenomen in de hardware en kan je het niet vermijden zonder de hardware grotendeels nutteloos te maken. Dit is geen probleem dat een goede iOS-app kan oplossen; het is een probleem dat je bij hardware-keuze al moest overwegen.

Een eerlijke beoordeling van HelioPeak's privacy

Voor de openheid, zo zit HelioPeak in elkaar wat privacy betreft:

• Geen HelioPeak-server. Alle PVOutput-data stroomt rechtstreeks van pvoutput.org naar je iOS-toestel. Er is geen tussenliggende heliopeak-server die je data ziet.
• PVOutput-credentials in iOS Keychain. Je API-sleutel en system-ID staan in de native Keychain van Apple, niet in een eigen database.
• iCloud Key-Value Store voor Notes-sync. Notities synchroniseren tussen je toestellen via Apple's eigen mechaniek. Mijn server ziet ze niet.
• TelemetryDeck voor analytics. Voor inzicht in hoe de app gebruikt wordt (welke schermen, hoeveel sessies, welke OS-versies), gebruik ik TelemetryDeck. Hun privacy-model is op zich strict (geen persoonlijke identifiers, gehashte signals, EU-gebaseerd). Maar het is wel een dienst van derden.
• Sentry voor crash reporting. Bij een app-crash krijg ik een stack trace plus minimale context. Sentry is een EU-tenant. Geen persoonlijke data wordt bewust gerapporteerd.
• Geen advertenties, geen IDFA, geen tracking. De app vraagt geen identifier-permissions.

Is dit perfect? Nee, want TelemetryDeck en Sentry zijn diensten van derden, ook al zijn ze privacy-bewust. Maar ze zijn opt-out (in app settings), en in een toekomstige update wil ik ze opt-in maken in plaats van opt-out. Dat is een trade-off tussen ontwikkelinzicht (waarmee ik betere features kan maken) en pure privacy.

Tot slot

De meeste zonne-monitoring-apps in 2026 hebben fatsoenlijke privacy-praktijken, en de enkele die echt slecht zijn, kunnen makkelijk geïdentificeerd worden door de hierboven vermelde vragen te stellen. Een ontwikkelaar die op vraag 1 helderheid biedt over backend-architectuur, op vraag 2 transparant is over analytics, op vraag 3 Apple's eigen mechanismen verkiest voor sync, en op vraag 4 alleen de strictnoodzakelijke permissions vraagt, levert je een privacy-bewuste app.

Wat ertoe doet is dat deze app je 25 jaar lang dagelijkse data zal zien. Een keuze nu om een app te vertrouwen die actief met je verbruiksdata onverantwoord omgaat, is een keuze die je in elk van die 9.000 dagen daarna draagt. De moeite om vooraf een paar minuten te besteden aan privacy-onderzoek is meer dan waard.