Evcc slim laden met de zon en dynamische tarieven

[Bravo]

JanHenk schreef op maandag 8 september 2025 @ 13:20:
[...]


Maar ik doe het niet automatisch, want dat is geen gegeven / zekerheid.

Op basis van resterende verwachting zou je daar wel iets mee kunnen. Bijvoorbeeld if forecast PV today remaining > 7,5 kWh > Enable batteryboost at plugin.

Ik kan overigens zo gauw niet vinden hoe je dit met de API zou moeten aanzetten, boost modus configuratie zit daar volgens mij (nog?) niet in.

Het zit niet bij de batterij, maar bij de loadpoint variabelen.

REST API of MQTT topic
Set battery boost:

code:

/loadpoints/{id}/batteryboost/{enable}
evcc/loadpoints/<id>/batteryboost  writeable [1/0]

[ Voor 9% gewijzigd door Bravo op 08-09-2025 13:37 ]

[Kammika]

Ik gebruik de ha integratie. Daar zit die knop boost from home batterij al in.

Dus daar ga ik eerst eens mee experimenteren. Dat is het makkelijkst…

[JanHenk]

@Bravo en @Kammika Ik heb de docs niet gecheckt voordat ik die uitspraak deed, had ik natuurlijk even moeten doen. Het blijkt dat ik een heel oude versie had (2024.10) van de ha-evcc integratie. Bijzonder, normaal komen de updates altijd wel mee via HACS, maar deze blijkbaar niet. Misschien destijds niet via HACS toegevoegd bedenk ik me.

Afijn, nu geüpdatet en zie hem nu wel staan, bovenaan zelfs

Ga ik eens over nadenken. Het enige is dat ik niet altijd na het inpluggen op dezelfde dag vertrek. Meestal gaat de zonnestroom in de auto voor het resterende deel van de dag en daarna, nadat het laden is gestopt, de batterij leeg aan het huisverbruik.

Het is niet vaak zo dat ik in de ochtend PV slurp en in de middag nog weg ga. Ik ga ofwel voor dag en dauw met de auto weg, of hij is de hele dag thuis. Dus om nu de boost modus altijd in te schakelen als er nog PV-opwek resterend is, hoeft ook niet...

[ Voor 31% gewijzigd door JanHenk op 08-09-2025 13:48 ]

[JanHenk]

JanHenk schreef op maandag 8 september 2025 @ 08:57:
Tegenwoordig heb ik hem bijna vast op 1-fase staan. Maar, wat ik eigenlijk zou willen is dat ie bij gepland snel laden, zoals bij laadplan, goedkope tarieven, etc. (in de PV-modus) of de snel laden (fast-modus) zelf schakelt naar 3-fase. Maar bij het reguliere PV-laden, dat ie in de 1-fase modus blijft.

Even self-quote. Maar dit zou ik natuurlijk ook kunnen oplossen met HA (schakelen tussen 1- en 3-fase). Echter is er geen sensor om het onderscheid te maken tussen 'regulier' PV-laden of 'tijdelijke boost i.v.m. laadplan, tarieven, etc.' in de PV-modus.

Of zie ik hier ook weer iets over het hoofd?

[Kammika]

JanHenk schreef op maandag 8 september 2025 @ 13:44:
[...]


Even self-quote. Maar dit zou ik natuurlijk ook kunnen oplossen met HA (schakelen tussen 1- en 3-fase). Echter is er geen sensor om het onderscheid te maken tussen 'regulier' PV-laden of 'tijdelijke boost i.v.m. laadplan, tarieven, etc.' in de PV-modus.

Of zie ik hier ook weer iets over het hoofd?

volgens mij kan dat niet in evcc zelf. Maar als je je lader in HA stopt en een custom lader in EVCC maakt, kun je natuurlijk in HA makkelijk bijautomatiseren wat EVCC zelf niet kan...

[Kammika]

Weet iemand trouwens waar je iets van roadmap kunt vinden? Ik merk nu dat EVCC het best aardig doet met zo'n thuisbatterij. Maar je blijft wel 2 apparaten houden die op 0 op de meter sturen.

EVCC houdt in zijn calculaties rekening met wat de batterij doet, maar blijft suboptimaal. Liefst zou je gewoon willen dat 1 systeem beide bestuurt.

Want nu krijg je of veel "schommelgedrag" omdat beiden die 0 op de meter beinvloeden, of je moet je interval timeout verruimen, zodat de batterij zijn werk voldoende gedaan kan hebben voordat EVCC weer gaat rekenen. Maar dat laatste is natuurlijk weer ongewenst, omdat EVCC ook de loadbalancing doet. Dus je wil ook niet dat die daar te laat op gaat schakelen...

Als EVCC beide bestuurt, heb je daar veel minder last van..

[Bravo]

JanHenk schreef op maandag 8 september 2025 @ 13:44:
[...]


Even self-quote. Maar dit zou ik natuurlijk ook kunnen oplossen met HA (schakelen tussen 1- en 3-fase). Echter is er geen sensor om het onderscheid te maken tussen 'regulier' PV-laden of 'tijdelijke boost i.v.m. laadplan, tarieven, etc.' in de PV-modus.

Of zie ik hier ook weer iets over het hoofd?

Nee, volgens mij zie je niet iets over het hoofd.
Ik heb een tijdje terug een discussie gelezen op de Github in relatie tot 1-fase 32A (PV) en 3-fase laden (Fast, boost, whatever the reason to go to the max) en dat de planning er niet mee om kan gaan dat je 3-fase 16A maximaal beschikbaar hebt. Je moet kiezen tussen of 1 fase 32A of 3 fase 16A, een mengelmoes leidt ertoe dat hij ermee rekent dat de auto 3 fase 32A lust...

[Bravo]

Kammika schreef op maandag 8 september 2025 @ 13:53:
Weet iemand trouwens waar je iets van roadmap kunt vinden? Ik merk nu dat EVCC het best aardig doet met zo'n thuisbatterij. Maar je blijft wel 2 apparaten houden die op 0 op de meter sturen.

EVCC houdt in zijn calculaties rekening met wat de batterij doet, maar blijft suboptimaal. Liefst zou je gewoon willen dat 1 systeem beide bestuurt.

Want nu krijg je of veel "schommelgedrag" omdat beiden die 0 op de meter beinvloeden, of je moet je interval timeout verruimen, zodat de batterij zijn werk voldoende gedaan kan hebben voordat EVCC weer gaat rekenen. Maar dat laatste is natuurlijk weer ongewenst, omdat EVCC ook de loadbalancing doet. Dus je wil ook niet dat die daar te laat op gaat schakelen...

Als EVCC beide bestuurt, heb je daar veel minder last van..

Op de github kun je redelijk volgen waar ze mee bezig zijn en wat prioriteit heeft.

Wat betreft het schommelen, dat is op te lossen door de batterij naar evcc te laten luisteren. Ik zie dat de Marstek het actieve batterijsturing symbooltje heeft bij evcc, dus dat zou moeten lukken als je die van NOM naar handmatig zet?

code:

maxchargepower: 2500 # Maximale Ladeleistung (W), 2500W ist das Maximum für Venus. (optional)
work_mode_normal: 1 # Work mode für Normal-Modus, 0=manuell, 1=Eigenverbrauch, 2=AI-Optimierung. (optional)

[ Voor 13% gewijzigd door Bravo op 08-09-2025 14:02 ]

[JanHenk]

Bravo schreef op maandag 8 september 2025 @ 13:56:
[...]

Nee, volgens mij zie je niet iets over het hoofd.
Ik heb een tijdje terug een discussie gelezen op de Github in relatie tot 1-fase 32A (PV) en 3-fase laden (Fast, boost, whatever the reason to go to the max) en dat de planning er niet mee om kan gaan dat je 3-fase 16A maximaal beschikbaar hebt. Je moet kiezen tussen of 1 fase 32A of 3 fase 16A, een mengelmoes leidt ertoe dat hij ermee rekent dat de auto 3 fase 32A lust...

Ja, dat soort dingen spelen bij mij niet zozeer (heb een 11 kW wallbox) maar bij een vriend van mij (waar ik ook een evcc instantie heb draaien) wel. Heb er ook al eens wat over geschreven op Github. Je zou eigenlijk een maximum vermogen moeten kunnen ingeven van de auto t.b.v. de planner, waar de planner dan rekening mee kan houden. Dat is nu niet zo, helaas.

In de auto-configuratie zit wel een maxcurrent: optie, maar die is vrij nutteloos in mijn ogen. maxPower is nuttiger in zo'n geval, of in ieder geval een gewenste aanvulling. Dan is dat issue met de planner ook opgelost.

Daarnaast zou ie natuurlijk ook moeten rekenen met de ingestelde loadbalancing maxPower. Ook die wordt nu genegeerd door de planner. Voor de Belgen onder ons zeer relevant.

[Kammika]

Bravo schreef op maandag 8 september 2025 @ 13:57:
[...]

Op de github kun je redelijk volgen waar ze mee bezig zijn en wat prioriteit heeft.

Wat betreft het schommelen, dat is op te lossen door de batterij naar evcc te laten luisteren. Ik zie dat de Marstek het actieve batterijsturing symbooltje heeft bij evcc, dus dat zou moeten lukken als je die van NOM naar handmatig zet?

code:

maxchargepower: 2500 # Maximale Ladeleistung (W), 2500W ist das Maximum für Venus. (optional)
work_mode_normal: 1 # Work mode für Normal-Modus, 0=manuell, 1=Eigenverbrauch, 2=AI-Optimierung. (optional)

ja dat zou misschien werken, maar dan mis ik nog wat functies in evcc om die batterij te besutren (bv manueel naar vol, of juist ontladen of whatever). Daarom hangt die in HA en heb ik een custom battery die de api's van HA aanroept voor de batterij en dan doet die geen actieve sturing. Maar goede tip ik ga er eens mee experimenteren.

Op github zie ik wel de commits, maar wie je aan welke prio's ze werken?

[Kammika]

Zit toch nog eens naar de docs te kijken, maar denk toch dat er iets nog niet goed gaat.

Er staat een voorbeeld bij de features, waarin de battery supported vehicle charing op de 75% drempel is gezet, en dan staat er deze uitleg bij:

Example: You release the area above 75% for Battery-supported charging. Your home storage has already filled up to 100% during the day. You plug in your electric car in Solar mode. In addition to the available surplus, the released upper 25% of the home battery is now also used to charge the electric car. If there is no surplus available and the charge level of the home storage has fallen to 75%, charging is stopped.

Dat implicieert dat EVCC toch echt al eerder stroom uit die batterij hoort te gaan trekken en dat anders dan dat het nu bij mij gebeurt. Lijkt dus gewoon niet helemaal lekker te werken.. ik zal eens in de officiele evcc discussie, eens kijken wat ze er daar van vinden..

[HyperBart]

Kammika schreef op maandag 8 september 2025 @ 13:30:
Ik gebruik de ha integratie. Daar zit die knop boost from home batterij al in.

Dus daar ga ik eerst eens mee experimenteren. Dat is het makkelijkst…

Bravo schreef op maandag 8 september 2025 @ 13:27:
[...]

Op basis van resterende verwachting zou je daar wel iets mee kunnen. Bijvoorbeeld if forecast PV today remaining > 7,5 kWh > Enable batteryboost at plugin.

[...]

Het zit niet bij de batterij, maar bij de loadpoint variabelen.

REST API of MQTT topic
Set battery boost:

code:

/loadpoints/{id}/batteryboost/{enable}
evcc/loadpoints/<id>/batteryboost  writeable [1/0]

Ik heb dit in een script verwerkt.
Die haalt de verwachting op via de API.
Bepaalt aan de hand daarvan + een ingestelde reserve wat hij moet houden of hij mag ontladen of niet en begint dan X aantal minuten voor zonsopgang met het laden om zo optimaal aan de dag te beginnen

[ Voor 3% gewijzigd door HyperBart op 08-09-2025 14:43 ]

[Kammika]

HyperBart schreef op maandag 8 september 2025 @ 14:43:
[...]


[...]


Ik heb dit in een script verwerkt.
Die haalt de verwachting op via de API.
Bepaalt aan de hand daarvan + een ingestelde reserve wat hij moet houden of hij mag ontladen of niet en begint dan X aantal minuten voor zonsopgang met het laden om zo optimaal aan de dag te beginnen

Dat ziet er goed uit zeg! En ook mooi om deze logica zo te zien. Ik heb het meeste al in HA hangen, dus voor mij wsch wat simpeler om een HA automation te maken.

Je bracht me wel op het idee om iets met het resterende aantal zonneuren te doen. Even zitten zoeken, maar die als je in mqtt kijkt, blijkt evcc die op dit topic te zetten: evcc/site/forecast/solar/today/yield

Dus even getest, en nu ook als sensor beschikbaar in HA, met deze definitie in HA:

code:

name: "EVCC Remaining Solar Forecast Today"
unique_id: evcc_remaing_solar_forecast_today
state_topic: "evcc/site/forecast/solar/today/yield"
unit_of_measurement: "Wh"
device_class: energy

Als ik het werkend heb, zal ik het hier wel plaatsen..

EDIT:

Dit zou 'm moeten zijn (kan pas testen als vanavond de auto weer aangesloten is ;-) ):

code:

alias: Start EVCC Battery Boost
description: >-
  Start EVCC boost modus als er een auto aangesloten is, en er meer dan 1kwh in
  de thuisbaterij zit
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.evcc_carport_connected
      - sensor.marstek_venus_available_energy_in_battery
      - sensor.evcc_remaining_solar_forecast_today
  - trigger: time_pattern
    minutes: /1
conditions:
  - condition: state
    entity_id: binary_sensor.evcc_carport_connected
    state: "on"
  - condition: numeric_state
    entity_id: sensor.marstek_venus_available_energy_in_battery
    above: 600
  - condition: numeric_state
    entity_id: sensor.evcc_remaining_solar_forecast_today
    above: 100
  - condition: state
    entity_id: switch.evcc_carport_battery_boost
    state: "off"
actions:
  - action: switch.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: switch.evcc_carport_battery_boost
mode: single

NOGEENEDIT: De auto is weer thuis, net proefondervindelijk vastgesteld dat dit goed lijkt te werken!

[ Voor 33% gewijzigd door Kammika op 08-09-2025 18:09 ]

[HyperBart]

Kammika schreef op maandag 8 september 2025 @ 15:43:
[...]

Dat ziet er goed uit zeg! En ook mooi om deze logica zo te zien. Ik heb het meeste al in HA hangen, dus voor mij wsch wat simpeler om een HA automation te maken.

Je bracht me wel op het idee om iets met het resterende aantal zonneuren te doen. Even zitten zoeken, maar die als je in mqtt kijkt, blijkt evcc die op dit topic te zetten: evcc/site/forecast/solar/today/yield

Dus even getest, en nu ook als sensor beschikbaar in HA, met deze definitie in HA:

code:

name: "EVCC Remaining Solar Forecast Today"
unique_id: evcc_remaing_solar_forecast_today
state_topic: "evcc/site/forecast/solar/today/yield"
unit_of_measurement: "Wh"
device_class: energy

Als ik het werkend heb, zal ik het hier wel plaatsen..

EDIT:

Dit zou 'm moeten zijn (kan pas testen als vanavond de auto weer aangesloten is ;-) ):

code:

alias: Start EVCC Battery Boost
description: >-
  Start EVCC boost modus als er een auto aangesloten is, en er meer dan 1kwh in
  de thuisbaterij zit
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.evcc_carport_connected
      - sensor.marstek_venus_available_energy_in_battery
      - sensor.evcc_remaining_solar_forecast_today
  - trigger: time_pattern
    minutes: /1
conditions:
  - condition: state
    entity_id: binary_sensor.evcc_carport_connected
    state: "on"
  - condition: numeric_state
    entity_id: sensor.marstek_venus_available_energy_in_battery
    above: 1000
  - condition: numeric_state
    entity_id: sensor.evcc_remaining_solar_forecast_today
    above: 0
  - condition: state
    entity_id: switch.evcc_carport_battery_boost
    state: "off"
actions:
  - action: switch.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: switch.evcc_carport_battery_boost
mode: single

Dank je, dat van jou ziet er ook leuk uit.
Ik ga niet uit van uren zon maar de dagvoorspelling in kWh. Ik ben heel benieuwd naar de herfst en lente dagen binnenkort.
Omdat ik een grotere batterij heb kan ik wat meer bufferen en op termijn gaat die batterij van 15kWh naar 30kWh gaan dus dat scheelt.

[Freezhost]

Ik ben al even aan het prutsen met EVCC, ik wil alleen laden op basis van tarief want mijn teruglevering is over het algemeen te laag om te laden en de laadpaal ondersteund dat ook nog niet helemaal. Ik gebruik een switch in HA om alles aan te sturen maar hij blijft ook laden als het tarief boven de limiet zit vanwege de teruglevering.

Ik heb al een enable en disable toegevoegd met -5000 en 5000 als threshold maar dat werkt niet. Iemand enige idee hoe ik er voor kan zorgen dat hij nooit gaat laden bij teruglevering?

[Bravo]

Freezhost schreef op maandag 8 september 2025 @ 17:04:
Ik ben al even aan het prutsen met EVCC, ik wil alleen laden op basis van tarief want mijn teruglevering is over het algemeen te laag om te laden en de laadpaal ondersteund dat ook nog niet helemaal. Ik gebruik een switch in HA om alles aan te sturen maar hij blijft ook laden als het tarief boven de limiet zit vanwege de teruglevering.

Ik heb al een enable en disable toegevoegd met -5000 en 5000 als threshold maar dat werkt niet. Iemand enige idee hoe ik er voor kan zorgen dat hij nooit gaat laden bij teruglevering?

Kun je een stukje logging delen waarin staat waarom het laadproces wordt gestart?
edit: je geeft aan dat hij door blijft gaan met laden als het tarief boven een limiet komt EN er teruglevering is.

Om te voorkomen dat het laden begint door teruglevering moet je enable threshold op een waarde zetten die nooit gehaald gaat worden. Dat kan -5000 zijn als je PV opwek (+ evt batterij teruglevering) onder deze waarde blijft. Dit werkt blijkbaar, tenminste je geeft niet aan dat er ongewenst een laadsessie wordt gestart.

Om ervoor te zorgen dat het laden stopt, moet je de disable threshold op een waarde zetten dat (ongeacht de teruglevering) het te weinig is. Hier heb je -5000 ingevuld? en een delay van 1m (1 minuut)?

Zou je de logging kunnen laten zien als hij toch doorgaat met laden?

[ Voor 33% gewijzigd door Bravo op 08-09-2025 17:22 ]

[Kammika]

HyperBart schreef op maandag 8 september 2025 @ 16:51:
[...]


Dank je, dat van jou ziet er ook leuk uit.
Ik ga niet uit van uren zon maar de dagvoorspelling in kWh. Ik ben heel benieuwd naar de herfst en lente dagen binnenkort.
Omdat ik een grotere batterij heb kan ik wat meer bufferen en op termijn gaat die batterij van 15kWh naar 30kWh gaan dus dat scheelt.

Die voorspelling die ik uitlees is het resterende aantal watturen van de dag…dus vergelijkbaar als in jouw oplossing…

[Freezhost]

Bravo schreef op maandag 8 september 2025 @ 17:15:
[...]

Kun je een stukje logging delen waarin staat waarom het laadproces wordt gestart?
edit: je geeft aan dat hij door blijft gaan met laden als het tarief boven een limiet komt EN er teruglevering is.

Om te voorkomen dat het laden begint door teruglevering moet je enable threshold op een waarde zetten die nooit gehaald gaat worden. Dat kan -5000 zijn als je PV opwek (+ evt batterij teruglevering) onder deze waarde blijft. Dit werkt blijkbaar, tenminste je geeft niet aan dat er ongewenst een laadsessie wordt gestart.

Om ervoor te zorgen dat het laden stopt, moet je de disable threshold op een waarde zetten dat (ongeacht de teruglevering) het te weinig is. Hier heb je -5000 ingevuld? en een delay van 1m (1 minuut)?

Zou je de logging kunnen laten zien als hij toch doorgaat met laden?

Zojuist nog even zitten spelen en dit is mijn configuratie

code:

loadpoints:
  - title: Oprit
    charger: zappi_custom
    mode: off
    meter: meter_zappi
    enable:      
      delay: 0m
      threshold: -5000
    disable:      
      delay: 0m
      threshold: 0

Het lijkt nu te werken, zodra ik hem op PV zet gaat de switch in HA uit maar, er is nu natuurlijk geen opwek. Alleen dan nu het rare als ik hem op Min+PV zet dan gaat de switch in HA aan terwijl hij volgens het tarief pas om 13 uur aan moet gaan. Zet ik hem dan weer naar PV dan gaat hij uit, het lijkt er dus op dat hij geen rekening houdt met het minimale tarief?

Welk stukje logging wil je? Debug of Trace?

[Bravo]

Freezhost schreef op dinsdag 9 september 2025 @ 11:07:
[...]


Zojuist nog even zitten spelen en dit is mijn configuratie

code:

loadpoints:
  - title: Oprit
    charger: zappi_custom
    mode: off
    meter: meter_zappi
    enable:      
      delay: 0m
      threshold: -5000
    disable:      
      delay: 0m
      threshold: 0

Het lijkt nu te werken, zodra ik hem op PV zet gaat de switch in HA uit maar, er is nu natuurlijk geen opwek. Alleen dan nu het rare als ik hem op Min+PV zet dan gaat de switch in HA aan terwijl hij volgens het tarief pas om 13 uur aan moet gaan. Zet ik hem dan weer naar PV dan gaat hij uit, het lijkt er dus op dat hij geen rekening houdt met het minimale tarief?

Dat de switch aangaat met Min+PV is logisch. Bij Min+PV wordt het laadpunt aangezet met een minimale (meestal 6A) waarde en daarnaast pakt hij alle PV surplus.
Als je dat 'dom' op een schakelaar projecteert (zonder gewenst aantal A mee te kunnen geven) dan gaat de schakelaar inderdaad aan. In dat geval is er geen verschil tussen Min+PV en Fast, allebei is 'aan'.

Welk stukje logging wil je? Debug of Trace?

Debug maakt vaak wel zichtbaar welke keuzes er worden gemaakt en waarom.

Je gebruikt nu 0 als instelling voor disable. Volgens mij gaat dat goed (bij enable kijkt hij dan naar ingestelde min A die behaalt moet worden, maar bij disable lijkt mij dat niet relevant), en zal hij afschakelen als er stroom uit het grid wordt gehaald. Mocht er voldoende (PV)overschot zijn, dan zal het laden door blijven gaan.

[Freezhost]

Bravo schreef op dinsdag 9 september 2025 @ 11:30:
[...]

Dat de switch aangaat met Min+PV is logisch. Bij Min+PV wordt het laadpunt aangezet met een minimale (meestal 6A) waarde en daarnaast pakt hij alle PV surplus.
Als je dat 'dom' op een schakelaar projecteert (zonder gewenst aantal A mee te kunnen geven) dan gaat de schakelaar inderdaad aan. In dat geval is er geen verschil tussen Min+PV en Fast, allebei is 'aan'.


[...]

Debug maakt vaak wel zichtbaar welke keuzes er worden gemaakt en waarom.

Je gebruikt nu 0 als instelling voor disable. Volgens mij gaat dat goed (bij enable kijkt hij dan naar ingestelde min A die behaalt moet worden, maar bij disable lijkt mij dat niet relevant), en zal hij afschakelen als er stroom uit het grid wordt gehaald. Mocht er voldoende (PV)overschot zijn, dan zal het laden door blijven gaan.

Aha, ik snap het, ik deed de aanname dat Min+Pv stond voor onder minimaal tarief of PV-overschot
Maar het minimale tarief is ook al van toepassing op de PV stand. Binnenkort even kijken at er gebeurd als ik teruglevering heb, dat gaat vandaag niet gebeuren helaas.

[Bravo]

Vandaag had ik een planner lopen om de auto voldoende vol te krijgen. Bij het uitschakelen van de planner zag ik de volgende regels in log:

code:

```
[lp-1 ] DEBUG 2025/09/09 15:35:30 projected site power 2464W >= 600W disable threshold
[lp-1 ] DEBUG 2025/09/09 15:35:30 pv disable in 0s
[lp-1 ] DEBUG 2025/09/09 15:35:30 pv disable timer elapsed
[lp-1 ] DEBUG 2025/09/09 15:35:30 pv timer reset
[lp-1 ] DEBUG 2025/09/09 15:35:30 pv timer inactive
[lp-1 ] DEBUG 2025/09/09 15:35:30 charger disable

Dit bij een 600W threshold en 5 minuten instellen. De power wordt ook op dat laadpunt gemeten.
Deze uitkomst was verrassend voor mij, ik had verwacht dat hij nog wel op een lager vermogen door zou gaan totdat de timer van 5 minuten zou zijn verstreken, echter werd de laadactie direct afgekapt.

[SolidStateRadio]

Dankzij dit topic ben ik op het spoor gekomen van EVCC en heb ik het (mede dankzij de info hier) draaiend op een Home Assistant Yellow als plugin. Erg blij mee!

Nu heb ik besloten om de P1-meter (ESPHome) en de SolarEdge via de HA API uit te lezen. EVCC en de Alfen laadpaal communiceren via Modbus. Is het aan te bevelen om toch eens te kijken om de integratie directer te doen, zodat de laadpaal bijvoorbeeld nog wat sneller reageert op veranderingen in de zonopbrengst?

[JanHenk]

@SolidStateRadio Met de PV-opwek doet evcc niks (qua sturing). Alleen voor de presentatie in de GUI. Dus daar is de tussenstap prima. Met SolarEdge-omvormer is dat ook de beste optie, want die staat maar één modbus-connectie toe en die is waarschijnlijk al in gebruik door HA.

Met de P1-meter doet evcc wel wat. Persoonlijk laat ik die het liefste direct uitlezen, maar ik weet niet of dat kan bij jou. Met Home Assistant ertussen heb je mogelijk wel vertraging (als HA bijv. iedere 5 seconden pollt).

[ Voor 23% gewijzigd door JanHenk op 10-09-2025 15:33 ]

[[RNMC] Viper]

Je kunt ook werken met modbus proxy. Zo doe ik het om oa mijn Marstek batterij als SolarEdge direct in EVCC in te lezen.

https://github.com/TCzerny/ha-modbusproxy

[JanHenk]

Klopt, dat heb ik ook een tijdje gebruikt. evcc heeft zelf overigens óók een modbus proxy ingebouwd.

[Get!em]

Ik heb zelf ook de SolarEdge Inline meter, die ik ook via Modbus uitlees en gebruik geen P1 meter in EVCC.

Voor de SolarEdge Modbus, zowel omvormer als de Inline Meter, gebruik ik de Modbus Proxy van EVCC. Vervolgens heb ik zowel EVCC meter en solar alsook HomeAssistant SolarEdge Modbus Multi weer gekoppeld aan die Proxy. Werkt prima.

Over snellere sturing: Default staat EVCC in 30seconden sturing interval (lezen van meters en schrijven/sturen van laadstroom op charger), en ik heb die naar 10 seconden gezet. Zijn er mensen die dat nog sneller hebben gezet? Anders heeft het helemaal geen zin om je P1 of Inlinemeter sneller dan 10 seconden uit te lezen.
https://docs.evcc.io/en/d...ce/configuration/interval

[ Voor 6% gewijzigd door Get!em op 11-09-2025 09:57 ]

[JanHenk]

@Get!em Ik heb hem op 6 seconden. Dat werkt prima. Sporadisch een "warning" van evcc van een mismatch (tussen verwacht en gemeten vermogen), maar dat is vaak maar eenmalig en de eerstvolgende cyclus weer klaar. Het is uiteindelijk de lader van de auto die daadwerkelijk moet reageren natuurlijk.

[Get!em]

JanHenk schreef op donderdag 11 september 2025 @ 10:01:
@Get!em Ik heb hem op 6 seconden. Dat werkt prima. Sporadisch een "warning" van evcc van een mismatch (tussen verwacht en gemeten vermogen), maar dat is vaak maar eenmalig en de eerstvolgende cyclus weer klaar. Het is uiteindelijk de lader van de auto die daadwerkelijk moet reageren natuurlijk.

Ik heb nu ook soms een mismatch, maar dat is 1x per laadsessie ongeveer. Zal eens kijken of 6 seconden ook werkt.

[JanHenk]

Ik heb zelf ook 4 en 5 seconden geprobeerd, maar dat was voor mijn gevoel wel wat te kort. In mijn geval kreeg ik dan een stukje vaker mismatch meldingen.

[niki_lauda]

Vraagje. Ik zie in de interface van EVCC


Hoe kan ik die waarde van de Energie met een factor 1000 verkleinen? Hij komt uit een mqtt en moet eigenlijk in Wh zijn.

[JanHenk]

@niki_lauda Energie is niet zo belangrijk. Ik zit meer te kijken naar die vermogens op regel 2. Dat lijkt me ook niet correct, met 401 en -1.386 kW. Maar goed, ook die zijn niet zo belangrijk volgens mij.

Vermogen onderaan namelijk, die -1,4 kW (teruglevering dus op dat moment) is het belangrijkst. Alleen, dit correspondeert niet met de stroomsterkte op de fases (6,0, 2,0 en 1,0). Daar zit dus ofwel een verschil in timing of überhaupt klopt één van beide niet. Als je geen load balancing of iets dergelijks laat doen door evcc, heb je uiteindelijk alleen de onderste regel (vermogen) nodig. Wil je ook load balancing, dan zou ik even uitzoeken hoe die stroomsterke zo komt.

Verder geen flauw idee waar die andere twee vermogens (op regel 2) vandaan komen. Want zelfs als het W ipv kW is, correspondeert het niet met die -1,4 kW.

Hier is nog wel wat uit te zoeken zeg maar

Ter info, hoe het er bij mij uit ziet:

[niki_lauda]

Klopt maar ik pak regel voor regel.
Oplossing was trouwens (net gevonden) scale: 0.0010

[NoFate]

Een eerste PR is een een feit, zodat we ook fast charging kunnen gaan gebruiken met een phase switching, ideaal voor het capaciteits tarief...

Dat kon helaas nog niet mee EVCC, en daarom gebruikte ik het nog niet, dus ga er volgende week eens tijd insteken...

https://github.com/evcc-io/evcc/pull/23571

Wie wil dit ook testen? Ik denk wel niet dat dit in de nightly build zit

[NoFate]

JanHenk schreef op donderdag 11 september 2025 @ 09:49:
Klopt, dat heb ik ook een tijdje gebruikt. evcc heeft zelf overigens óók een modbus proxy ingebouwd.

@JanHenk hoe werkt dit precies? Ik heb 2 x Venus batterijen, de lilygo heb ik aangeschaft, deze heb ik wellicht nodig dan om het modbus verkeer door te sturen via de Proxy? Hoe is jouw setup?

Iemand die de Venus batterijen al heeft gekoppeld met een lilygo?

[Get!em]

niki_lauda schreef op vrijdag 12 september 2025 @ 17:13:
Klopt maar ik pak regel voor regel.
Oplossing was trouwens (net gevonden) scale: 0.0010

Die bovenste, Energie, is wel degelijk in kWh. Dat is de totale energie die door je P1 meter is geregistreerd sinds inpluggen. Dus al voordat je evcc ging draaien.

[Get!em]

Ter vergelijking mijn actuele plaatje

[NoFate]

Ik heb 2 Venus batterijen, met CT003 in nom mode... Ik zou evcc willen inzetten maar dan om de batterijen NIET te gebruiken voor het laden van de auto, als ik deze toevoeg via modus, hoe gaat dat achterliggend in zijn werk? Gaat hij de batterijen dan uitschakelen zolang de auto aan het laden is? Want dat wil ik ook niet , want dan gaan de batterijen niet gebruikt worden voor de andere huishoudelijke toestellen... De batterijen worden nom geregeld via de CT , dan gaat dat in theorie niet werken? Want de CT ziet altijd een verbruik en gaat toch de batterijen gaan inzetten?

Dat gaat elkaar toch tegenwerken?

[klump4u]

Eindelijk alles in evcc, panelen en Zendure batterij.
Zendure gaat voor en rest is voor auto, wisselen van 1 fase naar 3 fase gaat nu ook goed met de Peblar i.p.v. de Easee lader.
Alles via HomeAssistant

[Kammika]

NoFate schreef op zondag 14 september 2025 @ 07:28:
[...]

@JanHenk hoe werkt dit precies? Ik heb 2 x Venus batterijen, de lilygo heb ik aangeschaft, deze heb ik wellicht nodig dan om het modbus verkeer door te sturen via de Proxy? Hoe is jouw setup?

Iemand die de Venus batterijen al heeft gekoppeld met een lilygo?

Even zoeken op dit forum: er is een apart topic voor waar alles in staat uitgelegd

[NoFate]

Kammika schreef op zondag 14 september 2025 @ 12:00:
[...]

Even zoeken op dit forum: er is een apart topic voor waar alles in staat uitgelegd

Ja, maar dat is iets anders, ik wil niet schakelen met modbus... Ik wil hun eigen NOM gebruiken via de CT... Maar ik wil dat EVCC deze batterijen niet gebruikt...

[Kammika]

NoFate schreef op zondag 14 september 2025 @ 12:16:
[...]

Ja, maar dat is iets anders, ik wil niet schakelen met modbus... Ik wil hun eigen NOM gebruiken via de CT... Maar ik wil dat EVCC deze batterijen niet gebruikt...

Dan moet evcc ‘m via de modbus kunnen uitlezen. Dus dan moet je eeret de instructies van dat draadje volgen om die modbus via tcp aansturing op orde te maken. Daarna kun je de documentatie van de evcc volgen om die batterij in evcc te configureren.

Ik gebruik zelf de Elfin ew11 hiervoor. Werkt imo eenvoudiger dan via een lilygo.

[ Voor 7% gewijzigd door Kammika op 14-09-2025 14:20 ]

[NoFate]

Kammika schreef op zondag 14 september 2025 @ 14:18:
[...]

Dan moet evcc ‘m via de modbus kunnen uitlezen. Dus dan moet je eeret de instructies van dat draadje volgen om die modbus via tcp aansturing op orde te maken. Daarna kun je de documentatie van de evcc volgen om die batterij in evcc te configureren.

Ik gebruik zelf de Elfin ew11 hiervoor. Werkt imo eenvoudiger dan via een lilygo.

Ik weet wel hoe ik dat moet doen... Maar dat was mijn vraag niet:+)
Moet ik volledig afstappen van de CT003? Want die wilt nog steeds nom regelen, waardoor hij toch EVCC gaat tegenwerken

[Kammika]

NoFate schreef op zondag 14 september 2025 @ 16:54:
[...]

Ik weet wel hoe ik dat moet doen... Maar dat was mijn vraag niet:+)
Moet ik volledig afstappen van de CT003? Want die wilt nog steeds nom regelen, waardoor hij toch EVCC gaat tegenwerken

Tsja ik weet even niet hoe het werkt als je de Marstek rechtstreeks in evcc gehangen hebt, want dan doet die volgens de documentatie ook actieve batterijsturing

Bij mij hangt die in home Assistant en staat op nom mode. In evcc is s de batterij geconfigureerd door de de sensoren via homeassistant api op te vragen

De batterij blijft op 0 sturen, en evcc houdt in zijn berekening dan rekening met de batterij. Als die de batterij wil ontladen laat die de auto wat harder opladen en Vice versa. Werkt heel simpel maar zeer effectief.

Ik zou verwachten dat een hetzelfde werkt als je ‘m rechtstreeks in evcc hebt hangen zonder ha ertussen (maar weet dat dus niet zeker)

[NoFate]

Kammika schreef op zondag 14 september 2025 @ 19:41:
[...]

Tsja ik weet even niet hoe het werkt als je de Marstek rechtstreeks in evcc gehangen hebt, want dan doet die volgens de documentatie ook actieve batterijsturing

Bij mij hangt die in home Assistant en staat op nom mode. In evcc is s de batterij geconfigureerd door de de sensoren via homeassistant api op te vragen

De batterij blijft op 0 sturen, en evcc houdt in zijn berekening dan rekening met de batterij. Als die de batterij wil ontladen laat die de auto wat harder opladen en Vice versa. Werkt heel simpel maar zeer effectief.

Ik zou verwachten dat een hetzelfde werkt als je ‘m rechtstreeks in evcc hebt hangen zonder ha ertussen (maar weet dat dus niet zeker)

Voor mij is een API request naar HA ook goed, ik heb hem daar nu in staan via de hame-relay, maar ga binnenkort over op de API zelf, dan is er geen modbus meer nodig...

Kan je de sensoren even sharen die je in EVCC hebt staan om de batterij toe te voegen...?
Maar snap nog steeds niet dat ze elkaar gaan tegenwerken, de CT wilt nom regelen, dan gaan de batterijen toch altijd ontladen als je de auto insteekt? Of wat gaat EVCC doen met de batterijen? Je gaat toch geen Manual modus sturen? Of bv een max discharge? Want die houd daar toch geen rekening mee als je de CT hebt gekoppeld?

Kan je die yaml delen van de sensoren die je gebruikt in EVCC? Vanuit HA dan

[Bravo]

NoFate schreef op zondag 14 september 2025 @ 19:55:
[...]


Voor mij is een API request naar HA ook goed, ik heb hem daar nu in staan via de hame-relay, maar ga binnenkort over op de API zelf, dan is er geen modbus meer nodig...

Kan je de sensoren even sharen die je in EVCC hebt staan om de batterij toe te voegen...?
Maar snap nog steeds niet dat ze elkaar gaan tegenwerken, de CT wilt nom regelen, dan gaan de batterijen toch altijd ontladen als je de auto insteekt? Of wat gaat EVCC doen met de batterijen? Je gaat toch geen Manual modus sturen? Of bv een max discharge? Want die houd daar toch geen rekening mee als je de CT hebt gekoppeld?

Kan je die yaml delen van de sensoren die je gebruikt in EVCC? Vanuit HA dan

Als evcc weet wat het ingaand en uitgaand vermogen van de accu is, dan kan evcc bepalen hoeveel vermogen er 'over' is voor het laden van de auto. Als de auto prioriteit heeft, dan gaat evcc de auto zo hard laten opladen dat er niets voor de batterij over om op te laden. Als PV wegvalt, zal evcc proberen het laden van de auto te verminderen zodat er niets uit de accu komt. Zo kan evcc met een niet actieve batterijaansturing toch de auto laden in combinatie met een thuisbatterij.

Je beeld dat de auto laadt van het net en het huis NOM op de accu draait zal niet lukken. Tenzij je die CT klemmen op een locatie kunt plaatsen dat het laden van de auto niet wordt gemeten. Maar dan mis je vast ook je PV overschot

[Kammika]

NoFate schreef op zondag 14 september 2025 @ 19:55:
[...]


Voor mij is een API request naar HA ook goed, ik heb hem daar nu in staan via de hame-relay, maar ga binnenkort over op de API zelf, dan is er geen modbus meer nodig...

Kan je de sensoren even sharen die je in EVCC hebt staan om de batterij toe te voegen...?
Maar snap nog steeds niet dat ze elkaar gaan tegenwerken, de CT wilt nom regelen, dan gaan de batterijen toch altijd ontladen als je de auto insteekt? Of wat gaat EVCC doen met de batterijen? Je gaat toch geen Manual modus sturen? Of bv een max discharge? Want die houd daar toch geen rekening mee als je de CT hebt gekoppeld?

Kan je die yaml delen van de sensoren die je gebruikt in EVCC? Vanuit HA dan

Ik weet niet wat je bedoelt met ´geen modbus meer nodig´ en `de API zelf gebruiken´. Voor zover mij bekend heeft de Marstek geen publieke API (of heb ik wat gemist), dus enige manier om aan te sturen is iets op de modbus zetten waardoor je dan wel kan besturen.

Anyway: Hier mijn Evcc yaml configuratie. Ik neem aan dat je die yaml bedoelt. (vul zelf even je IP adres en je long lived token in!)

code:

meters:
  - name: Marstek
    type: custom
    power:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.marstek_venus_modbus_ac_power
      method: get
      headers:
        - Authorization: Bearer <LONG_LIVED_ACCESS_TOKEN>
      insecure: true
      jq: (.state | tonumber)  # * -1 indien nodig
    soc:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.marstek_venus_modbus_battery_soc
      method: get
      headers:
        - Authorization: Bearer <LONG_LIVED_ACCESS_TOKEN>
      insecure: true
      jq: .state | tonumber
    capacity: 5.12

Onder site moet je 'm dan ook nog als battery toevoegen, die ziet er dan zo uit in mijn geval:

code:

site:
  meters:
    grid: P1
    pv: SolarEdge
    battery: Marstek

De batterij zelf laat je in de stand dat die op 0 op de meter stuurt.

En voor je vraag of ze niet gaan tegenwerken, is het antwoord nee: juist niet. EVCC stuurt de batterij indirect, doordat die weet dat de batterij op 0 op de meter stuurt, en zorgt op basis daarvan dat er juist overschot of stroombehoefte is waar de batterij op reageert. De batterij moet dus juist op de NOM stand staan om het te laten werken.

[HyperBart]

NoFate schreef op zondag 14 september 2025 @ 10:11:
Ik heb 2 Venus batterijen, met CT003 in nom mode...

OK, de Venus heeft dus zijn eigen logica om op 0 te geraken, zoals zo veel batterijen.

Ik zou evcc willen inzetten maar dan om de batterijen NIET te gebruiken voor het laden van de auto,

Ik begrijp dat die vraag terugkomt maar eigenlijk is dat een beetje een gekke redenering want je hebt een grotere behoefte aan energie dan je opwekt of kan stockeren in de batterij. Waarom mag alleen het huis gebruik maken van de batterij terwijl de auto op dat moment wel stroom van het net mag nemen?

als ik deze toevoeg via modus, hoe gaat dat achterliggend in zijn werk? Gaat hij de batterijen dan uitschakelen zolang de auto aan het laden is? Want dat wil ik ook niet , want dan gaan de batterijen niet gebruikt worden voor de andere huishoudelijke toestellen... De batterijen worden nom geregeld via de CT , dan gaat dat in theorie niet werken? Want de CT ziet altijd een verbruik en gaat toch de batterijen gaan inzetten?

Dat gaat elkaar toch tegenwerken?

Ja en neen. Hoe gaat dat in zijn werk: dat kies je en het is ook afhankelijk van welke modus je evcc draait.
Ik draai bv altijd in PV en heb mijn enable/disable tresholds goed staan voor mij. Verder werk ik met de planner als het zon-seizoen (nu ongeveer) voorbij is, te meer ook omdat ik 15kWh aan batterij thuis heb staan.

Daarnaast kan je ook de batterij sperren als je aan het laden bent. Dus dan stuurt ie een commando naar de batterij dat die niets meer moet doen. Waarom? Omdat je doorgaans op dat moment waarschijnlijk toch goedkope stroom in de nacht aan het tanken bent en dan moet de batterij je huisverbruik niet aanvullen.

Maar je moet niet sperren, je kan ook gewoon de batterij laten ontladen. Als je spert dan houdt hij het SoC aan en als het laden van de wagen stopt dan wordt de block er ook afgehaald.

[HyperBart]

NoFate schreef op zondag 14 september 2025 @ 16:54:
[...]

Ik weet wel hoe ik dat moet doen... Maar dat was mijn vraag niet:+)
Moet ik volledig afstappen van de CT003? Want die wilt nog steeds nom regelen, waardoor hij toch EVCC gaat tegenwerken

Tegenwerken is veel gezegd, de batterij komt als extra meter in het verhaal en doet altijd zelfstandig zijn NOM regeling. evcc kan daar rekening mee houden en op basis van die parameters beslissingen nemen maar hij gaat voorlopig nog niet actief het vermogen van de batterij balanceren met het huisverbruik.

evcc zit "achter het HEMS van de batterij".

[NoFate]

hey @HyperBart @Kammika
bedankt voor de antwoorden, nu weet ik idd meer..

om terug te komen op de API, er is een publieke API sinds een maandje , heb ze al getest door netcat commandos te sturen, werkt goed!
hierbij de link:
https://eu.hamedata.com/e.../MarstekDeviceOpenApi.pdf

ze zijn al druk bezig met een integratie in HA, die komt er snel aan

[NoFate]

@Kammika
daar ik geen modbus gebruik, hoe zien deze entiteiten eruit in HA? kan je daar een screenshot van tonen?
sensor.marstek_venus_modbus_ac_power => geeft deze aan -800 --- 2500 ?
sensor.marstek_venus_modbus_battery_soc => 0% --- 100%

?

[Kammika]

NoFate schreef op maandag 15 september 2025 @ 11:30:
@Kammika
daar ik geen modbus gebruik, hoe zien deze entiteiten eruit in HA? kan je daar een screenshot van tonen?
sensor.marstek_venus_modbus_ac_power => geeft deze aan -800 --- 2500 ?
sensor.marstek_venus_modbus_battery_soc => 0% --- 100%

?

Een screenshot van mij heb je niet veel aan, daar jij kennelijk een andere ha setup hebt.

Maar het is niet zo ingewikkelder. Voor ac power je idd de sensor hebben die het aantal ac volts weergeeft (dus idd in de range van -800 tot 2500). Soc is de state of charge, dus de sensor die aangeeft hoe vol (percentage) de batterij zit

[Kammika]

NoFate schreef op maandag 15 september 2025 @ 11:27:
hey @HyperBart @Kammika
bedankt voor de antwoorden, nu weet ik idd meer..

om terug te komen op de API, er is een publieke API sinds een maandje , heb ze al getest door netcat commandos te sturen, werkt goed!
hierbij de link:
https://eu.hamedata.com/e.../MarstekDeviceOpenApi.pdf

ze zijn al druk bezig met een integratie in HA, die komt er snel aan

Nice! Dat maakt het allemaal een stuk simpeler idd… anyway zie ik tegen die tijd wel. Via modbus over tcp was even knutselen, maar loopt wel als een zonnetje.

[NoFate]

Kammika schreef op maandag 15 september 2025 @ 12:55:
[...]

Een screenshot van mij heb je niet veel aan, daar jij kennelijk een andere ha setup hebt.

Maar het is niet zo ingewikkelder. Voor ac power je idd de sensor hebben die het aantal ac volts weergeeft (dus idd in de range van -800 tot 2500). Soc is de state of charge, dus de sensor die aangeeft hoe vol (percentage) de batterij zit

ok, merci

die soc is bij jouw 0--100 ? of 0 --- 5.12 ? want ik zie dat je idd een capacity hebt ingesteld van 5.12 in evcc?

zo ga ik de sensors aanmaken in HA totdat er een integratie is, ik ga met shell commands werken

bat_soc heb ik nodig? staat nu bv op 89
en dan ga ik de HomeWizard sockets gebruiken, die geven ook -800 --- +2500 aan , anders meot ik de scan_interval te hoog zetten

[ Voor 34% gewijzigd door NoFate op 15-09-2025 13:20 ]

[Kammika]

NoFate schreef op maandag 15 september 2025 @ 13:05:
[...]

ok, merci

die soc is bij jouw 0--100 ? of 0 --- 5.12 ? want ik zie dat je idd een capacity hebt ingesteld van 5.12 in evcc?

zo ga ik de sensors aanmaken in HA totdat er een integratie is, ik ga met shell commands werken

bat_soc heb ik nodig? staat nu bv op 89
en dan ga ik de HomeWizard sockets gebruiken, die geven ook -800 --- +2500 aan , anders meot ik de scan_interval te hoog zetten

[Afbeelding]

tsja.. het is een beetje trial and error, ik ken deze interface niet. Maar naar deze output kijken, is mijn vermoeden dat je bat_soc op het soc veld moet mappen in evcc en grid_power op het power veld in evcc...