Zelfbouw Laadpaal ervaringen

[rene037]

Of alleen als je thuis bent. Ha kan weten of je thuis bent, dus kun je hem alleen laten werken als je (en/of evt partner) thuis bent/is. Alleen bij starten laden, anders kun je niet ff op de fiets naar de supermarkt...

[ Voor 1% gewijzigd door rene037 op 21-07-2025 10:50 . Reden: Tenminste één gramaticafout verbeterd ]

[maart84]

Dat klinkt alsof je spreekt uit ervaring

[Deikke]

Wellicht kun je de auto via een API benaderen of die thuis is/aangesloten is op de lader?
Of een bluetooth tracker in de auto plaatsen die HA kan detecteren?

[ Voor 27% gewijzigd door Deikke op 21-07-2025 11:21 ]

[mukky]

RonJ schreef op maandag 21 juli 2025 @ 08:49:
[...]
Wago heeft tegenwoordig een din-rail adapter voor de welbekende lasklemmen, dat heb ik hier toegepast.

Ooohhhj daar is dat ding dus voor er zat er één in mijn Wago doos maar geen idee wat het was.

Als je een link plaatst laat het deel achter het ? weg, dat zijn tracking links die Elektramat wijzer maken ipv onze community. Heb ‘m hierboven in de quote aangepast.

[rene037]

maart84 schreef op maandag 21 juli 2025 @ 11:18:
Dat klinkt alsof je spreekt uit ervaring

Nee, ik heb het niet. Ik heb rfid gebouwd, maar gebruik ik nooit. Als ik op vakantie ga zet ik hem in groepenkast uit.
Nog nooit iemand op mijn parkeerplek betrapt.

[mukky]

rene037 schreef op maandag 21 juli 2025 @ 11:41:
[...]

Nee, ik heb het niet. Ik heb rfid gebouwd, maar gebruik ik nooit. Als ik op vakantie ga zet ik hem in groepenkast uit.
Nog nooit iemand op mijn parkeerplek betrapt.

Ik zet m dan op solar only, als er iemand laadt kost het mij niets en helpen we allemaal het klimaat een handje. Helaas nog nooit gebruikt maar misschien ook maar beter zo want het is een krappe oprit

[O085105116N]

Ik heb de inepro380-mod aangesloten. Die staat blijkbaar op addr 001, maar dat kan je niet kiezen in de controller. Ik heb hem op 12 gezet. Krijg nogthans de melding dat de ev meter niet kan worden gevonden 9600n/1 is ingesteld.In de controller heb ik custom meter gekozen.

[Solarsparc]

Volgens https://github.com/SmartE...ster/docs/installation.md :

Inepro PRO-380-Mod (should be configured as WAGO 879-30x0, seems to be identical)

[ Voor 29% gewijzigd door Solarsparc op 21-07-2025 16:05 ]

[jossie67]

Sinds gisteren mij huidige evhub omgebouwd met een SmartESVE-3, niet erg ingewikkeld.
Nu wil ik de leds aan de buiten kan ook aansluiten. heeft iemand dat al gedaan?

Nu wil ik ook de waarde van mijn DSMR-reader doorsturen naar de SmartESVE-3 (v3.9.0)

Ik zie twee verschillen steeds langs komen
topic: SmartEVSE-6563/Set/MainsMeter
of
topic: SmartEVSE/Set/MainsMeter

Welke moet ik nu gebruiken

[O085105116N]

Solarsparc schreef op maandag 21 juli 2025 @ 16:02:
Volgens https://github.com/SmartE...ster/docs/installation.md :

[...]

yes, dat had ik inmiddels gevonden, maar dan nog werkt het niet. Krijg de melding dat er geen ev meter beschikbaar is.

Sowieso raar dat ie die melding geeft zodra ik via de API de MAINS data begin te sturen.

[ Voor 53% gewijzigd door O085105116N op 21-07-2025 16:09 ]

[Robbiedobbie]

jossie67 schreef op maandag 21 juli 2025 @ 16:04:
Sinds gisteren mij huidige evhub omgebouwd met een SmartESVE-3, niet erg ingewikkeld.
Nu wil ik de leds aan de buiten kan ook aansluiten. heeft iemand dat al gedaan?

Nu wil ik ook de waarde van mijn DSMR-reader doorsturen naar de SmartESVE-3 (v3.9.0)

Ik zie twee verschillen steeds langs komen
topic: SmartEVSE-6563/Set/MainsMeter
of
topic: SmartEVSE/Set/MainsMeter

Welke moet ik nu gebruiken

Je kan het beste even met MQTT-explorer kijken waar je SmartEVSE zelf op published en daar je topic mee bepalen. Bij mij was het op laatste versie (Toevallig zaterdag ook een laadpaal gebouwd met SmartEVSE) zelfs SmartEVSE/xxxx/Set/MainsMeter waarbij xxxx m'n serienummer is

[Solarsparc]

jossie67 schreef op maandag 21 juli 2025 @ 16:04:
Welke moet ik nu gebruiken

https://github.com/SmartE...15c37abe/SmartEVSE-3/test

Als je feed_mains.sh bekijkt, zie je hoe de "officiele" test het doet, dat is dus incl. serienummer. Er is misschien een topic zonder serienummer zodat je in 1 keer naar meerdere meters kunt sturen? Maar dat zal hier niet aan de orde zijn.

Edit: Nu ik de voorbeelden in configuration.md bekijk, vermoed ik dat die fout of legacy/outdated zijn. De test is /SmartEVSE/<serienummer>/Set/ iig.

[ Voor 14% gewijzigd door Solarsparc op 21-07-2025 16:30 ]

[Solarsparc]

O085105116N schreef op maandag 21 juli 2025 @ 16:07:
[...]


yes, dat had ik inmiddels gevonden, maar dan nog werkt het niet. Krijg de melding dat er geen ev meter beschikbaar is.

100% zeker van de modbus-bedrading en zelfde adres? Dan wellicht even debug-versie flashen om meer informatie te krijgen.

[O085105116N]

Solarsparc schreef op maandag 21 juli 2025 @ 16:50:
[...]


100% zeker van de modbus-bedrading en zelfde adres? Dan wellicht even debug-versie flashen om meer informatie te krijgen.

97,3% Ik heb A en B goed aangesloten, met de multimeter net nog nagemeten. Ik heb er voor de zekerheid een twisted pair kabeltje van gemaakt. Dus de straight gewoon opgedraaid. Adres net nog aangepast van 12 naar 11. Wat ie dan doet is even de de melding ready geven om daarna weer in de status can't read ev meter te geven. ik zal de debug versie eens flashen, kan toch niet zo moeilijk zijn dit.

[Solarsparc]

O085105116N schreef op maandag 21 juli 2025 @ 16:54:
[...]
97,3%

Kunt ook nog checken of de meter niet toevallig als modbus-master is ingesteld, moet slave zijn.

[databeestje]

jossie67 schreef op maandag 21 juli 2025 @ 16:04:
Sinds gisteren mij huidige evhub omgebouwd met een SmartESVE-3, niet erg ingewikkeld.
Nu wil ik de leds aan de buiten kan ook aansluiten. heeft iemand dat al gedaan?

Nu wil ik ook de waarde van mijn DSMR-reader doorsturen naar de SmartESVE-3 (v3.9.0)

Ik zie twee verschillen steeds langs komen
topic: SmartEVSE-6563/Set/MainsMeter
of
topic: SmartEVSE/Set/MainsMeter

Welke moet ik nu gebruiken

Dit is uit mijn voorbeeld hierboven vanuit HA.

code:

- id: '1732101563658'
  alias: Mains Meter Current to SmartEVSE
  description: ''
  triggers:
  - trigger: time_pattern
    seconds: /5
  conditions: []
  actions:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: true
      qos: 0
      retain: false
      topic: SmartEVSE-9999/Set/MainsMeter
      payload: '{% set voltage = states(''sensor.electricity_meter_spanning_fase_l1'')
        |float %}

        {% set import = states(''sensor.electricity_meter_energieverbruik'') | float
        * 10000 |float / voltage %}

        {% set export = states(''sensor.electricity_meter_energieproductie'') | float
        * 10000 |float / voltage %}

        {{ (import - export) | round(0) }}{{ ":0" }}{{ ":0" }}'
  mode: single

De code zet het vermogen om naar de stroom aan de hand van de huidige netspanning.
Dit post uiteindelijk "9.9:0:0" naar "Topic SmartEVSE-9999/Set/MainsMeter"
Mijn SmartEVSE gebruikt op dit moment v3.6.7.

[O085105116N]

ik heb een poging ondernomen om de debug firmware te installeren, dat eindigt met: Firmware update succesfully completed, will reboot as soon as no EV is connected.

Er is geen ev connected, maar ik zie geen herstart en ook geen verandering. Handmatige reboot lijkt ook niet te werken. Dan zegt ie ook dat ie herstart zodra er geen auto aan het laden is.

Ik zie ook net dat ik /? kan openen, dan krijg ik helemaal al "vreemde" details te zien.

[ Voor 11% gewijzigd door O085105116N op 21-07-2025 17:40 ]

[m.eddy]

O085105116N schreef op maandag 21 juli 2025 @ 17:38:
ik heb een poging ondernomen om de debug firmware te installeren, dat eindigt met: Firmware update succesfully completed, will reboot as soon as no EV is connected.

Er is geen ev connected, maar ik zie geen herstart en ook geen verandering. Handmatige reboot lijkt ook niet te werken. Dan zegt ie ook dat ie herstart zodra er geen auto aan het laden is.

Ik zie ook net dat ik /? kan openen, dan krijg ik helemaal al "vreemde" details te zien.

Je moet zelf van die pagina weg navigeren. Ws draai je de debug dus al. Doe eens een telnet naar het ip.

[O085105116N]

ik zie in de logging dat er geen communicatie tot stand kan worden gebracht met de meter. Deze melding: (MBhandleError)(C1) Error response: E0 - Timeout, address: 0a, function: 03, reg: 600c.

[dingo35]

Parity moet None zijn; 9600 N81

[O085105116N]

adres 10 is ingesteld (0a), maar nog altijd de melding dat er geen ev meter is gekoppeld. er is geen auto aangesloten: (V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 46 24 03 71
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x600c Response
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x5012, token:0x0a035012, data: 0x0002.
(V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x5012 Response
(D) (ModbusRequestLoop)(C1) ModbusRequest 20: Request EVMeter Current Measurement Node 0
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x500c, token:0x0a03500c, data: 0x0006.
(V) (ModbusDecode)(C1) Received packet (15 bytes) 0a 03 0c 00 00 00 00 00 00 00 00 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x500c Response
(V) (CalcBalancedCurrent)(C1) Checkpoint 1 Isetbalanced=-1567.3 A Imeasured=1583.3 A MaxCircuit=16 Imeasured_EV=0.0 A, Battery Current = 0.0 A, mode=2.
(V) (CalcBalancedCurrent)(C1) phaseLastUpdate=1753118148.
(V) (CalcBalancedCurrent)(C1) Checkpoint 2 Isetbalanced=0.0 A, Idifference=-1567.3, mod=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 3 Isetbalanced=0.0 A, IsumImport=2384.6, Isum=2384.6, ImportCurrent=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 4 Isetbalanced=-1567.3 A.
(D) (CalcBalancedCurrent)(C1) Checkpoint c: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=-1567.3A, saveActiveEVSE=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 5 Isetbalanced=-1567.3 A.
(V) (ModbusSend8)(C1) Sent packet address: 0x09, function: 0x06, reg: 0x0001, token:0x09060001, data: 0x0009.

[ Voor 17% gewijzigd door O085105116N op 21-07-2025 19:37 ]

[dingo35]

Pariteit aangepast?

[ikke26]

O085105116N schreef op maandag 21 juli 2025 @ 19:25:
adres 10 is ingesteld (0a), maar nog altijd de melding dat er geen ev meter is gekoppeld. er is geen auto aangesloten: (V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 46 24 03 71
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x600c Response
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x5012, token:0x0a035012, data: 0x0002.
(V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x5012 Response
(D) (ModbusRequestLoop)(C1) ModbusRequest 20: Request EVMeter Current Measurement Node 0
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x500c, token:0x0a03500c, data: 0x0006.
(V) (ModbusDecode)(C1) Received packet (15 bytes) 0a 03 0c 00 00 00 00 00 00 00 00 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x500c Response
(V) (CalcBalancedCurrent)(C1) Checkpoint 1 Isetbalanced=-1567.3 A Imeasured=1583.3 A MaxCircuit=16 Imeasured_EV=0.0 A, Battery Current = 0.0 A, mode=2.
(V) (CalcBalancedCurrent)(C1) phaseLastUpdate=1753118148.
(V) (CalcBalancedCurrent)(C1) Checkpoint 2 Isetbalanced=0.0 A, Idifference=-1567.3, mod=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 3 Isetbalanced=0.0 A, IsumImport=2384.6, Isum=2384.6, ImportCurrent=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 4 Isetbalanced=-1567.3 A.
(D) (CalcBalancedCurrent)(C1) Checkpoint c: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=-1567.3A, saveActiveEVSE=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 5 Isetbalanced=-1567.3 A.
(V) (ModbusSend8)(C1) Sent packet address: 0x09, function: 0x06, reg: 0x0001, token:0x09060001, data: 0x0009.

Het kan het perspectief van de foto zijn, maar weet je zeker dat de draadjes in de goede plek op de SmartEVSE zitten en niet één positie verschoven?

Ik heb deze meter ook en bij mij was het ook even rommelen, ook met adressen.
Misschien kun je adres 11 of 12 proberen? Bij mij deed die het op lage adressen eerst ook niet.
Ik weet alleen niet meer of dat (alleen) aan het adres lag of dat ik ook nog een andere setting moest aanpassen.
Het duurt overigens een seconde of 10 voordat de Inepro geldige modbus waarden uitstuurt.

[fishman]

RonJ schreef op maandag 21 juli 2025 @ 08:49:
[...]


Als het goed is heeft je verdeelkast een aardrail om aarde op aan te sluiten. Als je kabel ook aan die zijde binnenkomt dan kan het gewoon direct daarop (en idealiter doe je er een sokje omheen binnen de kast). Als je wil doorverbinden, Wago heeft tegenwoordig een din-rail adapter voor de welbekende lasklemmen, dat heb ik hier toegepast.

Goed info, dankjewel.

[O085105116N]

dingo35 schreef op maandag 21 juli 2025 @ 19:52:
Pariteit aangepast?

yes, ik zie dus ook berichten binnenkomen, maar die kunnen niet kloppen. Er wordt verbruik gemeten, maar er zit geen auto aan. Die details worden ook weergegeven bij de mains meter.

Ik kan verschillende ev meters kiezen, ik zie letterlijk de getallen bij MAINS meter wijzigen, dat kan niet kloppen. Ik draai nu ook 3.9 debug om te testen.

Kan je wel MAINS=API en EVmeter=WAGO zetten? Dat lijkt bij mij helemaal verkeerd te gaan.

De EV data komt bij MAINS terecht.

Van de ruwe data:
ev_meter
description "WAGO"
address 10
import_active_power 0
total_kwh 0
charged_kwh 0
currents
TOTAL 0
L1 0
L2 0
L3 0
import_active_energy 0
export_active_energy 0
mains_meter
import_active_energy 0
export_active_energy 0
phase_currents
TOTAL -25407
L1 -12050
L2 0
L3 -13357
last_data_update 1753137228
original_data
TOTAL -25407
L1 -12050
L2 0
L3 -13357

de telnet log:
(D) (ModbusRequestLoop)(C0) ModbusRequest 4: Request Energy Node 0
(V) (ModbusSend8)(C0) Sent packet address: 0x0a, function: 0x03, reg: 0x600c, token:0x0a03600c, data: 0x0002.
(I) (Timer1S_singlerun)(C0) Not enough current available!
(V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 46 24 03 71
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x600c Response
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x5012, token:0x0a035012, data: 0x0002.
(V) (ModbusDecode)(C1) Received packet (7 bytes) 0a 03 04 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x5012 Response
(D) (ModbusRequestLoop)(C1) ModbusRequest 20: Request EVMeter Current Measurement Node 0
(V) (ModbusSend8)(C1) Sent packet address: 0x0a, function: 0x03, reg: 0x500c, token:0x0a03500c, data: 0x0006.
(V) (ModbusDecode)(C1) Received packet (15 bytes) 0a 03 0c 00 00 00 00 00 00 00 00 00 00 00 00
(V) (ModbusDecode)(C1) valid Modbus packet: Address 0x0a Function 0x03 Register 0x500c Response
(V) (CalcBalancedCurrent)(C1) Checkpoint 1 Isetbalanced=-1567.3 A Imeasured=1583.3 A MaxCircuit=16 Imeasured_EV=0.0 A, Battery Current = 0.0 A, mode=1.
(V) (CalcBalancedCurrent)(C1) phaseLastUpdate=1753136324.
(V) (CalcBalancedCurrent)(C1) Checkpoint 2 Isetbalanced=0.0 A, Idifference=-1567.3, mod=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 4 Isetbalanced=-1567.3 A.
(D) (CalcBalancedCurrent)(C1) Checkpoint c: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=-1567.3A, saveActiveEVSE=0.
(V) (CalcBalancedCurrent)(C1) Checkpoint 5 Isetbalanced=-1567.3 A.
(V) (ModbusSend8)(C1) Sent packet address: 0x09, function: 0x06, reg: 0x0001, token:0x09060001, data: 0x0009.

[ Voor 87% gewijzigd door O085105116N op 22-07-2025 00:38 ]

[dingo35]

Mains=API en EV=Wago is prima instelling; in de log zie je dat je Wago via modbus 0 waardes ontvangt, wat logisch is als je er geen auto aan hebt hangen.

En je stuurt via je API belachelijk hoge waardes, dat is ook zichtbaar in de logs. Je moet de waarde in deci-Ampères sturen, dus 100 = 10.0A.

Lees anders de handleiding eens, daar ataat t allemaal in: https://github.com/dingo3...ation.md#how-to-configure

[adjego]

ikke26 schreef op maandag 21 juli 2025 @ 22:21:
[...]


Het kan het perspectief van de foto zijn, maar weet je zeker dat de draadjes in de goede plek op de SmartEVSE zitten en niet één positie verschoven?

Ik heb deze meter ook en bij mij was het ook even rommelen, ook met adressen.
Misschien kun je adres 11 of 12 proberen? Bij mij deed die het op lage adressen eerst ook niet.
Ik weet alleen niet meer of dat (alleen) aan het adres lag of dat ik ook nog een andere setting moest aanpassen.
Het duurt overigens een seconde of 10 voordat de Inepro geldige modbus waarden uitstuurt.

@O085105116N Je draadjes zitten helemaal verkeerd zo het lijkt. A/B zijn de eerste twee posities van de onderste aansluitingen, en op de foto lijk jij positie 2 en 3 te gebruiken.

[O085105116N]

Het is bijna helemaal gelukt! Ik heb adres 10/11/12 getest die werken niet. Kan met MBus overlap te maken hebben? Ik heb adres 15 getest en nu begint e.e.a op de juiste plek binnen te druppelen. Ik gebruik V3.9 Debug op dit moment.

adjego schreef op dinsdag 22 juli 2025 @ 08:13:
[...]


@O085105116N Je draadjes zitten helemaal verkeerd zo het lijkt. A/B zijn de eerste twee posities van de onderste aansluitingen, en op de foto lijk jij positie 2 en 3 te gebruiken.

Die zitten gewoon op de eerste 2 posities van de controller.

[ Voor 24% gewijzigd door O085105116N op 22-07-2025 11:33 ]

[O085105116N]

dingo35 schreef op dinsdag 22 juli 2025 @ 07:46:
Mains=API en EV=Wago is prima instelling; in de log zie je dat je Wago via modbus 0 waardes ontvangt, wat logisch is als je er geen auto aan hebt hangen.

En je stuurt via je API belachelijk hoge waardes, dat is ook zichtbaar in de logs. Je moet de waarde in deci-Ampères sturen, dus 100 = 10.0A.

Lees anders de handleiding eens, daar ataat t allemaal in: https://github.com/dingo3...ation.md#how-to-configure

Ik heb de automation die de mains waardes stuurt uitgeschakeld. De EV meter werkt hoe dan ook niet, ook al komen de pakketten aan, hij blijft aangeven, can't read ev meter.

Die waardes van MAINS, komen echt van de ev meter af. Zodra ik het modbus adres weer terug zet op het adres van de meter, vult ie daar de waardes weer in. Ik draai nu ook in solarmode, maar ik mis nu opties? Ik geloof het scherm battery mist hier?



en nu ook deze, maar nu valt op dat er wel iets bij ev meter staat, ik snap er niks van:

[ Voor 40% gewijzigd door O085105116N op 22-07-2025 11:24 ]

[ikke26]

O085105116N schreef op dinsdag 22 juli 2025 @ 09:24:
[...]


Ik heb de automation die de mains waardes stuurt uitgeschakeld. De EV meter werkt hoe dan ook niet, ook al komen de pakketten aan, hij blijft aangeven, can't read ev meter.

Die waardes van MAINS, komen echt van de ev meter af. Zodra ik het modbus adres weer terug zet op het adres van de meter, vult ie daar de waardes weer in. Ik draai nu ook in solarmode, maar ik mis nu opties? Ik geloof het scherm battery mist hier?

[Afbeelding]

en nu ook deze, maar nu valt op dat er wel iets bij ev meter staat, ik snap er niks van:


[Afbeelding]

Als de rest het nog niet doet, zou je bij de Inepro wanneer het wel werkt in ieder geval de total kWh charged moeten kunnen uitlezen. In principe doet de rest het dan ook.

Ik had het idee dat toen de config nog niet klopte, de SmartEVSE zich niet leek te herstellen van de foutmelding tot ik de stroom er een minuut af had gehaald / een reboot had gedaan. Als ik dat niet deed, kreeg ik ook allerlei vreemd gedrag van de EVSE. Mains en EV op hetzelfde modbus adres zetten zorgde ook voor fouten.
Misschien dat het helpt om mains eerst weer uit te zetten dan exit menu en herstart en dan opnieuw instellen?

[ Voor 8% gewijzigd door ikke26 op 22-07-2025 13:14 ]

[O085105116N]

ikke26 schreef op dinsdag 22 juli 2025 @ 13:11:
[...]


Als de rest het nog niet doet, zou je bij de Inepro wanneer het wel werkt in ieder geval de total kWh charged moeten kunnen uitlezen. In principe doet de rest het dan ook.

Ik had het idee dat toen de config nog niet klopte, de SmartEVSE zich niet leek te herstellen van de foutmelding tot ik de stroom er een minuut af had gehaald / een reboot had gedaan. Als ik dat niet deed, kreeg ik ook allerlei vreemd gedrag van de EVSE. Mains en EV op hetzelfde modbus adres zetten zorgde ook voor fouten.
Misschien dat het helpt om mains eerst weer uit te zetten dan exit menu en herstart en dan opnieuw instellen?

Als ik modbus adrr 10/11/12 gebruik gaat het onherroepelijk fout, ik heb modbus 15 gepakt en daarna begon alles te werken. Als ik 10/11/12 gebruik, komen de ev meter details bij MAINS terecht en ook nog eens helemaal fout. Pak ik adres 15 icm WAGO dan gaat het goed. MAINS staat al die tijd al op API.

[dingo35]

Het enige wat ik kan bedenken bij dit vreemde gedrag:
-hangt er nog iets anders op de modbus?
-geen fout bij hexadecimaal/decimaal ingeven van het adres bij meter en/of SmartEVSE?

Als je software fout wil uitsluiten kun je via "upgrade" vrij gemakkelijk downgraden naar de huidige stabiele versie v3.8.5; in v3.9.0 is maar 1 known bug en dit is m niet ...

EDIT : post je /settings eens geheel, dus via een volledige json cut'n paste, en niet een half bewerkt iets ...

[ Voor 13% gewijzigd door dingo35 op 22-07-2025 15:27 ]

[O085105116N]

dingo35 schreef op dinsdag 22 juli 2025 @ 15:23:
Het enige wat ik kan bedenken bij dit vreemde gedrag:
-hangt er nog iets anders op de modbus?
-geen fout bij hexadecimaal/decimaal ingeven van het adres bij meter en/of SmartEVSE?

Als je software fout wil uitsluiten kun je via "upgrade" vrij gemakkelijk downgraden naar de huidige stabiele versie v3.8.5; in v3.9.0 is maar 1 known bug en dit is m niet ...

EDIT : post je /settings eens geheel, dus via een volledige json cut'n paste, en niet een half bewerkt iets ...

Nee er hangt verder niks aan de modbus, volgens mij is er wel overlap op M-bus adressen. ik heb nu gedowngrade naar 3..8.5. Nu de kwh meter op addr 15 draait gaat alles prima, ook hier geen gekke dingen meer met verkeerd weergeven van MAINS en EV meter.

Je kan niks meer instellen als de ev meter of WAGO staat, dat kan alleen bij Custom. En dan nog kan ik niet verklaren waar die vreemde waardes vandaan kwamen.

[creon]

Hoe zou ik de boel zo in kunnen stellen dat de stroom niet naar de huis accu gaat maar naar de wagen
Ik heb de home wizard P1 dongel gekoppeld aan de EVSE en ook een eastron welke bijhoud hoeveel er de wagen in gaat
Als ik de evse op solar zet dat wordt het vermogen elke keer met een klein stapje opgevoerd totdat de home wizard meld dat er stroom verbruikt wordt
Maar met een thuis accu werkt dat niet omdat de thuis accu dus ook stroom gaat leveren aan de evse

[BarryH]

creon schreef op dinsdag 22 juli 2025 @ 18:33:
Hoe zou ik de boel zo in kunnen stellen dat de stroom niet naar de huis accu gaat maar naar de wagen
Ik heb de home wizard P1 dongel gekoppeld aan de EVSE en ook een eastron welke bijhoud hoeveel er de wagen in gaat
Als ik de evse op solar zet dat wordt het vermogen elke keer met een klein stapje opgevoerd totdat de home wizard meld dat er stroom verbruikt wordt
Maar met een thuis accu werkt dat niet omdat de thuis accu dus ook stroom gaat leveren aan de evse

Hangt van de thuisaccu af, wat kan je daar aan aansturen. Dus apart topic van maken

[O085105116N]

Ik kan iig mededelen dat alles nu goed lijkt te werken. Uiteindelijk bleek mijn DSMR integratie in HA ook nog gescrashed. Die gaf dus ook nog maar lange tijd 1 waarde door. Iets om rekening mee te houden als ik dit via HA laat werken.

Wat geeft dit scherpje precies aan en waarom?

[ Voor 24% gewijzigd door O085105116N op 23-07-2025 10:49 ]

[tukker999]

creon schreef op dinsdag 22 juli 2025 @ 18:33:
Hoe zou ik de boel zo in kunnen stellen dat de stroom niet naar de huis accu gaat maar naar de wagen
Ik heb de home wizard P1 dongel gekoppeld aan de EVSE en ook een eastron welke bijhoud hoeveel er de wagen in gaat
Als ik de evse op solar zet dat wordt het vermogen elke keer met een klein stapje opgevoerd totdat de home wizard meld dat er stroom verbruikt wordt
Maar met een thuis accu werkt dat niet omdat de thuis accu dus ook stroom gaat leveren aan de evse

Dat regel je met homeassistant of domoticz.
Programmeren is - voor mij althans - een pak makkelijker in domoticz dan in homeassistant.
Bovendien regelt AI het.
Ik vertel welke sensoren er zijn en wat ze meten en stel een eisenpakket op.

[jpiscaer]

Hoe sturen jullie de P1 data naar SmartEVSE? Ik heb een SlimmeLezer+ (en ook een DSMR-reader met een USB-P1 kabel eventueel), en natuurlijk HomeAssistant (waar zowel SlimmerLezer+ als DSMR-reader geintegreerd zijn)

Edit: er lijkt een esphome config te zijn van slimmelezer+ om direct naar de Smart EVSE te sturen, daar kijk ik ff naar. Eerst indruk geeft me een boel esphome yaml syntax errors, maar zou wel de handigste optie zijn (zonder MQTT, zonder HomeAssistant)

[ Voor 37% gewijzigd door jpiscaer op 24-07-2025 00:35 ]

[tukker999]

Ik stuur geen P1 data naar de SmartEVSE.
De software bepaalt de laadstroom aan de hand van de data van P1 en die stuurt vervolgens met MQTT de waarde van de CurrentOverride.
Dus niet met Solar of Smart maar met mode Normal.
Mijn software werkt met een buffer zodat het laden niet steeds wisselt bij het kleinste wolkje voor de zon.

[mukky]

jpiscaer schreef op woensdag 23 juli 2025 @ 23:30:
Hoe sturen jullie de P1 data naar SmartEVSE? Ik heb een SlimmeLezer+ (en ook een DSMR-reader met een USB-P1 kabel eventueel), en natuurlijk HomeAssistant (waar zowel SlimmerLezer+ als DSMR-reader geintegreerd zijn)

Edit: er lijkt een esphome config te zijn van slimmelezer+ om direct naar de Smart EVSE te sturen, daar kijk ik ff naar. Eerst indruk geeft me een boel esphome yaml syntax errors, maar zou wel de handigste optie zijn (zonder MQTT, zonder HomeAssistant)

Yes, die optie gebruik ik ook. Vind alleen de afhankelijkheid van wifi nog een puntje, laatst vloog Ziggo eruit en dan stopt het laden dus ook. Enfin dat wordt weer een ander project.

[JoooostB]

mukky schreef op donderdag 24 juli 2025 @ 07:44:
[...]

Yes, die optie gebruik ik ook. Vind alleen de afhankelijkheid van wifi nog een puntje, laatst vloog Ziggo eruit en dan stopt het laden dus ook. Enfin dat wordt weer een ander project.

In principe is er niks aan de hand als Ziggo eruit vliegt toch? De communicatie is immers lokaal.

[mukky]

JoooostB schreef op donderdag 24 juli 2025 @ 09:01:
[...]


In principe is er niks aan de hand als Ziggo eruit vliegt toch? De communicatie is immers lokaal.

Klopt maar in dit geval crashte de modem (rood lampje) waardoor ook het Wifi signaal wegviel

[stefxx]

mukky schreef op donderdag 24 juli 2025 @ 09:02:
[...]

Klopt maar in dit geval crashte de modem (rood lampje) waardoor ook het Wifi signaal wegviel

Lijkt me makkelijk op te lossen door geen Ziggo te gebruiken... of anders in ieder geval een fatsoenlijke router

[Elmardus]

Bij het plaatsen van mijn laadpaal ben ik wel voornemens de Sensorbox v2 te installeren, die via de Homewizard P1-splitter ook op de P1-poort is aangesloten naast de slimmelezer. Als mijn wifi/router om wat voor reden dan ook uitvalt, lijkt het mij niet handig om de hoofdzekering te moeten laten vervangen zodra er een wolkje voor de zon verschijnt.

Ik kan het SmartEVSE-circuit namelijk dimensioneren op 32A in verband met de solaropbrengst (op een 25A hoofdzekering), maar dat gaat alleen goed zolang de zon ook daadwerkelijk schijnt. Volgens de NEN1010 is dit toegestaan, zolang er bescherming tegen overbelasting is, maar het lijkt mij onverstandig om dit van wifi te laten afhangen.

[adjego]

Elmardus schreef op donderdag 24 juli 2025 @ 09:12:
Bij het plaatsen van mijn laadpaal ben ik wel voornemens de Sensorbox v2 te installeren, die via de Homewizard P1-splitter ook op de P1-poort is aangesloten naast de slimmelezer. Als mijn wifi/router om wat voor reden dan ook uitvalt, lijkt het mij niet handig om de hoofdzekering te moeten laten vervangen zodra er een wolkje voor de zon verschijnt.

Ik kan het SmartEVSE-circuit namelijk dimensioneren op 32A in verband met de solaropbrengst (op een 25A hoofdzekering), maar dat gaat alleen goed zolang de zon ook daadwerkelijk schijnt. Volgens de NEN1010 is dit toegestaan, zolang er bescherming tegen overbelasting is, maar het lijkt mij onverstandig om dit van wifi te laten afhangen.

Zodra connectiviteit van de "API" wegvalt zal de laadpaal stoppen met laden, en niet lukraak maar gewoon blijven doorgaan met laden. Dus dat zomaar je hoofdzekeringen eruit springen bij wegvallende wifi is niet van toepassing.

[Elmardus]

adjego schreef op donderdag 24 juli 2025 @ 09:19:
[...]
Zodra connectiviteit van de "API" wegvalt zal de laadpaal stoppen met laden, en niet lukraak maar gewoon blijven doorgaan met laden. Dus dat zomaar je hoofdzekeringen eruit springen bij wegvallende wifi is niet van toepassing.

Ah! Hier heb ik overheen gelezen. In dat geval kan ik wel een P1 splitter + sensorbox uitsparen. Dat maakt het wel interessant. Als dan het laden een keertje stopt vind ik dat wel prima.

Voor anderen die deze nog niet gevonden hadden: Slimmelezer esphome yaml config

[jpiscaer]

Elmardus schreef op donderdag 24 juli 2025 @ 09:25:
[...]

Voor anderen die deze nog niet gevonden hadden: Slimmelezer esphome yaml config

nevermind.

[ Voor 17% gewijzigd door jpiscaer op 24-07-2025 10:02 ]

[mapsy]

jpiscaer schreef op donderdag 24 juli 2025 @ 09:27:
[...]


nevermind.

Met esphome 2025.6.1 moest ik in de yaml wel headers: veranderen naar request_headers:

[con1]

Ik ben bezig met het zelfbouwen van een laadgelegenheid met de SmartEvse.

Zou iemand (of meerderen) een screenshot kunnen plaatsen wat je allemaal
kunt uitlezen maar ook kunt instellen in Home Assistant?

[ikke26]

@con1

Cable lock: 0 of 1.
Op rij 2 staat "charge current override"
Custom button on of off
Modus Off, Normal, Smart, Solar, Pause

[con1]

ikke26 schreef op donderdag 24 juli 2025 @ 11:56:
@con1

Cable lock: 0 of 1.
Op rij 2 staat "charge current override"
Custom button on of off
Modus Off, Normal, Smart, Solar, Pause
[Afbeelding]

Top, bedankt.

Met welke button? of dropdown? kun je kiezen tussen 1 en 3 fase laden?

[sandergar]

con1 schreef op donderdag 24 juli 2025 @ 12:20:
[...]


Top, bedankt.

Met welke button? of dropdown? kun je kiezen tussen 1 en 3 fase laden?

[ikke26]

sandergar schreef op donderdag 24 juli 2025 @ 12:49:
[...]

[Afbeelding]

Dit is zo te zien een screenshot van de oude HA integratie en niet van de nieuwere MQTT integratie?

In de MQTT integratie kan ik de C2 contactor optie niet vinden, maar van wat ik begreep wordt het gebruik van de HA integratie afgeraden @dingo35 ?

[mukky]

stefxx schreef op donderdag 24 juli 2025 @ 09:06:
[...]


Lijkt me makkelijk op te lossen door geen Ziggo te gebruiken... of anders in ieder geval een fatsoenlijke router

In september komt er Freedom met een eigen Mikrotik router. Wordt aan gewerkt dus

[dingo35]

ikke26 schreef op donderdag 24 juli 2025 @ 13:11:
[...]


Dit is zo te zien een screenshot van de oude HA integratie en niet van de nieuwere MQTT integratie?

In de MQTT integratie kan ik de C2 contactor optie niet vinden, maar van wat ik begreep wordt het gebruik van de HA integratie afgeraden @dingo35 ?

MQTT is lichter, sneller; als de HA integratie doet wat je wil kun je die prima gebruiken, maar gebruikersspecifieke wensen voer ik niet meer door; de HA ontwikkelomgeving wijzigt een paar keer per jaar en is slecht gedocumenteerd, waardoor het altijd weer een hopeloze zoekactie is naar de juiste syntax van die maand ...

[ruud76]

jpiscaer schreef op woensdag 23 juli 2025 @ 23:30:
Hoe sturen jullie de P1 data naar SmartEVSE? Ik heb een SlimmeLezer+ (en ook een DSMR-reader met een USB-P1 kabel eventueel), en natuurlijk HomeAssistant (waar zowel SlimmerLezer+ als DSMR-reader geintegreerd zijn)

Edit: er lijkt een esphome config te zijn van slimmelezer+ om direct naar de Smart EVSE te sturen, daar kijk ik ff naar. Eerst indruk geeft me een boel esphome yaml syntax errors, maar zou wel de handigste optie zijn (zonder MQTT, zonder HomeAssistant)

Klopt, die heb ik gemaakt maar is voor de wrt32-eth1 versie en staat in de SmartEVSE repo. Zorg dat je SmartEVSE altijd hetzelfde ip adres krijgt en zet dat op in de yaml file die je in de smartevse repo vindt. Na het laden van de yaml file in de slimmelezer zet je in home assistant (bij de slimmelezer) de SmartEVSE integratie aan (kan ook op de webpagina van de slimmelezer) en dat zou het moeten zijn. De slimmelezer geeft het energieverbruik dan direct aan de SmartEVSE door via de REST API, zonder tussenkomst van Home Assistant.

Als je niet de wt32-eth1 versie van de slimmelezer hebt dan kun je de wijzigingen (ik heb ze allemaal gemarkeerd) toepassen op de yaml file van jouw slimmelezer en zou het ook moeten werken.

Laat maar weten als je er niet uit komt.

[ Voor 40% gewijzigd door ruud76 op 24-07-2025 16:04 ]

[Robbiedobbie]

dingo35 schreef op donderdag 24 juli 2025 @ 14:13:
[...]

MQTT is lichter, sneller; als de HA integratie doet wat je wil kun je die prima gebruiken, maar gebruikersspecifieke wensen voer ik niet meer door; de HA ontwikkelomgeving wijzigt een paar keer per jaar en is slecht gedocumenteerd, waardoor het altijd weer een hopeloze zoekactie is naar de juiste syntax van die maand ...

Heb je ook een kant en klaar voorbeeld voor de mqtt configuratie van smartevse? Ik heb dit weekend zitten zoeken maar kon alleen de http based integratie vinden en de mqtt configs om energie meter data door te sturen.

[dingo35]

Nee, de MQTT inferface publiceert alle variabelen op een zodanige wijze dat HA ze allemaal automatisch ontdekt en configureert.

Je hoeft dus alleen maar de HA- MQTT integratie naar je broker te configureren (hostname/ip, user, passwoord) en dan verschijnt de SmartEVSE "vanzelf" in HA.

[Beekforel]

dingo35 schreef op donderdag 24 juli 2025 @ 19:44:
Nee, de MQTT inferface publiceert alle variabelen op een zodanige wijze dat HA ze allemaal automatisch ontdekt en configureert.

Je hoeft dus alleen maar de HA- MQTT integratie naar je broker te configureren (hostname/ip, user, passwoord) en dan verschijnt de SmartEVSE "vanzelf" in HA.

Ik mis wel wat dingen in HA MQTT:
- C2 selector (hoewel ik die nu niet meer gebruik sinds de 1-3-1F mogelijkheid )
- solar stop time setting
- solar max import
- solar start current

De uptime human readable zou ook fijn zijn.

Zitten sowieso nog best wel veel verschillen tussen de HA integratie en de HA MQTT, 52 entities in de integratie vs 38 in MQTT. Is dat bewust? Of work in progress?

[jpiscaer]

ruud76 schreef op donderdag 24 juli 2025 @ 15:39:
[...]


Klopt, die heb ik gemaakt maar is voor de wrt32-eth1 versie en staat in de SmartEVSE repo. Zorg dat je SmartEVSE altijd hetzelfde ip adres krijgt en zet dat op in de yaml file die je in de smartevse repo vindt. Na het laden van de yaml file in de slimmelezer zet je in home assistant (bij de slimmelezer) de SmartEVSE integratie aan (kan ook op de webpagina van de slimmelezer) en dat zou het moeten zijn. De slimmelezer geeft het energieverbruik dan direct aan de SmartEVSE door via de REST API, zonder tussenkomst van Home Assistant.

Als je niet de wt32-eth1 versie van de slimmelezer hebt dan kun je de wijzigingen (ik heb ze allemaal gemarkeerd) toepassen op de yaml file van jouw slimmelezer en zou het ook moeten werken.

Laat maar weten als je er niet uit komt.

Zoals in 90% van de gevallen, ik had net even iets mer moeten lezen, met een vers paar ogen (ipv 's avonds laat), en de errors verdwenen als sneeuw voor de zon ;-)

[con1]

Ik heb alle onderdelen inmiddels binnen en kan lekker beginnen met assembleren.

Nu probeerde ik gisteren de SmartEVSE te connecten maar is niet gelukt.
Mijn PC zag het accesspoint wél maar waarschijnlijk heb ik een verkeerd
IP (192.168.4.1) gebruikt in mijn browser om de controller te benaderen.

Doe ik iets fout of gebruik ik een verkeerd IP adres.?

[dingo35]

https://github.com/dingo3...ocs/configuration.md#wifi

[dingo35]

Beekforel schreef op donderdag 24 juli 2025 @ 20:54:
[...]

Ik mis wel wat dingen in HA MQTT:
- C2 selector (hoewel ik die nu niet meer gebruik sinds de 1-3-1F mogelijkheid )
- solar stop time setting
- solar max import
- solar start current

De uptime human readable zou ook fijn zijn.

Zitten sowieso nog best wel veel verschillen tussen de HA integratie en de HA MQTT, 52 entities in de integratie vs 38 in MQTT. Is dat bewust? Of work in progress?

Dat is niet bewust, degene die indertijd MQTT ingebouwd heeft was wat minder "info hungry".

Maar als er behoefte is aan meer MQTT data breiden we dat uit op verzoek. Maak even een issue op mijn github aan met deze drie items dan staat t op mijn lijstje. Als je C2 selector niet gebruikt dan hoort hij er niet op, ik merk het wel als iemand hem tóch nog nodig heeft, maar als het goed is is met v3.9.0 het manipuleren hiervan verleden tijd.

[Grondgebonden]

dingo35 schreef op vrijdag 25 juli 2025 @ 12:03:
[...]

Dat is niet bewust, degene die indertijd MQTT ingebouwd heeft was wat minder "info hungry".

Maar als er behoefte is aan meer MQTT data breiden we dat uit op verzoek. Maak even een issue op mijn github aan met deze drie items dan staat t op mijn lijstje. Als je C2 selector niet gebruikt dan hoort hij er niet op, ik merk het wel als iemand hem tóch nog nodig heeft, maar als het goed is is met v3.9.0 het manipuleren hiervan verleden tijd.

Dat zelfde kan m.i. ook gezegd worden over de entries in MQTT voor homeassistant: als je die niet gebruikt, dan zouden die niet in MQTT moeten komen.

[dingo35]

Vermoedelijk heb je het over de announcements voor HA; deze worden slechts eenmalig, bij opstarten verstuurd; nauwelijks een belasting voor broker noch SmartEVSE; en als ze je hinderen lijkt het me niet moeilijk ze te verwijderen uit je broker (remove retained).

Daarnaast kunnen ze óók gebruikt worden dopr niet HA MQTT clients, wellicht met enige omzetting van topic names/values.

[con1]

con1 schreef op vrijdag 25 juli 2025 @ 08:07:
Ik heb alle onderdelen inmiddels binnen en kan lekker beginnen met assembleren.

Nu probeerde ik gisteren de SmartEVSE te connecten maar is niet gelukt.
Mijn PC zag het accesspoint wél maar waarschijnlijk heb ik een verkeerd
IP (192.168.4.1) gebruikt in mijn browser om de controller te benaderen.

Doe ik iets fout of gebruik ik een verkeerd IP adres.?

Ik ben er uit. Via Wifi ging het in geen van de 3 standaard manieren.

Uiteindelijk via Putty en de opdrachtpromt in combinatie met een USB kabel
is het wél gelukt. Nu ook via HACS in Home Assistant ruimschoots zichtbaar.
Maar het was wel een flink aantal uren zoeken en tobben.

Dus voor de liefhebber die ook problemen ondervindt.

[databeestje]

Om het verbruik van de auto beter in HA te kunnen monitoren een goedkope kWh meter gekocht via Aliexpress.

Het is een Kowsi KWS-306L met modbus aansluiting, voor de ontsluiting in de laadpaal een Elfin EW11 rs485 serial server erbij gekocht. Binnen een week geleverd, voor respectievelijk 30 en 14 euro inclusief verzending.

Voor het ontsluiten met de Elfin EW11, deze eerst een keer factory resetten, anders doet deze het niet, en pakt deze niet de instellingen voor de seriële poort. Dank aan deze forum post.
Ik heb eerder een keer via Ali goeedkope USB-C headers gekocht die ik kon gebruiken voor de power. In de laadpaal tap ik 12 Volt af voor de voeding. Als je een groter bereik nodig hebt van 5-36 Volt dan moet je de A variant bestellen.

De instellingen voor de KWS-306L zijn vrijwel identiek aan de KWS-303L, en daar heeft de volgende persoon een pagina aan gewijd. 9600N81 op adres 1. Via mode knopje optie 14 is met + en - het adres in te stellen naar een ander.

Voor het aansluiten van de KWS-306L zijn de rs485 terminals niet aangegeven. Op de voorgaande pagina is aangegeven dat A rood is en B zwart. Soort van eigenaardig is dat de kWh meter een relais heeft om uit en aan te schakelen.


Voor home assistant zijn genoeg voorbeelden te vinden en ziet het er nu ongeveer zo uit. Of de fase 2 en 3 kloppen durf ik nog niet te zeggen, de 3 fase komt pas over een maand

code:

# Example configuration.yaml entry
modbus:
  - name: modbus_ev
    type: tcp
    host: 192.168.11.222
    port: 502
    sensors:
    - name: kws306_frequency
      address: 51
      input_type: input
      slave: 1
      unit_of_measurement: Hz
      device_class: frequency
      scale: 0.01
      precision: 2
      state_class: MEASUREMENT

    - name: kws306_total_active_energy
      address: 55
      input_type: input
      slave: 1
      unit_of_measurement: kWh
      device_class: energy
      state_class: total_increasing
      precision: 2
      scale: 0.01
      
    - name: kws306_total_active_power
      address: 26
      input_type: input
      slave: 1
      unit_of_measurement: W
      device_class: power
      scale: 0.1
      state_class: MEASUREMENT
      
    - name: kws306_phase_1_voltage
      slave: 1
      address: 14
      input_type: input
      unit_of_measurement: V
      device_class: voltage
      scale: 0.01
      precision: 1
      state_class: MEASUREMENT
      
    - name: kws306_phase_2_voltage
      slave: 1
      address: 15
      input_type: input
      unit_of_measurement: V
      device_class: voltage
      scale: 0.01
      precision: 1
      state_class: MEASUREMENT
      
    - name: kws306_phase_3_voltage
      slave: 1
      address: 16
      input_type: input
      unit_of_measurement: V
      device_class: voltage
      scale: 0.01
      precision: 1
      state_class: MEASUREMENT

De boel ingebouwd in de laadpaal. Ik kan missschien net genoeg ruimte maken voor een 2e contactor, de 12 Volt voeding kan er technisch nu uit aangezien de SmartEVSE deze niet nodig heeft. Door de ingebouwde 12 volt van de SmartEVSE kan ook de EW11 aan. Er zit een halve din verbindingsblok in voor de CP, vervangen door een Wago klem, niet meer nodig met nieuwe kabel overigens.



Die losse weerstand voor de PP gaat er ook nog tussenuit, ik heb een nieuwe kabel voor 3 fase welke deze gewoon in de stekker heeft.

Ik heb voor de afneembare kap een losse JST connector verlengkabel gescoord. Misschien een tip voor Stegen om deze verlengkabeltjes mee te leveren met de RGB button.
"PH2.0 200MM 2/3/4/5/6 Pin Man-vrouw Connector met Draad 2.0MM 2p 3p 4p 5p 6p Kabel JST Verlenglijn"

[ Voor 15% gewijzigd door databeestje op 27-07-2025 08:53 ]

[ben144]

Is het mogelijk om met smartEVSE een OCPP autoauthorize sessie pas later te starten, dus niet automatisch indien de laadkabel in de EV zit zoals de default werking ?
Ik zou mijn officiele laadsessie (met badge werkgever) pas willen starten wanneer mijn ESS-system dit ok vind.

Volgende al geprobeerd, maar ik krijg dan laadpas niet authorised foutmelding
- smartEVSE v3.8.5, geen rfid lezer
- Enable OCPP staat meestal uit, maar is wel geconfigureerd
- Eigen systeem belijkt wanneer de ev geladen kan worden, kijkt of EV connected is.
- Zo ja : enable OCPP aanzetten via http call wanneer hij mag laden
- Maar dan staat op het display authorise, mode normal of smart enablen helpt niet dan.
- Is er nog iets wat ik dan kan oproepen om mijn laadpas in veld auto-authorize aan te melden ?

Bovenstaande met de laadkabel even los en terug in te steken werkt wel, maar is natuurlijk niet handig.

Volgende workaround werkt wel, maar dan heb ik teveel onnodige +-lege laadsessies
- Enable OCPP blijft altijd aan.
- ESS systeem gooit smartEVSE direct in pause indien niet ok
- Maar komt wel regelmatig voor dat de laadsessie nooit terug geactiveerd w omdat de auto weer even weg moet etc...

[dingo35]

Ik heb het niet uitgeprobeerd, maar volgens mij wordt in OFF mode niet eens gedetecteerd dat het EV aangesloten wordt; hij komt pas in State B als hij in Smart, Solar of Normal gezet wordt.

[tukker999]

dingo35 schreef op zaterdag 26 juli 2025 @ 17:20:
Ik heb het niet uitgeprobeerd, maar volgens mij wordt in OFF mode niet eens gedetecteerd dat het EV aangesloten wordt; hij komt pas in State B als hij in Smart, Solar of Normal gezet wordt.

Dit is de display bij mijn 3.7.2 versie.

EVSE
Mode: OFF
Connected: Yes
State: Charging Stopped
Charge: 6.0 A
Temp: 34 °C / 65 °C
MQTT: Connected
Contactor 2: Always Off

Voor zover ik weet is connected bij de Volvo plugin en de SmartEVSE in alle gevallen gelijk.

[ben144]

dingo35 schreef op zaterdag 26 juli 2025 @ 17:20:
Ik heb het niet uitgeprobeerd, maar volgens mij wordt in OFF mode niet eens gedetecteerd dat het EV aangesloten wordt; hij komt pas in State B als hij in Smart, Solar of Normal gezet wordt.

Jawel, zonet getest, ev disconnected, power reset, naar OFF mode (met ocpp en auto-authorise vinkje enabled) daarna ev (vw id7) inpluggen en hij begint met laden.
v3.8.5

[jpiscaer]

Ok, mijn SmartEVSE project is succesvol afgerond. NewMotion Advanced 2.1 paal met Inepro kWh meter omgebouwd naar een Smart EVSE, met P1 data vanuit een slimmelezer+. Nu het volgende deel van het project: periodieke (maandelijks? jaarlijks?) lijst met transacties bijhouden voor verrekening met de (eigen) zaak. Ik heb nu steve ocpp draaien, maar die lijkt geen PDFs te kunnen genereren (en is veel te uitgebreid voor mijn doel om alleen PDFs te draaien). Aangezien er best aan aantal mensen hier in dezelfde situatie zullen zitten, wat zijn manieren waarop jullie je zakelijke laadkosten verrekenen?

[tukker999]

Wat dacht je van een tussenmeter voor de laadpaal in de meterkast.
Een pen en papier zijn voldoende om de stand op 31 december even voor 12 uur te noteren.
Daarnaast beschik je over een notitie van de km stand van de EV en klaar is kees.
Je kunt het verbruik altijd aannemelijk maken in geval de fiscus vragen stelt.
Ik heb het zo gedaan vanaf 2013 tm 2023 en nooit een vraag hierover gehad van de Belastingdienst.

EDIT
Op 31 december maakte ik een foto van de tussenmeter en van de kilometerstand, drukte beide af op een A4-tje met een aantekening er bij.
Dat in de map van de belastingaangifte en klaar is kees.

[ Voor 22% gewijzigd door tukker999 op 26-07-2025 22:47 ]

[jpiscaer]

tukker999 schreef op zaterdag 26 juli 2025 @ 22:43:
Wat dacht je van een tussenmeter voor de laadpaal in de meterkast.
Een pen en papier zijn voldoende om de stand op 31 december even voor 12 uur te noteren.
Daarnaast beschik je over een notitie van de km stand van de EV en klaar is kees.
Je kunt het verbruik altijd aannemelijk maken in geval de fiscus vragen stelt.
Ik heb het zo gedaan vanaf 2013 tm 2023 en nooit een vraag hierover gehad van de Belastingdienst.

EDIT
Op 31 december maakte ik een foto van de tussenmeter en van de kilometerstand, drukte beide af op een A4-tje met een aantekening er bij.
Dat in de map van de belastingaangifte en klaar is kees.

Zo simpel kan 't zijn.. Heb inderdaad een inepro kWh meter erin zitten die ik (ook digitaal) kan uitlezen.. Kan dat ook via Home Assistant uitlezen en wegschrijven. Tnx!

[RonJ]

jpiscaer schreef op zaterdag 26 juli 2025 @ 20:42:
Ok, mijn SmartEVSE project is succesvol afgerond. NewMotion Advanced 2.1 paal met Inepro kWh meter omgebouwd naar een Smart EVSE, met P1 data vanuit een slimmelezer+. Nu het volgende deel van het project: periodieke (maandelijks? jaarlijks?) lijst met transacties bijhouden voor verrekening met de (eigen) zaak. Ik heb nu steve ocpp draaien, maar die lijkt geen PDFs te kunnen genereren (en is veel te uitgebreid voor mijn doel om alleen PDFs te draaien). Aangezien er best aan aantal mensen hier in dezelfde situatie zullen zitten, wat zijn manieren waarop jullie je zakelijke laadkosten verrekenen?

Ik gebruik al een tijdje tapelectric als ocpp backend, dat doet precies wat je wilt.

[jpiscaer]

RonJ schreef op zondag 27 juli 2025 @ 11:19:
[...]


Ik gebruik al een tijdje tapelectric als ocpp backend, dat doet precies wat je wilt.

Die heeft een prijskaartje toch, €2,50/maand?

[Robbiedobbie]

jpiscaer schreef op zondag 27 juli 2025 @ 11:42:
[...]

Die heeft een prijskaartje toch, €2,50/maand?

Nee hoor, de tap electric backoffice is gratis. Toevallig vorige week ook aangemaakt en in gebruik genomen.

Ze hebben wel abbonementen voor verdere opties, en ook als je kortingen wil als je hun laadpas gebruikt.

[BarryH]

Robbiedobbie schreef op zondag 27 juli 2025 @ 11:44:
[...]

Nee hoor, de tap electric backoffice is gratis. Toevallig vorige week ook aangemaakt en in gebruik genomen.

Ze hebben wel abbonementen voor verdere opties, en ook als je kortingen wil als je hun laadpas gebruikt.

Maar bij gratis abbo gaat er toch een opslag over de kWh prijs?

[Robbiedobbie]

BarryH schreef op zondag 27 juli 2025 @ 12:01:
[...]

Maar bij gratis abbo gaat er toch een opslag over de kWh prijs?

Klopt, maar je kan je eigen pas gewoon als gratis markeren en dan is er ook geen opslag. Dan heb je wel je administratie hoeveel/wanneer geladen is

[jpiscaer]

Robbiedobbie schreef op zondag 27 juli 2025 @ 12:03:
[...]

Klopt, maar je kan je eigen pas gewoon als gratis markeren en dan is er ook geen opslag. Dan heb je wel je administratie hoeveel/wanneer geladen is

Heeft Tap een goede automatische export van transacties naar PDF?

[Robbiedobbie]

Poeh, ik zelf exporteer eigenlijk die transacties niet. Ik gebruik tap electric alleen zodat als kennissen langskomen ze gewoon (betaald) kunnen bijladen indien nodig. Misschien dat @RonJ kan toelichten hoe hij tap electric gebruikt?

Zelf heb ik een rfid druppel als gratis gemarkeerd en omdat het geen echte laadpas is komt die niet in mijn overzicht voor met laadsessies. Mijn auto is dan ook totaal niet zakelijk in gebruik, en daar heb ik zelf een flow in nodered lopen die de laadsessies in LubeLogger zet bij de juiste auto zodat ik mooie stats krijg over gebruik vs kosten.

[jpiscaer]

Robbiedobbie schreef op zondag 27 juli 2025 @ 12:13:
Poeh, ik zelf exporteer eigenlijk die transacties niet. Ik gebruik tap electric alleen zodat als kennissen langskomen ze gewoon (betaald) kunnen bijladen indien nodig. Misschien dat @RonJ kan toelichten hoe hij tap electric gebruikt?

Zelf heb ik een rfid druppel als gratis gemarkeerd en omdat het geen echte laadpas is komt die niet in mijn overzicht voor met laadsessies. Mijn auto is dan ook totaal niet zakelijk in gebruik, en daar heb ik zelf een flow in nodered lopen die de laadsessies in LubeLogger zet bij de juiste auto zodat ik mooie stats krijg over gebruik vs kosten.

haha ok, andere use case dus!

In mijn geval denk ik dat steve (https://github.com/steve-community/steve) een goede eerste stap is: self-hosted ocpp back-end die transacties bijhoudt. Mogelijk doe ik 't simpeler en doe ik een maandelijkse export van KM-stand en kWh-meter meterstand via home assistant voor de administratie..

[databeestje]

Nabrander, koppelen van de KWS-306L is gelukt met de SmartEVSE als EV meter.

hbf & hwf
int16
input

volt 14 / 100
cur 18 /1000
pow 26 / 10
ene 55 / 100

[Adze]

jpiscaer schreef op zondag 27 juli 2025 @ 12:06:
[...]

Heeft Tap een goede automatische export van transacties naar PDF?

Ja, die krijg ik elke maand per mail. Alle transacties van alle laadpalen op één overzicht.

[Thepawn]

just installed my smartEVSE. nicely charging at 3x25A

[Stefannn]

Thepawn schreef op zondag 27 juli 2025 @ 14:15:
just installed my smartEVSE. nicely charging at 3x25A [Afbeelding]

That’s a lot!
Most common installations have 3x 16A at the subgroups. If you have 3x25A mains that is also the max allowed. Do you have 3x35A mains connection?

[RonJ]

jpiscaer schreef op zondag 27 juli 2025 @ 11:42:
[...]

Die heeft een prijskaartje toch, €2,50/maand?

Je hebt alleen kosten als je laadpassen met een betaling wil accepteren zonder opslag. Dan krijg je ook een factuur in de mail. Dat zou ik zelf weer doen als ik een laadpas van de zaak had: Publiek laden toestaan en de kosten voor het abo in het tarief verwerken.

Ik heb nu geen leaseauto meer, dus gebruik nu alleen twee als gratis ingestelde rfid-druppels om de kosten per auto bij te houden, daarvoor kan je dan periodiek de sessies exporteren naar een .csv file.

[Thepawn]

Stefannn schreef op zondag 27 juli 2025 @ 14:40:
[...]

That’s a lot!
Most common installations have 3x 16A at the subgroups. If you have 3x25A mains that is also the max allowed. Do you have 3x35A mains connection?

I have 3x25A mains.
The "peak shaving" function of my Deye hybrid inverter is constantly watching the grid current, and can increase production (from solar or home battery) to avoid the grid going above 25A when additional load is turned on.
This means I can also charge the car at 32A.
The smartEVSE will need to slow down only when the inverter power is maxed out (plenty of other load in the house as well)

[Stefannn]

Thepawn schreef op zondag 27 juli 2025 @ 15:33:
[...]


I have 3x25A mains.
The "peak shaving" function of my Deye hybrid inverter is constantly watching the grid current, and can increase production (from solar or home battery) to avoid the grid going above 25A when additional load is turned on.
This means I can also charge the car at 32A.
The smartEVSE will need to slow down only when the inverter power is maxed out (plenty of other load in the house as well)

You need to have the smartevse on a fused subgroup.
Subgroup needs to be on a lower rating than the mains. Standard is “2 steps” so 3x16A.
I personally use 20A (= 1step below 25A).as contant 3x16 can blow the 16A fuses after some time. There is a lot of discussion on this forum whether that is wise or not but a took the risk.
However… using the full 3x25A on a subgroup and fully relying on the active power control is quite excessive.

[Thepawn]

Stefannn schreef op zondag 27 juli 2025 @ 23:00:
[...]

Subgroup needs to be on a lower rating than the mains.

I don't think this still applies in case of home batteries.
I went for a 32A breaker and 6mm2 wires.
Mains can provide 25A, but the Deye can provide 20A extra.
And even in the unlikely event that both the Deye peak shaving and the smartEVSE would fail to slow down, I would just trip the grid breakers: is that a big deal?
Charging at 3x25A happens only when the car is suited for it: most times it's limited to 3x16A anyway.
However, there's still many models that charge single phase: 1x32A is still reasonable to me, while 1x16A would be useless (in my opinion)

[Stefannn]

Thepawn schreef op maandag 28 juli 2025 @ 06:56:
[...]


I don't think this still applies in case of home batteries.
I went for a 32A breaker and 6mm2 wires.
Mains can provide 25A, but the Deye can provide 20A extra.
And even in the unlikely event that both the Deye peak shaving and the smartEVSE would fail to slow down, I would just trip the grid breakers: is that a big deal?
Charging at 3x25A happens only when the car is suited for it: most times it's limited to 3x16A anyway.
However, there's still many models that charge single phase: 1x32A is still reasonable to me, while 1x16A would be useless (in my opinion)

Note, I guess you speak English as that is what you used in your first post.
In Dutch this is called “selectiviteit” which means “selectivity”. The idea is that a subgroup will always trip faster than the grid.
It goes in 2 ways:
- continues current: for that your reasoning does hold.
- shortcut current: for that your reasoning does not hold because for that the speed of breaking is important.
See below picture. Normally you have type-C 25A grid breakers and type-B 16A subgroups. The 16A being 2 steps down from 25 (25 -> 20 -> 16).
I myself use 20A B-curve for the smartevse which is only 1step down for reason that using a breaker at 100% for multiple hours can still trip it. Some people already find that irresponsible but I feel that it will still trip faster than de 25A C-curve. It’s definitely getting to the edge.
However… using 32A on a subgroup really misses the point. The grid breaker will always trip before the subgroup.

Tripping a grid breaker is something to avoid. In modern installations you can reset them yourself, older situations (like mine from 2008) do not allow that. You will need to get it replaced by a certified technician. In all cases it’s bad practice to rely on grid breakers for protection. They are intended as “last defense in case sub circuit protection fails”.

In the Netherlands regulations are in nen1010. I googled a bit but I could not find battery specific directives. Nen1010 is not freely available. You have to buy it. This is because the Dutch regulation is very strange (as a foreigner you would have never guessed)
- it’s mandatory to make the system save
- it’s your responsibility to do that and to provide evidence you did in case something went wrong
- nen1010 is a government accepted method to be safe, so if you can show you followed nen1010 that serves as fulfilling this responsibility
- but nen1010 is not mandatory, in case something went wrong you are free to argue you made it safe differently

This is a very strange Dutch thing. As a result:
- nen1010 is exploited commercially. As it isn’t law it’s not necessarily freely available
- but following nen1010 is still highly recommended as insurers can demand to only insure if nen1010 is followed.

Although you have to buy nen1010 (which is extremely big and has numerous chapters) the main directives are often freely available, copied, loosely referenced in free articles. This referencing can however be messy.
Anyway…. I did not find something specific on batteries.

[dingo35]

@Stefannn @Thepawn is right, if you look in the installation manual of the Deye you see that on the Load side it can deliver grid+battery discharge current, so the breaker on the load side is usually twice the breaker on the grid side.

Whole other problems then selectivity arise in this situation, e.g. if a shortcircuit arises, can the Deye deliver enough current to trip any of the breakers?

If on the loadside you have a shortcircuit, say the Deye can deliver 50A; then it can still take _minutes_ before any of the breakers (grid or load) trip; in a normal situation your grid would deliver say 200A for a very short time abd immediately trip the breaker.

Less current is not always safer!

[RonJ]

Stefannn schreef op maandag 28 juli 2025 @ 08:30:
[...]

Note, I guess you speak English as that is what you used in your first post.
In Dutch this is called “selectiviteit” which means “selectivity”. The idea is that a subgroup will always trip faster than the grid.
It goes in 2 ways:
- continues current: for that your reasoning does hold.
- shortcut current: for that your reasoning does not hold because for that the speed of breaking is important.
See below picture. Normally you have type-C 25A grid breakers and type-B 16A subgroups. The 16A being 2 steps down from 25 (25 -> 20 -> 16).
I myself use 20A B-curve for the smartevse which is only 1step down for reason that using a breaker at 100% for multiple hours can still trip it. Some people already find that irresponsible but I feel that it will still trip faster than de 25A C-curve. It’s definitely getting to the edge.
However… using 32A on a subgroup really misses the point. The grid breaker will always trip before the subgroup.

Tripping a grid breaker is something to avoid. In modern installations you can reset them yourself, older situations (like mine from 2008) do not allow that. You will need to get it replaced by a certified technician. In all cases it’s bad practice to rely on grid breakers for protection. They are intended as “last defense in case sub circuit protection fails”.

While it's a good idea to have automatic CB's as main breakers if you rely on the loadbalancing feature of your EVSE to not trigger them, it's not mandatory. Neither is selectivity in domestic installations. It's recommended, not mandatory.

It's pretty common to have EV-chargers these days that can do more than the main breakers, since PV- or battery inverters can provide additional power.

What you do need to look into is whether your breaker board is suitable to handle the extra current. Most domestic breaker boards have RCD's and wiring that are only good up to 40 Amps. Since your Deye can add 20A to the 25A main, that's 45A that you need to deal with. Either by upgrading all the wiring and RCD's to 63A capable items OR by placing an additional breaker ("rem automaat" that limits current from the Deye and the Grid towards the consumer breakers to 40A.

[Stefannn]

dingo35 schreef op maandag 28 juli 2025 @ 08:38:
@Stefannn @Thepawn is right, if you look in the installation manual of the Deye you see that on the Load side it can deliver grid+battery discharge current, so the breaker on the load side is usually twice the breaker on the grid side.

Whole other problems then selectivity arise in this situation, e.g. if a shortcircuit arises, can the Deye deliver enough current to trip any of the breakers?

If on the loadside you have a shortcircuit, say the Deye can deliver 50A; then it can still take _minutes_ before any of the breakers (grid or load) trip; in a normal situation your grid would deliver say 200A for a very short time abd immediately trip the breaker.

Less current is not always safer!

Thanks….
I guess my information on nen1010 still holds
Which probably means this is uncharted territory?
Anyway…. I think this is a trigger to “think for oneself”.
I leave it to @Thepawn to use all inputs wisely.

[Stefannn]

RonJ schreef op maandag 28 juli 2025 @ 08:43:
[...]


While it's a good idea to have automatic CB's as main breakers if you rely on the loadbalancing feature of your EVSE to not trigger them, it's not mandatory. Neither is selectivity in domestic installations. It's recommended, not mandatory.

It's pretty common to have EV-chargers these days that can do more than the main breakers, since PV- or battery inverters can provide additional power.

What you do need to look into is whether your breaker board is suitable to handle the extra current. Most domestic breaker boards have RCD's and wiring that are only good up to 40 Amps. Since your Deye can add 20A to the 25A main, that's 45A that you need to deal with. Either by upgrading all the wiring and RCD's to 63A capable items OR by placing an additional breaker ("rem automaat" that limits current from the Deye and the Grid towards the consumer breakers to 40A.

Thanks.
Yes,.. selectivity is recommended not mandatory , that’s why I included the explanation on nen1010.
But… besides that: looks like you have more info/experience on this.
Do you have any source with best practices in case of active current limitation and/or batteries?

As said, I’m currently using 20A for my smartevse subgroup. When I mentioned that in some forum I already got comments from people who found that irresponsible. In some future I will go for a battery.
With all that said: “nen1010 as I know it will no longer be sufficient”.
So: any recommendation on reading material for this new realities?

[RonJ]

Stefannn schreef op maandag 28 juli 2025 @ 08:57:
[...]

Thanks.
Yes,.. selectivity is recommended not mandatory , that’s why I included the explanation on nen1010.
But… besides that: looks like you have more info/experience on this.
Do you have any source with best practices in case of active current limitation and/or batteries?

As said, I’m currently using 20A for my smartevse subgroup. When I mentioned that in some forum I already got comments from people who found that irresponsible. In some future I will go for a battery.
With all that said: “nen1010 as I know it will no longer be sufficient”.
So: any recommendation on reading material for this new realities?

I agree the NEN1010 has a blindspot here and urgently needs another update to deal with battery-, PV- and EV-inverter loads as well as semi off-grid installations. The lack of inverter driven short-circuit current @dingo35 mentioned is also becoming more and more of a deal that's kind of neglected by the domestic NEN norms. There is a lot of discussion already about this in the relevant topic. It's best to continue this discussion over there imho.

To stick with the topic here, your 20A for the SmartEVSE is fine and according to a lot of people, it's actually recommended to oversize the breaker. I have a C16A RCBO, which a lot of people are also against because it generates more heat than a 20A would. So it's a matter of what you prioritize, reduced heat generation or selectivity.

[Stefannn]

@RonJ @dingo35 @Thepawn
Thinking about it a bit longer,
I think I remember the formal recommendation is to have the battery in a separate subgroup with 16A B-curve breaker.
And smartevse also in a separate subgroup with 16A B-curve breaker.
Given the active current protection I guess these 16A breakers could be safely replaced by 20A B-curve breakers.
By this:
- short current is well protected
- but only max 20A can be used from the battery (45A battery and grid together)

Of course one can feel free to do different at own risk. I guess that is indeed off topic here.
Just wanted to close off with at least the “formal recommendation”.

[Thepawn]

dingo35 schreef op maandag 28 juli 2025 @ 08:38:
@Stefannn @Thepawn is right, if you look in the installation manual of the Deye you see that on the Load side it can deliver grid+battery discharge current, so the breaker on the load side is usually twice the breaker on the grid side.

Whole other problems then selectivity arise in this situation, e.g. if a shortcircuit arises, can the Deye deliver enough current to trip any of the breakers?

If on the loadside you have a shortcircuit, say the Deye can deliver 50A; then it can still take _minutes_ before any of the breakers (grid or load) trip; in a normal situation your grid would deliver say 200A for a very short time abd immediately trip the breaker.

Less current is not always safer!

I think there's a misunderstanding.
My smartEVSE is not connected to the load side of the Deye.
The load (also called UPS output) is feeding only small loads, like servers.

The Deye is working as grid-tied, so it's pushing current on the grid terminals.
The Deye peak shaving is configured to allow max 23A on the grid breakers.
The smartEVSE is configured to allow max 24A on the same breakers.
So both systems are working as limiters to avoid tripping the breakers, and indeed they never trip.

What happens in practice when the 32A subgroup of the smartEVSE is using 32A: the grid is providing 24A, and the Deye is providing 8A. If Deye is failing to support(for any reason), then the current on the grid breakers will momentarily increase to 32A and the smartEVSE will slow down.

If an extra load turns on, the Deye increase the production to match, and the reaction is very quick (1 second): the smartEVSE doesn't notice a thing and doesn't even need to slow down.
The electrical panel is rated for 40A; 6mm2 (or thicker) wires are used.

In case of a short circuit, the high current from the grid will make sure the breakers will trip.

I think using the NEN1010 recommendations were very relevant in the past, when:
- you risked to blow the fuses (breakers were not invented yet)
- load balancing for heavy loads was not a thing (smartEVSE was not invented yet)
- heavy loads didn't have a dynamically adjustable power consumption
- solar panels and most importantly home batteries were not common at home
- "peak shaving" active controls were not there

I don't think it's fair to just ignore all the above and "stick to the NEN1010" recommendations.
We are on Tweakers, right? I love to tweak

[RonJ]

Thepawn schreef op maandag 28 juli 2025 @ 10:16:
[...]


I think there's a misunderstanding.
My smartEVSE is not connected to the load side of the Deye.
The load (also called UPS output) is feeding only small loads, like servers.

I understand that, but the deye can also push current back onto the grid feed, as you say below.

The Deye is working as grid-tied, so it's pushing current on the grid terminals.
The Deye peak shaving is configured to allow max 23A on the grid breakers.
The smartEVSE is configured to allow max 24A on the same breakers.
So both systems are working as limiters to avoid tripping the breakers, and indeed they never trip.

If an extra load turns on, the Deye increase the production to match, and the reaction is very quick (1 second): the smartEVSE doesn't notice a thing and doesn't even need to slow down.
The electrical panel is rated for 40A; 6mm2 (or thicker) wires are used.

40A rated is not enough then if you can actually push 25+20A through it (EVSE + other loads).

[RonJ]

Stefannn schreef op maandag 28 juli 2025 @ 10:05:
@RonJ @dingo35 @Thepawn
Thinking about it a bit longer,
I think I remember the formal recommendation is to have the battery in a separate subgroup with 16A B-curve breaker.
And smartevse also in a separate subgroup with 16A B-curve breaker.
Given the active current protection I guess these 16A breakers could be safely replaced by 20A B-curve breakers.
By this:
- short current is well protected
- but only max 20A can be used from the battery (45A battery and grid together)

Of course one can feel free to do different at own risk. I guess that is indeed off topic here.
Just wanted to close off with at least the “formal recommendation”.

That would be my recommendation also, but then you have to make sure your breaker board can handle that 45A.