Met een utility data API haalt je ESG-, facturatie- of analyseplatform meterdata zelf op, volgens een vast schema en in een vast formaat. Voor een vastgoedteam is dat het verschil tussen iemand die elke maand een spreadsheet exporteert en cijfers die er gewoon al staan.
Deze uitleg behandelt wat een utility data API is, welke data erdoorheen komt, hoe die verschilt van een CSV-export of een koppeling met het gebouwbeheersysteem (BMS), en welke vijf vragen je stelt voordat je de API aan een ESG- of facturatieplatform koppelt. Geschreven voor wie de integratie moet bouwen, en voor het vastgoedteam dat op de uitkomst moet kunnen vertrouwen.
Wat is een utility data API?
Een utility data API is een vaste manier waarop het ene systeem automatisch energie-, gas-, water- en warmtedata opvraagt bij een ander systeem. API staat voor application programming interface: een gedocumenteerde set verzoeken die een systeem van een ander systeem accepteert. Je ESG-, facturatie- of analyseplatform downloadt dus geen bestand om het ergens anders te uploaden, maar vraagt de data op die het nodig heeft en krijgt die terug in een consistent formaat.
In vastgoed is het systeem dat antwoordt meestal het monitoringplatform dat de meetwaarden van de meters verzamelt. De systemen die vragen zijn die voor rapportage, facturatie of analyse: een ESG-rapportageplatform, een vastgoedbeheer- en facturatiesysteem of een BI-tool.
Welke data levert een utility data API?
Een utility data API levert vier soorten informatie: de meetwaarden zelf, de gegevens van elke meter, de eenheden en de status van elke meetwaarde. De meetwaarden zijn pas bruikbaar als de andere drie meekomen.
| Wat levert de API? | Hoe ziet dat eruit? | Waarom doet het ertoe? |
|---|---|---|
| Intervalmetingen | Verbruik per meter met een vast interval, bijvoorbeeld elk kwartier of elk uur, elk met een tijdstempel. | Het interval bepaalt wat je kunt analyseren, van maandtotalen tot het verbruik om drie uur 's nachts. |
| Metergegevens | Het meter-ID, de utiliteit, de locatie, de toewijzing aan gebouw of huurder, en of het een hoofdmeter of een submeter is. | Zonder metergegevens kun je een getal niet aan het juiste gebouw, de juiste huurder of de juiste rapportageregel koppelen. |
| Eenheden | kWh, m³, GJ en zo verder, expliciet vermeld bij elke waarde. | Een ontvangend systeem hoeft nooit te raden of een gaswaarde in kubieke meters of in kilowattuur staat. |
| Gaten en schattingen | Ontbrekende, geschatte of gecorrigeerde meetwaarden, als zodanig gemarkeerd in plaats van stilzwijgend aangevuld. | Accountants en huurders vragen welke getallen gemeten zijn en welke niet. |
Wat dat interval in de praktijk betekent, lees je in onze uitleg over 15-minuten intervaldata: wat elke resolutie wel en niet laat zien.
Wat is het verschil tussen een utility data API, een CSV-export en een BMS-koppeling?
Een utility data API levert actuele, gestructureerde verbruiksdata over veel gebouwen, zonder dat er iemand tussen zit. Een CSV-export is een handmatige momentopname, en een BMS-koppeling is gebouwd om de installaties van één gebouw aan te sturen, niet om over een portefeuille te rapporteren.
| Hoe komt de data aan? | CSV-export | BMS-koppeling | Utility data API |
|---|---|---|---|
| Wie start de overdracht? | Iemand downloadt een bestand en uploadt het, en dat hangt ervan af of die persoon eraan denkt. | Een integrator verbindt het BMS van één locatie met één ander systeem. | Het ontvangende systeem vraagt de data volgens een vast schema op, zonder dat er iemand tussen zit. |
| Hoe actueel is de data? | Zo oud als de laatste export, vaak een maand of meer. | Actueel, maar meestal alleen voor de installaties die het BMS aanstuurt. | Zo actueel als het meetinterval, bijvoorbeeld elk kwartier. |
| Wat valt eronder? | Wat de persoon die exporteerde die dag selecteerde. | Meestal één locatie en de apparatuur van één leverancier. | Elke gekoppelde meter, over gebouwen en utiliteiten heen. |
| Blijft het formaat gelijk? | Kolommen, eenheden en datumnotaties wisselen vaak per bestand. | Dat hangt af van de BMS-leverancier en van hoe de integratie is gebouwd. | De structuur ligt vast en is gedocumenteerd, dus het ontvangende systeem weet wat het kan verwachten. |
Een CSV-export is niet fout. Voor één gebouw dat eens per jaar rapporteert, kan het genoeg zijn. Het houdt op te werken zodra dezelfde data elke maand bij meerdere systemen moet aankomen, voor tientallen gebouwen, want elke handmatige stap is een kans op een gemist bestand of een verkeerde eenheid.
Hoe werkt een utility data API in de praktijk?
De meeste utility data API's werken volgens hetzelfde patroon: het ontvangende systeem meldt zich aan, vraagt de lijst met meters op en vraagt daarna per meter het verbruik over een periode op. De antwoorden komen terug als gestructureerde data, meestal JSON via HTTPS, volgens REST-conventies.
Aanmelden gaat meestal via OAuth 2.0 client credentials, een standaard waarmee een systeem zich bij een ander systeem identificeert, of via een eenvoudigere API-key. Sommige API's sturen data ook zelf door in plaats van te wachten op een verzoek: een webhook stuurt het ontvangende systeem een bericht zodra er iets gebeurt, zoals een nieuwe meetwaarde of een overschreden drempel. Goede API's publiceren hun endpoints in een OpenAPI-specificatie, zodat een developer elk verzoek en elk antwoord ziet voordat er een regel code geschreven is.
Wat vraag je voordat je een utility data API integreert?
Stel vijf vragen voordat je een utility data API aan een ESG- of facturatieplatform koppelt. Elke vraag dekt een fout die meestal pas zichtbaar wordt als de integratie al live is.
1. Welke meters en utiliteiten vallen eronder?
Controleer of de API elektriciteit, gas, water en warmte dekt, inclusief submeters en meters zonder slimme uitlezing. Een API die alleen de hoofdmeters voor elektriciteit levert, laat de doorbelasting aan huurders en de watercijfers in een spreadsheet achter.
2. Wat is het meetinterval, en hoe snel komt nieuwe data binnen?
Het meetinterval bepaalt het fijnste detail dat je kunt analyseren, de vertraging bepaalt hoe actueel je rapportages zijn. Vraag naar allebei: een kwartierwaarde die een dag later binnenkomt, gedraagt zich heel anders dan een die binnen het uur binnen is.
3. Hoe worden gaten, schattingen en correcties behandeld?
Vraag hoe een ontbrekende meetwaarde wordt gemarkeerd, of schattingen als schatting herkenbaar zijn en hoe een gecorrigeerde waarde met terugwerkende kracht wordt aangevuld. Als correcties oude waarden zonder spoor overschrijven, kijken je rapportage en je accountant naar verschillende getallen.
4. Zijn eenheden, tijdzones en metergegevens in alle gebouwen gelijk?
Vraag of elk gebouw dezelfde eenheden, dezelfde tijdzoneafspraak en dezelfde velden voor metergegevens teruggeeft. Juist hier gaat het het vaakst mis: de integratie werkt voor het eerste gebouw en loopt vast bij het tiende.
5. Welke regels gelden voor aanmelden, limieten en versies?
Vraag hoe toegangsgegevens worden uitgegeven en ingetrokken, hoeveel verzoeken de API per minuut accepteert en hoe wijzigingen in de API worden aangekondigd. Vraag daarna wie de integratie ondersteunt als er iets misgaat, en hoe snel.
Wanneer is een utility data API niet het antwoord?
Een utility data API is niet het antwoord als er geen systeem is dat de data ontvangt, of geen meter waar de data vandaan komt. Een API verplaatst data, maar maakt die niet. Als de helft van je gebouwen nog op handmatige meteropnames draait, levert een API de gaten alleen sneller af, hij dicht ze niet.
Voor een kleine portefeuille, waar één persoon eens per jaar over een handvol gebouwen rapporteert, is een API ook meer dan nodig. Dan kan een export volstaan, of de dashboards in het monitoringplatform zelf. De API verdient zich terug zodra meerdere systemen dezelfde data vaak nodig hebben, voor veel gebouwen.
Waar past Rhino in dit plaatje?
Rhino is de datalaag tussen je meters en je systemen. Rhino verzamelt data over elektriciteit, gas, water en warmte, inclusief submeters, via bestaande slimme meters, koppelingen met netbeheerders en leveranciers, installaties die al in het gebouw zitten, of eigen Rhino-hardware waar niets anders past. Rhino is geen ESG-platform en geen facturatiesysteem: Rhino levert de data aan die systemen.
De Rhino Utility Data API levert die data per kwartier als JSON via HTTPS, gedocumenteerd met OpenAPI. Elke meetwaarde heeft een tijdstempel, meter-ID, verbruikswaarde en eenheid, en de endpoints dekken meteroverzichten, verbruikstijdreeksen, gebouwhiërarchieën en alarmstatussen. Aanmelden gaat via OAuth 2.0 client credentials of een API-key, webhooks zijn beschikbaar voor realtime triggers en historische data is beschikbaar vanaf het moment van aansluiten. API-toegang zit in het platformabonnement.
De API kan geen meter uitlezen die niet is aangesloten, dus de eerste stap is meestal een check welke meters op afstand uit te lezen zijn. Bekijk hoe één dataset voor al je gebouwen het portefeuillebeheer ondersteunt, of plan een afspraak om de data samen met je technisch verantwoordelijke door te nemen.
Veelgestelde vragen
Wat is een utility data API in vastgoed?
Een utility data API is een gedocumenteerde manier waarop het ene systeem automatisch energie-, gas-, water- en warmtedata opvraagt bij een ander systeem. In vastgoed beantwoordt het monitoringplatform dat de meetwaarden verzamelt die verzoeken, en vragen ESG-, facturatie- of analyseplatformen erom. De data komt volgens een vast schema in een vast formaat binnen, in plaats van via handmatige exports.
Is een utility data API beter dan een CSV-export?
Een utility data API is beter zodra meerdere systemen dezelfde data vaak nodig hebben, voor veel gebouwen. De API levert actuele data volgens een vast schema en in een vaste structuur, zonder dat er iemand tussen zit. Een CSV-export kan volstaan voor één gebouw dat eens per jaar rapporteert, maar elke handmatige stap is een kans op een gemist bestand of een verkeerde eenheid.
Welke data levert een utility data API?
Een utility data API levert intervalmetingen, metergegevens, eenheden en de status van elke meetwaarde. Intervalmetingen geven het verbruik per meter met een vast interval, zoals elk kwartier. Metergegevens bepalen om welke meter, utiliteit, welk gebouw en welke huurder het gaat. Eenheden staan bij elke waarde, en ontbrekende of geschatte meetwaarden horen gemarkeerd te zijn in plaats van stilzwijgend aangevuld.
Wat controleer ik voordat ik een utility data API aan een ESG-platform koppel?
Controleer vijf dingen voordat je een utility data API aan een ESG-platform koppelt: welke meters en utiliteiten eronder vallen, het meetinterval en de vertraging, hoe gaten en correcties worden gemarkeerd, of eenheden en metergegevens in alle gebouwen gelijk zijn, en de regels voor aanmelden, limieten en versies. Ga ook na wie de integratie ondersteunt als er iets misgaat.
