Zelfbouw Laadpaal ervaringen

[Pim57]

bbbrumbrum schreef op donderdag 12 maart 2026 @ 09:41:
[...]

Hun laatste email is niet zo stellig als wat ze in de podcast zeiden:

[...]

Zolang er geen lijst is van toegestane laadpalen, voldoet elke doos die een laadpaal voorstelt.
Een type plaatje kun je zelf verzinnen, uitprinten en erop plakken.

[Kaspers]

adjego schreef op donderdag 12 maart 2026 @ 10:58:
[...]


Ik heb zo'n zelfde via marktplaats aangeschaft, en deze is ook uit 2022. Ik denk dat het gewoon oudere modellen zijn. Die in het bericht staan van tweakers zijn van 2024.

Op deze site is het gewoon dezelfde: https://www.eastrongroup....ion-ev-charger-meter.html

Heb via email contact opgenomen met Eastron, met de vraag of het een origineel product is en of ik het veilig kan gebruiken.

Initiele reactie:

About the meter SDM72D-M, I notied that it shall be produced in the year 2022, and already almost 3-4 years passed. but did you just purchased it?

May I know where did you purchase it and what time did you purchase it?

For Eastron energy meters, we do not suggest you buy M22 version but shall be M25 or M26 version at the current stage.

En in een vervolg email:

Thank you for your reply.

I believe it is important for us to track the platform and reseller as these meter where quarantined and should have been recycled . We had paid for these to be collected by a recycling company, with the strict instructions that they are not to be sold due to the expired warranty.

Kind regards

Verklaart mogelijk de lage prijs van die dingen.

[rene037]

Eigenlijk wordt er gevraagd waar ze nog verkocht worden, want ze mogen niet verkocht worden omdat ze betaald hebben om ze te laten vernietigen.... Dus je kunt ze een linkje sturen. Hij zal best werken als ik het goed begrijp...

[adjego]

rene037 schreef op donderdag 12 maart 2026 @ 23:56:
Eigenlijk wordt er gevraagd waar ze nog verkocht worden, want ze mogen niet verkocht worden omdat ze betaald hebben om ze te laten vernietigen.... Dus je kunt ze een linkje sturen. Hij zal best werken als ik het goed begrijp...

Ja zo lees ik het ook inderdaad. En het werkt hier ook al echt een hele tijd. Via marktplaats is er nooit echt iets van garantie dus dat neem ik al sinds ik hem heb gekocht voor lief.

[ruud76]

bbbrumbrum schreef op donderdag 12 maart 2026 @ 09:41:
[...]

Hun laatste email is niet zo stellig als wat ze in de podcast zeiden:

[...]

Voor wat het waard is: Den Hartog heeft mijn SmartEVSE met Eastron MID meter in de laadpaal behuizing geaccepteerd.

[Wolly]

ruud76 schreef op vrijdag 13 maart 2026 @ 09:27:
[...]


Voor wat het waard is: Den Hartog heeft mijn SmartEVSE met Eastron MID meter in de laadpaal behuizing geaccepteerd.

Top. Hebben ze nog voorwaarden eraan verbonden, bijvoorbeeld dat het alleen voor 2026 is?

En hoe ga je de laadsessies dan aan ze rapporteren? Ik heb nog een SmartEVSE v2.1 van Stegen, die heeft geen verbindingen naar internet of api's.

[ocaj]

rene037 schreef op donderdag 12 maart 2026 @ 23:56:
Eigenlijk wordt er gevraagd waar ze nog verkocht worden, want ze mogen niet verkocht worden omdat ze betaald hebben om ze te laten vernietigen.... Dus je kunt ze een linkje sturen. Hij zal best werken als ik het goed begrijp...

Ik lees dat Eastron deze partij "quarantained" heeft en iemand betaald heeft om ze te vernietigen/recylen.
Een normaal bedrijf doet dat alleen als er iets mis is met die batch, want het kost geld. Kennelijk waren ze niet meer verkoopbaar.

Persoonlijk zou ik op basis van dit bericht van Eastron het ding direct uit mijn meterkast schroeven.

Voor een paar tientjes lagere prijs ga je toch geen afgekeurd product gebruiken waar serieus stroom doorheen loopt ? Je moet er niet aan denken dat er brand ontstaat en je huis affikt, maar hé, "wel een mooie deal op marktplaats gescoord"

[rene037]

ocaj schreef op vrijdag 13 maart 2026 @ 09:36:
[...]

Ik lees dat Eastron deze partij "quarantained" heeft en iemand betaald heeft om ze te vernietigen/recylen.
Een normaal bedrijf doet dat alleen als er iets mis is met die batch, want het kost geld. Kennelijk waren ze niet meer verkoopbaar.

Persoonlijk zou ik op basis van dit bericht van Eastron het ding direct uit mijn meterkast schroeven.

Voor een paar tientjes lagere prijs ga je toch geen afgekeurd product gebruiken waar serieus stroom doorheen loopt ? Je moet er niet aan denken dat er brand ontstaat en je huis affikt, maar hé, "wel een mooie deal op marktplaats gescoord"

Ik denk dat ze dan wel stelliger gereageerd hadden. Je wilt als fabrikant niet dat er gevaarlijke producten in omloop zijn. Dit was gewoon overproductie. En die wil je niet in de markt. Veroudering van onderdelen (bijv condensatoren) gaat door en dat bekort de levensduur met de tijd die ze lagen te verstoffen.

[Kaspers]

Valt er nog iets af te dingen op dit theoretische schema ?

_klikbaar


Paar opmerkingen alvast van mijn kant:
1. Ik volg niet de stroomrichting zoals voorgesteld door Eastron op de kwh meter. Dit is echter geen probleem, de meetwaarden kunnen door de smartevse ge-invert worden middels een configuratie parameter.
2. Ik wijk ook wat af met de stroomrichting op de contactors / relais (zie link). Ook dat maakt niet uit voor de schakeling.
3. PP signaal is achterwege gebleven, ivm het gebruik van een vaste laadkabel.

[dingo35]

Ik kan geen fout ontdekken, anders dan dat de volgorde van de sterkstroomaansluitingen anders is bij mijn controller; maar zolang je de belettering aanhoudt gaat t goed!

[Kaspers]

@dingo35, ik zie dat jij een fork onderhoudt van serkri, die weer een fork is van het originele project. Wat maakt jouw fork mogelijk interessanter dan het origineel?

[AirwinB]

Kaspers schreef op vrijdag 13 maart 2026 @ 21:48:
@dingo35, ik zie dat jij een fork onderhoudt van serkri, die weer een fork is van het originele project. Wat maakt jouw fork mogelijk interessanter dan het origineel?

Haha. Ik ben benieuwd hoe @dingo35 hierop gaat reageren 😀
Heb je hulp nodig om de loftrompet te laten schallen of kun je het zelf?
Zonder gekheid: volgens mij is de fork van @dingo35 nu de defacto standaard. Lees de 390 forum pagina’s maar na 😁

[dingo35]

Twee Belgen, Koen en Kristof, hebben ooit een repo geforked van die van Stegen; zij waren het die de REST API, het web dashboard en de accu-interface gestart zijn; ze noemden de repo "Serkri", een samenstelling van hun voor- en achternamen. Ik ben daar zaken aan gaan toevoegen, op hun repo; al snel bleek dat Koen en Kristof "klaar" waren; de SmartEVSE werkte naar hun tevredenheid; bij mij ook, maar ik vond het leuk om ook zaken voor anderen toe te voegen, ook al had ik daar zelf geen use case voor.
Na verloop van tijd wilde ik graag volledige admin rechten op de repo, maar Koen en Kristof wilden toch een vinger in de pap houden; toen ben ik mijn eigen fork gestart, en heb in overleg met Michael Stegen, de fabrikant, het zo ingericht dat als wij geen vreemde dingen doen in onze fork, die versie later, als voldoende stabiel, wordt overgenomen in de fabrieksrepo.
Het kost wel wat overleg nu en dan, maar levert mooie firmware op!

[Kaspers]

dingo35 schreef op vrijdag 13 maart 2026 @ 22:06:
Twee Belgen, Koen en Christof, hebben ooit een repo geforked van die van Stegen; zij waren het die de REST API, het web dashboard en de accu-interface gestart zijn; ze noemden de repo "Serkri", een samenstelling van hun voor- en achternamen. Ik ben daar zaken aan gaan toevoegen, op hun repo; al snel bleek dat Koen en Christof "klaar" waren; de SmartEVSE werkte naar hun tevredenheid; bij mij ook, maar ik vond het leuk om ook zaken voor anderen toe te voegen, ook al had ik daar zelf geen use case voor.
Na verloop van tijd wilde ik graag volledige admin rechten op de repo, maar Koen en Christof wilden toch een vinger in de pap houden; toen ben ik mijn eigen fork gestart, en heb in overleg met Michael Stegen, de fabrikant, het zo ingericht dat als wij geen vreemde dingen doen in onze fork, die versie later, als voldoende stabiel, wordt overgenomen in de fabrieksrepo.
Het kost wel wat overleg nu en dan, maar levert mooie firmware op!

Leuk deze achtergrond te lezen , geeft mij voldoende overtuiging ermee aan de slag te gaan! Misschien iets om op te nemen in de TS @Proton_ ?

[Geim]

Kaspers schreef op vrijdag 13 maart 2026 @ 21:13:
Valt er nog iets af te dingen op dit theoretische schema ?

Je Residual Current Monitor is niet aangesloten op de Smart EVSE

[Kaspers]

Geim schreef op vrijdag 13 maart 2026 @ 22:46:
[...]


Je Residual Current Monitor is niet aangesloten op de Smart EVSE

Bij deze (met nog wat andere aanpassingen, het mag duidelijk zijn hoe ik dit in de meterkast ga ophangen )

[edwin2021]

Kaspers schreef op vrijdag 13 maart 2026 @ 23:27:
[...]


Bij deze (met nog wat andere aanpassingen, het mag duidelijk zijn hoe ik dit in de meterkast ga ophangen )

[Afbeelding]

Erg handig overzicht. Misschien nog even onderdeel lijstje erbij?

[maarten_NL]

@Kaspers waarom zet je daar nog een automaat naast? Ik weet natuurlijk niet hoe ver jouw meterkast van de kWh meter en contactor af zit maar als je het mij vraagt is het een dure aan/uit schakelaar met onnodige bedrading.

Daarnaast mag je de EVSE ook aan de bemeterde kant van de kWh meter aansluiten, dat is namelijk ook stroom die je nodig hebt om de auto te laden dus die mag je ook meenemen voor de ERE.

[Geim]

@Kaspers Waarom heb je voor een 3-fase aardlekautomaat gekozen? Zit je al niet achter een aardlek?

[Allewijn]

maarten_NL schreef op zaterdag 14 maart 2026 @ 07:22:

Daarnaast mag je de EVSE ook aan de bemeterde kant van de kWh meter aansluiten, dat is namelijk ook stroom die je nodig hebt om de auto te laden dus die mag je ook meenemen voor de ERE.

Mee nemen voor de ERE?
Het ziet er als ik het goed heb toch naar uit dat ná 2026 geen enkele zelfbouw lader meer door inboekdienstverleners geaccepteerd wordt?
Enkel 2026 zijn er enkelen die het aandurven, maar die geven al aan dat dat eenmalig is.

[Geim]

Allewijn schreef op zaterdag 14 maart 2026 @ 10:30:
[...]


Mee nemen voor de ERE?
Het ziet er als ik het goed heb toch naar uit dat ná 2026 geen enkele zelfbouw lader meer door inboekdienstverleners geaccepteerd wordt?
Enkel 2026 zijn er enkelen die het aandurven, maar die geven al aan dat dat eenmalig is.

Oh, dit is nieuw voor mij, waar heb je die wijsheid vandaan?

[Wolly]

Allewijn schreef op zaterdag 14 maart 2026 @ 10:30:
[...]


Mee nemen voor de ERE?
Het ziet er als ik het goed heb toch naar uit dat ná 2026 geen enkele zelfbouw lader meer door inboekdienstverleners geaccepteerd wordt?
Enkel 2026 zijn er enkelen die het aandurven, maar die geven al aan dat dat eenmalig is.

Dat laatste is een vraag die ik heb gesteld aan @ruud76

ruud76 in "Zelfbouw Laadpaal ervaringen"

[Allewijn]

Geim schreef op zaterdag 14 maart 2026 @ 10:34:
[...]


Oh, dit is nieuw voor mij, waar heb je die wijsheid vandaan?

Omdat ik al een tijdje verdiepende ben in het vervangen van mijn huidige domme Tesla TWC3 lader voor een slimme MID lader ivm meedoen ERE.
Daarbij zoekende of ik zelfbouw wens of een kant en klare toch de slimme weg is.

Er is véél over te lezen in het ERE topic:
[EV] ERE certificaten, geld verdienen met thuisladen

Diverse tweakers die het eenmalig gelukt is zelfbouw met mid aan te melden (en bericht dat dit na 2026 stopt), maar ook tweakers waarbij het afgewezen is.

Hier bijv zo'n afwijzing van een paal met hele duidelijke begeleidende fotos:
DiXY in "[EV] ERE certificaten, geld verdienen met thuisladen"

Maar na 24 maart weten we denk ik pas echt meer.
Tot die tijd bouw/koop ik nog maar even niks zelf bij Stegen...

[ Voor 16% gewijzigd door Allewijn op 14-03-2026 10:48 ]

[Kaspers]

maarten_NL schreef op zaterdag 14 maart 2026 @ 07:22:
@Kaspers waarom zet je daar nog een automaat naast? Ik weet natuurlijk niet hoe ver jouw meterkast van de kWh meter en contactor af zit maar als je het mij vraagt is het een dure aan/uit schakelaar met onnodige bedrading.

Geim schreef op zaterdag 14 maart 2026 @ 10:02:
@Kaspers Waarom heb je voor een 3-fase aardlekautomaat gekozen? Zit je al niet achter een aardlek?

Terechte vragen!
Situatie:
Meterkast in de hal:

_klikbaar


Rechtsonder zie je een Hager aardlekautomaat B20 300mA, die loopt naar de bijkeuken (6mm2), 20 meter verderop naar deze verdeelkast:



Hier zitten meerdere groepen in, voor o.a. warmtepomp, verlichting, wandcontacten. Ik wil niet dat dit spul er uit vliegt wanneer er een aardlek ontstaat bij het laden van de toekomstige wagen, vandaar ik voornemens ben een automaat te plaatsen na de hoofdschakelaar van deze kast voor de EVSE.

Alle componenten zoals hier afgebeeld komen dus in de rechterzijde van deze verdeelkast.

Deze opmerking van @Stefannn houdt mij nog wel even bezig:

Stefannn schreef op woensdag 5 juni 2024 @ 18:31:
Exact! Dat is de juiste manier.
Letop: dat betekent dat de Smartevse in de meterkast NIET geaard is! Aarde via het buiten boxje.
Vooral bij lange draden relevant

Ik ben voornemens om langs de YMVK (25 meter) naar de vaste laadkabel ook een signaalkabel te laten lopen voor de CP. Ik wil de mantel van de signaalkabel ook aarden, voor een stabiele connectie.

Als ik jouw opmerking zo lees, heb ik het idee dat dat ook voor mij van toepassing is.

Begrijp ik het goed dat je voorstelt om de EVSE module in de meterkast niet te aarden, maar deze te verbinden met de aarde op de signaalkabel, en aan het uiteinde van de signaalkabel (waar deze samenkomt met de YMVK) deze daar samen te laten komen met de aarde uit de YMVK, die op zijn beurt weer is geaard in de verdeler / meterkast?

[ Voor 26% gewijzigd door Kaspers op 14-03-2026 11:05 ]

[Geim]

Kaspers schreef op zaterdag 14 maart 2026 @ 10:57:

Hier zitten meerdere groepen in, voor o.a. warmtepomp, verlichting, wandcontacten. Ik wil niet dat dit spul er uit vliegt wanneer er een aardlek ontstaat bij het laden van de toekomstige wagen, vandaar ik voornemens ben een automaat te plaatsen na de hoofdschakelaar van deze kast voor de EVSE.

Alle componenten zoals hier afgebeeld komen dus in de rechterzijde van deze verdeelkast.

Hoe ga je het vermogen meten van de hele onderverdeelkast, om te voorkomen dat de 3x20A in de hoofdverdeelkast er uit vliegt?

[Kaspers]

Geim schreef op zaterdag 14 maart 2026 @ 11:10:
[...]


Hoe ga je het vermogen meten van de hele onderverdeelkast, om te voorkomen dat de 3x20A in de hoofdverdeelkast er uit vliegt?

Die 3x20A in de hoofdverdeler is nog een twijfelpuntje. Ik zit nog te overwegen om deze te hergebruiken als automaat voor de EVSE (ipv de 3x16A), en de automaat in de hoofdverdeler te vervangen door een 3x25A. Ben ik alleen niet meer selectief, maar wel kostenefficient. Als ik selectief (t.o.v. de 25A hoofdzekering) wil zijn moet ik het toch bij de 3x16A automaat voor de EVSE houden. Met een 3x25A in de hoofdverdeler kan ik volstaan met het de waardes die ik vanuit de DSMR monitor.

[Geim]

Kaspers schreef op zaterdag 14 maart 2026 @ 11:16:
[...]
Met een 3x25A in de hoofdverdeler kan ik volstaan met het de waardes die ik vanuit de DSMR monitor.

Hoe gaat je DSMR de Smart EVSE van data voorzien? Via HA (of andere domotic oplossing) of via de Smart EVSE sensorbox? In het laatste geval kun je ook opteren voor een sensorbox in de onderverdelkast met stroomtransformatoren. Als je het via een API doet zou je een Shelly 3EM pro in je onderveldeelkast kunnnen zetten.
Of nog een 3 fase modbus energiemeter, vergelijkbaar met die in je laadcircuit.

[rene037]

Zoals al vaker opgemerkt, maar voor het laatst al een tijdje terug, is het niet verstandig/onwenselijk om een 3x16A automaat te gebruiken om je auto te laden. Die wordt dat te heet. Ze zijn niet ontworpen om langere tijd de maximale stroom te leveren. 3x20 is dan beter, ten koste van wat selectiviteit.

[Stefannn]

Kaspers schreef op zaterdag 14 maart 2026 @ 10:57:

Deze opmerking van @Stefannn houdt mij nog wel even bezig:

Exact! Dat is de juiste manier.
Letop: dat betekent dat de Smartevse in de meterkast NIET geaard is! Aarde via het buiten boxje.
Vooral bij lange draden relevant

Ik ben voornemens om langs de YMVK (25 meter) naar de vaste laadkabel ook een signaalkabel te laten lopen voor de CP. Ik wil de mantel van de signaalkabel ook aarden, voor een stabiele connectie.

Als ik jouw opmerking zo lees, heb ik het idee dat dat ook voor mij van toepassing is.

Begrijp ik het goed dat je voorstelt om de EVSE module in de meterkast niet te aarden, maar deze te verbinden met de aarde op de signaalkabel, en aan het uiteinde van de signaalkabel (waar deze samenkomt met de YMVK) deze daar samen te laten komen met de aarde uit de YMVK, die op zijn beurt weer is geaard in de verdeler / meterkast?

Tjonge... een quote van 2024.

Ik heb de smartEVSE ook in de meterkast hangen
En uiteindelijk zowel direct als via signaalkabel geaard. dus tegen mijn eigen advies in.
In praktijk maakt het bijzonder weinig uit.

Maar....
Mijns inziens is de correcte manier om hem enkel te aarden met de signaalkabel die van de auto komt.

Zolang er nergens kortsluiting is maakt het niet uit.
Maar MOCHT er ooit sluiting naar aarde komen in de vmvk dan krijg je een spanningspuls over de aarddraad (ter grootte kortsluitstroom x draadweerstand) hetgeen dan een puls op de smartevse zet.

Aan de 230V kant heeft de aarde aansluiting van de smartEVSE geen functie.
Aan de signaalkant wel want daar is het de referentie van de signaal waardes.
Het zou dus correct zijn de aarde volledig te refereren aan de signaalkant. dus aan de signaalkant op 0 aan te sluiten.
in praktijk: met zo'n 25m kabel heb je waarschijnlijk een lasdoos vlak bij de auto waar vmvk overgaat in soepel. Op dat punt zou je dan de signaalkabel op de aarde moeten aftakken en separaat naar de meterkast moeten voeren. bij voorkeur als twisted pair met de CP.

Dat is "in principe correct"
Uiteindelijk heb ik het dus ook niet zo aangelegd. Het is een beetje "roomser dan de paus". Bij leiding van paar 100m ga je verschil zien. op 25 meter waarschijnlijk niet.

[Stefannn]

Kaspers schreef op zaterdag 14 maart 2026 @ 11:16:
[...]


Die 3x20A in de hoofdverdeler is nog een twijfelpuntje. Ik zit nog te overwegen om deze te hergebruiken als automaat voor de EVSE (ipv de 3x16A), en de automaat in de hoofdverdeler te vervangen door een 3x25A. Ben ik alleen niet meer selectief, maar wel kostenefficient. Als ik selectief (t.o.v. de 25A hoofdzekering) wil zijn moet ik het toch bij de 3x16A automaat voor de EVSE houden. Met een 3x25A in de hoofdverdeler kan ik volstaan met het de waardes die ik vanuit de DSMR monitor.

De selectiviteit van een 3x20A automaat "repareer" je door de actieve stroombewaking.
3x16A heeft de neiging er uit te klappen na een paar uur laden.
Met 3x20A kan je dan bovendien in solar mode op 1x20A laden hetgeen heel prettig is. 1x16A is redelijk weinig en je wilt dan regelmatig omschakelen naar 3x6A maar dat betekent dan EN heel veel schakelen EN een 2A gat tussen 1x16A en 3x6A. Ik gebruik het solar laden tegenwoordig enkel 1 fase op max 1x20A en dat werkt prima en "rustig".

[Kaspers]

Geim schreef op zaterdag 14 maart 2026 @ 11:58:
[...]

Hoe gaat je DSMR de Smart EVSE van data voorzien? Via HA (of andere domotic oplossing) of via de Smart EVSE sensorbox? In het laatste geval kun je ook opteren voor een sensorbox in de onderverdelkast met stroomtransformatoren. Als je het via een API doet zou je een Shelly 3EM pro in je onderveldeelkast kunnnen zetten.
Of nog een 3 fase modbus energiemeter, vergelijkbaar met die in je laadcircuit.

Inderdaad via HA, die krijgt vanuit de DSMR5 via een TCP connectie elke seconde een reading. En HA stuurt vervolgens elke seconde een mqtt publish met de huidige load op het topic SmartEVSE-XXXXX/Set/MainsMeter, dus dat scheelt weer het e.e.a. aan componenten.

[ Voor 56% gewijzigd door Kaspers op 14-03-2026 14:01 ]

[Kaspers]

rene037 schreef op zaterdag 14 maart 2026 @ 12:08:
Zoals al vaker opgemerkt, maar voor het laatst al een tijdje terug, is het niet verstandig/onwenselijk om een 3x16A automaat te gebruiken om je auto te laden. Die wordt dat te heet. Ze zijn niet ontworpen om langere tijd de maximale stroom te leveren. 3x20 is dan beter, ten koste van wat selectiviteit.

Ik ben bekend met dit advies. Ik lees echter hier ook andere adviezen.

Als ik met 14A ga laden, zit ik mijns inziens veilig, eens? Ik ga in ieder geval met de 16A alamat niet nat op mijn hoofdzekering, daar zit de smeltvariant in, dus vervelend als die een keer klapt. Zou ik met 20A gaan afzekeren en er loopt een keer wat meer vermogen en de hoofdzekering smelt door, dan zitten we een tijdje zonder.

Stefannn schreef op zaterdag 14 maart 2026 @ 13:18:
[...]

De selectiviteit van een 3x20A automaat "repareer" je door de actieve stroombewaking.
3x16A heeft de neiging er uit te klappen na een paar uur laden.
Met 3x20A kan je dan bovendien in solar mode op 1x20A laden hetgeen heel prettig is. 1x16A is redelijk weinig en je wilt dan regelmatig omschakelen naar 3x6A maar dat betekent dan EN heel veel schakelen EN een 2A gat tussen 1x16A en 3x6A. Ik gebruik het solar laden tegenwoordig enkel 1 fase op max 1x20A en dat werkt prima en "rustig".

Maar dit zet mij wel weer aan het denken.
Ik ben er nog niet uit

[ Voor 27% gewijzigd door Kaspers op 14-03-2026 14:02 ]

[Stefannn]

Kaspers schreef op zaterdag 14 maart 2026 @ 14:00:
[...]
Als ik met 14A ga laden, zit ik mijns inziens veilig, eens? Ik ga in ieder geval met de 16A alamat niet nat op mijn hoofdzekering, daar zit de smeltvariant in, dus vervelend als die een keer klapt. Zou ik met 20A gaan afzekeren en er loopt een keer wat meer vermogen en de hoofdzekering smelt door, dan zitten we een tijdje zonder.

Ik heb ook een smeltzekering als hoofdzekering.
Ik heb dus 20A automaten.

Selectiviteit is een heel betrekkelijk begrip. Het is selectief om 4x16A op 1x 25A fase aan te sluiten. Als je die 4 groepen helemaal uitgekiend vol hebt geplempt gaat de hoofdzekering er toch echt uit vanwege 64A belasting.
Behalve de evse zit er helemaal niks anders op de automaten dus "er is geen kans dat je langdurig 20A gaat trekken". Als jij je laadstroom op 16A, of zelfs 14A zet dan gaat er helemaal geen 20A lopen.

check ook onderstaand grafiekje mbt afschakeltijd:
Je 25A hoofdzekering kan dus 10seconden lang 50A hebben en/of 20 seconden [25A + 16A].
Dat gaat dus niet direct fout.
Ik heb 2 jaar lang de boel bewaakt met voeden van api vanuit mijn DMRS2.2 P1 sport op 10sec (sinds vorige week heb ik DMRS5). Dat is altijd goed gegaan. Ik had de "max mains" wel op 23A gezet voor "net een beetje extra headroom".
Was wel echt de rand.
Je hebt dan dus 20seconden als er bij maximale 25A belasting opeens een hele groep van 16A bij komt (voor mij een reële situatie als ik de sauna aan zet tijdens het laden. Dat heb ik dus daadwerkelijk getest).
Met beetje pech duurt het 10seconden voordat de P1 dat rapporteert. De auto reageert in mijn geval met een gemeten 5seconden reactietijd. Tel daar 2x 1sec api communicatie bij op en je hebt een worst case reactie tijd van 17seconden op een max van 20seconden.
Daarom had ik de max-mains dus op 23A gezet. Net een beetje extra headroom.

In solar mode op 20A is ook geen probleem want die 20A gaat helemaal niet door de hoofdzekering maar komt voor minimaal 1/3 van het dak met mijn 3fase PV systeem. Het is intern gesaldeerd dus in slechtste geval mains currents van -6.6A, -6.6A, +13.2A.

[ Voor 12% gewijzigd door Stefannn op 14-03-2026 14:27 ]

[DanTm]

Ik laad al heel lang met 25A op een 25A hoofdzekering. Die gaan er echt niet zo snel uit. Als het zonnetje schijnt laad ik zelfs met 32A.
Goede load balancer is wel van belang natuurlijk.

[rene037]

De 20A is een veiligheid, bijvoorbeeld bij kortsluiting. Je auto (SmartEVSE) stel je in op 16A, dus waarom zou er meer dat 16A gaan lopen? M.a.w.: voor de selectiviteit maakt het niet uit. Heb je achter een automaat een variabel aantal gebruikers die bij elkaar meer dat 16A kunnen gebruiken, dan speelt selectiviteit natuurlijk wel en moet je geen 20A automaat nemen. Voor je auto heeft die automaat een net wat andere functie, nl niet tegen overbelasting, maar een storing (Sluiting). En bij 20A gaat hij er dan (bijna) net zo hard uit als de 20A versie.

[Geim]

Ik heb Laadloon gisteren rechtstreeks gevraagd of ze zelfbouw meters ook ondersteunen. Dit was het antwoord:

Zelfbouw laadpalen zijn van harte welkom, zolang er afdoende bewijs geleverd kan worden over het laadverbruik.
Mocht deze ook automatisch kunnen worden uitgelezen dan hebben we in de toekomst daar natuurlijk ook een oplossing voor.

Met vriendelijke groet,

[Allewijn]

Geim schreef op zondag 15 maart 2026 @ 08:46:
Ik heb Laadloon gisteren rechtstreeks gevraagd of ze zelfbouw meters ook ondersteunen. Dit was het antwoord:

Zelfbouw laadpalen zijn van harte welkom, zolang er afdoende bewijs geleverd kan worden over het laadverbruik.
Mocht deze ook automatisch kunnen worden uitgelezen dan hebben we in de toekomst daar natuurlijk ook een oplossing voor.

Met vriendelijke groet,

En heb je ook gevraagd of ze dit ná 2026 blijven ondersteunen?
Want de andere inboekdienstverleners geven nu al aan dat dit alleen voor dit jaar nog kan...

[Geim]

Allewijn schreef op zondag 15 maart 2026 @ 09:15:
[...]
En heb je ook gevraagd of ze dit ná 2026 blijven ondersteunen?

Nope, ik lees nergens dat ze dat (niet meer) gaan doen.

[Allewijn]

Geim schreef op zondag 15 maart 2026 @ 09:34:
[...]


Nope, ik lees nergens dat ze dat (niet meer) gaan doen.

En je leest ook nergens dat ze dat wel blijven doen...
Vandaar dat ik adviseer om er even specifiek naar te vragen, voordat het na 2026 een teleurstelling voor je wordt.

[Geim]

Allewijn schreef op zondag 15 maart 2026 @ 20:36:
[...]
En je leest ook nergens dat ze dat wel blijven doen...

Wie heeft dan nu al aangegeven dat ze dat wel gaan doen? Ik verwacht niet dat ik ergens een garantie krijg voor 2027.

[Wolly]

Geim schreef op zondag 15 maart 2026 @ 08:46:
Ik heb Laadloon gisteren rechtstreeks gevraagd of ze zelfbouw meters ook ondersteunen. Dit was het antwoord:

Zelfbouw laadpalen zijn van harte welkom, zolang er afdoende bewijs geleverd kan worden over het laadverbruik.
Mocht deze ook automatisch kunnen worden uitgelezen dan hebben we in de toekomst daar natuurlijk ook een oplossing voor.

Met vriendelijke groet,

Wat is afdoende bewijs zou de vervolgvraag zijn.

[Geim]

Wolly schreef op zondag 15 maart 2026 @ 21:10:
[...]


Wat is afdoende bewijs zou de vervolgvraag zijn.

Ik zou zeggen, mail ze met die vraag. Ik geef hier alleen maar door welk antwoord ik gekregen heb op mijn vraag. Ik voel me niet aangesproken om al deze vervolgvragen te stellen.

[ Voor 25% gewijzigd door Geim op 15-03-2026 22:26 ]

[Martijn02]

Ik ben vandaag aan de slag gegaan om mijn domme EVHub om te bouwen naar een SmartEVSE laadpunt.

Ik heb net de oude EVHub stap voor stap losgehaald, en ik kom een situatie tegen waarvan ik niet snap hoe het ooit gewerkt kan hebben. De aarde die op de grijze kabel vanuit de meterkast binnenkomt was aangesloten op de EVHub controller (op de foto net verdwijderd) maar deze was verder niet de laadkabel verbonden.

De aarde die naar de laadkabel van de auto (zwarte kabel, rechts) was via het terminalblok rechts, verbonden met... de aarde van het extra stopcontact linksonder in de evhub bhuizing.

Ik snap er niets van. De EVhub hing al aan het huis toen ik het kocht, en het ziet er niet uit alsof er door de vorige eigenaar aan gesleuteld is. (geloof me, ik heb verschillende dingen van 'm gevonden, dat was duidelijk als zodanig herkenbaar)

Volgens mij zou het zo niet moeten werken, maar het heeft dus wel altijd goed gewerkt, ondanks dat de aardedraad van de auto nooit verbonden is geweest met de aarde, of de EVHUB controller.

[THM0]

Martijn02 schreef op maandag 16 maart 2026 @ 10:17:
Ik ben vandaag aan de slag gegaan om mijn domme EVHub om te bouwen naar een SmartEVSE laadpunt.

Ik heb net de oude EVHub stap voor stap losgehaald, en ik kom een situatie tegen waarvan ik niet snap hoe het ooit gewerkt kan hebben. De aarde die op de grijze kabel vanuit de meterkast binnenkomt was aangesloten op de EVHub controller (op de foto net verdwijderd) maar deze was verder niet de laadkabel verbonden.

De aarde die naar de laadkabel van de auto (zwarte kabel, rechts) was via het terminalblok rechts, verbonden met... de aarde van het extra stopcontact linksonder in de evhub bhuizing.

Ik snap er niets van. De EVhub hing al aan het huis toen ik het kocht, en het ziet er niet uit alsof er door de vorige eigenaar aan gesleuteld is. (geloof me, ik heb verschillende dingen van 'm gevonden, dat was duidelijk als zodanig herkenbaar)

Volgens mij zou het zo niet moeten werken, maar het heeft dus wel altijd goed gewerkt, ondanks dat de aardedraad van de auto nooit verbonden is geweest met de aarde, of de EVHUB controller.

[Afbeelding]

De aarde-klemmen hebben een metalen verbinding met de DIN rail, de aardklem aan de rechterkant is op die manier via de DIN rail en de klem links met aarde in de meterkast verbonden.

[Martijn02]

THM0 schreef op maandag 16 maart 2026 @ 10:34:
[...]

De aarde-klemmen hebben een metalen verbinding met de DIN rail, de aardklem aan de rechterkant is op die manier via de DIN rail en de klem links met aarde in de meterkast verbonden.

Aaaah, wat dom. Dat had ik nog niet gezien, Dan snap ik waarom het werkt, thanks!

[rene037]

THM0 schreef op maandag 16 maart 2026 @ 10:34:
[...]

De aarde-klemmen hebben een metalen verbinding met de DIN rail, de aardklem aan de rechterkant is op die manier via de DIN rail en de klem links met aarde in de meterkast verbonden.

En daarnaast heb je (Als de dinrail geen verbinding zou maken) gewoon een zwevende aarddraad. Maakt voor de werking niet uit lijkt me. Afgezien van de veiligheid natuurlijk.

[adjego]

rene037 schreef op maandag 16 maart 2026 @ 10:40:
[...]

En daarnaast heb je (Als de dinrail geen verbinding zou maken) gewoon een zwevende aarddraad. Maakt voor de werking niet uit lijkt me. Afgezien van de veiligheid natuurlijk.

Daar kunnen sommige auto's anders wel streng in zijn. Geen goeie PE dan wordt er niet geladen.

[ruud76]

Kaspers schreef op vrijdag 13 maart 2026 @ 23:27:
[...]


Bij deze (met nog wat andere aanpassingen, het mag duidelijk zijn hoe ik dit in de meterkast ga ophangen )

Heb je de 2-fasen contactor bewust vóór de 4-fasen contactor gezet in plaats van er na? Ik moet het nog installeren maar ik was precies andersom van plan...

[Frankyy]

ruud76 schreef op maandag 16 maart 2026 @ 11:24:
[...]


Heb je de 2-fasen contactor bewust vóór de 4-fasen contactor gezet in plaats van er na? Ik moet het nog installeren maar ik was precies andersom van plan...

Zo staat het in github als aanbevolen:
https://github.com/dingo3...on.md#second-contactor-c2

Dan heb je ook nooit dat om wat voor reden L2+L3 kan leveren zonder dat N actief is.

"This way the (dangerous) situation is avoided that some Phases are switched ON, and Neutral is switched OFF."

[ Voor 10% gewijzigd door Frankyy op 16-03-2026 11:59 ]

[RonJ]

adjego schreef op maandag 16 maart 2026 @ 10:47:
[...]


Daar kunnen sommige auto's anders wel streng in zijn. Geen goeie PE dan wordt er niet geladen.

Dat is altijd een goede test van je aardweerstand. Sluit een Renault aan en als die wil laden zit je goed.

[RonJ]

Frankyy schreef op maandag 16 maart 2026 @ 11:59:
[...]

Zo staat het in github als aanbevolen:
https://github.com/dingo3...on.md#second-contactor-c2

Dan heb je ook nooit dat om wat voor reden L2+L3 kan leveren zonder dat N actief is.

"This way the (dangerous) situation is avoided that some Phases are switched ON, and Neutral is switched OFF."

Dat kan toch ook niet als je 'm erna zet? Als de C1 maar alle fases en de N schakelt dan.

[Frankyy]

RonJ schreef op maandag 16 maart 2026 @ 12:09:
[...]


Dat kan toch ook niet als je 'm erna zet? Als de C1 maar alle fases en de N schakelt dan.

Och ja, verkeerd gelezen, dan is het antwoord erna inderdaad.

[Martijn02]

rene037 schreef op maandag 16 maart 2026 @ 10:40:
[...]

En daarnaast heb je (Als de dinrail geen verbinding zou maken) gewoon een zwevende aarddraad. Maakt voor de werking niet uit lijkt me. Afgezien van de veiligheid natuurlijk.

Nee, De EV Charger communiceert met de auto door spanning op de CP pin te zetten, en het verschil tussen CP en de aarde uit te lezen. Als de EVHub niet met de Aarde-pin van de auto zou zijn verbonden had 't nooit kunnen werken.

Ik heb hem er inmiddels inzitten, en alles lijkt te werken. Helemaal blij mee. Heb naast de 2e relais ook ook de drukknop en de residual current monitor toegevoegd.



Ik vraag me alleen af of ik misschien ook de leds van de kast nog kan aansluiten. Weet iemand wat daar het aansluitschema van is?

[ruud76]

Frankyy schreef op maandag 16 maart 2026 @ 11:59:
[...]

Zo staat het in github als aanbevolen:
https://github.com/dingo3...on.md#second-contactor-c2

Dan heb je ook nooit dat om wat voor reden L2+L3 kan leveren zonder dat N actief is.

"This way the (dangerous) situation is avoided that some Phases are switched ON, and Neutral is switched OFF."

Dat is in beide situaties het geval. De vraag is: aan welke kant zit de auto: aan de boven- of aan de onderkant van dit plaatje. Ik denk dat de auto aan de onderkant zit (omdat dat in het plaatje verder naar boven ook zo is: 1, 3, 5, 7 is de input en 2, 4, 6, 8 de output) dus je hebt éérst de 4-fasen contactor om de boel aan of uit te zetten en dan de 2-fasen contactor op L2 en L3 om die bij of af te schakelen. Jij hebt ‘m andersom geïnterpreteerd in jouw plaatje. Vandaar ook mijn vraag 😀

[ Voor 11% gewijzigd door ruud76 op 16-03-2026 13:01 ]

[THM0]

ruud76 schreef op maandag 16 maart 2026 @ 12:53:
[...]


Dat is in beide situaties het geval. De vraag is: aan welke kant zit de auto: aan de boven- of aan de onderkant van dit plaatje. Ik denk dat de auto aan de onderkant zit (omdat dat in het plaatje verder naar boven ook zo is: 1, 3, 5, 7 is de input en 2, 4, 6, 8 de output) dus je hebt éérst de 4-fasen contactor om de boel aan of uit te zetten en dan de 2-fasen contactor op L2 en L3 om die bij of af te schakelen. Jij hebt ‘m andersom geïnterpreteerd in jouw plaatje. Vandaar ook mijn vraag 😀

Het maakt in de praktijk toch weinig uit? Het is een logische AND schakeling…

[DanTm]

Martijn02 schreef op maandag 16 maart 2026 @ 12:44:
[...]

Ik vraag me alleen af of ik misschien ook de leds van de kast nog kan aansluiten. Weet iemand wat daar het aansluitschema van is?

de LED's van de evhub zijn niet compatible, ik heb de drukknop van Stegen erin gezet (heb dezelfde ombouw gedaan).

[ruud76]

THM0 schreef op maandag 16 maart 2026 @ 13:27:
[...]

Het maakt in de praktijk toch weinig uit? Het is een logische AND schakeling…

Voor het resultaat niet als alles werkt. Maar ik vermoed dat je liever geen spanning op de C2 contactor wil hebben als C1 niet aan staat.

[THM0]

ruud76 schreef op maandag 16 maart 2026 @ 13:30:
[...]

Voor het resultaat niet als alles werkt. Maar ik vermoed dat je liever geen spanning op de C2 contactor wil hebben als C1 niet aan staat.

Waarom niet? Dat ding is toch gemaakt om ingevoedde spanning wel/niet door te laten naargelang de stand van C2?

[Stefannn]

THM0 schreef op maandag 16 maart 2026 @ 13:54:
[...]

Waarom niet? Dat ding is toch gemaakt om ingevoedde spanning wel/niet door te laten naargelang de stand van C2?

Vooral esthetisch
Als je de 4pool als hoofdschakelaar ziet en de 2pool als onderverdeler dan is het logisch dat hij erna komt.
Mocht je het ooit ingewikkelder willen maken dan is dat ook logischer.
- ingewikkelder maken ga je echter vrij zeker niet doen
- en als de kast dicht zit is enkel de functie en niet de logica belangrijk.

Voor een simpel ding als de smartEVSE is dit Defacto een non-issue. Grote installaties moet je wel “logisch” maken anders krijg je geheid later fouten.

[rene037]

Martijn02 schreef op maandag 16 maart 2026 @ 12:44:
[...]

Nee, De EV Charger communiceert met de auto door spanning op de CP pin te zetten, en het verschil tussen CP en de aarde uit te lezen. Als de EVHub niet met de Aarde-pin van de auto zou zijn verbonden had 't nooit kunnen werken.

De 0 is in de meterkast met de aarde verbonden, dus de auto merkt daar niets van als het goed is. Door de weerstand van de kabel kun je wel iets verschil meten (Anders zou een aardlek niet werken.) maar voor de CP-puls is dat niet van belang.

[rvdgaag]

rene037 schreef op maandag 16 maart 2026 @ 14:55:
[...]

De 0 is in de meterkast met de aarde verbonden

Gevaarlijke uitspraak omdat dat zeker niet waar is in heel Nederland !

[Geim]

rvdgaag schreef op maandag 16 maart 2026 @ 17:16:
[...]


Gevaarlijke uitspraak omdat dat zeker niet waar is in heel Nederland !

Sterker nog het TT stelsel (aarde ligt bij de trafo aan de nul en de woning heeft een eigen aardpen) is het meest voorkomende aardingssysteem (in de woningbouw) in Nederland: Wikipedia: TT-aardingssysteem

[ Voor 0% gewijzigd door Geim op 16-03-2026 19:27 . Reden: typo ]

[Martijn02]

Geim schreef op maandag 16 maart 2026 @ 19:27:
[...]


Sterker nog het TT stelsel (aarde ligt bij de trafo aan de nul en de woning heeft een eigen aardpen) is het meest voorkomende aardingssysteem (in de woningbouw) in Nederland: Wikipedia: TT-aardingssysteem

Hier ook een TT stelsel, en ik vond dat ook wel heel stellig gezegd, dus ik begon bijna aan mezelf te twijfelen.

Net na zonsondergang nog even een rondje gewandeld en nu is de gele knipperende led (in solar stand, zonder zon) wel heel erg fel. Nou kan je ‘m natuurlijk met home assistant bij zonsondergang wat dimmen, of misschien de solar stand wel op stop zetten tussen zonsondergang en zonsopgang. Zijn er mensen die daar nog iets slims mee hebben gedaan?

[THM0]

Inmiddels heb ik de SmartEVSE gekoppeld aan EVCC via OCPP. Dat werkt op zich, maar ik mis oa wisselen tussen 1-fase en 3-fase. En je kunt hem dan niet echt koppelen aan een backoffice mocht je dat willen (bijv voor ERE), tenzij je met een proxy gaat klooien.
Hoe mooi zou het zijn als de SmartEVSE helemaal ondersteund wordt in EVCC via de API.. omdat de SmartEVSE firmware opensource is zou dat ook geen EVCC sponsortoken vereisen dacht ik.

Is er iemand met coding skills die hiermee bezig is? Volgens mij missen er twee dingen in de SmartEVSE API om goed aan te kunnen sluiten op EVCC:
- Uitlezen van IEC 61851-1 status code (letter A-F)
- Commando om een nette wissel tussen 1-fase en 3-fase te doen in beide richtingen (weet niet of C2 'hard' schakelen de manier is...).

Het zou echt een hele mooie feature set ontsluiten voor de SmartEVSE zonder de limieten van de ESP32 op te hoeven zoeken, eens te meer wanneer het salderen afgeschaft wordt en naar ik vemoed velen van ons met PV naar dynamisch contract gaan, al dan niet aangevuld met thuisaccu...

Helaas mis ik de coding skills om dit te ontwikkelen.
Wie werpt zich op?

[TheJVH]

THM0 schreef op maandag 16 maart 2026 @ 21:41:
Inmiddels heb ik de SmartEVSE gekoppeld aan EVCC via OCPP. Dat werkt op zich, maar ik mis oa wisselen tussen 1-fase en 3-fase. En je kunt hem dan niet echt koppelen aan een backoffice mocht je dat willen (bijv voor ERE), tenzij je met een proxy gaat klooien.
Hoe mooi zou het zijn als de SmartEVSE helemaal ondersteund wordt in EVCC via de API.. omdat de SmartEVSE firmware opensource is zou dat ook geen EVCC sponsortoken vereisen dacht ik.

Is er iemand met coding skills die hiermee bezig is? Volgens mij missen er twee dingen in de SmartEVSE API om goed aan te kunnen sluiten op EVCC:
- Uitlezen van IEC 61851-1 status code (letter A-F)
- Commando om een nette wissel tussen 1-fase en 3-fase te doen in beide richtingen (weet niet of C2 'hard' schakelen de manier is...).

Het zou echt een hele mooie feature set ontsluiten voor de SmartEVSE zonder de limieten van de ESP32 op te hoeven zoeken, eens te meer wanneer het salderen afgeschaft wordt en naar ik vemoed velen van ons met PV naar dynamisch contract gaan, al dan niet aangevuld met thuisaccu...

Helaas mis ik de coding skills om dit te ontwikkelen.
Wie werpt zich op?

Als ik zo snel door de OpenEVSE code van EVCC heen lees zit daar al wel wat in voor 1/3 fase switching. Ik heb zelf nog geen van beide draaien maar wil wel een setup met SmartEVSE en EVCC gaan opzetten. Ik kan dan ook wel eens gaan kijken naar de integratie van beide.

Het verbaast mij eigenlijk dat dit nog niet helemaal werkt, beide projecten lijken mij elkaar super aanvullen.

[rene037]

rvdgaag schreef op maandag 16 maart 2026 @ 17:16:
[...]


Gevaarlijke uitspraak omdat dat zeker niet waar is in heel Nederland !

Ok.... Ik dacht dat het 'de Nederlandse standaard' was. Neemt niet weg dat de 0 en aarde niet veel van elkaar mogen verschillen toch in potentiaal? Maar kan voor CP-signaal natuurlijk wel verstorend genoeg zijm. Maar goed, theoretisch gelul natuurlijk, in de praktijk hoort alles goed aangesloten te zijn. Maar ik heb weer wat geleerd:).

[dingo35]

Sterker nog het ís zeer verstorend als de PE niet op de SmartEVSE aangesloten is, ik geloof dat het het nr 1 probleem voor nieuw aangesloten SmartEVSEs is! Het is de eerste vraag die Michael Stegen stelt als een EV niet wil laden...

[Maverick]

Ik heb een irritant probleem. Ik ben sinds kort over op een nieuwe meter (yay!) met DSMR5, waardoor ik over ben op het meten van de stroom via de P1 poort voor mijn smartEVSE. Lijkt allemaal prima te werken qua meting, maar wat ik sindsdien merk, is dat mijn lader continue stopt met laden. (ik kan het relais door de muur heen horen schakelen, dus het valt op).
Nu zit ik in home assistant te kijken, en het is overduidelijk dat dit komt door mijn Quooker. Je ziet de pieken daarvan samenvallen met het klapperen.
Echter, die pieken zijn bij lange na niet tot aan de 25 Ampere. Hij kan nog makkelijk met minimaal 6A blijven laden. Mijn limiet in de smartEVSE staat ook echt op 25A ingesteld. Is er iets anders dat er voor kan zorge dat hij dit gedrag vertoont? Ik limiteer bijvoorbeeld wel de laadsnelheid tussen de 16A en 6A naar gelang de stroomprijs van dat moment, maar dat staat hier toch los van?
Iemand een suggestie?

[Hmmbob]

Werkt bij jullie het ''fysiek'' bedienen van de SmartEVSE (via de webinterface) nog?

Ik zit op versie 3.10.2 en het lijkt erop dat wat ik ook doe, er geen reactie is op het gebruik van de knoppen in de webinterface (ongeacht de status van de screenshot en wel na invoeren juiste pin)


edit:

[ Voor 24% gewijzigd door Hmmbob op 18-03-2026 14:52 ]

[adjego]

Hmmbob schreef op woensdag 18 maart 2026 @ 14:50:
Werkt bij jullie het ''fysiek'' bedienen van de SmartEVSE (via de webinterface) nog?

Ik zit op versie 3.10.2 en het lijkt erop dat wat ik ook doe, er geen reactie is op het gebruik van de knoppen in de webinterface (ongeacht de status van de screenshot)
[Afbeelding]

Hier alles prima met ook versie 3.10.2.

[Stefannn]

Maverick schreef op woensdag 18 maart 2026 @ 13:40:
Ik heb een irritant probleem. Ik ben sinds kort over op een nieuwe meter (yay!) met DSMR5, waardoor ik over ben op het meten van de stroom via de P1 poort voor mijn smartEVSE. Lijkt allemaal prima te werken qua meting, maar wat ik sindsdien merk, is dat mijn lader continue stopt met laden. (ik kan het relais door de muur heen horen schakelen, dus het valt op).
Nu zit ik in home assistant te kijken, en het is overduidelijk dat dit komt door mijn Quooker. Je ziet de pieken daarvan samenvallen met het klapperen.
Echter, die pieken zijn bij lange na niet tot aan de 25 Ampere. Hij kan nog makkelijk met minimaal 6A blijven laden. Mijn limiet in de smartEVSE staat ook echt op 25A ingesteld. Is er iets anders dat er voor kan zorge dat hij dit gedrag vertoont? Ik limiteer bijvoorbeeld wel de laadsnelheid tussen de 16A en 6A naar gelang de stroomprijs van dat moment, maar dat staat hier toch los van?
Iemand een suggestie?

[Afbeelding]

Ik weet niet “hoe” je de data naar de P1 poort stuurt maar ik denk “te vaak”.
Bij mij is ook 2 weken geleden de dmrs2.2 meter vervangen naar dmrs5.
Ik heb meteen een testje gedaan.
Met MIJN AUTO… is de delay 5 secondes.
Het is een echte delay, niet langzaam omhoog/naar beneden. 5 secondes geen reactie en dan alles.
Ik doe de loadbalancing vanuit mijn eigen software zelf via de api. Maar ik zie dus dat een commando voor meer danwel minder stroom pas na 5 secondes effect heeft.
Als je de smartEVSE de boel laat regelen en echte elke seconde data geeft dan zal hij op de eerste sample terugregelen, en dan op de tweede sample waarschijnlijk ook “omdat de gemeten stroom nog steeds hoog is”. Er zit wel iets van filter in trouwens.
@dingo35 heeft wel eens gezegd dat de regeling bedoeld is voor “elke 2 secondes een meetpunt”.
Ik zou dus experimenteren met “om de N waardes”, met N van 2 tot 5.

[Maverick]

Stefannn schreef op woensdag 18 maart 2026 @ 15:41:
[...]

Ik weet niet “hoe” je de data naar de P1 poort stuurt maar ik denk “te vaak”.
Bij mij is ook 2 weken geleden de dmrs2.2 meter vervangen naar dmrs5.
Ik heb meteen een testje gedaan.
Met MIJN AUTO… is de delay 5 secondes.
Het is een echte delay, niet langzaam omhoog/naar beneden. 5 secondes geen reactie en dan alles.
Ik doe de loadbalancing vanuit mijn eigen software zelf via de api. Maar ik zie dus dat een commando voor meer danwel minder stroom pas na 5 secondes effect heeft.
Als je de smartEVSE de boel laat regelen en echte elke seconde data geeft dan zal hij op de eerste sample terugregelen, en dan op de tweede sample waarschijnlijk ook “omdat de gemeten stroom nog steeds hoog is”. Er zit wel iets van filter in trouwens.
@dingo35 heeft wel eens gezegd dat de regeling bedoeld is voor “elke 2 secondes een meetpunt”.
Ik zou dus experimenteren met “om de N waardes”, met N van 2 tot 5.

Euhm. Ik stuur geen data naar de P1 poort. De Sensorbox leest de P1 uit en stuurt dat door naar de smartEVSE. Ik kan die data naar mijn weten helemaal niet manipuleren, of wel?

[dingo35]

@Maverick Je sensorbox zou dit allemaal prima voor je moeten regelen. Zorg er allereerst voor dat er geen automations in HA de parameters van de SmartEVSE wijzigen; ten tweede, post je /settings zodat we kunnen zien wat er aan de hand is.

EDIT: Ik zie ook nog een slimmelezer referentie in je grafiek, waarom heb je die als je al een sensorbox hebt?

[ Voor 19% gewijzigd door dingo35 op 18-03-2026 16:13 ]

[Robert-Jan]

Hmmbob schreef op woensdag 18 maart 2026 @ 14:50:
Werkt bij jullie het ''fysiek'' bedienen van de SmartEVSE (via de webinterface) nog?

Ik zit op versie 3.10.2 en het lijkt erop dat wat ik ook doe, er geen reactie is op het gebruik van de knoppen in de webinterface (ongeacht de status van de screenshot en wel na invoeren juiste pin)

Op Mobile Safari had ik inderdaad hetzelfde probleem.

In een nieuwe (test)-release zit hier al een verbetering in. In die versie is de code die de status van de knoppen afhandelt herschreven (voor de techneuten: dit gaat nu via een websocket).

Dus: even wachten op de volgende test-release, of zelf een build maken als je niet wilt wachten.

[DanTm]

Kun je override current ook in smart mode gebruiken, en zo ja, blijft load balancing dan werken, en zo nee, kun je op een andere manier de laadsnelheid beperken en tegelijkertijd load balancing actief houden? (Eigenlijk een soort van de max current aanpassen ).

[Maverick]

dingo35 schreef op woensdag 18 maart 2026 @ 16:07:
@Maverick Je sensorbox zou dit allemaal prima voor je moeten regelen. Zorg er allereerst voor dat er geen automations in HA de parameters van de SmartEVSE wijzigen; ten tweede, post je /settings zodat we kunnen zien wat er aan de hand is.

Ik heb 1 automation waarin ik de chargecurrentoverride wijzig en de mode tussen paused en smart wissel.
Hier mijn /settings:

JSON:

{"version":"v3.10.2","serialnr":8716,"mode":"PAUSE","mode_id":4,"car_connected":true,
"wifi":{"status":"WL_CONNECTED","ssid":"1110","rssi":-50,"bssid":"54:A0:50:5B:48:F0"},
"evse"{"temp":26,"temp_max":65,"connected":true,"access":2,"mode":1,"loadbl":0,"pwm":1024,"custombutton":false,"solar_stop_timer":0,"state":"Charging stopped","state_id":9,"error":"None","error_id":0,"rfidreader":"Disabled","nrofphases":3,"rfid":"Not Installed"},
"settings":"charge_current":60,"override_current":60,"current_min":6,"current_max":16,"current_main":25,"current_max_circuit":16,"current_max_sum_mains":25,"max_sum_mains_time":0,"solar_max_import":0,"solar_start_current":4,"solar_stop_time":10,"enable_C2":"Not present","mains_meter":"Sensorbox","starttime":0,"stoptime":0,"repeat":0,"lcdlock":0,"lock":0,"cablelock":0},
"mqtt":"host":"192.168.1.178","port":1883,"topic_prefix":"SmartEVSE/8716","username":"","password_set":false,"tls":false,"status":"Connected","smartevse_server":false},
"ocpp":"mode":"Disabled","backend_url":"","cb_id":"","auth_key":"","auto_auth":"Disabled","auto_auth_idtag":"","status":"Disconnected"},
"home_battery":{"current":0,"last_update":0},
"ev_meter":"description":"Disabled","address":12,"import_active_power":0,"total_wh":0,"charged_wh":0,"currents":{"TOTAL":0,"L1":0,"L2":0,"L3":0},"import_active_energy":0,"export_active_energy":0},
"mains_meter":{"import_active_energy":0,"export_active_energy":0},
"phase_currents":{"TOTAL":114,"L1":13,"L2":2,"L3":99,"last_data_update":1773857880,"original_data":{"TOTAL":114,"L1":13,"L2":2,"L3":99}},
"backlight":{"timer":0,"status":"OFF"},"color":{"off":{"R":0,"G":0,"B":0},"normal":{"R":0,"G":255,"B":0},"smart":{"R":0,"G":255,"B":0},"solar":{"R":255,"G":170,"B":0},"custom":{"R":0,"G":0,"B":255}}}

Ik zie wel bijvoorbeeld "current_max_circuit" op 16 staan, zou dit 25 moeten zijn? Ik weet alleen niet hoe ik deze aan kan passen. Niet op het display geloof ik? Weet ook niet of dit de fase van de hoofdzekering is, of van de groep. Dan klopt 16 wel.

EDIT: Ik zie ook nog een slimmelezer referentie in je grafiek, waarom heb je die als je al een sensorbox hebt?

Ja die had ik al aan mijn HA gekoppeld. Die lees ik daar wel uit, maar daar doe ik verder niets mee. Ik had deze hier even aangezet om te checken of de waardes daarvan ook overeen kwamen met e waardes die via de EVSE bij HA aankomen.

[dingo35]

Als je geen sub panel configuratie hebt moet Max Circuit heel hoog staan, bijv. gelijk aan Mains of hoger.

Maar je probleem is MaxSumMains, je begrenst je laadcapaciteit tot 25A over 3 fasen = 8,3A per fase. Disablen of op 600A zetten.

[Maverick]

dingo35 schreef op woensdag 18 maart 2026 @ 20:10:
...MaxSumMains...

Ah, dat was hem. Hartelijk dank

[dingo35]

@DanTm Lang geleden dat ik dat gebouwd heb, maar probeer het eens. Als je in Smart mode zit zouden MaxMains, MaxCurrent en MaxCircuit gehonoreerd moeten worden; maar als je dan toch zelf regelt, waarom ga je dan niet naar Normal mode en bewaak je zelf de grenzen?

[DanTm]

dingo35 schreef op donderdag 19 maart 2026 @ 03:01:
@DanTm Lang geleden dat ik dat gebouwd heb, maar probeer het eens. Als je in Smart mode zit zouden MaxMains, MaxCurrent en MaxCircuit gehonoreerd moeten worden; maar als je dan toch zelf regelt, waarom ga je dan niet naar Normal mode en bewaak je zelf de grenzen?

Ik heb het getest, en lijkt inderdaad te werken in smart mode.
Ik wil geen Normal gebruiken, omdat er dan geen bewaking meer is als mijn eigen logica faalt. Hij zal dan gewoon door blijven laden met de laatst gestuurde current.
Als je nu verplicht binnen 10 seconden ofzo de override current moet blijven sturen om de regeling actief te houden zou het wel kunnen. Maar goed, met Smart lijkt het prima te werken

[adjego]

Hmmbob schreef op woensdag 18 maart 2026 @ 14:50:
Werkt bij jullie het ''fysiek'' bedienen van de SmartEVSE (via de webinterface) nog?

Ik zit op versie 3.10.2 en het lijkt erop dat wat ik ook doe, er geen reactie is op het gebruik van de knoppen in de webinterface (ongeacht de status van de screenshot en wel na invoeren juiste pin)
[Afbeelding]

edit:



[Afbeelding]

Ging dit overigens over mobiel? Want dat heeft bij mij nog nooit gewerkt

[dingo35]

Dat had te maken met de "longpress" functionaliteit op Android en IOS; dat zou nu verholpen moeten zijn...

[Beekforel]

Kan ik de SmartEVSE vertellen dat hij geen stroom van mijn thuisbatterijen mag nemen?

Wanneer de batterijen laden gaat hij prima ermee om (pakt voorrang op de batterijen) maar de stroom van de batterijen moet niet naar de auto.

[DanTm]

Beekforel schreef op donderdag 19 maart 2026 @ 16:23:
Kan ik de SmartEVSE vertellen dat hij geen stroom van mijn thuisbatterijen mag nemen?

Wanneer de batterijen laden gaat hij prima ermee om (pakt voorrang op de batterijen) maar de stroom van de batterijen moet niet naar de auto.

Dat moet je de batterijen vertellen, smartevse kan dat niet beslissen.

[Phantone]

Net een Thuisbatterij besteld en die kan niet met de SlimmeLezer+ overweg, wel met de HomeWizard P1.
Nu had ik geen zin in een splitter dus heb even de HomeWizard V1 API toegevoegd aan de SlimmeLezer+
Toen zag ik dat de nieuwe SmartEVSE firmware deze tegenwoordig ook support dus dacht ik laat ik even hier de yaml delen.

code:

#
# SlimmeLezer+ configuration with SmartEVSE REST support.
# Extended from github://zuidwijk/slimmelezer-wt32-eth01/wt32.yaml@main
#
# Added:
#   - SmartEVSE Integration switch (available in HA)
#   - SmartEVSE API connectivity status sensor (available in HA)
#   - Electricity tariff sensor (available in HA, useful for automations)
#   - Send data to SmartEVSE using http post REST interface
#   - HomeWizard HWE-P1 API emulation (for Indevolt and other batteries)
#   - mDNS announcement as HomeWizard P1 meter
#
# Please update 'smartevse_host' below to match your SmartEVSE
#

substitutions:
  device_name: slimmelezer
  smartevse_host: 192.168.*.*  # <== YOUR SMARTEVSE IP ADDRESS HERE

esphome:
  name: ${device_name}
  name_add_mac_suffix: false
  comment: SlimmeLezer+ / SmartEVSE / HomeWizard API
  project:
    name: zuidwijk.slimmelezer
    version: "1.2"
  on_boot:
    # ── Bestaande boot logica (decryptie sleutel) ────────────────────────────
    - priority: 600.0
      then:
        - if:
            condition:
              lambda: return id(has_key);
            then:
              - lambda: |-
                  std::string key(id(stored_decryption_key), 32);
                  id(dsmr_instance).set_decryption_key(key.c_str());
            else:
              - logger.log:
                  level: info
                  format: "Not using decryption key. If you need to set a key use Home Assistant service 'ESPHome:  ${device_name}_set_dsmr_key'"
    # ── HomeWizard API registreren (na webserver start) ──────────────────────
    - priority: -100.0
      then:
        - lambda: |-
            auto *server = esphome::web_server_base::global_web_server_base->get_server();

            // GET /api/v1/telegram  →  ruwe DSMR telegram tekst
            server->on("/api/v1/telegram", HTTP_GET, [](AsyncWebServerRequest *req) {
              req->send(200, "text/plain", id(last_telegram).c_str());
            });

            // GET /api/v1/data eerst registreren (meest specifieke route)
            server->on("/api/v1/data", HTTP_GET, [](AsyncWebServerRequest *req) {
              // wifi dBm (-100..0) → percentage (0..100)
              int wifi_pct = (int)clamp((id(hw_wifi_signal).state + 100.0f) * 2.0f, 0.0f, 100.0f);
              int smr_ver  = atoi(id(hw_p1_version).state.c_str());

              // kW → W
              float p_net = (id(hw_power_delivered).state - id(hw_power_returned).state) * 1000.0f;
              float l1_w  = (id(hw_power_del_l1).state   - id(power_returned_l1).state) * 1000.0f;
              float l2_w  = (id(hw_power_del_l2).state   - id(power_returned_l2).state) * 1000.0f;
              float l3_w  = (id(hw_power_del_l3).state   - id(power_returned_l3).state) * 1000.0f;

              // Gesigneerde stroom per fase (negatief bij teruglevering)
              float i1 = id(power_returned_l1).state > 0 ? -id(current_l1).state : id(current_l1).state;
              float i2 = id(power_returned_l2).state > 0 ? -id(current_l2).state : id(current_l2).state;
              float i3 = id(power_returned_l3).state > 0 ? -id(current_l3).state : id(current_l3).state;

              // Totaal import/export (t1 + t2)
              float total_import = id(hw_energy_t1).state + id(hw_energy_t2).state;
              float total_export = id(hw_return_t1).state + id(hw_return_t2).state;

              // gas_timestamp als YYMMDDhhmmss
              time_t now = time(nullptr);
              struct tm *ti = localtime(&now);
              long long gas_ts = (long long)(ti->tm_year % 100) * 10000000000LL
                               + (ti->tm_mon + 1)               * 100000000LL
                               + ti->tm_mday                    * 1000000LL
                               + ti->tm_hour                    * 10000LL
                               + ti->tm_min                     * 100LL
                               + ti->tm_sec;

              // Cursor-gebaseerde JSON opbouw: conditionele velden worden
              // weggelaten als de waarde niet beschikbaar is (isnan)
              static char buf[1280];
              int p = 0;
              #define A(...) p += snprintf(buf + p, sizeof(buf) - p, __VA_ARGS__)
              #define AF(key, val) if (!isnan(val)) A("\"" key "\":%.0f,", val)

              A("{");
              A("\"unique_id\":\"%s\",",          id(hw_equipment_id).state.c_str());
              A("\"wifi_ssid\":\"%s\",",           WiFi.SSID().c_str());
              A("\"wifi_strength\":%d,",           wifi_pct);
              A("\"smr_version\":%d,",             smr_ver);
              A("\"meter_model\":\"%s\",",         id(hw_identification).state.c_str());
              A("\"active_tariff\":%d,",           atoi(id(hw_tariff).state.c_str()));
              A("\"total_power_import_kwh\":%.3f,",  total_import);
              A("\"total_power_import_t1_kwh\":%.3f,", id(hw_energy_t1).state);
              A("\"total_power_import_t2_kwh\":%.3f,", id(hw_energy_t2).state);
              A("\"total_power_export_kwh\":%.3f,",  total_export);
              A("\"total_power_export_t1_kwh\":%.3f,", id(hw_return_t1).state);
              A("\"total_power_export_t2_kwh\":%.3f,", id(hw_return_t2).state);
              A("\"active_power_w\":%.0f,",        p_net);
              A("\"active_power_l1_w\":%.0f,",     l1_w);
              A("\"active_power_l2_w\":%.0f,",     l2_w);
              A("\"active_power_l3_w\":%.0f,",     l3_w);
              A("\"active_voltage_l1_v\":%.1f,",   id(hw_voltage_l1).state);
              A("\"active_voltage_l2_v\":%.1f,",   id(hw_voltage_l2).state);
              A("\"active_voltage_l3_v\":%.1f,",   id(hw_voltage_l3).state);
              A("\"active_current_l1_a\":%.1f,",   i1);
              A("\"active_current_l2_a\":%.1f,",   i2);
              A("\"active_current_l3_a\":%.1f,",   i3);
              AF("voltage_sag_l1_count",   id(hw_sag_l1).state);
              AF("voltage_sag_l2_count",   id(hw_sag_l2).state);
              AF("voltage_sag_l3_count",   id(hw_sag_l3).state);
              AF("voltage_swell_l1_count", id(hw_swell_l1).state);
              AF("voltage_swell_l2_count", id(hw_swell_l2).state);
              AF("voltage_swell_l3_count", id(hw_swell_l3).state);
              AF("any_power_fail_count",   id(hw_power_fail).state);
              AF("long_power_fail_count",  id(hw_long_power_fail).state);
              A("\"total_gas_m3\":%.3f,",          id(hw_gas).state);
              A("\"gas_timestamp\":%lld,",         gas_ts);
              A("\"unique_gas_id\":\"%s\",",       id(hw_gas_equipment_id).state.c_str());
              A("\"external\":[{"
                  "\"unique_id\":\"%s\","
                  "\"type\":\"gas_meter\","
                  "\"timestamp\":%lld,"
                  "\"value\":%.3f,"
                  "\"unit\":\"m3\""
                "}]",
                id(hw_gas_equipment_id).state.c_str(),
                gas_ts,
                id(hw_gas).state);
              A("}");
              #undef A
              #undef AF

              req->send(200, "application/json", buf);
            });

            // GET /api  →  device-identificatie als HWE-P1 (na /api/v1/data registreren)
            server->on("/api", HTTP_GET, [](AsyncWebServerRequest *req) {
              req->send(200, "application/json",
                "{\"product_type\":\"HWE-P1\","
                "\"product_name\":\"P1 Meter\","
                "\"serial\":\"a3f8c21d904e\","
                "\"firmware_version\":\"5.18\","
                "\"api_version\":\"v1\"}");
            });

esp8266:
    restore_from_flash: true
    board: d1_mini

# Enable logging
logger:
  baud_rate: 0
  logs:
    component: ERROR
    http_request.arduino: ERROR  # onderdruk de framework warning

# Enable Home Assistant API
api:
  services:
    service: set_dsmr_key
    variables:
      private_key: string
    then:
      - logger.log:
          format: Setting private key %s. Set to empty string to disable
          args: [private_key.c_str()]
      - globals.set:
          id: has_key
          value: !lambda "return private_key.length() == 32;"
      - lambda: |-
          if (private_key.length() == 32)
            memcpy(id(stored_decryption_key), private_key.c_str(), 32);
          id(dsmr_instance).set_decryption_key(private_key.c_str());

ota:
  platform: esphome

dashboard_import:
  package_import_url: github://zuidwijk/dsmr/slimmelezer.yaml@main
  import_full_config: true

uart:
  id: uart_dsmr
  baud_rate: 115200
  rx_pin: D7
  rx_buffer_size: 1700

web_server:
  port: 80

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  min_auth_mode: WPA2

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}

captive_portal:

# mDNS: kondigt de SlimmeLezer+ aan als HomeWizard HWE-P1
mdns:
  services:
    - service: _hwenergy
      protocol: _tcp
      port: 80
      txt:
        api_enabled: "1"
        path: /api/v1
        product_name: P1 Meter
        product_type: HWE-P1
        serial: b4f8f21d965a

globals:
  - id: has_key
    type: bool
    restore_value: yes
    initial_value: "false"
  - id: stored_decryption_key
    type: char[32]
    restore_value: yes
  - id: smartevse_integration  # SmartEVSE addition
    type: bool
  - id: smartevse_error  # SmartEVSE addition
    type: int
  - id: last_telegram       # HomeWizard API telegram endpoint
    type: std::string
    restore_value: no
    initial_value: '""'

dsmr:
  uart_id: uart_dsmr
  id: dsmr_instance
  max_telegram_length: 1700
  # For Luxembourg users set here your decryption key
  #decryption_key: !secret decryption_key // enable this when using decryption for Luxembourg; key like '00112233445566778899AABBCCDDEEFF'

sensor:
  - platform: dsmr
    energy_delivered_lux:
      name: "Energy Consumed Luxembourg"
    energy_delivered_tariff1:
      id: hw_energy_t1                    # HomeWizard API
      name: "Energy Consumed Tariff 1"
    energy_delivered_tariff2:
      id: hw_energy_t2                    # HomeWizard API
      name: "Energy Consumed Tariff 2"
    energy_returned_lux:
      name: "Energy Produced Luxembourg"
    energy_returned_tariff1:
      id: hw_return_t1                    # HomeWizard API
      name: "Energy Produced Tariff 1"
    energy_returned_tariff2:
      id: hw_return_t2                    # HomeWizard API
      name: "Energy Produced Tariff 2"
    power_delivered:
      id: hw_power_delivered              # HomeWizard API
      name: "Power Consumed"
      accuracy_decimals: 3
    power_returned:
      id: hw_power_returned               # HomeWizard API
      name: "Power Produced"
      accuracy_decimals: 3
    electricity_failures:
      id: hw_power_fail                   # HomeWizard API
      name: "Electricity Failures"
      icon: mdi:alert
    electricity_long_failures:
      id: hw_long_power_fail              # HomeWizard API
      name: "Long Electricity Failures"
      icon: mdi:alert
    voltage_sag_l1:
      id: hw_sag_l1                       # HomeWizard API
      name: "Voltage Sags Phase 1"
    voltage_sag_l2:
      id: hw_sag_l2                       # HomeWizard API
      name: "Voltage Sags Phase 2"
    voltage_sag_l3:
      id: hw_sag_l3                       # HomeWizard API
      name: "Voltage Sags Phase 3"
    voltage_swell_l1:
      id: hw_swell_l1                     # HomeWizard API
      name: "Voltage Swells Phase 1"
    voltage_swell_l2:
      id: hw_swell_l2                     # HomeWizard API
      name: "Voltage Swells Phase 2"
    voltage_swell_l3:
      id: hw_swell_l3                     # HomeWizard API
      name: "Voltage Swells Phase 3"
    voltage_l1:
      id: hw_voltage_l1                   # HomeWizard API
      name: "Voltage Phase 1"
    voltage_l2:
      id: hw_voltage_l2                   # HomeWizard API
      name: "Voltage Phase 2"
    voltage_l3:
      id: hw_voltage_l3                   # HomeWizard API
      name: "Voltage Phase 3"
    current_l1:
      id: current_l1                      # SmartEVSE + HomeWizard API
      name: "Current Phase 1"
    current_l2:
      id: current_l2                      # SmartEVSE + HomeWizard API
      name: "Current Phase 2"
    current_l3:
      id: current_l3                      # SmartEVSE + HomeWizard API
      name: "Current Phase 3"
    power_delivered_l1:
      id: hw_power_del_l1                 # HomeWizard API
      name: "Power Consumed Phase 1"
      accuracy_decimals: 3
    power_delivered_l2:
      id: hw_power_del_l2                 # HomeWizard API
      name: "Power Consumed Phase 2"
      accuracy_decimals: 3
    power_delivered_l3:
      id: hw_power_del_l3                 # HomeWizard API
      name: "Power Consumed Phase 3"
      accuracy_decimals: 3
    power_returned_l1:
      id: power_returned_l1               # SmartEVSE + HomeWizard API
      name: "Power Produced Phase 1"
      accuracy_decimals: 3
    power_returned_l2:
      id: power_returned_l2               # SmartEVSE + HomeWizard API
      name: "Power Produced Phase 2"
      accuracy_decimals: 3
    power_returned_l3:
      id: power_returned_l3               # SmartEVSE + HomeWizard API
      name: "Power Produced Phase 3"
      accuracy_decimals: 3
    gas_delivered:
      id: hw_gas                          # HomeWizard API
      name: "Gas Consumed"
    gas_delivered_be:
      name: "Gas Consumed Belgium"
  - platform: uptime
    name: "SlimmeLezer Uptime"
    update_interval: 60s
  - platform: wifi_signal
    id: hw_wifi_signal                    # HomeWizard API
    name: "SlimmeLezer Wi-Fi Signal"
    update_interval: 60s

text_sensor:
  - platform: dsmr
    identification:
      id: hw_identification               # HomeWizard API
      name: "DSMR Identification"
    equipment_id:
      id: hw_equipment_id                 # HomeWizard API (unique_id)
      name: "Equipment ID"
    gas_equipment_id:
      id: hw_gas_equipment_id             # HomeWizard API (unique_gas_id)
      name: "Gas Equipment ID"
    p1_version:
      id: hw_p1_version                   # HomeWizard API
      name: "DSMR Version"
    p1_version_be:
      name: "DSMR Version Belgium"
    electricity_tariff:                   # SmartEVSE + HomeWizard API
      id: hw_tariff
      name: "Electricity tariff"
    telegram:                             # HomeWizard API telegram endpoint
      id: hw_telegram
      internal: true
      on_value:
        then:
          - lambda: |-
              id(last_telegram) = x;
  - platform: wifi_info
    ip_address:
      name: "SlimmeLezer IP Address"
    ssid:
      name: "SlimmeLezer Wi-Fi SSID"
    bssid:
      name: "SlimmeLezer Wi-Fi BSSID"
  - platform: version
    name: "ESPHome Version"
    hide_timestamp: true

# SmartEVSE additions

binary_sensor:
  - platform: template
    name: "SmartEVSE API"
    device_class: connectivity
    lambda: "return id(smartevse_error) < 5;"

switch:
  - platform: template
    name: "SmartEVSE Integration"
    optimistic: true
    turn_on_action:
      - globals.set:
          id: smartevse_integration
          value: "true"
      - globals.set:
          id: smartevse_error
          value: "5"
    turn_off_action:
      - globals.set:
          id: smartevse_integration
          value: "false"
      - globals.set:
          id: smartevse_error
          value: "5"
    icon: "mdi:ev-station"
    restore_mode: RESTORE_DEFAULT_ON

http_request:
  timeout: 1500ms
  verify_ssl: false
  esp8266_disable_ssl_support: true

interval:
  - interval: 2sec
    then:
      - if:
          condition:
            lambda: |-
              return (id(smartevse_integration) &&
                      !isnan(id(current_l1).state) &&
                      !isnan(id(current_l2).state) &&
                      !isnan(id(current_l3).state));
          then:
            - http_request.post:
                url: !lambda |-
                  float s1 = id(power_returned_l1).state > 0 ? -id(current_l1).state : id(current_l1).state;
                  float s2 = id(power_returned_l2).state > 0 ? -id(current_l2).state : id(current_l2).state;
                  float s3 = id(power_returned_l3).state > 0 ? -id(current_l3).state : id(current_l3).state;
                  static char url[128];
                  snprintf(url, sizeof(url),
                          "http://${smartevse_host}/currents?L1=%.0f&L2=%.0f&L3=%.0f",
                          s1 * 10, s2 * 10, s3 * 10);
                  return url;
                request_headers:
                  Content-Length: 0
                on_response:
                  then:
                    lambda: |-
                      if (id(smartevse_error) != 0) {
                        id(smartevse_error) = 0;
                      }
                on_error:
                  then:
                    lambda: |-
                      if (id(smartevse_error) < 5) {
                        id(smartevse_error) += 1;
                      }

[Andrehj]

@Phantone Je bespaart de lezers een heleboel onnodig scrollwerk als je dat lange codeblock even tussen quote-tags zet...

[Phantone]

Andrehj schreef op donderdag 19 maart 2026 @ 20:20:
@Phantone Je bespaart de lezers een heleboel onnodig scrollwerk als je dat lange codeblock even tussen quote-tags zet...

Thanks voor de tip, done

[jpiscaer]

Nog even terugkomend op EVCC en SmartEVSE.

Ik heb een simpele custom charger integratie geschreven voor de SmartEVSE om in EVCC alle features te kunnen benutten (specifiek 1p3p). Echter denk ik dat ik de network stack van de SmartEVSE overvraag, krijg regelmatig 'connection reset' op de SmartEVSE. Als community werkende custom code maken?

code:

## required attributes [type: custom]

status: # charger status (A: not connected, B: connected, C: charging)
  source: http
  uri: http://10.10.10.50/settings  # ← your SmartEVSE IP
  method: GET
  jq: '["A","B","C","C","E","F"][.evse.state_id]'
  # state_id: 0=A(ready) 1=B(connected) 2=C(charging) 3=D(vent) 4=E 5=F

enabled: # is charging enabled?
  source: http
  uri: http://10.10.10.50/settings
  method: GET
  jq: '.mode_id != 0'
  # mode_id 0=OFF → false, anything else → true

enable: # enable/disable charging
  source: http
  uri: http://10.10.10.50/settings
  method: POST
  headers:
    - Content-Type: application/json
  body: '{"mode": {{if .enable}}1{{else}}0{{end}}}'
  # mode: 0=OFF 1=Normal 2=Solar 3=Smart

maxcurrent: # set maximum charge current in A
  source: http
  uri: http://10.10.10.50/settings
  method: POST
  headers:
    - Content-Type: application/json
  body: '{"override_current": {{.maxcurrent}}}'
  # override_current in whole amps (same scale as current_max); 0 = no override


## optional attributes (read-only)

#icon: car

power: # charge power in W
  source: http
  uri: http://10.10.10.50/settings
  method: GET
  jq: .ev_meter.import_active_power

energy: # meter reading in kWh
  source: http
  uri: http://10.10.10.50/settings
  method: GET
  jq: '.ev_meter.total_wh / 1000'
  # total_wh is cumulative Wh → divide by 1000 for kWh

currents: # phase currents in A
  - source: http
    uri: http://10.10.10.50/settings
    method: GET
    jq: .ev_meter.currents.L1
  - source: http
    uri: http://10.10.10.50/settings
    method: GET
    jq: .ev_meter.currents.L2
  - source: http
    uri: http://10.10.10.50/settings
    method: GET
    jq: .ev_meter.currents.L3


## optional attributes (writeable)

phases1p3p: # switch phases (requires 'tos: true')
  source: http
  uri: http://10.10.10.50/settings
  method: POST
  headers:
    - Content-Type: application/json
  body: '{"enable_C2": {{.phases1p3p}}}'
  # evcc sends 1 or 3 → EnableC2: 1=ALWAYS_OFF (1-phase) 3=ALWAYS_ON (3-phase)
  # currently "Auto" — evcc overrides this when managing phases
tos: true

[thalx]

jpiscaer schreef op vrijdag 20 maart 2026 @ 11:45:
Nog even terugkomend op EVCC en SmartEVSE.

Ik heb een simpele custom charger integratie geschreven voor de SmartEVSE om in EVCC alle features te kunnen benutten (specifiek 1p3p). Echter denk ik dat ik de network stack van de SmartEVSE overvraag, krijg regelmatig 'connection reset' op de SmartEVSE. Als community werkende custom code maken?

[...]

Zo heb ik het eerder ook gedaan, maar dit overstuurt compleet de SmartEVSE, advies om het via MQTT te doen. HTTP polling is gewoon niet zo efficiënt sowieso.

[ Voor 4% gewijzigd door thalx op 20-03-2026 12:51 ]

[Phantone]

Ik weet niet hoe dat werkt in EVCC maar zoals ik het nu lees doet vrijwel elke sensor een call naar de settings endpoint. Als hij alles uit leest elke interval zijn dat er dus 7 requests.

Als je iets als dit doet zal het aantal request flink gereduceerd worden. Het cache attribuut zorgt er voor dat de GET request maar 1x per 5s aangeroepen wordt. Dit gaat niet op voor POST requests maar die poll je ook niet.

code:

# Definieer de GET-call één keer als anchor
_get_settings: &get_settings
  source: http
  uri: http://10.10.10.50/settings
  method: GET
  cache: 5s

## required attributes [type: custom]

status:
  <<: *get_settings
  jq: '["A","B","C","C","E","F"][.evse.state_id]'
  # state_id: 0=A(ready) 1=B(connected) 2=C(charging) 3=D(vent) 4=E 5=F

[jpiscaer]

thalx schreef op vrijdag 20 maart 2026 @ 12:50:
[...]

Zo heb ik het eerder ook gedaan, maar dit overstuurt compleet de SmartEVSE, advies om het via MQTT te doen. HTTP polling is gewoon niet zo efficiënt sowieso.

Heb je een config die via mqtt gaat toevallig?
waar Claude Code niet al goed voor is. Dit is een werkend stuk code, maar een sanity check zou fijn zijn :-)

code:

## required attributes [type: custom]

status: # charger status (A: not connected, B: connected, C: charging)
  source: mqtt
  topic: SmartEVSE-8088/EVChargePower
  timeout: 30s
  jq: 'if (. | tonumber) > 0 then "C" else "B" end'
  # ⚠ Cannot distinguish A (no vehicle) from B (connected/paused) via numeric MQTT.
  # Both return B when power=0. SmartEVSE prevents actual current without a vehicle.

enabled: # is charging enabled?
  source: mqtt
  topic: SmartEVSE-8088/EVChargePower
  timeout: 30s
  jq: '(. | tonumber) > 0'

enable: # enable/disable charging
  source: mqtt
  topic: SmartEVSE-8088/Set/Mode
  payload: '{{if .enable}}1{{else}}4{{end}}'
  # 1=Normal (evcc controls), 4=Pause (pilot alive, no current)
  # NOT 0=OFF — OFF stops pilot monitoring and breaks status detection

maxcurrent:
  source: mqtt
  topic: SmartEVSE-8088/Set/CurrentOverride
  payload: '{{ printf "%.0f" (mulf .maxcurrent 10) }}'

## optional attributes (read-only)

power: # charge power in W
  source: mqtt
  topic: SmartEVSE-8088/EVChargePower
  timeout: 30s
  # Direct watts — confirmed 11198W at 3×16A ✓

energy: # meter reading in kWh
  source: mqtt
  topic: SmartEVSE-8088/EVTotalEnergyCharged
  timeout: 30s
  scale: 0.001  # Wh → kWh

currents: # phase currents in A
  - source: mqtt
    topic: SmartEVSE-8088/EVCurrentL1
    timeout: 30s
    scale: 0.1  # confirmed deciamps: 160 = 16.0A ✓
  - source: mqtt
    topic: SmartEVSE-8088/EVCurrentL2
    timeout: 30s
    scale: 0.1  # 161 = 16.1A ✓
  - source: mqtt
    topic: SmartEVSE-8088/EVCurrentL3
    timeout: 30s
    scale: 0.1  # 161 = 16.1A ✓


## optional attributes (writeable)

phases1p3p: # switch phases (requires 'tos: true')
  source: mqtt
  topic: SmartEVSE-8088/Set/EnableC2
  payload: '{{.phases1p3p}}'
  # evcc sends 1 → ALWAYS_OFF (1-phase) / 3 → ALWAYS_ON (3-phase)
tos: true

[ Voor 76% gewijzigd door jpiscaer op 20-03-2026 14:34 ]

[mr_density]

Ben vandaag de smart evse aan het opbouwen. En heb een vraagje wat ik even wil checken of ik het goed begrijp:

Klopt het dat ik de kWh meter (eastron smd72d) moet aansluiten op de A en B punten waar de sensorbox ookal op aangesloten is?

[dingo35]

Ja het is een modBUS dus daar kunnen meerdere apparaten tegelijk op aangesloten worden...

[fcapri]

ik moet het hele topic hier nog lezen, maar ben dus ook begonnen aan mijn laadpaal.

nu laad ik mijn auto nog op met een VOLDT lader. deze kan je starten met een app op gsm en heeft 4 standen (8A-10A-13A en 16A).
ik wil dat er ook gecommuniceerd wordt met de zonnepanelen, dus kocht een mennekes laadstekker met 1 stand (16A). daar ga ik de CP signalen van onderbreken en mijn eigen PWM erop zetten met een ESP8266.
plaats genoeg om een ESP bij te steken


de relais, aansturing en voeding ga ik hergebruiken. mijn ESP komt er gewoon bovenop te zitten en zal dan de signalen uitsturen.
de STM32F ga ik niet gebruiken. weet niet of ik die eraf ga slopen, of gewoon de signaal draden onderbreken




mijn ESP zal een webserver krijgen zodat ik bv in de winter geprogrammeerd kan opladen snachts.
maar als er overdag dus injectie is, dat die ook kan bijladen.
ik vermoed dat ik met een schuifbalk ga bepalen hoeveel er geladen moet worden.
bv mijn auto is op 50% en ik wil er 20kW bijsteken vandaag.
als er door de zon bv 3uur lang met 16A is geladen en 1uur met 10A dan is er dus al 13kWh geladen. dan zorg ik ervoor dat die snachts nog 7kWh bijlaad (2uur lang met 16A bijvoorbeeld, of 4uur lang met 8A).
is overdag de grens bereikt, moet die niks meer doen.

ik wil dan ook dynamisch kunnen regelen. bv elke 5min herinstellen 6-16A afhankelijk van de injectie (of zelf uitschakelen als er netverbruik is).

momenteel eerst nog de voeding aan het reserve engineeren, daarna de aansturing van de relais uitzoeken en eens dat allemaal werkt, ga ik met bezig houden met de PWM op de CP pin en de auto detectie.
dan rest enkel nog de software schrijven

[ Voor 18% gewijzigd door fcapri op 20-03-2026 16:58 ]

[dingo35]

Lief dagboek?