Evcc slim laden met de zon en dynamische tarieven

[Allewijn]

JanHenk schreef op maandag 30 maart 2026 @ 11:34:
TWC3 wordt helemaal niet gebruikt voor aansturing en dat is inderdaad een vreemde eend in de bijt.
...
....
Nog mooier, maar uiteraard kostbaar, is gewoon een andere laadpaal

Je raakt hier idd wel de essentie van waarom ik (als HA en EVCC noob) nu begonnen ben met het verkennen van 'of/hoe goed' mijn Tesla voertuig samen met mijn TWC3 lader via evcc kan voorzien in mijn toekomstige behoeften (zonneladen, load balancing, etc vanaf 2027).

Want ik ben héél blij met de TWC3 qua looks en gemak (met oa het knopje om te unlocken bovenop de stekker), máár ik wil nu ook een paal met MID-> want ERE-certificaten.

Als evcc volledig goed voor mij gaat werken, dan zou ik switchen naar de (relatief goedkope) nieuwe TWC3 met geïntegreerde mid kWh meter.

Als het niet volledig gaat werken (wat echt ook aan mijn kennis/kunnen op dit vlak kan liggen merk ik nu), dan ga ik straks toch voor een paal die dit alles solistisch kan (zoals een Peblar Business).
Ook het voordeel van 1p3p faseschakeling ga ik straks echt willen om het maximale qua pv-laden te halen denk ik. Dat gemis noemt @nMad ook duidelijk.

Maar ik geef nog niet op.
De TeslaBleHttpProxy wordt nu al door meerderen aangegeven (dank daar voor!) als beter alternatief tov betaalde proxy via TeslaMate. Ook dat weet ik nog niet helemaal in te stellen, maar misschien eerst maar eens de hardwarekopen en dan handleidingen volgen en/of weer hulp vragen...

Óf de door @nMad genoemde 'optie 3': EVCC met Tesla Home Assistant charger (als je al HA hebt),
Dat kan ik ook verkennen, want Home Assistant draait ook op mijn Synology (alleen deed er nog niks mee).

[ Voor 11% gewijzigd door Allewijn op 30-03-2026 13:32 ]

[JanHenk]

@Allewijn Je zou, bijvoorbeeld, een Peblar Business met socket kunnen nemen en dan een losse laadkabel, deze locken in de Peblar (zodat ie niet meegenomen kan worden maar vast blijft zitten). Je hebt losse kabels met dat Tesla-knopje. Dus dan heb je die functionaliteit nog steeds.

Persoonlijk zou ik het eerst proberen met de Tesla-BLE proxy i.c.m. evcc. Als je daar de brui aan wil geven, is een andere laadpaal nog altijd een optie als ik het zo hoor.

Overigens is evcc draaien óók een meerwaarde als de laadpaal zelf al wat software heeft voor bijv. zonneladen. Met evcc zijn de mogelijkheden nog veel groter

[CBA]

Allewijn schreef op maandag 30 maart 2026 @ 10:09:
@CBA Wat is jouw ervaring/kijkende naar mijn probleem? Hoe heb jij het werkende op jouw Tesla?

Zelf ben ik nog niet zover, mijn laadpaal is toegevoegd (easee) de loadbalancer (equalizer) van easee kan ik denk ik niet toevoegen. Alsook mijn inverter van Huawei moet ik eerst nog de modbus instelling kunnen aanpassen voor ik verder kan.

Aangezien alles nu via easee loopt, laden & loadbalancing is er geen haast bij en probeer ik stapje per stapje uit te zoeken.

[djiedjee]

Ik heb vandaag mijn Marstek Thuisbatterij via modbus in Home assistant beschikbaar en heb hem ook als "home assistant" batterij in EVCC ingesteld.
Dat lijkt allemaal goed te staan en daar kan ik overdag mee aan de slag als de zon schijnt.

Wel vroeg ik me af: ik definieer in EVCC met sensors om de batterij uit te lezen en kan prio in vergelijking met de laadpaal instellen.
Kan ik ook "stand alone" de batterij op basis van de beschikbare dynamische tarieven laten laden/ontladen? (effectief dus uitzetten of modus NOM kiezen)

[JanHenk]

@djiedjee Als ik me niet vergis, maar ik heb het zo gauw niet nagekeken, zit de "Active battery control" niet in de "Home Assistant Battery" template. Dat moet eigenlijk nog even toegevoegd worden....

Je kan de Marstek ook rechtstreeks in evcc plaatsen, dus zonder de omweg. Dan heb je wel active battery control.

[r2504]

djiedjee schreef op maandag 30 maart 2026 @ 20:41:
Ik heb vandaag mijn Marstek Thuisbatterij via modbus in Home assistant beschikbaar en heb hem ook als "home assistant" batterij in EVCC ingesteld.

Bizar want de MT Venus E 3.0 kan slechts één modbus connectie aan... dus ofwel een integratie (via modbus) ofwel evcc... maar beide kan niet. Ben je zeker dat je HA integratie modbus gebruikt ?

[Mirabis]

r2504 schreef op maandag 30 maart 2026 @ 22:46:
[...]


Bizar want de MT Venus E 3.0 kan slechts één modbus connectie aan... dus ofwel een integratie (via modbus) ofwel evcc... maar beide kan niet. Ben je zeker dat je HA integratie modbus gebruikt ?

Het is slechts één modbus connectie in de setup zoals omschreven hierboven. HA <-> Batterij = modbus. EVCC <-> HA = homeassistant api/websockets. De batterij entities worden gewoon uitgelezen door EVCC.

[JanHenk]

Ah, vandaar. Dan zou ik de modbus proxy van evcc gebruiken om hem daar door te koppelen naar Home Assistant

[C.QL]

HyperBart schreef op zondag 22 maart 2026 @ 11:27:
[...]


Ik zie heel veel SMA producten. Is alles maximaal inzetbaar? Is er geen beperking op SMA niveau geconfigureerd?

Post eens een log in situ (dus niet screenshots van een ander moment).

Verdorie, je had gelijk. Ineens viel mijn frank dat ik er ooit een limiet van 22 A op had gezet. Weggenomen uit de SMA configuratie van de lader, en opgelost. Bedankt voor de tip en zo mijn geheugen op te frissen!

[djiedjee]

Ik heb hem ingesteld zoals @Mirabis beschrijft.

@JanHenk
Van modbus proxy had ik nog niet gehoord, dat ziet er ook bruikbaar uit. En dan heb ik meer sturing vanuit EVCC begrijp ik.

Dat ga ik deze week ook testen!

[[RNMC] Viper]

RvV schreef op maandag 30 maart 2026 @ 11:32:
Ik gebruik deze voor de communicatie met de auto ipv Teslamate: https://github.com/wimaha/TeslaBleHttpProxy
Die is tenminste gratis icm een rpi zero.

of deze als app in Home Assistant https://github.com/Lenart12/TeslaBle2Mqtt-addon

[ Voor 61% gewijzigd door [RNMC] Viper op 31-03-2026 16:47 ]

[Get!em]

djiedjee schreef op dinsdag 31 maart 2026 @ 09:29:
Ik heb hem ingesteld zoals @Mirabis beschrijft.

@JanHenk
Van modbus proxy had ik nog niet gehoord, dat ziet er ook bruikbaar uit. En dan heb ik meer sturing vanuit EVCC begrijp ik.

Dat ga ik deze week ook testen!

Modbus proxy is een addon in EVCC, overigens ook addon/app in HA verkrijgbaar. GitHub - Akulatraxas/ha-modbusproxy: Hassio Addon packaging modus-proxy · GitHub


Zie de modbus proxy vooral als een soort splitter of netwerkswitch. Het helpt bij devices die wel modbus hebben, maar slechts 1 client toestaan.

Dus

Device --> HA
Device--> EVCC
Werkt niet tegelijkertijd.

Maar

Device --> Modbusproxy
Modbusproxy --> HA
Modbusproxy --> EVCC
Werkt wel tegelijkertijd.

Je maakt in de modbusproxy een configuratie aan per device die je wilt ontsluiten. Zorg ervoor dat ze niet op dezelfde poorten komen.

Ik gebruik het oa voor de SolarEdge modbus, die ook slechts 1 client toestaat.

[Guillome]

Bah, mijn peugeot was goed gekoppeld in evcc. Maar was nu een token fout. En als ik hem verwijder en opnieuw toevoeg zegt ie altijd: token expired... is dat door de zomertijd? Bug bij Peugeot?

Edit: de peugeot app logt ook niet meer in..

Edit 2: werkt weer...

[ Voor 15% gewijzigd door Guillome op 31-03-2026 22:32 ]

[Get!em]

Guillome schreef op dinsdag 31 maart 2026 @ 17:35:
Bah, mijn peugeot was goed gekoppeld in evcc. Maar was nu een token fout. En als ik hem verwijder en opnieuw toevoeg zegt ie altijd: token expired... is dat door de zomertijd? Bug bij Peugeot?

Edit: de peugeot app logt ook niet meer in..

De achilleshiel van al die integraties met cloud backends. De inlogsystemen veranderen, cooky, token en captcha's erbij.

Hyundai, Kia, Volvo ook allemaal al.

Dan is zo'n BLE tesla lokale optie zo gek nog niet. indien die werkt.

[jaapzb]

Get!em schreef op dinsdag 31 maart 2026 @ 17:53:
[...]

De achilleshiel van al die integraties met cloud backends. De inlogsystemen veranderen, cooky, token en captcha's erbij.

Hyundai, Kia, Volvo ook allemaal al.

Dan is zo'n BLE tesla lokale optie zo gek nog niet. indien die werkt.

Ik begrijp niet dat er in het laadprotocol niet gewoon is opgenomen om de SoC van de auto over de laadkabel te communiceren met de laadpaal, zodat je die gewoon van de laadpaal af kan lezen. Een andere reden om een integratie met die externe auto api's te hebben is er eigenlijk niet.

Of zal het wel in het protocol zitten, maar simpelweg niet door de laders uitleesbaar gemaakt worden?

[Get!em]

jaapzb schreef op dinsdag 31 maart 2026 @ 18:50:
[...]

Ik begrijp niet dat er in het laadprotocol niet gewoon is opgenomen om de SoC van de auto over de laadkabel te communiceren met de laadpaal, zodat je die gewoon van de laadpaal af kan lezen. Een andere reden om een integratie met die externe auto api's te hebben is er eigenlijk niet.

Of zal het wel in het protocol zitten, maar simpelweg niet door de laders uitleesbaar gemaakt worden?

Nee, bij AC niet in protocol. Bij DC laden wel.

[HyperBart]

jaapzb schreef op dinsdag 31 maart 2026 @ 18:50:
[...]

Ik begrijp niet dat er in het laadprotocol niet gewoon is opgenomen om de SoC van de auto over de laadkabel te communiceren met de laadpaal, zodat je die gewoon van de laadpaal af kan lezen. Een andere reden om een integratie met die externe auto api's te hebben is er eigenlijk niet.

Of zal het wel in het protocol zitten, maar simpelweg niet door de laders uitleesbaar gemaakt worden?

Get!em schreef op dinsdag 31 maart 2026 @ 19:15:
[...]

Nee, bij AC niet in protocol. Bij DC laden wel.

Bij AC zit het ook maar dat zit in ISO15118.

Alfen ondersteunt ISO15118 bv in hun laatste line-up van EVSE’s.

[ Voor 47% gewijzigd door HyperBart op 31-03-2026 19:58 ]

[JanHenk]

Klopt, technisch hebben de laadpalen daarvoor een powerline communicatiemodule nodig, dus het is niet alleen slechts een standaard maar ook benodigde hardware in de paal.

Het zou er dus in de toekomst wel een keer aan moeten komen. Ik heb nog geen praktische toepassingen gezien, maar de Peblar Business die ik op kantoor heb zou er ook voorbereid voor moeten zijn. Dus ben benieuwd op welke wijze we daar een keer iets mee zouden kunnen doen. Zou top zijn om eens van die cloud afhankelijkheid af te komen.

[roel00]

HyperBart schreef op woensdag 25 maart 2026 @ 15:37:
[...]

Laten we wel even eerlijk wezen, HA en evcc hebben eigenlijk totaal niks met elkaar te maken. HA is op een gegeven moment evcc gaan integreren maar au fond heb je daar niks mee te doen als je met evcc aan de slag wil. Door met HA te werken zit je vaak ook met een nesting van filesystems of zoeken naar configfiles. Ik zou daar dus abstractie van nemen en het rechtstreeks draaien. Kant en klaar kan het zelfs met een rPi:

Die redenatie kan ik niet goed volgen. EVCC maakt gebruik van je p1 meter, pv data, je thuisbatterij en ev data. Een platform als HA maakt het als huisautomatiseringsplatform incl energiemanagement relatief eenvoudig voor gebruikers om dit soort gegevens uit te wisselen met evcc. Een app zoals EVCC past in mijn beleving daarmee uitstekend binnen het gebruiksdoel van HA. En HA OS draait prima op een rpi en is voor de meeste gebruikers eenvoudig te beheren. Geneste filesystems heb je helemaal geen last van en hoor je ook niet op die manier te doen. Gewoon je evcc.yaml toevoegen aan de directory met andere yaml config files die je met de ingebouwde file editor kunt bewerken. Dus juist voor een belangrijke energie app zoals evcc, zou ik de meeste gebruikers aanraden om dit met HA te doen, i.p.v. het noeste handwerk.

[HyperBart]

Een stuk correct maar HA is een nodeloze complexiteit voor de meeste mensen die hier in eerste instantie gewoon met evcc aan de slag willen. Goed bedacht om HA adoptie te verhogen dat we evcc dan als opstapje gebruiken maar in de essentie van evcc (waar de meeste hier naar op zoek zijn) absoluut niet nodig.

HA als schil in de software hoedanigheid is een veel te bloated oplossing voor mensen die gewoon met evcc simpel aan de slag willen. Je kan ondertussen ook kant en klaar een rPi draaien zoals je zelf ook aangeeft maar dan lekker eenvoudig met een image van evcc zelf, als dat noest handwerk is dan bel je beter een installateur of laadpaal met eigen HEMS.

Ik heb nu laatst weer een kennis geholpen "waar staat je YAML?" Ze weten het niet.

Als je de vragen ziet die hier voorbij komen met de adoptie van evcc dan vind ik het compleet van de zotte dat je daar nog eens de complexiteit van HA bij legt, want dat gaat alle kanten dan op. Hou het gewoon simpel en eenvoudig, zorg dat ze dat self hosted onder de knie hebben ipv onduidelijkheid bij beginners te zaaien door HA en evcc op een hoopje te smijten.

[dirixmjm]

HyperBart schreef op woensdag 1 april 2026 @ 11:48:
de adoptie van evcc dan vind ik het compleet van de zotte dat je daar nog eens de complexiteit van HA bij legt, want dat gaat alle kanten dan op. Hou het gewoon simpel en eenvoudig, zorg dat ze dat self hosted onder de knie hebben ipv onduidelijkheid bij beginners te zaaien door HA en evcc op een hoopje te smijten.

Is het doel van dit topic enkel om nieuwe gebruikers van EVCC te ondersteunen, of is er ook ruimte voor power-users?

[HyperBart]

Het doel van dit topic is om gebruikers van evcc te ondersteunen of ervaringen te bespreken, maar de adviezen voor die powerusers zijn anders dan wat de gebruikersgroep die hier voorheen besproken werd.

Ik verwacht ook van een poweruser dat die prima zelf dat onderscheid kan maken tussen HA en evcc en de complexiteit. Dus die ruimte is er zeker, als je je poweruser kan noemen natuurlijk.

[Guillome]

Uch, de peugeot klapt er elke x dagen uit met Token expired. Ik lees dat veel meer merken hier last van hebben. Opel, Volvo en ook Tesla. Dat is wel heel irritant..

[Guillome]

Ik heb vandaag mijn laadpaal gekregen! De Peblar Business. De eerste was een DOR (kapot) Gelukkig hadden ze meer meegenomen.

Nu probeer ik via deze converter mijn Growatt 4200tl xe aan te sluiten:
https://www.kiwi-electron...b-to-rs485-converter-9944
Maar dat lukt niet. Hij verstuurt wel data (TXD) maar krijgt niets terug (RXD).
Hij was eerst aangesloten met stroomkabel, maar dat was niet goed volgens ai (en werkte ook niet).
Nu met een twisted pair uit een utp kabel (blauw en blauwwit). Die zijn wel weer heel dun. Maar werkt dus ook niet.
Pin 3 op A en Pin 4 op B gedaan. En andersom.
Growatt luistert naar bus/adres 1. De shine wifi usb adapter zit er ook nog in maar zou niet een probleem moeten zijn.
Heb de Growatt ook herstart.

Iemand tips waar het aan zou kunnen liggen?

[PisPix]

Sinds kort gestart met EVCC (als container op Synology) in trial mode om te kijken of ik hiermee het wat complexere laadschema kan uitvoeren.

Daarnaast draai ik Home Assistant en heb ik die twee gekoppeld. Hieronder de hardware schets:
2x EV (beide worden correct herkend door EVCC via HA middels diverse helpers)
1x Deye 12k met 48 kWh batterij (via Balans Energie, dus niet in eigen beheer)
1x Marstek Venus E v2.0 5 kWh welke ik alleen gebruik om het laden/ontladen wanneer de Deye doet doet ivm gunstige tarieven. Of om de eventuele PV opbrengsten te boosten zodat de auto gaat laden op 6A.
2x PV systemen welke gekoppeld zijn aan HA.
1x HW P1 meter
1x Peblar Business laadpaal (gekoppeld aan de HW P1 voor de huislimiet, niet de PV overschot).

Ik heb een custom template sensor gemaakt die de PV overschot berekening maakt en deze op 0 zet wanneer de Deye gaat ontladen (ivm tarieven onbalans). Dit monitor ik al een tijdje en deze sensor geeft de juiste waardes weer (positieve waarde bij PV overschot, 0 bij alle andere situaties). In EVCC heb ik deze sensor geconfigureerd als de PV opbrengst sensor (niet als extra sensor bij de laadpaal).

In EVCC kloppen alle waardes die ik zie van de batterijen/auto/pv/enz. Maar toch werkt het niet zoals verwacht. De fase omschakeling staat op automatisch, maar als in EVCC de stand op min+pv staat gaat de auto met 1.4 kWh laden terwijl er nog 5kWh overproductie is. Hij lijkt niet op te schalen op 1 fase, maar ook niet om te schakelen naar 3 fases.
De Peblar heeft de laatst beschikbare firmware (1.9.0+1+WL-1).
De Peblar staat op "standaard" ingesteld zodat EVCC zelf de limiet regeling kan doen op basis van PV overschot.
Naast het niet correct willen laden heb ik de uitdaging dat Balans Energie vraagt je auto niet te laden tussen 07:00-09:00 en 17:00-23:00. Daarvoor heb ik in HA een automation lopen die op deze tijdstippen de binary_sensor.evcc_peblar_enabled op aan/uit zet.

Ik lees her en der veel over de evcc.yaml maar zie geen mogelijkheid deze te editten/bekijken. In de logs lees ik geen foutmeldingen, ik begrijp niet goed waarom de Peblar niet correct aangestuurd lijkt te worden door EVCC qua PV en fase schakeling.

[jaapzb]

PisPix schreef op vrijdag 3 april 2026 @ 19:17:
Sinds kort gestart met EVCC (als container op Synology) in trial mode om te kijken of ik hiermee het wat complexere laadschema kan uitvoeren.

Daarnaast draai ik Home Assistant en heb ik die twee gekoppeld. Hieronder de hardware schets:
2x EV (beide worden correct herkend door EVCC via HA middels diverse helpers)
1x Deye 12k met 48 kWh batterij (via Balans Energie, dus niet in eigen beheer)
1x Marstek Venus E v2.0 5 kWh welke ik alleen gebruik om het laden/ontladen wanneer de Deye doet doet ivm gunstige tarieven. Of om de eventuele PV opbrengsten te boosten zodat de auto gaat laden op 6A.
2x PV systemen welke gekoppeld zijn aan HA.
1x HW P1 meter
1x Peblar Business laadpaal (gekoppeld aan de HW P1 voor de huislimiet, niet de PV overschot).

Ik heb een custom template sensor gemaakt die de PV overschot berekening maakt en deze op 0 zet wanneer de Deye gaat ontladen (ivm tarieven onbalans). Dit monitor ik al een tijdje en deze sensor geeft de juiste waardes weer (positieve waarde bij PV overschot, 0 bij alle andere situaties). In EVCC heb ik deze sensor geconfigureerd als de PV opbrengst sensor (niet als extra sensor bij de laadpaal).

In EVCC kloppen alle waardes die ik zie van de batterijen/auto/pv/enz. Maar toch werkt het niet zoals verwacht. De fase omschakeling staat op automatisch, maar als in EVCC de stand op min+pv staat gaat de auto met 1.4 kWh laden terwijl er nog 5kWh overproductie is. Hij lijkt niet op te schalen op 1 fase, maar ook niet om te schakelen naar 3 fases.
De Peblar heeft de laatst beschikbare firmware (1.9.0+1+WL-1).
De Peblar staat op "standaard" ingesteld zodat EVCC zelf de limiet regeling kan doen op basis van PV overschot.
Naast het niet correct willen laden heb ik de uitdaging dat Balans Energie vraagt je auto niet te laden tussen 07:00-09:00 en 17:00-23:00. Daarvoor heb ik in HA een automation lopen die op deze tijdstippen de binary_sensor.evcc_peblar_enabled op aan/uit zet.

Ik lees her en der veel over de evcc.yaml maar zie geen mogelijkheid deze te editten/bekijken. In de logs lees ik geen foutmeldingen, ik begrijp niet goed waarom de Peblar niet correct aangestuurd lijkt te worden door EVCC qua PV en fase schakeling.

Hoe bereken je dat pv overschot? Heb je in EVCC ook je grid meter geconfigureerd? Misschien dat EVCC nog eens jouw berekende overschot van de grid meter afhaalt, waardoor je volgens EVCC dus eigenlijk nooit overschot hebt?

[Crusader]

PisPix schreef op vrijdag 3 april 2026 @ 19:17:
Sinds kort gestart met EVCC (als container op Synology) in trial mode om te kijken of ik hiermee het wat complexere laadschema kan uitvoeren.

Daarnaast draai ik Home Assistant en heb ik die twee gekoppeld. Hieronder de hardware schets:
2x EV (beide worden correct herkend door EVCC via HA middels diverse helpers)
1x Deye 12k met 48 kWh batterij (via Balans Energie, dus niet in eigen beheer)
1x Marstek Venus E v2.0 5 kWh welke ik alleen gebruik om het laden/ontladen wanneer de Deye doet doet ivm gunstige tarieven. Of om de eventuele PV opbrengsten te boosten zodat de auto gaat laden op 6A.
2x PV systemen welke gekoppeld zijn aan HA.
1x HW P1 meter
1x Peblar Business laadpaal (gekoppeld aan de HW P1 voor de huislimiet, niet de PV overschot).

Ik heb een custom template sensor gemaakt die de PV overschot berekening maakt en deze op 0 zet wanneer de Deye gaat ontladen (ivm tarieven onbalans). Dit monitor ik al een tijdje en deze sensor geeft de juiste waardes weer (positieve waarde bij PV overschot, 0 bij alle andere situaties). In EVCC heb ik deze sensor geconfigureerd als de PV opbrengst sensor (niet als extra sensor bij de laadpaal).

In EVCC kloppen alle waardes die ik zie van de batterijen/auto/pv/enz. Maar toch werkt het niet zoals verwacht. De fase omschakeling staat op automatisch, maar als in EVCC de stand op min+pv staat gaat de auto met 1.4 kWh laden terwijl er nog 5kWh overproductie is. Hij lijkt niet op te schalen op 1 fase, maar ook niet om te schakelen naar 3 fases.
De Peblar heeft de laatst beschikbare firmware (1.9.0+1+WL-1).
De Peblar staat op "standaard" ingesteld zodat EVCC zelf de limiet regeling kan doen op basis van PV overschot.
Naast het niet correct willen laden heb ik de uitdaging dat Balans Energie vraagt je auto niet te laden tussen 07:00-09:00 en 17:00-23:00. Daarvoor heb ik in HA een automation lopen die op deze tijdstippen de binary_sensor.evcc_peblar_enabled op aan/uit zet.

Ik lees her en der veel over de evcc.yaml maar zie geen mogelijkheid deze te editten/bekijken. In de logs lees ik geen foutmeldingen, ik begrijp niet goed waarom de Peblar niet correct aangestuurd lijkt te worden door EVCC qua PV en fase schakeling.

Ik heb dezelfde setup, EVCC in Synology container en Peblar Business.
Bij mij gaat de aansturing prima en schakelt ook netjes tussen 1- en 3-fasen.
Heb je wel Modbus API ingeschakeld op de Peblar, zodat EVCC via die weg de aansturing kan doen?

Mij viel ook op dat ik geen EVCC yaml heb, alles gaat via de gui en configuratie wordt in een evcc.db database opgeslagen. Wel jammer dat ik daardoor sommige fine tuning of troubleshooting niet kan uitvoeren.

[Kammika]

Crusader schreef op zaterdag 4 april 2026 @ 09:38:
[...]

Ik heb dezelfde setup, EVCC in Synology container en Peblar Business.
Bij mij gaat de aansturing prima en schakelt ook netjes tussen 1- en 3-fasen.
Heb je wel Modbus API ingeschakeld op de Peblar, zodat EVCC via die weg de aansturing kan doen?

Mij viel ook op dat ik geen EVCC yaml heb, alles gaat via de gui en configuratie wordt in een evcc.db database opgeslagen. Wel jammer dat ik daardoor sommige fine tuning of troubleshooting niet kan uitvoeren.

Volgens mij zit tegenwoordig alle yaml functionaliteit ook in de GUI. Wat mis je dan nog precies? (ik gebruik overigens nog wel de YAML, maar dat is puur omdat ik het fijn vind dat ik een backupje van de config kan maken. Dat backupje maken en kunnen restoren van de config mis ik nog wel in de GUI. Dat is het enige wat mij nog tegen houdt die GUI te gebruiken)

[Guillome]

Is toch een sql database in een .db file?

[Kammika]

Guillome schreef op zaterdag 4 april 2026 @ 09:55:
Is toch een sql database in een .db file?

Ja klopt, maar als je daar een backup van terugzet ben je dus ook al je historie qua laadsessies kwijt tot het moment van backup. Ik zou dus enkel de config willen kunnen backuppen/restoren los van de rest van inhoud van de database.

[Guillome]

Ik denk als je sqllite installeert en de juiste tabellen .. nouja, het kan wel maar is inderdaad wel echt wat meer werk

[Get!em]

Kammika schreef op zaterdag 4 april 2026 @ 09:58:
[...]

Ja klopt, maar als je daar een backup van terugzet ben je dus ook al je historie qua laadsessies kwijt tot het moment van backup. Ik zou dus enkel de config willen kunnen backuppen/restoren los van de rest van inhoud van de database.

Er is in de GUI wel een backup knop. (Helemaal onderaan configureren pagina) Die download de hele database. Alleen de config is niet een optie inderdaad. Is dat al een feature request?

[Guillome]

Ik krijg helaas mijn RS485 koppeling niet werkend. 3 verschillende kabels geprobeerd

[PisPix]

jaapzb schreef op vrijdag 3 april 2026 @ 23:56:
[...]

Hoe bereken je dat pv overschot? Heb je in EVCC ook je grid meter geconfigureerd? Misschien dat EVCC nog eens jouw berekende overschot van de grid meter afhaalt, waardoor je volgens EVCC dus eigenlijk nooit overschot hebt?

Ik bereken het overschot aan de hand van de Deye laad power. Zodra er stroom die accu inloopt, is dat overschot. Maar alleen in het geval dat de Deye zelf niet van het net staat te laden.

Ik heb even wat zaken uit EVCC gehaald om het minder complex te maken. Dus nu zit alleen de Peblar erin, de twee autos, de HA koppeling voor de overschot sensor. Maar dan ook gaat de lader niet opschalen terwijl er genoeg overschot is.
De Peblar heeft alleen de HW P1 voor de huislimit gekoppeld aan zich, geen PV sensor dus voor de Peblar zelf gezien is het een dom ding die aan/uit kan. EVCC brengt de magie mee die op basis van overschot moet op/afschalen. Ik heb geen grid meter erin zitten nu om dat uit te sluiten.



In dit plaatje zou ik verwachten dat de auto op 2,5 kWh zou gaan laden. Maar je ziet de teller rechtsonder al aflopen omdat er niet genoeg overschot zou zijn. Maar dat is er dus wel.

@Crusader Yes, modbus api staat open maar ik zie ook de rest api open staan. Ik gok dat Home Assistant via Modbus loopt en EVCC via Rest API? Zit hier wellicht 't probleem mbt aansturing?

[ Voor 11% gewijzigd door PisPix op 04-04-2026 11:05 ]

[Crusader]

Kammika schreef op zaterdag 4 april 2026 @ 09:54:
[...]

Volgens mij zit tegenwoordig alle yaml functionaliteit ook in de GUI. Wat mis je dan nog precies? (ik gebruik overigens nog wel de YAML, maar dat is puur omdat ik het fijn vind dat ik een backupje van de config kan maken. Dat backupje maken en kunnen restoren van de config mis ik nog wel in de GUI. Dat is het enige wat mij nog tegen houdt die GUI te gebruiken)

Op dit moment mis ik niets, maar tijdens installatie & configuratie kreeg ik via Google en ChatGPT allerlei trucs om toe te passen, maar die hadden het allemaal over aanpassingen in de evcc.yaml, die ik dus niet heb. Dan ben je gewoon langer bezig om dingen uit te vinden.

[Kammika]

PisPix schreef op zaterdag 4 april 2026 @ 10:55:
[...]


Ik bereken het overschot aan de hand van de Deye laad power. Zodra er stroom die accu inloopt, is dat overschot. Maar alleen in het geval dat de Deye zelf niet van het net staat te laden.

Ik heb even wat zaken uit EVCC gehaald om het minder complex te maken. Dus nu zit alleen de Peblar erin, de twee autos, de HA koppeling voor de overschot sensor. Maar dan ook gaat de lader niet opschalen terwijl er genoeg overschot is.
De Peblar heeft alleen de HW P1 voor de huislimit gekoppeld aan zich, geen PV sensor dus voor de Peblar zelf gezien is het een dom ding die aan/uit kan. EVCC brengt de magie mee die op basis van overschot moet op/afschalen. Ik heb geen grid meter erin zitten nu om dat uit te sluiten.

[Afbeelding]

In dit plaatje zou ik verwachten dat de auto op 2,5 kWh zou gaan laden. Maar je ziet de teller rechtsonder al aflopen omdat er niet genoeg overschot zou zijn. Maar dat is er dus wel.

@Crusader Yes, modbus api staat open maar ik zie ook de rest api open staan. Ik gok dat Home Assistant via Modbus loopt en EVCC via Rest API? Zit hier wellicht 't probleem mbt aansturing?

Je moet het überhaupt niet 2 stukken software hetzelfde apparaat laten aansturen. Dat is vragen om moeilijkheden

Stuur dus of via evcc aan en haal dat weer binnen in ha via de hacs integratie van evcc

Of configureer in ha en lees dan in evcc weer via ha (met dus de home Assistant templates)

[Crusader]

PisPix schreef op zaterdag 4 april 2026 @ 10:55:
[...]

@Crusader Yes, modbus api staat open maar ik zie ook de rest api open staan. Ik gok dat Home Assistant via Modbus loopt en EVCC via Rest API? Zit hier wellicht 't probleem mbt aansturing?

Precies andersom (bij mij in elk geval), EVCC gebruikt de Modbus en Home Assistant de API.

Overigens wordt bij mij het overschot door EVCC berekend via Modbus TCP naar de SolarEdge omvormer en de gegevens uit de HomeWizard P1 meter.

[ Voor 15% gewijzigd door Crusader op 04-04-2026 11:12 ]

[Kammika]

Crusader schreef op zaterdag 4 april 2026 @ 11:10:
[...]
Overigens wordt bij mij het overschot door EVCC berekend via Modbus TCP naar de SolarEdge omvormer en de gegevens uit de HomeWizard P1 meter.

klopt niet wat hier staat. EVCC rekent niet met de zonnepanel opbrengst voor overschot, houdt dan enkel de P1 meter aan wat die aan overschot opgeeft. Dat je de de zonnepanel ook kunt configueren is enkel voor een leuke weergave in je UI zodat je beter je echte verbruik kan zien, maar doet niets met de interne werking van EVCC vwb aansturen laadpaal

EVCC gebruikt overigens ook de gegevens van je thuisbatterij: heb zelf ook een marstek, die wordt niet actief aangestuurd, maar wel indirect als je marstek om NOM staat (staat die op de NOM modus? Anders raakt EVCC ook in de war als je die geconfigureerd hebt) en dan te spelen met hoe hard de auto aan het laden is.

[PisPix]

Crusader schreef op zaterdag 4 april 2026 @ 11:10:
[...]

Precies andersom (bij mij in elk geval), EVCC gebruikt de Modbus en Home Assistant de API.

Overigens wordt bij mij het overschot door EVCC berekend via Modbus TCP naar de SolarEdge omvormer en de gegevens uit de HomeWizard P1 meter.

Ah, ik zie dat HA de Rest API gebruikt en Modbus wordt via EVCC gebruikt, dus dat is hetzelfde.

@Kammika Ik heb de Rest API nu op "alleen lezen" gezet om eventuele verstoring af te vangen.
Ik had hiervoor een Zappi (met CT klemmen) die vrij realtime de overproductie de auto in liet lopen. Ik heb 't idee dat EVCC veel langzamer schakelt. En ik heb hem ook nog niet zien opschakelen naar 3 fases. Het is nu vrij wisselend weer qua opbrengst, de ene keer 2 kWh, dan weer 6 kWh. Mogelijk heeft dat ermee te maken?
De Marstek staat op "manual" en schakel ik alleen via HA automations. NOM werkt niet meer met een Balans Energie batterij, dan ga je tegen de stroom in werken.

[ Voor 8% gewijzigd door PisPix op 04-04-2026 11:27 ]

[Kammika]

Crusader schreef op zaterdag 4 april 2026 @ 11:06:
[...]

Op dit moment mis ik niets, maar tijdens installatie & configuratie kreeg ik via Google en ChatGPT allerlei trucs om toe te passen, maar die hadden het allemaal over aanpassingen in de evcc.yaml, die ik dus niet heb. Dan ben je gewoon langer bezig om dingen uit te vinden.

als die yaml configuraties kun je ook in de UI invoeren voor zover ik weet. Ik ben teruggegaan naar de yaml file, maar heb nog geen enkele yaml ontdekt die ik niet ook in de GUI kon invoeren..

[Kammika]

PisPix schreef op zaterdag 4 april 2026 @ 11:26:
[...]

Ah, ik zie dat HA de Rest API gebruikt en Modbus wordt via EVCC gebruikt, dus dat is hetzelfde.

@Kammika Ik heb de Rest API nu op "alleen lezen" gezet om eventuele verstoring af te vangen.
Ik had hiervoor een Zappi (met CT klemmen) die vrij realtime de overproductie de auto in liet lopen. Ik heb 't idee dat EVCC veel langzamer schakelt. En ik heb hem ook nog niet zien opschakelen naar 3 fases. Het is nu vrij wisselend weer qua opbrengst, de ene keer 2 kWh, dan weer 6 kWh. Mogelijk heeft dat ermee te maken?

dat kan want er zitten timers waarin die op en down schakelt om te snel schakelen te voorkomen. Die kun je zelf ook configureren overigens. MAar als dat het is, moet je die timer ook in de UI wel kunnen zien. Die geeft nl weer hoe lang het nog duurt voordat die omhoog of omlaag schakelt...

Sowieso zit er een interval in de configuratie. Die kun je instellen. Ik weet niet hoe snel zappi reageert. Standaard staat die ovlgens mij op 30 sec. Ik heb zelf omlaag gezet naar 10 sec voor mijn alfen laadpaal. Dat werkt prima, maar je moet even checken of dat voor jouw laadpaal ook OK is.

Anyway als je goede ondesteuning wilt is het handig om hier ook de logging te delen van EVCC, dan kan iemand er wellicht veel gerichter op antwoorden. (of nog beter: Doe dat in de officiele discussiegroep waar de developers ook zitten, die reageren vrijwel gelijk)

[ Voor 10% gewijzigd door Kammika op 04-04-2026 11:30 ]

[PisPix]

Ik zit de surplus sensor even in de gaten te houden en zie deze af en toe terugvallen naar 0. Dit is de template die ik gemaakt heb om de surplus sensor te maken:

code:

{% if states('sensor.deye_load_power')|float <= 0 
and states('sensor.p1_meter_power')|float >= -20 
and states('sensor.p1_meter_power')|float < 500 %}
{{ -1 * states('sensor.deye_load_power')|float | round(1)}}
{% else %}
0
{% endif %}

Ik heb al de -20 naar -500 gezet maar eigenlijk zou hier een soort van vertraging in moeten zitten zodat ie niet te jumpy is, daar zal EVCC niet zo lekker op gaan gok ik.

[PisPix]

Ik denk dat het probleem helder is. @jaapzb jij gaf terecht aan dat het mogelijk kan zijn dat EVCC het eigen verbruik van 't overschot afhaalt en er zo geen overschot lijkt te zijn.
In dit screenshot lijkt dat ook wel bevestigd te worden. De huis load is 2.3 kWh, het overschot is ook 2.3 kWh en de Peblar gaat uit omdat er geen overschot zou zijn. Terwijl er in totaal 4.6 kWh is en er dus 2.3 kWh overschot is. Nu is de vraag, hoe pas ik de logica aan (en waar) zodat EVCC ziet dat het overschot is en er geen som meer gemaakt hoeft te worden. Ik kan de Grid meter (P1) of Deye verwijderen uit EVCC, dan moet hij wel op de overschot sensor gaat draaien maar dan mis ik overzicht in EVCC.

[Kammika]

Ik snap er niks van wat je doet. Volgens mij doe je allemaal dingen waar evcc niet voor bedoelt is.

Evcc denkt volgens die plaatje dat je huis precies verbruikt wat je zonne paneel producten. Volgens evcc is er dus geen overschot en dus zal Innsolar mode niets doen en in minpv alleen ie minimum geconfigureerde waarde

De grid meter eruit halen slaat nergens op. In de basis kijkt evcc naar je grid meter en in solar mode stuurt die op basis daarvan je laadpaal aan. Dat wordt allemaal iets slimmer als je een andere toetsers en bellen toevoegt

Ik zou zeggen begin opnieuw met een lege configuratie. Configureer in evcc alleen je laadpaal en je gridmeter en kijk of die dan op overschot op gridmeter idd gaat opschakelen.

Zet je marstek ook even op
Manueel ipv nom (anders krijg je ook raar gedrag omdat 2 apparaten onafhankelijk van elkaar op nom gaan sturen)

Voeg (pas als dat wat hiervoor staat werkt) daarna je zonnepanelen toe en kijk of het dan mooier wordt weergegeven.

Als alles nog steeds goed gaat, voeg ook dan pas je thuisbatterij weer toe


Nb: als je op een ander overschot dan op de meter wilt schakelen, dan kat ie dat niet voor elkaar krijgen in evcc. Stop dan met evcc en n maak Custom scripts in home Assistant (alhoewel ik me geen enkele use case kan voorstellen waarom je dit zou willen)


Als je wat anders wilt moet je niet evcc gebrui


Ik zou zeggen

[ Voor 3% gewijzigd door Kammika op 04-04-2026 12:36 ]

[Tunestwo]

PisPix schreef op zaterdag 4 april 2026 @ 11:51:
Ik denk dat het probleem helder is. @jaapzb jij gaf terecht aan dat het mogelijk kan zijn dat EVCC het eigen verbruik van 't overschot afhaalt en er zo geen overschot lijkt te zijn.
In dit screenshot lijkt dat ook wel bevestigd te worden. De huis load is 2.3 kWh, het overschot is ook 2.3 kWh en de Peblar gaat uit omdat er geen overschot zou zijn. Terwijl er in totaal 4.6 kWh is en er dus 2.3 kWh overschot is. Nu is de vraag, hoe pas ik de logica aan (en waar) zodat EVCC ziet dat het overschot is en er geen som meer gemaakt hoeft te worden. Ik kan de Grid meter (P1) of Deye verwijderen uit EVCC, dan moet hij wel op de overschot sensor gaat draaien maar dan mis ik overzicht in EVCC.

[Afbeelding]

Ik heb het niet helemaal gevold, maar zoals je op de foto deelt, vebruikte je huis op dat moment 2.3 kw.

Zie hier het huis icoontje als huis verbruik,
Auto is auto verbruik
zonnetje is zonnepanelen
stroommast is uit het net.

Zorg ervoor dat je een P1 meter hebt voor huis verbruik, een zonnepaneel modbus/wifi module /Shelly EM oid voor energie opwek en een laadpaaltje.

[PisPix]

Tunestwo schreef op zaterdag 4 april 2026 @ 12:48:
[...]

Ik heb het niet helemaal gevold, maar zoals je op de foto deelt, vebruikte je huis op dat moment 2.3 kw.
[Afbeelding]
Zie hier het huis icoontje als huis verbruik,
Auto is auto verbruik
zonnetje is zonnepanelen
stroommast is uit het net.

Zorg ervoor dat je een P1 meter hebt voor huis verbruik, een zonnepaneel modbus/wifi module /Shelly EM oid voor energie opwek en een laadpaaltje.

Ik heb het inmiddels werkend. Door alle componenten toe te voegen (batterij/PV/P1/EV/enz) maakt EVCC de berekeningen waarbij rekening gehouden wordt met wat de batterijen in gaat en wat de EV's. Ik ging er vanuit dat ik qua PV opbrengst het netto overschot moest aanleveren in plaats van bruto. Dank allen voor de input/feedback/suggesties!

[Guillome]

De hele! dag bezig geweest om de omvormer via wifi/mosquitto/MQTT te koppelen, maar het lukt niet (met claude.ai). Ik word helemaal tuureluuurs. Hij zegt op het einde dit, is dit enigszins logisch? Ik kan dat echt niet beoordelen:

"Dan is het een Growatt MIN omvormer — precies wat we al dachten! De T06NNNNXMIN layout zou dus de juiste moeten zijn.
Het probleem is dat jouw omvormer record type 0104 stuurt, maar Grott zoekt naar dat type in de whitelist en gebruikt dan de generieke T06NNNNX layout in plaats van de specifieke T06NNNNXMIN.
We hebben al een T060104X.json aangemaakt met de MIN layout. Maar de waarden kloppen nog niet — dat komt waarschijnlijk door de valueoffset.
Morgen vroeg als de zon schijnt doen we dit:

Grott verbose draaien
Plain data opvangen
Netspanning opzoeken in de bytes (moet ~2300 zijn voor 230V met divide 10)
Zo de juiste offset bepalen"

[djiedjee]

@Guillome
Ik heb echt geeeeeeen idee wat je allemaal aan het doen bent.

Je draait EVCC stand alone, niet als HA addon?

[Guillome]

Haha ok even wat context.

Ik draai evcc standalone op Raspberry pi 4 (debian).

Ik wil nu mijn omvormer (Growatt) aansluiten maar ik denk dat mijn modbus (RS485) stuk is.
Heb een usb=>RS485 converter en aangesloten met 3 verschillende kabels en de juiste pins. Verstuurt wel maar ontvangt niets.

Dus toen maar via de ShineWIFI-dongle. Heb deze ingesteld dat hij naar mijn raspberry stuurt ipv server.growatt.com.
En om dat op te vangen heb je (blijkbaar) Mosquitto / MQTT nodig. Ik heb nog niet precies door wat wat is. En het werkt ook nog niet dus...
De data komt wel binnen en kan ik inzien via de mosquitto log. Alleen kloppen de waardes niet want, nouja, zie verhaal van mijn vorige bericht. En krijg m (daardoor?) ook niet aan de praat in evcc, die blijft hangen op valideren.

[ Voor 5% gewijzigd door Guillome op 04-04-2026 19:01 ]

[Tunestwo]

Guillome schreef op zaterdag 4 april 2026 @ 18:58:
Haha ok even wat context.

Ik draai evcc standalone op Raspberry pi 4 (debian).

Ik wil nu mijn omvormer (Growatt) aansluiten maar ik denk dat mijn modbus (RS485) stuk is.
Heb een usb=>RS485 converter en aangesloten met 3 verschillende kabels en de juiste pins. Verstuurt wel maar ontvangt niets.

Dus toen maar via de ShineWIFI-dongle. Heb deze ingesteld dat hij naar mijn raspberry stuurt ipv server.growatt.com.
En om dat op te vangen heb je (blijkbaar) Mosquitto / MQTT nodig. Ik heb nog niet precies door wat wat is. En het werkt ook nog niet dus...
De data komt wel binnen en kan ik inzien via de mosquitto log. Alleen kloppen de waardes niet want, nouja, zie verhaal van mijn vorige bericht. En krijg m (daardoor?) ook niet aan de praat in evcc, die blijft hangen op valideren.

Gekke vraag, maar staat de Growatt wel bij supported devices. Ik heb niet perse hetzelfde maar goodwe omvormer is ook drama, uit eindelijk een Shelly EM er tussen gezet en alles was grote blij.

[Guillome]

Ja de Growatt staat er wel tussen. Maar op de USB converter kan je zien dat er wel verzonden wordt maar niets ontvangen op moment van valideren).
Ik zal eens zoeken wat zo`n Shelly is en misschien voor mij ook zou werken.

[djiedjee]

Zonder dat ik weet wat je allemaal geprobeerd hebt:
Ik heb een Growatt Wilan-X2 stick gekocht voor 20 euro in plaats van de oude wifi-stick te gebruiken/flashen.

De modbus connectie werkt dan heel eenvoudig. Ik heb hem wel in Home assistant, niet EVCC direct.

[Guillome]

En dan ook via MQTT? Klinkt wel als een goede oplossing.

[J82]

Klinkt allemaal complex. Kan bijvoorbeeld niet helemaal volgen waarom er iets via MQTT zou moeten lopen.

Ik zou AI even links laten liggen en de documentatie van EVCC zelf volgen.

https://docs.evcc.io/en/docs/devices/meters#growatt

Ik denk dat je dit stukje van die pagina nodig hebt voor gebruik met je USB-kabel.

code:

meters:
  - name: my_grid
    type: template
    template: growatt-hybrid
    usage: grid
    
    # RS485 via adapter (Modbus RTU)
    modbus: rs485serial
    id: 1
    device: /dev/ttyUSB0 # USB-RS485 Adapter Adresse
    baudrate: 9600 # Prüfe die Geräteeinstellungen, typische Werte sind 9600, 19200, 38400, 57600, 115200
    comset: "8N1" # Kommunikationsparameter für den Adapter

Let op dat je daarbij naar het juiste device verwijst. Misschien even googlen naar: /dev/serial/by-id

Daarnaast ook dit gezien?
To use the active battery control, a one-time manual setup is necessary. The modbus registers 1100, 1101, 1102 need to be set to the values 0, 5947, 0 at the same time (via "write multiple", FC 16). This can be done by e.g. using the Modbus CLI: modbus [...] H@1100=0 H@1101=5947 H@1102=0. The active battery control uses the first "Battery first" timeslot, so it cannot be used otherwise.

[Guillome]

Growatt Wilan-X2 besteld. Thanks voor de tip!

[r2504]

Ik heb zonet even m'n batterij (MT Venus 3.0) ook mee geconfigureerd in evcc, echter deze gaat niet aan het laden (de auto wel) ondanks dat in de instellingen staat "Opladen van de thuisbatterij heeft prioriteit tot 80% bereikt is" ?

Enkel wanneer ik evcc op PV zet (en er geen 1.4 kW is) start m'n batterij met laden ? Bij Min+PV of Snel start steeds de auto en niet de batterij ?

Ik zie nu in de MT app dat de batterij van Mode "Selfconsumption" is versprongen naar geen mode meer ?

[Gophlin]

Vrijdag de nieuwe MID gecertificeerde laadpaal (Tesla Wall Connector Gen 3 MID) geinstalleerd, en vandaag na de paasbrunch maar eens goed gaan zitten om EVCC op Docker werkende te krijgen.

Voor het aansturen van mijn Tesla maak ik geen gebruik van MyTeslaMate, maar van het gratis fleetproxy.de. MyTeslaMate verzamelde naar mijn idee iets te veel data om vooral haar eigen database completer te vullen, en rekende ook nog een tarief per API gebruik.

fleetproxy.de claimt een GDPR compliant variant gehost in Duitsland met minimale data opslag.

De rest (Enphase IQ Envoy, P1 Meter, en de Wall Connector zelf) zijn allemaal online inmiddels, dus nu eens stoeien met laadschema's e.d.

[Guillome]

M`n eerste laadsessie (nog zonder de omvormer gekoppeld dus).
Maar ben tevreden! Ging vanzelf laden, nu 25% bijgeladen in 3 uur (heb een fase 1 3.7kwh boordlader).
Perfect dus, precies mijn opbrengst. Kosten: 8 cent haha. Worth it!!

[Krisp]

Sinds kort heb ik een batterij en ben ik de Optimizer een beetje aan het testen. Maar dat viel tegen: ondanks dat er bij batterijen ‘active battery control’ staat, betekent dat niet dat de batterij volledig gecontroleerd staat zoals ik het verwacht. De makers van EVCC willen naar eigen zeggen ‘ Übersteuern aber nicht regeln’, oftewel: wel overrulen, maar de NOM-modus moet de batterij zelfstandig doen.

En daarmee is een hele belangrijke use case voor EVCC weg.

[r2504]

Onlangs m’n batterij opgenomen in evcc maar deze wou niet laden ondanks de instelling dat ik ze prioriteit gaf tot ze 100% was opgeladen.

Diverse dingen geprobeerd maar de auto bleef gewoon laden.

[replica17]

proostyves schreef op zaterdag 28 maart 2026 @ 12:07:
Ik heb mijn forecast geconfigureerd in EVCC via Solcast en merk dat deze telkens na ongeveer een week niet meer zichtbaar is. Moet dan opnieuw valideren en opslaan.

Token is ingevuld en interval staat op 3h, dus dit valt binnen de limiet van 10 calls per dag.
Ik heb wel 2 arrays geconfigureerd (oost-west) en dus ook 2 forecasts ingesteld in EVCC . Weet iemand of deze samen in 1 call zitten, of worden hier 2 calls voor gedaan (en ik dus best de interval op 6 uur zet)?
Aangezien het na opnieuw valideren steeds onmiddellijk werkt vermoed ik dat dit niet het probleem gaat zijn.

Nog iemand die dit voorheeft?

Ik werd hier ook gek van... ga ook open-meteo proberen

Update: krijg bij open-meteo een error 525 SSL handshake failed.

[ Voor 4% gewijzigd door replica17 op 07-04-2026 09:42 ]

[proostyves]

replica17 schreef op dinsdag 7 april 2026 @ 09:28:
[...]


Ik werd hier ook gek van... ga ook open-meteo proberen

Update: krijg bij open-meteo een error 525 SSL handshake failed.

Gisteren ging het hier nog goed, vandaag ook geen gegevens meer van Open Meteo.
Hoop dat het een tijdelijk dingetje is.

[JanHenk]

r2504 schreef op maandag 6 april 2026 @ 21:43:
Onlangs m’n batterij opgenomen in evcc maar deze wou niet laden ondanks de instelling dat ik ze prioriteit gaf tot ze 100% was opgeladen.

Diverse dingen geprobeerd maar de auto bleef gewoon laden.

Kun je de situatie herproduceren en dan een stukje van de debug-log delen? Dan kunnen we even meekijken.

In beginsel doet evcc niets met de batterij: die heeft z'n eigen sturing! Ja, tenzij inderdaad overruled als in stand-by of op volle snelheid (andere opties zijn er nu niet). Wat jij wil zeggen is dat evcc blijkbaar de laadpaal aan heeft gestuurd om te (blijven) laden ondanks dat er volgens mij prio aan de thuisbatterij gegeven zou moeten worden voor wat betreft de vraag "waar gaat het overschot eerst naartoe".

Je zou het antwoord op die vraag uit de logs kunnen halen.

[JanHenk]

Krisp schreef op maandag 6 april 2026 @ 21:29:
Sinds kort heb ik een batterij en ben ik de Optimizer een beetje aan het testen. Maar dat viel tegen: ondanks dat er bij batterijen ‘active battery control’ staat, betekent dat niet dat de batterij volledig gecontroleerd staat zoals ik het verwacht. De makers van EVCC willen naar eigen zeggen ‘ Übersteuern aber nicht regeln’, oftewel: wel overrulen, maar de NOM-modus moet de batterij zelfstandig doen.

En daarmee is een hele belangrijke use case voor EVCC weg.

Met active battery control kunnen momenteel twee dingen: volle snelheid laden, stand-by (dus niet laden noch ontladen) of 'normaal bedrijf' waarbij evccc niet overruled, doorgaans een batterij die zelf NOM houdt. Welke optie mis je? Ik vermoed "maximaal ontladen", of niet?

evcc is van oorsprong een Duits stukje software is en ze kennen ter plaatse niet iets als de salderingsregeling. Onze combinatie van dynamische tarieven en salderingsregeling maakt de casus ook wat anders dan voor anderen in de wereld.

Maximaal ontladen is vanaf 2027 bij ons ook niet gauw relevant, maar het zou wel handig zijn om die toe te voegen imo.

[JanHenk]

Al die API integraties met zowel auto als zaken als PV-forecast of tarieven zijn wel wat de achilleshiel van evcc, of eigenlijk ieder ander stukje software dat zijn info uit gratis cloudbased bronnen haalt. Je kan het de makers niet kwalijk nemen als er weer eens iets omvalt, maar het zorgt wel voor minder brede acceptatie.

De Volkswagen API is gelukkig al een tijdje heel betrouwbaar. Solcast werkt bij mij ook prima (betrouwbare voorspelling, maar ik hanteer een 8h interval). Dynamische tarieven heb ik (nog) niet, maar daar is de laatste tijd wel vaak wat mee aan de hand. Diverse bronnen die aan elkaar gelinkt zijn, etc.

[r2504]

JanHenk schreef op dinsdag 7 april 2026 @ 10:13:
[...]
Kun je de situatie herproduceren en dan een stukje van de debug-log delen? Dan kunnen we even meekijken.

Ik zag op het eerste gezicht zelf niet echt iets verdachts... maar ik zal bij een volgende test nogmaals kijken.

Wat jij wil zeggen is dat evcc blijkbaar de laadpaal aan heeft gestuurd om te (blijven) laden ondanks dat er volgens mij prio aan de thuisbatterij gegeven zou moeten worden voor wat betreft de vraag "waar gaat het overschot eerst naartoe".

Inderdaad... als de batterij niet op de aangegeven SOC zit mag evcc m'n auto niet laden... wat het wel deed (ondanks dat de batterij SOC duidelijk in evcc zichtbaar was).

[r2504]

JanHenk schreef op dinsdag 7 april 2026 @ 10:22:
Je kan het de makers niet kwalijk nemen als er weer eens iets omvalt, maar het zorgt wel voor minder brede acceptatie.

Als de makers het lef hebben 150 euro voor hun "open source" software te vragen om de integraties in orde te hebben dan kijk ik daar anders tegenaan dan wanneer het pure OSS is. Ik blijf het dus moeilijk hebben met hun model.

[JanHenk]

r2504 schreef op dinsdag 7 april 2026 @ 11:12:
[...]

Inderdaad... als de batterij niet op de aangegeven SOC zit mag evcc m'n auto niet laden... wat het wel deed (ondanks dat de batterij SOC duidelijk in evcc zichtbaar was).

In de debug-log staat bij ieder interval iets als "grid power", "battery power" en "site power". En als je een batterij prio hebt ingesteld moet er ook ergens "battery soc: x%" met eventueel target soc achter staan. Site power is wat evcc gebruikt om de laadpaal aan te sturen en is een resultante van grid power, battery power, aux power (eventueel) en battery soc. En eventueel een 'residual power' als je dat hebt ingesteld (wordt wel aangeraden bij gebruik thuisbatterij, bijv. 100W). Ik kan hier de rekensommen in ieder geval goed herleiden afhankelijk van de batterij instellingen.

Misschien helpt dit je al verder, anders deel maar even een stukje van de log tussen de vier liggende ---- streepjes (dat is één interval).

[Krisp]

JanHenk schreef op dinsdag 7 april 2026 @ 10:17:
[...]


Met active battery control kunnen momenteel twee dingen: volle snelheid laden, stand-by (dus niet laden noch ontladen) of 'normaal bedrijf' waarbij evccc niet overruled, doorgaans een batterij die zelf NOM houdt. Welke optie mis je? Ik vermoed "maximaal ontladen", of niet?

Ik mis de NOM-variant. Niet elke batterij heeft die stand (Zendure niet, en laat ik die nu net hebben), en ik vind het ook moeilijk te begrijpen dat gegeven het feit dat laadpalen juist die NOM-stand (de PV-stand) wel hebben in EVCC, hij er voor batterijen niet in zit.

[r2504]

Krisp schreef op dinsdag 7 april 2026 @ 11:41:
[...]
Ik mis de NOM-variant. Niet elke batterij heeft die stand (Zendure niet, en laat ik die nu net hebben)

Huh ? Dat is toch de essentie van iedere batterij... NOM ? (Bij Marstek noemt dat trouwens Self-Consumption)

[JanHenk]

Krisp schreef op dinsdag 7 april 2026 @ 11:41:
[...]

Ik mis de NOM-variant. Niet elke batterij heeft die stand (Zendure niet, en laat ik die nu net hebben), en ik vind het ook moeilijk te begrijpen dat gegeven het feit dat laadpalen juist die NOM-stand (de PV-stand) wel hebben in EVCC, hij er voor batterijen niet in zit.

Oké, eens, voor de laadpalen neemt evcc het juist over inderdaad. Dat is de kern van het product. Maar van thuisbatterijen is toch (al) de kern dat ze nul-op-de-meter doen (zonnestroom opslaan)? Dus iedere thuisbatterij heeft toch zo'n modus?

Ik ken Zendure niet, maar voor wat ik heb gelezen hebben die toch ook gewoon een "NOM"-regelmodus? Of gaat dat mis op moment dat je iets wil overschrijven met een andere modus van externe software?

[djiedjee]

JanHenk schreef op maandag 30 maart 2026 @ 23:04:
Ah, vandaar. Dan zou ik de modbus proxy van evcc gebruiken om hem daar door te koppelen naar Home Assistant

@JanHenk Ik heb het omgekeerd opgelost en een modbus proxy in HA geinstalleerd en EVCC + home assistant met de proxy laten connecten.
Op deze manier kan ik EVCC de batterij laten aansturen en HA de batterij laten uitlezen/aansturen.

Voor de EVCC addon had ik een sponsortoken nodig en ik heb ook liever dat de basis in HA draait.

[r2504]

djiedjee schreef op dinsdag 7 april 2026 @ 14:19:
[...]
Op deze manier kan ik EVCC de batterij laten aansturen en HA de batterij laten uitlezen/aansturen.

Krijg je dan geen conflicten als twee stukjes software vinden dat ze iets moeten aansturen ?

[jaapzb]

Krisp schreef op maandag 6 april 2026 @ 21:29:
Sinds kort heb ik een batterij en ben ik de Optimizer een beetje aan het testen. Maar dat viel tegen: ondanks dat er bij batterijen ‘active battery control’ staat, betekent dat niet dat de batterij volledig gecontroleerd staat zoals ik het verwacht. De makers van EVCC willen naar eigen zeggen ‘ Übersteuern aber nicht regeln’, oftewel: wel overrulen, maar de NOM-modus moet de batterij zelfstandig doen.

En daarmee is een hele belangrijke use case voor EVCC weg.

Wat voor regelgedrag verwacht je dat EVCC voor jou doet?

EDIT sorry zag niet dat er verderop al over gesproken werg

[ Voor 4% gewijzigd door jaapzb op 07-04-2026 15:51 ]

[jaapzb]

Op dit soort zonnige dagen ben ik toch wel heel blij met EVCC, moet ik zeggen. Voelt gewoon lekker om de accu weer vol te krijgen met "gratis" energie

[djiedjee]

r2504 schreef op dinsdag 7 april 2026 @ 14:29:
[...]


Krijg je dan geen conflicten als twee stukjes software vinden dat ze iets moeten aansturen ?

Ja mogelijk, dus daar moet ik voor oppassen.

Het is OF zelf alles programmeren OF EVCC de belangrijkste zaken laten regelen en ik zelf een paar uitzonderingen.

Ik ben aan het kijken wat EVCC precies gaat doen, die opties zijn allemaal gericht op het laden van de auto in combinatie met een batterij.
Vanuit HA hoop ik op bepaalde momenten alleen de NoM-stand tijdelijk te pauzeren. Dat zijn momenten waarop ik de auto juist niet laadt.

[Hangover_ohoo]

Ik heb 2 marsteks van 5kWh en HBC voor NOM sturing (ESP32, modbus). Ik gebruik EVCC voor laden van mijn auto (via Alfen laadpaal).

Ik ervaar dat zodra ik auto ga laden en marsteks in NOM modus laat staan deze de laadsnelheid (EVCC) gaat kanabaliseren. Batterijen proberen NOM te houden, EVCC in PV werkt niet (geen overschot want NOM en minimaal is 6A nodig uit PV), in MINPV modus is enkel 1.4kW laden mogelijk (minimum). Batterijen NOM zit dan EVCC in de weg. Dus via HBC forceer ik full stop op de batterijen als de laadpaal vermogen neemt (via HBC instelling te regelen). Dan stoppen de batterijen volledig met laden of terugleveren. Dat werkt op zich prima, maar een tussenvorm zou nog mooier zijn. Mijn PV overschot schomelt in dit jaargetijden op max van 5000 watt opwek minus huisload van 200-300 watt blijft er net genoeg over om op 3 fase 4.1 tot 4.8kW te laden via EVCC. Maar door interne sturing van EVCC schommelt dit nog wel aantal honderden watts. En loop ik het 'gevaar' (bij wisselende half bewolkte condities) dat EVCC naar 1 fase terugschakelt. Op die momenten zou ik wel graag de marsteks EVCC willen laten helpen. Dus dat ze bijspringen in het leveren van bijvoorbeeld een load van 500 - 1000 watt (enigsinds intelligent) om deze schommelingen in laadvermogen te beperken en 3 fase langer laden langer vol te houden. HBC heeft diverse strategien - mogelijk is een timed Sell strategie dan een optie (gedurende een laadsessie dus toestaan dat er ontladen wordt vanuit de batterij tot een bepaalde SOC vd batterijen).

Iemand hier ervaringen mee ? Of een slimmere denkrichting ? Doel is optimaal zonneladen zo efficient mogelijk en nog voldoende over houden in de marsteks voor NOM huisload ná de laadsessie.

[Krisp]

r2504 schreef op dinsdag 7 april 2026 @ 11:55:
[...]


Huh ? Dat is toch de essentie van iedere batterij... NOM ? (Bij Marstek noemt dat trouwens Self-Consumption)

Nee, dat is het dus niet. Iig Zendure heeft de mogelijkheid zo’n batterij helemaal te controleren, en als je dat doet, ondersteunt het geen NOM-meer (dat moet je zelf regelen). Dat vind ik ook niet gek, want anders heb je meerdere kapiteins op 1 schip. NOM kun je immers ook bereiken met je laadpaal, met het afregelen van de PV-omvormer, of het opregelen van de warmtepomp. Als je meerdere batterijen van verschillende merken hebt, gaan die verschillende NOM-modussen met elkaar conflicteren.

Ik wil 1 kapitein, en dat is dan (logischerwijs) EVCC. Voor mij is het een verbazing dat anderen verwachten dat de batterij dat wel oppakt. Dat zegt waarschijnlijk ook iets over mij.

[MountainMo]

Hallo,

Weet niet zeker of ik dit in het goede topic plaats maar ik heb een vraag over het toevoegen van mijn Volvo in EVCC home assistant.

Ik heb de autorisatie voor elkaar gekregen en zie onder het blok integraties een autorizatiestatus met Volvo en een groen bolletje, hoe nu verder? Ik zie geen nieuweselectie mogelijkheid van de door mijn gekoppelde auto wanneer ik een auto probeer toe te voegen in via de EVCC configuratie.

Alvast bedankt voor de hulp/doorverwijzing.

Maurice

P.S: laatste versie van zowel Home assistant als EVCC draait via Home assistant green

[Get!em]

MountainMo schreef op dinsdag 7 april 2026 @ 20:59:
Hallo,

Weet niet zeker of ik dit in het goede topic plaats maar ik heb een vraag over het toevoegen van mijn Volvo in EVCC home assistant.

Ik heb de autorisatie voor elkaar gekregen en zie onder het blok integraties een autorizatiestatus met Volvo en een groen bolletje, hoe nu verder? Ik zie geen nieuweselectie mogelijkheid van de door mijn gekoppelde auto wanneer ik een auto probeer toe te voegen in via de EVCC configuratie.

Alvast bedankt voor de hulp/doorverwijzing.

Maurice

P.S: laatste versie van zowel Home assistant als EVCC draait via Home assistant green

Evcc en Homeassistant zijn twee verschillende stukken software en hebben niets met elkaar te maken. Ja, je kunt ze viceversa met elkaar verbinden voor extra functionaliteit, maar in de basis zijn het twee losse zaken. De evcc als app binnen Homeassistant is alleen een simpele manier om hem als servercontainer te draaien (en maakt het op bepaalde wijze zelfs complexer)

Als je het over integraties hebt, neem ik aan dat je je Volvo in HomeAssistant hebt toegevoegd?

Of heb je je Volvo in de webinterface van EVCC toegevoegd aan vehicles.

[ Voor 6% gewijzigd door Get!em op 07-04-2026 22:07 ]

[MountainMo]

Ik heb de Volvo toegevoegd in de webinterface van evcc. Het laden van de auto en de thuisbatterij werkt wel wanneer er een gastauto is geselecteerd.

Ook heb ik de Volvo api correct werkend in het home assistant gedeelte.

[ Voor 20% gewijzigd door MountainMo op 08-04-2026 07:04 ]

[jaapzb]

Krisp schreef op dinsdag 7 april 2026 @ 17:27:
[...]

Nee, dat is het dus niet. Iig Zendure heeft de mogelijkheid zo’n batterij helemaal te controleren, en als je dat doet, ondersteunt het geen NOM-meer (dat moet je zelf regelen). Dat vind ik ook niet gek, want anders heb je meerdere kapiteins op 1 schip. NOM kun je immers ook bereiken met je laadpaal, met het afregelen van de PV-omvormer, of het opregelen van de warmtepomp. Als je meerdere batterijen van verschillende merken hebt, gaan die verschillende NOM-modussen met elkaar conflicteren.

Ik wil 1 kapitein, en dat is dan (logischerwijs) EVCC. Voor mij is het een verbazing dat anderen verwachten dat de batterij dat wel oppakt. Dat zegt waarschijnlijk ook iets over mij.

In de documentatie van EVCC lees ik dat de optimizer nog experimenteel is, en momenteel nog geen controleacties uitvoert. Maar dat dat wel gaat komen.

https://docs.evcc.io/en/docs/features/optimizer

The optimizer is currently informational only. It shows forecasts and potential savings but does not yet actively control anything.

Next steps:

• Integrate actions: actively control the home battery
• Let the optimizer optimise charging plans
• Enable users to hand over specific settings to the optimizer

[Freezhost]

Nou lekker, ik dacht dat de Zaptec Go 2 actief phase switching zou ondersteunen maar dat is dus niet het geval. De marketing brengt dat wel zo maar affijn niet goed gelezen. Wie heeft er een laadpaal in gebruik die door EVCC tijdens laden met pv op 1 fase wordt gezet en tijdens een goedkoop blok automatisch naar 3 fase overschakelt en weer terug naar 1 fase als het goedkope blok voorbij is? Wie heeft er aanbevelingen als het gaat om een laadpaal die dit goed kan in combinatie met EVCC?

[proostyves]

replica17 schreef op dinsdag 7 april 2026 @ 09:28:
[...]


Ik werd hier ook gek van... ga ook open-meteo proberen

Update: krijg bij open-meteo een error 525 SSL handshake failed.

Ondertussen is het bij mij automagisch terug in orde, dus was idd een tijdelijk issue.

[jaapzb]

Freezhost schreef op woensdag 8 april 2026 @ 10:20:
Nou lekker, ik dacht dat de Zaptec Go 2 actief phase switching zou ondersteunen maar dat is dus niet het geval. De marketing brengt dat wel zo maar affijn niet goed gelezen. Wie heeft er een laadpaal in gebruik die door EVCC tijdens laden met pv op 1 fase wordt gezet en tijdens een goedkoop blok automatisch naar 3 fase overschakelt en weer terug naar 1 fase als het goedkope blok voorbij is? Wie heeft er aanbevelingen als het gaat om een laadpaal die dit goed kan in combinatie met EVCC?

Ik heb een Zaptec Go 2 die wel schakelt van 1 naar 3 fases. Waarschijnlijk staat een instelling verkeerd in je portal (https://portal.zaptec.com), die moet jij of je installateur inschakelen.



Het kan na het aanpassen van de instellingen even duren voor de lader deze instellingen overgenomen heeft.

De zaptec heeft wel als nadeel dat er een limiet zit aan het aantal schakelingen. Als je dus een bewolkte dag hebt en hij schakelt telkens de lader uit, of van 1 naar 3 fasen en weer terug dan gaat hij op een bepaald moment in een beveiligingsstoring en moet je de auto opnieuw aansluiten. Op een bewolkte dag zet ik hem zelf meestal vast op 1 fase via de EVCC UI.

Hij is op dit moment 1 fase aan het laden, hij zal straks wel overschakelen naar 3.

Er word momenteel ook nog een issue besproken tussen EVCC en Zaptec engineers over faseschakelingen die niet helemaal goed gaan. Ze zijn er mee bezig: https://github.com/evcc-io/evcc/issues/28689

[ Voor 30% gewijzigd door jaapzb op 08-04-2026 10:35 ]

[Krisp]

jaapzb schreef op woensdag 8 april 2026 @ 09:04:
[...]

In de documentatie van EVCC lees ik dat de optimizer nog experimenteel is, en momenteel nog geen controleacties uitvoert. Maar dat dat wel gaat komen.

https://docs.evcc.io/en/docs/features/optimizer

[...]

Klopt, en dat is prima. Maar de NOM-modus zou er nu al wel in kunnen komen (zoals dat ook voor EV-laders gebeurt).

[JanHenk]

Krisp schreef op dinsdag 7 april 2026 @ 17:27:
[...]

Nee, dat is het dus niet. Iig Zendure heeft de mogelijkheid zo’n batterij helemaal te controleren, en als je dat doet, ondersteunt het geen NOM-meer (dat moet je zelf regelen). Dat vind ik ook niet gek, want anders heb je meerdere kapiteins op 1 schip. NOM kun je immers ook bereiken met je laadpaal, met het afregelen van de PV-omvormer, of het opregelen van de warmtepomp. Als je meerdere batterijen van verschillende merken hebt, gaan die verschillende NOM-modussen met elkaar conflicteren.

Ik wil 1 kapitein, en dat is dan (logischerwijs) EVCC. Voor mij is het een verbazing dat anderen verwachten dat de batterij dat wel oppakt. Dat zegt waarschijnlijk ook iets over mij.

Ik denk dat het wat met de historie te maken heeft: de eerste laadpalen deden niets met laden op zonnestroom en gaven via modbus of soortgelijke protocollen eventueel wel derden toegang tot sturing. Heden ten dage zijn er nog steeds gewoon palen die alleen maar aan/uit kunnen regelen vanuit hun eigen software en laden op zonnestroom zit er niet in. Soms ontbreekt zelfs load balancing al.

Een thuisbatterij heeft een ander doel en is door de fabrikant vaak al ontwikkeld om de huisaansluiting te monitoren en dus de grid import en export te sturen met eigen software. Dan snap ik dat de eerste focus ligt op het overrulen, maar niet per se het 'nabouwen' van NOM-functionaliteit.

Maar ik zie nu ook dat Zendure die NOM functionaliteit ook loslaat als je wil overrulen, een Tweaker heeft dat helemaal zelf helemaal nagemaakt in Home Assistant en dergelijke... Daarin zijn ze in mijn optiek wel een vreemde eend in de bijt. De meeste batterijfabrikanten geven opties voor overrulen (vol laden, vol ontladen, etc.) maar kennen ook hun eigen (NOM-)aansturing waarop teruggevallen kan (blijven) worden zonder interveniëren.

Op dezelfde wijze kun je ook bijv. smart grid boilers en zo integreren in evcc: ze hebben in beginsel hun eigen regeling, evcc kan er op attent worden gemaakt (om werkelijk overschot te berekenen), maar er kan in sommige gevallen ook overruled worden.

[Freezhost]

jaapzb schreef op woensdag 8 april 2026 @ 10:25:
[...]

Ik heb een Zaptec Go 2 die wel schakelt van 1 naar 3 fases. Waarschijnlijk staat een instelling verkeerd in je portal (https://portal.zaptec.com), die moet jij of je installateur inschakelen.

[Afbeelding]

Het kan na het aanpassen van de instellingen even duren voor de lader deze instellingen overgenomen heeft.

De zaptec heeft wel als nadeel dat er een limiet zit aan het aantal schakelingen. Als je dus een bewolkte dag hebt en hij schakelt telkens de lader uit, of van 1 naar 3 fasen en weer terug dan gaat hij op een bepaald moment in een beveiligingsstoring en moet je de auto opnieuw aansluiten. Op een bewolkte dag zet ik hem zelf meestal vast op 1 fase via de EVCC UI.

Hij is op dit moment 1 fase aan het laden, hij zal straks wel overschakelen naar 3.

Er word momenteel ook nog een issue besproken tussen EVCC en Zaptec engineers over faseschakelingen die niet helemaal goed gaan. Ze zijn er mee bezig: https://github.com/evcc-io/evcc/issues/28689

Bedankt voor de tip, die 6Ampere stond hier nog op 8, verder stond alles al hetzelfde. Ik heb ook iedere keer een fout van de API van Zaptec, dat heeft denk ik te maken met dat issue dus dat blijf ik even volgen. Ik ben benieuwd of het nu wel werkt, momenteel hangt er een 1 fase auto aan dus vandaag zal hij op 1 fase blijven staan.

Heb jij de Zaptec gekoppeld via de Zaptec cloud of via Home Assistant? Beide heb ik geprobeerd maar en nu heb ik hem via Zaptec zelf toegevoegd en dan krijg ik deze meldingen in de log:

code:

Nissan Leaf: switch phases: unexpected status: 500 (Internal Server Error) POST https://api.zaptec.com/api/installation/xxxxxxx/update
Nissan Leaf: charger logic error: current mismatch (got 10.4A measured, expected 0A) - make sure your interval is at least 30s

Enige idee wat dit kan zijn?
n.b. ik heb wel de Sense gekoppeld, jij ook of gebruik jij load balancing van EVCC?

[jaapzb]

Freezhost schreef op woensdag 8 april 2026 @ 10:47:
[...]


Bedankt voor de tip, die 6Ampere stond hier nog op 8, verder stond alles al hetzelfde. Ik heb ook iedere keer een fout van de API van Zaptec, dat heeft denk ik te maken met dat issue dus dat blijf ik even volgen. Ik ben benieuwd of het nu wel werkt, momenteel hangt er een 1 fase auto aan dus vandaag zal hij op 1 fase blijven staan.

Heb jij de Zaptec gekoppeld via de Zaptec cloud of via Home Assistant? Beide heb ik geprobeerd maar en nu heb ik hem via Zaptec zelf toegevoegd en dan krijg ik deze meldingen in de log:

code:

Nissan Leaf: switch phases: unexpected status: 500 (Internal Server Error) POST https://api.zaptec.com/api/installation/xxxxxxx/update
Nissan Leaf: charger logic error: current mismatch (got 10.4A measured, expected 0A) - make sure your interval is at least 30s

Enige idee wat dit kan zijn?
n.b. ik heb wel de Sense gekoppeld, jij ook of gebruik jij load balancing van EVCC?

Ik heb ook even de integratie via HA geprobeerd, maar daarmee kon ik niet faseschakelen (dat lijkt nu net in de nieuwe versie 0.304.1 wel te moeten kunnen). Dus mijn integratie loopt gewoon via de zaptec cloud integratie in EVCC zelf.

Ik heb bij aankoppelen van de auto dat ook de charger in EVCC even out of sync gaat met de daadwerkelijke staat van de charger, hij start al met laden terwijl EVCC dat niet verwacht.

Ik heb de sense niet, loadbalancing gebeurt bij mij idd via EVCC. De sense regelt ook de current dus kan me best voorstellen dat dat niet werkt in combinatie met EVCC. Ze gaan dan immers beiden die instelling proberen te wijzigen. De loadbalancing in EVCC werkt voor mij prima, dus misschien heb je die sense helemaal niet nodig?

[Krisp]

JanHenk schreef op woensdag 8 april 2026 @ 10:39:
[...]


Ik denk dat het wat met de historie te maken heeft: de eerste laadpalen deden niets met laden op zonnestroom en gaven via modbus of soortgelijke protocollen eventueel wel derden toegang tot sturing. Heden ten dage zijn er nog steeds gewoon palen die alleen maar aan/uit kunnen regelen vanuit hun eigen software en laden op zonnestroom zit er niet in. Soms ontbreekt zelfs load balancing al.

Een thuisbatterij heeft een ander doel en is door de fabrikant vaak al ontwikkeld om de huisaansluiting te monitoren en dus de grid import en export te sturen met eigen software. Dan snap ik dat de eerste focus ligt op het overrulen, maar niet per se het 'nabouwen' van NOM-functionaliteit.

Maar ik zie nu ook dat Zendure die NOM functionaliteit ook loslaat als je wil overrulen, een Tweaker heeft dat helemaal zelf helemaal nagemaakt in Home Assistant en dergelijke... Daarin zijn ze in mijn optiek wel een vreemde eend in de bijt. De meeste batterijfabrikanten geven opties voor overrulen (vol laden, vol ontladen, etc.) maar kennen ook hun eigen (NOM-)aansturing waarop teruggevallen kan (blijven) worden zonder interveniëren.

Op dezelfde wijze kun je ook bijv. smart grid boilers en zo integreren in evcc: ze hebben in beginsel hun eigen regeling, evcc kan er op attent worden gemaakt (om werkelijk overschot te berekenen), maar er kan in sommige gevallen ook overruled worden.

Ja, ik denk dat je de historie goed beschrijft. En tegelijk denk ik dat deze fase een interbellum is waarbij je nu maar 1 of 2 opties hebt om op een NOM-modus te draaien. Dat worden er alleen steeds meer:

• Meerdere batterijen, mogelijk ook van meerdere merken
• een auto met V2G
• PV opwek

Daarmee kun je slimmer acteren:

• Hoe optimaliseer je op prijs als de prijs (zoals afgelopen weekend) kaal onder nul is, maar inclusief belasting boven nul en je niet alle energie kan opslaan?
• Hoe ga je om met (ont)laadcurves en efficiency? Zeker op lagere vermogens is dat een serieus probleem.
• Hoe zorg je voor goede aansturing wanneer meerdere devices op NOM (kunnen) draaien?

Ik zag ook een voorbeeld voorbij komen van iemand die geen ruimte had voor een extra dongle in de meterkast. Nog los van de kosten van zo’n extra dongle.

Je wilt m.i. 1 tool die de regie voert. Ik kan me voorstellen dat je het decentraal wil beleggen als het kan, maar er zijn genoeg redenen om het wel centraal te willen managen.

[Freezhost]

jaapzb schreef op woensdag 8 april 2026 @ 11:16:
[...]

Ik heb ook even de integratie via HA geprobeerd, maar daarmee kon ik niet faseschakelen (dat lijkt nu net in de nieuwe versie 0.304.1 wel te moeten kunnen). Dus mijn integratie loopt gewoon via de zaptec cloud integratie in EVCC zelf.

Ik heb bij aankoppelen van de auto dat ook de charger in EVCC even out of sync gaat met de daadwerkelijke staat van de charger, hij start al met laden terwijl EVCC dat niet verwacht.

Ik heb de sense niet, loadbalancing gebeurt bij mij idd via EVCC. De sense regelt ook de current dus kan me best voorstellen dat dat niet werkt in combinatie met EVCC. Ze gaan dan immers beiden die instelling proberen te wijzigen. De loadbalancing in EVCC werkt voor mij prima, dus misschien heb je die sense helemaal niet nodig?

Dat klopt, EVCC gaat bij mij ook out of sync maar blijft dat momenteel ook dus ik heb hem nu weer even via HA toegevoegd. Ik had van Zaptec juist begrepen dat je de Sense nodig hebt om PV laden te activeren en dus ook phase switching. Load balancing via EVCC heb ik ook gehad maar ik vond dat erg traag reageren en er zit ook best van marge op. Misschien gaat het beter als je hem als OCPP koppelt maar dat is in het geval van de zaptec ocpp 1.6j en dat is puur voor authenticatie en niet voor het aansturen van de current.

Misschien dat ik die Sense dan maar even loskoppel en het nog een keer via EVCC ga proberen maar ik wacht even dat issue af.

Het lijkt er op dat deze functionaliteit nog niet helemaal af is, quote van de site:

Voorbereid op laden met zonne-energie
Voorbereid op integratie met zonnepanelen; schakelt tussen 1-fase en 3-fase laden voor optimale energie-efficiëntie.

[jaapzb]

Freezhost schreef op woensdag 8 april 2026 @ 12:15:
[...]


Dat klopt, EVCC gaat bij mij ook out of sync maar blijft dat momenteel ook dus ik heb hem nu weer even via HA toegevoegd. Ik had van Zaptec juist begrepen dat je de Sense nodig hebt om PV laden te activeren en dus ook phase switching. Load balancing via EVCC heb ik ook gehad maar ik vond dat erg traag reageren en er zit ook best van marge op. Misschien gaat het beter als je hem als OCPP koppelt maar dat is in het geval van de zaptec ocpp 1.6j en dat is puur voor authenticatie en niet voor het aansturen van de current.

Misschien dat ik die Sense dan maar even loskoppel en het nog een keer via EVCC ga proberen maar ik wacht even dat issue af.

Het lijkt er op dat deze functionaliteit nog niet helemaal af is, quote van de site:


[...]

Ja ik denk dat ze daarmee bedoelen dat je die sense nodig hebt om via het systeem van zaptec zelf het zonneladen te doen. Maar dat hebben ze nog helemaal niet, al willen ze dat nog wel toevoegen in een latere update. Enige wat de sense nu toevoegd is dat loadbalancing.

[NoFate]

Ik heb altijd gewerkt met de residualPower om mijn piek van 4200 Watt te hebben (capaciteteits tarief)

Nu wil ik eens werken met de maxPower als test, dus deze aangemaakt via de UI, om de max power te beperken van de grid, maar krijg een validatie error op de grid meter, wellicht de naam niet ok?

code:

- name: main
  title: Main Circuit
  maxPower: 4200
  meter: grid

Maar als ik kijg naar de logs, dan is de naam toch gewoon "grid"?

```
[site ] INFO 2026/04/08 14:44:14 meters: grid ✓ pv ✓ battery ✗
```

code:

Error during startup. Check your configuration and restart.
circuit: cannot create circuit 'main': not found: grid
loadpoint: [db:2] circuit: not found: main

[ Voor 13% gewijzigd door NoFate op 08-04-2026 14:51 ]

[djiedjee]

Hangover_ohoo schreef op dinsdag 7 april 2026 @ 16:57:

Iemand hier ervaringen mee ? Of een slimmere denkrichting ? Doel is optimaal zonneladen zo efficient mogelijk en nog voldoende over houden in de marsteks voor NOM huisload ná de laadsessie.

Ik begin inmiddels ook te zien dat EVCC niet in alle gevallen voldoende is. Zo wil ik mijn accu nog niet volladen wanneer er zonne-overschot is, maar wanneer er zonne-overschot is EN de prijs gezakt is. MIjn eerste overschot kan ik nog terugleveren tegen een hoge prijs.
In HA gaan dit dan een aantal automations worden denk ik.

Na 1/1/27 moeten er weer andere regels ingesteld worden natuurlijk. Zo blijven we bezig.

[JanHenk]

NoFate schreef op woensdag 8 april 2026 @ 14:46:
Ik heb altijd gewerkt met de residualPower om mijn piek van 4200 Watt te hebben (capaciteteits tarief)

Nu wil ik eens werken met de maxPower als test, dus deze aangemaakt via de UI, om de max power te beperken van de grid, maar krijg een validatie error op de grid meter, wellicht de naam niet ok?

code:

- name: main
  title: Main Circuit
  maxPower: 4200
  meter: grid

Maar als ik kijg naar de logs, dan is de naam toch gewoon "grid"?

```
[site ] INFO 2026/04/08 14:44:14 meters: grid ✓ pv ✓ battery ✗
```

code:

Error during startup. Check your configuration and restart.
circuit: cannot create circuit 'main': not found: grid
loadpoint: [db:2] circuit: not found: main

Gezien ik bij loadpoint ook db:2 zie staan, heb je denk ik je 'grid meter' toegevoegd via de GUI? Dan moet je in dat stukje yaml ook verwijzen naar de db-code die bij de grid meter hoort. Kun je zien met mouse-over over de settings ervan.

[JanHenk]

djiedjee schreef op woensdag 8 april 2026 @ 14:55:
[...]


Ik begin inmiddels ook te zien dat EVCC niet in alle gevallen voldoende is. Zo wil ik mijn accu nog niet volladen wanneer er zonne-overschot is, maar wanneer er zonne-overschot is EN de prijs gezakt is. MIjn eerste overschot kan ik nog terugleveren tegen een hoge prijs.
In HA gaan dit dan een aantal automations worden denk ik.

Na 1/1/27 moeten er weer andere regels ingesteld worden natuurlijk. Zo blijven we bezig.

Je kan een teruglever-prijslimiet instellen in de GUI bij de instellingen van het loadpoint, toch? Of ken je die wel, maar zoek je wat anders?

Liefst pas je die dynamisch aan denk ik, maar daar heb je nu inderdaad nog iets als home assistant voor nodig om de feed-in limit aan te passen. Als de optimizer verder is uitgewerkt zou dat daar ook uit moeten volgen imo.

[ Voor 5% gewijzigd door JanHenk op 08-04-2026 15:17 ]

[djiedjee]

@JanHenk
Die feed-in limiet heb ik bij de laadpaal, niet bij de batterij.
Bij de batterij heb ik alleen deze setting:


Ik zoek het omgekeerde: een manier om de NoM-stand tijdelijk uit te schakelen op basis van prijs.

[JanHenk]

djiedjee schreef op woensdag 8 april 2026 @ 15:38:
@JanHenk
Die feed-in limiet heb ik bij de laadpaal, niet bij de batterij.
Bij de batterij heb ik alleen deze setting:
[Afbeelding]

Ik zoek het omgekeerde: een manier om de NoM-stand tijdelijk uit te schakelen op basis van prijs.

Ah, sorry, ik dacht dat het ging om de laadpaal. Nee, voor de batterij zit dit er nog niet in. Die slurpt zelf (standaard) de zonnestroom op. Ook dat is iets dat hopelijk met de optimizer wel komt, want evcc is technisch wel in staat om de 'hold'-modus aan te roepen. Dat is nu optioneel al zo bij snel laden namelijk.

[Kanoet]

h3llrais3rke schreef op donderdag 2 oktober 2025 @ 11:01:
Een vraag voor de skoda enyaq rijders hier.
...

Hier een verse 2e hands lease bak, dus oude versie rijder. Geen problemen met het opnieuw beginnen met PV laden. Zowel met Peblar Home Plus laadpaal aansturing als EVCC via modbus.

[Kanoet]

Kan iemand mij helpen met het volgende issue?
-Enphase Metered Gateway
-PV opwek tot 3.6kw, ]momenteel is dat zo'n 3kw.
-Peblar Home Plus laadpaal (automatisch wisselen 1-3 fasen)
-Skoda Enyaq 2021
-Homewizard
-Dynamisch energiecontract. Momenteel kunnen we nog (belasting) salderen, straks niet meer.

EVCC lijkt de basis te hebben om goedkoop te laden en daarbij gebruik te maken van PV opwek.
Voorwaarde: gebruik zoveel mogelijk eigen zonnestroom én beperk terugleveren mij negatieve/lage tarieven.

Dus: spreidt laden uit over PV opwek én de meest negatieve uren, zodat ik nog iets verdien aan de uren in de ochtend dat de tarieven positief zijn.

Ik heb een voorspelling van mijn PV opwek.

Genoeg om mijn auto bij te laden dus.

Het laadplan kiest er echter voor om voluit te laden op de kwartieren met de laagste tarieven. Daardoor ben ik genoodzaakt het vermogen te beperken via de instellingen. Niet de meest handige optie. Ik zoek juist EVCC voor de integraties en zodat ik niet alsnog zelf van alles moet instellen. Tijdelijk snelladen staat dus UIT.


Is dit een bekend probleem of doe ik iets verkeerd? Ik heb 'Tijdelijk snel laden in PV mode' uit staan en heb de energiebelasting in de tarieven verwerkt. Dit zou dus niet mogen meespelen.
Hoe zorg ik ervoor dat evcc het maximale vermogen van de PV opwek meeneemt in het plan?

[ Voor 29% gewijzigd door Kanoet op 08-04-2026 16:34 ]