· 6 min
Joulo API koppelen aan Home Assistant
Volg je ERE-verdiensten als sensordata: de API-endpoints die ertoe doen en hoe je ze in je eigen dashboard krijgt.
Praktijknotitie: gebruik dit artikel als technische leidraad, maar valideer altijd op je eigen laadpaal, firmware en contractvoorwaarden.
Waarom de API naast het dashboard
Het Joulo-dashboard is prima voor een snelle blik, maar wie thuis al Home Assistant of Grafana draait, wil dezelfde cijfers als data, niet als zoveelste site om in te loggen. Joulo heeft daarvoor een nette REST API: met een bearer token in de Authorization-header lees je laadstatus, sessiehistorie, maandtotalen en je ERE-opbrengstpositie gewoon uit als JSON.
Wat je nodig hebt
Drie dingen: een laadpaal die via de cloud-koppeling aan Joulo hangt en MID-gecertificeerd is (dat maakt hem überhaupt ERE-waardig), een account met API-toegang, en een bearer token. Bewaar dat token in een wachtwoordmanager of in de secrets van Home Assistant, nooit als platte tekst in een configuratiebestand dat je ergens deelt of back-upt.
Zelf aan de slag
Ik gebruik Joulo zelf voor mijn ERE-registratie. Werkt je laadpaal ermee, dan is dit een goed moment om het te checken.
Gebruik je mijn referral, dan krijgen jij en ik allebei 1% korting op de fee. Check altijd de actuele voorwaarden.
De endpoints die ertoe doen
Vier endpoints dekken vrijwel alles. Het chargers-endpoint geeft live status en, tijdens het laden, het aantal kWh van de lopende sessie. Het sessions-endpoint is je ruwe logboek per laadsessie, inclusief een veld dat aangeeft of de sessie meetelt voor ERE, handig om een afgekeurde sessie vroeg te spotten. Het energy-endpoint levert kant-en-klare maandtotalen in kWh, sessies en ERE-credits, zodat je zelf niets hoeft te aggregeren voor een maandgrafiek.
Het geld-endpoint: je ERE-positie
Het interessantste endpoint voor de financiële kant is de ERE-positie. Daar staat je verwachte jaaropbrengst, wat al verkocht en uitbetaald is, hoeveel ERE-credits nog onverkocht zijn en wat die naar verwachting waard zijn, plus de platformfee en de indicatieve marktprijs per ERE. Die laatste is de moeite om over tijd te volgen: ERE-prijzen bewegen, en zo zie je of wachten met verkopen loont of juist niet.
Zo zet je het in Home Assistant
De rest-integratie van Home Assistant kan één API-antwoord in meerdere sensoren splitsen, dus per endpoint volstaat één poll. Laat de laadstatus elke vijf minuten verversen en de geld-endpoints één keer per uur: die cijfers veranderen hooguit dagelijks, dus vaker pollen heeft geen zin. Geef de cumulatieve tellers (totaal kWh, totaal ERE-credits) de state class voor oplopende tellers mee: dan behandelt het energiedashboard ze als echte meterstanden en krijg je correcte dag- en maanddelta's in plaats van een kale stand. Bij mij levert dat onder meer `sensor.joulo_session_kwh` (energy, total_increasing) en `sensor.joulo_expected_year_eur` op, herkenbare namen zodra je ze een keer in de developer tools hebt opgezocht.
Waarom zelf bouwen, geen kant-en-klare integratie
Er bestaat een community Home Assistant-integratie voor Joulo (`crryp/joulo-ha`). Ik heb 'm geïnstalleerd, maar nooit echt gebruikt: geen enkele config-entry heeft ooit verbinding gemaakt, dus het stond er puur als dode gewicht bij. De reden om zelf te bouwen in plaats van erop te vertrouwen was bewust: het is geen HACS-geaccepteerde integratie, en met een losse ontwikkelaar als enige onderhouder wil ik niet dat mijn dashboard breekt zodra die persoon stopt. Wel heb ik pragmatisch een paar van de nieuwere ERE-berekeningen uit die integratie overgenomen (het compliance-jaar, onverkocht/pending YTD, de huidige-kwartaal-breakdown), simpelweg omdat die dezelfde `/ere-position`-call hergebruiken die ik toch al pol.
Praktische tips uit het gebruik
Vang de situatie af waarin er géén sessie loopt: het veld met de lopende sessie ontbreekt dan, en zonder standaardwaarde geeft je sensor een fout tussen sessies door. De API heeft ook een reboot-endpoint dat op afstand een OCPP-reset doet, een prima redmiddel voordat je naar de meterkast loopt om de laadpaal fysiek van spanning te halen. En exporteer af en toe je sessiehistorie: met een eigen kopie kun je een uitbetaling altijd naast je eigen log leggen. Eén concrete miskleun uit mijn eigen dashboard: in een markdown-kaart gebruikte ik per ongeluk button-card-syntax (`[[[ ... ]]]`) in plaats van gewone Jinja (`{{ }}`). Een markdown-kaart evalueert dat niet, dus stond er dagenlang letterlijk `[[[ ]]]` op het scherm in plaats van een bedrag. Geen API-probleem, gewoon de verkeerde template-taal in de verkeerde kaart.
Wat je als volgende kunt controleren
- Controleer of je sessiedata in dashboard en API hetzelfde beeld geven.
- Check of je laadpaalmodel en firmware stabiel zijn voor jouw gewenste koppeling.
- Lees lock-in, fee en opzegvoorwaarden voor je productiekeuzes vastlegt.
Volgende stap
Vergelijk eerst je technische setup, datakwaliteit en onboardingvoorwaarden voordat je een platformkeuze vastlegt.
Lees ook
Mijn ERE-cijfers: wat thuisladen mij oplevert
Geen rekenvoorbeeld maar echte cijfers: zoveel kWh, sessies en ERE-credits levert mijn eigen laadpaal op.
ERE-opbrengst in 2026: wat is realistisch?
Wat thuisladen dit jaar echt oplevert per kWh, en waarom je met bandbreedtes moet rekenen in plaats van vaste bedragen.
Meer diepgang over dit onderwerp: Laadpaal API-koppelingen, Home Assistant laadpaal integratie, MID-meter uitleg. Of bekijk alle technische gidsen.