Zelfbouw Laadpaal ervaringen

[X21r]

dingo35 schreef op woensdag 17 december 2025 @ 07:53:
Kan het zijn dat python niet geïnstalleerd is onder windows11? Geef in een command-shell "python" als hij dan "command not found" geeft moet je python nog installeren.

Python is geïnstalleerd.

C:\Users\Ron>python
Python 3.13.9 (tags/v3.13.9:8183fa5, Oct 14 2025, 14:09:13) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

Ik ga straks op een ander laptop met W10 proberen , eens kijken wat dat oplevert.
Currend laptopt W11 intel i5.

[Blackraven]

stegen schreef op vrijdag 7 november 2025 @ 10:58:
Je kan de bootloader software vinden in de SmartEVSE 1 repo:
https://github.com/SmartE...se/tree/master/bootloader
Gebruik een FTDI kabel, en sluit deze aan op de controller.

Verbind de kabel met de 6 pins aansluiting op de SmartEVSE (een rijtje met 6 pennen (pinheader) is wel nodig om deze te kunnen aansluiten.
De zwarte draad van de kabel komt aan de kant waar BLK staat.
Zorg er voor dat er geen EV's zijn aangesloten op het laadpunt.

Start het AN1310ui.exe programma op, en kies de juiste COM poort.
Probeer nu verbinding te maken met de module door op het groene RUN knopje te klikken.
Druk enkele keren op Enter, en het command line menu van de SmartEVSE moet nu zichtbaar zijn.

Als dit lukt, kies dan het rode vierkantje (bootloader mode) , en laad de laatste firmware in.
Deze kan je hier vinden:
https://github.com/SmartE...artEVSE2.X.production.hex

Druk vervolgens op "write device" om de module te programmeren.
Druk op het groene RUN knopje, om weer terug te gaan naar het menu van de SmartEVSE.
Als het goed is, is de firmware nu geupdate

Top, is gelukt om de SmartEVSE V2 naar 2.40 te brengen, ik had geen 6 pin header, dus moest even zoeken naar de pinout voor de RX en TX, maar met deze info: https://github.com/SmartEVSE/SmartEVSE-2/discussions/38 is het helemaal goed gekomen.

Pin-nummering loopt van rechts naar links, waarbij GND dus op 1/rechts zit.

code:

Pin Color   Function
1   Black   GND - Ground
2   Brown   CTS - Clear to Send
3   Red     VCC- Positive Voltage Output (+5V)
4   Orange  TXD- Transmit Asynchronous Data output
5   Yellow  RXD- Receive Asynchronous Data input
6   Green   RTS- Request to Send

[X21r]

@dingo35
Het zelfde resultaat op compleet andere machine.
Geen foutmeldingen bij "pio run -t uploadfs"maar geen programmering naar de SmartEVSE

Maar bij "pio run -t upload" foutmeldingen en stoppen.
Wat ik gekopieerd heb van github is de inhoud van folder SmartEVSE-3 naar /scripts
dmv "CODE" download unzip naar aparte folder en van daar uit de SmartEVSE-3 naar /scripts


Bij " firmware.elf " loopt hij OOK vast in errors.

Compiling .pio\build\release\FrameworkArduino\main.cpp.o
Compiling .pio\build\release\FrameworkArduino\stdlib_noniso.c.o
Compiling .pio\build\release\FrameworkArduino\wiring_pulse.c.o
Compiling .pio\build\release\FrameworkArduino\wiring_shift.c.o
Archiving .pio\build\release\libFrameworkArduino.a
Linking .pio\build\release\firmware.elf
c:/users/ron/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio/build/release/src/lib/RemoteDebug/src/RemoteDebug.cpp.o: in function `RemoteDebug::write(unsigned char const*, unsigned int)':
C:\Users\ron\.platformio\penv\Scripts/lib/RemoteDebug/src/RemoteDebug.cpp:854: multiple definition of `RemoteDebug::write(unsigned char const*, unsigned int)';
etc etc etc..

[dingo35]

Uploadfs heb je helemaal niet nodig; na het clonen van de git repository moet je in de directory gaan staan waar platformio.ini in staat, en dan moet pio run -t upload de rest doen.

Dus niks "kopiëren", in je uitgepakte / gekloonde git repo gaan staan.

[ Voor 17% gewijzigd door dingo35 op 17-12-2025 13:53 ]

[X21r]

@dingo35
Eindelijk gisteren het voor elkaar gekregen te unbricken.
De beschrijving in github programmeren dmv "https://github.com/marcelstoer/nodemcu-pyflasher"mag je weg halen die programmeert ALLES op adres 0 !!!!!.


Nu de letterlijke beschrijving voor windows 10 / 11 om de SmartEVSE een complete update te geven cq opnieuw te programmeren na een brick.

-Zorg dat je een account heb op GitHub ( heb je later nodig )

-Open command venster(opdracht prompt) ( in zoekbalk onder aan type CMD )
Dan gaat een nieuw venster open, met ongeveer de tekst C:\Users\xx gebruikers naam xx>
-Check of python geïnstalleerd is. type python. dan moet je zo iets ongeveer zien "Python 3.13.9 xxxxx " zo niet dan verschijnt er bij W11 een download link volg die. Mocht je 4 paarse >>>> zien type dan exit, dan sluit je dit programma.

Sluit venster en ga met de webbrowser naar https://docs.platformio.o...lation/methods/index.html
kies daar de link " Local Download (macOS / Linux / Windows)". daar aangekomen SAVE AS de file met de tekst "get-platformio.py " naar de download folder.
Nu kan je met verkenner naar de download folder en daar op de file get-platformio.py klikken, dan word het geheel geïnstalleerd.
Nog even voor de duidelijkheid "Visual studio "niet nodig. En PlatformCORE ook niet.... platformIO moet je hebben.

Dan verschijnt er een zwart opdracht venster dat gevuld word met info ( geduld) en verdwijnt weer
Dan heeft hij een folder aan gemaakt ( was zichtbaar in de eerste paar regels) "C:\Users\xxusernamexx\.platformio\"

Ter info skills
"dir" geeft een lijst met file namen handig als je het goed moet intypen.
"cd.." ga een level terug omhoog.
"cd foldernaam " ga naar die folder. je ziet hem dan ook terug in je opdracht balk.

Maak een nieuwe opdracht venster open (cmd)
Als het goed is staat je opdrachtbalk dus zo C:\Users\xx user name xx.
Nu moeten we naar .platformio dus type in "cd .platformio".
Je regel moet nu zo uitzien "C:\Users\xx user name xx\.platformio>"
Nu moeten we naar "penv" type in "cd penv"
Nu moeten we naar schripts type in "cd schripts"
Je regel moet nu zo uitzien "C:\Users\xx user name xx\.platformio\schripts>"
Type nu "pio run -t upload"en je zal zien dat hij een fout melding geeft .
Type nu "platformio project init" en de .ini word gemaakt.

Dus als het goed is staan we nu in "C:\Users\xxusernamexx\.platformio\penv\Scripts> ( gebruik dir zien of er wel een "platformio.ini" staat.
Sluit opdracht venster.

Terug naar webbrowser en ga naar "https://git-scm.com/install/windows "
en selecteer "Git for Windows/x64 Setup." en download en run, geeft 15x next niets veranderen, en dan finish
Nu even checken of die inderdaad is geïnstalleerd- opdracht venester openen en type "git" nu moet je een goede help respons krijgen.

Ok terug naar webbrowser naar https://github.com/dingo35/SmartEVSE-3.5/tree/v3.9.0 .
Eventueel links boven op "code" klikken om terug naar de begin pagina te gaan.
Nu verschijnt er recht half boven een button in een kleur groen de tekst " CODE " en een uitklap venster .
Kopieer de link .bv "https:// ..... "

Open opdracht venster weer CMD
Ga naar de folder "C:\Users\xxusernamexx\.platformio\penv\Scripts> "
type in "git clone " met daar achter het adres wat je net van die web site heb gekopieerd onder de groene knop
bv " "git clone https://github.com/dingo35/SmartEVSE-3.5.git"
Dan download hij het geheel aan software. hij zal een paar keer piepen voor inlog maar gewoon volhouden.

Nu niet vergeten de SmartEVSE aan te sluiten.

Als hij klaar is dan naar de folder SmartEVSE-3 dus "cd SmartEVSE-3" .......let op een niveau dieper !!.
Dit word dat "C:\Users\xxusernamexx\.platformio\penv\Scripts\SmartEVSE-3.5\SmartEVSE-3>"

En nu mag je " pio run -t upload in typen, en hij gaat runnen en je SmartEVSE programmeren.

[Andrehj]

Hoe stopt het laden bij te weinig beschikbare stroom?

Stel dat het laden tussendoor moet stoppen, omdat er te weinig PV-stroom beschikbaar is (bij PV-laden) of omdat een fase overbelast dreigt te laden. Wat gebeurt er dan? Ik kan twee mogelijkheden bedenken:

1. De EVSE communiceert met de auto dat de laadstroom naar 0 moet, wacht tot dat gedaan is (via feedback vanuit de auto?, de EVSE kan immers zelf niet meten) en schakelt dan het relais uit of
2. De EVSE schakelt direct het relais uit zonder hierover met de lader in de auto te communiceren.

Optie 1 lijkt me aardiger voor de elektronica in de auto, maar kan wellicht falen doordat de communicatie niet lekker gaat en is wellicht te langzaam.
Optie 2 werkt natuurlijk altijd, maar wat vindt de laadelektronica in de auto hiervan?

Misschien dat iemand (@dingo35 of @stegen?) kan uitleggen hoe dit werkt?

[Hippe Lip]

@Andrehj Waarom wil je het relais uitschakelen? Je kan via het CP-signaal de stroom naar nul reduceren, zodat je die weer kan opvoeren als er weer stroom beschikbaar is, toch?

[Andrehj]

Hippe Lip schreef op zaterdag 20 december 2025 @ 10:51:
@Andrehj Waarom wil je het relais uitschakelen? Je kan via het CP-signaal de stroom naar nul reduceren, zodat je die weer kan opvoeren als er weer stroom beschikbaar is, toch?

Het gaat me niet om het schakelen van het relais, maar ik vraag me af hoe het terugbrengen van de stroom bestuurd wordt.
Ik hoorde namelijk van een collega (met een Smart EVSE) dat bij hem het relais (nogal duidelijk hoorbaar) steeds aan en uit schakelt als het laden wordt onderbroken. Dus ik ging er vanuit dat dat schakelen van het relais sowieso gebeurt. Maar volgens jou is dat dus niet het geval?

[Hippe Lip]

Andrehj schreef op zaterdag 20 december 2025 @ 11:12:
[...]

Het gaat me niet om het schakelen van het relais, maar ik vraag me af hoe het terugbrengen van de stroom bestuurd wordt.
Ik hoorde namelijk van een collega (met een Smart EVSE) dat bij hem het relais (nogal duidelijk hoorbaar) steeds aan en uit schakelt als het laden wordt onderbroken. Dus ik ging er vanuit dat dat schakelen van het relais sowieso gebeurt. Maar volgens jou is dat dus niet het geval?

Dat relais hoeft volgens mij niet te schakelen. En het besturen van de laadstroom gebeurt door de duty cycle (puls breedte) van de blokgolf te regelen op de CP-pin van de aansluiting.
Zoek dat maar eens op internet op. Redelijk eenvoudig vernuft.

[thalx]

Andrehj schreef op zaterdag 20 december 2025 @ 11:12:
[...]

Het gaat me niet om het schakelen van het relais, maar ik vraag me af hoe het terugbrengen van de stroom bestuurd wordt.
Ik hoorde namelijk van een collega (met een Smart EVSE) dat bij hem het relais (nogal duidelijk hoorbaar) steeds aan en uit schakelt als het laden wordt onderbroken. Dus ik ging er vanuit dat dat schakelen van het relais sowieso gebeurt. Maar volgens jou is dat dus niet het geval?

https://www.einfochips.co...the-ev-charging-standard/

Kan gewoon inderdaad via het protocol, ik heb bij mijn SmartEVSE nog nooit volgens mij het relais gehoord bij Smart/Solar mode als er even geen stroom beschikbaar is en hij terugschakelt naar 0, of weer opschaalt naar het laden van de auto.

[master1104]

Het relais wordt normaliter in elk geval niet gebruikt om onder load te schakelen. Kan ook zijn dat je college het L2/L3 relais hoorde? Die wordt optioneel gebruikt om een enkelfase laadoptie aan te bieden voor Solarmode. Het laadprotocol van EV’s staat geen laadstroom tussen 0 en 6A toe, waardoor je op drie fase dus alleen kan kiezen uit 0 of >18A laden. Door dit relais wordt dat kiezen uit 0 of > 6A. Daardoor wordt de laadstroom beter afgestemd op het beschikbare PV vermogen.

Al met al een top systeem dat SmartEVSE

[BazemanKM]

Vraag: Is de huidige SmartEVSE ook geschikt voor V2H/V2G?

[HyperBart]

hterhofte schreef op zaterdag 15 mei 2021 @ 14:11:
[...]


Ja, door op de zwarte knop te drukken, druk je feitelijk twee aparte knopjes tegelijk in.

• Een van die knopjes zorgt ervoor dat het printje, gevoed door de 3,3V knoopcel, het RF signaal naar de auto stuurt om het laadklepje te openen (wat alleen werkt als de auto unlocked is en/of als je met je gekoppelde smartphone dicht in de buurt van de auto bent).
• Het andere knopje lijkt 'iets' te doen met het PP-CP circuit. Sowieso zit het hele printje met twee draadjes (via de pinnetjes en de female connector die slecht contact bij mij maakte) aangesloten op de PP en CP polen van de stekker en komt ook in de plaats van de weerstand die de stekker normaal aan boord heeft om aan de auto aan te geven tot welke stroomsterkte de laadkabel belast kan worden.
  
  Door het knopje in te drukken wordt op zijn minst de weerstand veranderd in dit circuit (of wellicht zelfs wordt het circuit onderbroken?), waardoor de Tesla, indien de stekker erin zit en er mogelijk ook geladen wordt, sowieso het laden stopt en de vergrendering van de stekker haalt.

Zie ook https://www.evchargeking....lation%20Instructions.pdf

En zie ook dit schema: [Afbeelding]

Ik wil hier wat van bijleren en het zelf knutselen. Ik heb geen nood aan het RF gedeelte om het klepje open te doen maar ik wil wel dat ik op een knop kan duwen op de laadstekker zodat de Tesla de poort unlockt.
Weet iemand wat er precies gebeurt met die weerstanden? Wordt de PP en de PE gewoon verbroken of moet ik 2 weerstandjes bijzetten? Zo ja, welke?

[JoooostB]

De SmartEVSE staat hier al langer dan een jaar naar allen tevredenheid onze Tesla Model 3 zo goedkoop mogelijk te laden met behulp van EV Smart Charging in Home Assistant.
Sinds een paar weken is onze tweede auto ook vervangen voor een elektrische variant, namelijk de Renault 5. Deze doet het echter niet zo probleemloos als de Tesla en eerlijk gezegd verdenk ik de Franse slag in de Renault software 🇫🇷.

Hoe denken jullie over onderstaande?:

Het laden start prima, maar als de lader pauzeert (bijvoorbeeld omdat er even te weinig zonne-energie is of de stroomprijs te hoog is), hervat de Renault het laden niet meer zodra de EVSE van Off/Paused weer naar Smart schakelt. Mijn Tesla Model 3 heeft hier geen enkel probleem mee en gaat gewoon verder met laden.
Mijn vermoeden is dat de Renault de laadsessie bij het pauzeren volledig afbreekt en in een soort deep-sleep terecht komt waar hij niet meer uit wakker wordt tot ik op "Start charge" in de app druk of de auto fysiek ontgrendel.

Kan iemand mij vertellen hoe de SmartEVSE omgaat met stoppen en/of pauzeren van de laadsessie? Kan het zijn dat hier een soort disconnect gesimuleerd wordt om de auto te dwingen de sessie direct te stoppen in plaats van het communiceren van een pauze signaal (9V PWM)? Ik ben benieuwd naar jullie mening/bevindingen. Thanks!

[Hippe Lip]

BazemanKM schreef op zaterdag 20 december 2025 @ 15:06:
Vraag: Is de huidige SmartEVSE ook geschikt voor V2H/V2G?

Ik denk het niet, want het Control Pilot Signal protocol kent geen ruimte om teruglevering te activeren of regelen.

Zie de link over de protocollen een paar posts hiervoor.

[ Voor 14% gewijzigd door Hippe Lip op 20-12-2025 16:55 ]

[dingo35]

Dat klopt, V2G en V2H vereisen:
- een modem om het EV in V2G / V2H mode te schakelen
- iso15118-20 ondersteuning van zowel EV als SmartEVSE
- een inverter die de DC hoogspanning van het EV omzet naar 230V

Merk daarbij op dat er maar weinig EV's zijn die dit daadwerkelijk ondersteunen; mijn Enyaq zou dit als upgrade later krijgen, maar die upgrade is 3 jaar later nog niet gearriveerd; EVs die dit wel ondersteunen lijken daarvoor vaak één specifiek merk/model laadpaal nodig te hebben.

[Hippe Lip]

dingo35 schreef op zaterdag 20 december 2025 @ 17:39:
Dat klopt, V2G en V2H vereisen:
- een modem om het EV in V2G / V2H mode te schakelen
- iso15118-20 ondersteuning van zowel EV als SmartEVSE
- een inverter die de DC hoogspanning van het EV omzet naar 230V

Dan heb je het over DC-V2G.

Ik dacht meer aan AC-V2G, waarbij je met een type-2 stekker toe kan. Maar ook daarin voorziet dat CP-protocol niet, voor zover ik weet.
Hoe het dan wel moet weet ik ook niet.

[tukker999]

Andrehj schreef op zaterdag 20 december 2025 @ 11:12:
[...]

Het gaat me niet om het schakelen van het relais, maar ik vraag me af hoe het terugbrengen van de stroom bestuurd wordt.
Ik hoorde namelijk van een collega (met een Smart EVSE) dat bij hem het relais (nogal duidelijk hoorbaar) steeds aan en uit schakelt als het laden wordt onderbroken. Dus ik ging er vanuit dat dat schakelen van het relais sowieso gebeurt. Maar volgens jou is dat dus niet het geval?

Dat schakelen van het relais gebeurt alleen maar bij het schakelen van 0 naar iets en omgekeerd.
Voor het overige is het simpele communicatie van de SmartEVSE naar de EV en de EV bepaalt de stroomsterkte.
Een stukje script

code:

        -- Bepaal MAXIMAAL MOGELIJK niveau met MARGIN_UP
        if devices.availableEnergy >= (devices.powerLevels['16A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '16A'
        elseif devices.availableEnergy >= (devices.powerLevels['13A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '13A'
        elseif devices.availableEnergy >= (devices.powerLevels['10A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '10A'
        elseif devices.availableEnergy >= (devices.powerLevels['8A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '8A'
        elseif devices.availableEnergy >= (devices.powerLevels['6A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '6A'
        end

en naar de SmartEVSE toe

code:

--[[
    Script Name: Charging Level Selector Switch
    Description: This script manages the charging level of an electric vehicle (EV) charger based on the selected level from a Domoticz selector switch.
                 It sends MQTT commands to a Smart EVSE (Electric Vehicle Supply Equipment) to adjust the charging current or turn off the charger.
                 The script ensures that the EV charger operates at the desired current level or is turned off when the selector switch is set to "Off".

    Key Features:
    - Adjusts the charging current based on the selected level from a Domoticz selector switch.
    - Sends MQTT commands to a Smart EVSE to control the charging mode and current.
    - Logs the current charging level for debugging purposes.
    - Supports multiple charging levels (6A, 8A, 10A, 13A, 16A) and an "Off" state.

    Devices Involved:
    - 'Charging Level': A Domoticz selector switch that allows the user to set the desired charging level (Off, 6A, 8A, 10A, 13A, 16A).

    MQTT Topics:
    - "SmartEVSE/Set/CurrentOverride": Sets the charging current in deciamps (e.g., 60 for 6A, 80 for 8A, etc.).
    - "SmartEVSE/Set/Mode": Sets the charging mode to "Normal" or "Off".
    - "SmartEVSE/Set/ColorOff": Sets the LED color of the EVSE when it is turned off.

    Logic:
    - The script is triggered when the 'Charging Level' selector switch is changed.
    - It maps the selected level to a corresponding charging current (6A, 8A, 10A, 13A, 16A) or turns off the charger.
    - MQTT commands are sent to the Smart EVSE to adjust the charging current or turn off the charger.
    - The script logs the selected charging level for debugging purposes.

    Notes:
    - The script uses the `mosquitto_pub` command to send MQTT messages to the Smart EVSE.
    - The script assumes that the Smart EVSE is configured to listen to the specified MQTT topics.
    - The script runs only when the 'Charging Level' selector switch is changed.
]]--

return {
    on = {
        devices = {'Charging Level'},
    },
    logging = {
        level = domoticz.LOG_ERROR,
        marker = '---- Charging Level Selector Switch  -----',
    },
    execute = function(domoticz, device)
        local level = device.level
        domoticz.log('#1 Current charging level: ' .. level, domoticz.LOG_DEBUG)
        local powerLevels = {
            [0] = 'Off',
            [10] = '6A',
            [20] = '8A',
            [30] = '10A', 
            [40] = '13A', 
            [50] = '16A' 
        }
        local currentLevel = powerLevels[level]
        
        if currentLevel == 'Off' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 0')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Off')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/ColorOff" -m 0,250,0')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '6A'  then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 60')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '8A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 80')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '10A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 100')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '13A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 130')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '16A' then
            domoticz.executeShellCommand('mosquitto_pub  -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub  -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 160')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        end

        -- domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
    end
}

[Hippe Lip]

@Andrehj
Die besturing wordt in het genoemde document duidelijk uitgelegd, met onder andere deze tabel van de duty cycle van de blokgolf op de CP-pin.

[PimDoos]

Hippe Lip schreef op zaterdag 20 december 2025 @ 18:08:
[...]

Dan heb je het over DC-V2G.

Ik dacht meer aan AC-V2G, waarbij je met een type-2 stekker toe kan. Maar ook daarin voorziet dat CP-protocol niet, voor zover ik weet.
Hoe het dan wel moet weet ik ook niet.

"een inverter die de DC hoogspanning van het EV omzet naar 230V" kan je ook lezen als de OBC in de auto. Mijn Kia EV3 heeft zo'n OBC, maar deze kan nu alleen gebruikt worden als V2L. Volgens mij zijn de standaarden voor V2G nog niet helemaal rond.

[Hippe Lip]

PimDoos schreef op zaterdag 20 december 2025 @ 20:42:
[...]

"een inverter die de DC hoogspanning van het EV omzet naar 230V" kan je ook lezen als de OBC in de auto. Mijn Kia EV3 heeft zo'n OBC, maar deze kan nu alleen gebruikt worden als V2L. Volgens mij zijn de standaarden voor V2G nog niet helemaal rond.

De standaard voor V2G (ISO 15118-20) is al jaren rond. Dat is het probleem niet.
Dat de V2L in jouw auto niet als V2G werkt is omdat de synchronisatie er niet is. De auto moet synchroon met het net lopen om terug te kunnen leveren.

Mijn overtuiging is dat het er wel allemaal in zit, maar simpelweg niet aan staat.

[ Voor 6% gewijzigd door Hippe Lip op 20-12-2025 22:47 ]

[HyperBart]

HyperBart schreef op zaterdag 20 december 2025 @ 16:00:
[...]


Ik wil hier wat van bijleren en het zelf knutselen. Ik heb geen nood aan het RF gedeelte om het klepje open te doen maar ik wil wel dat ik op een knop kan duwen op de laadstekker zodat de Tesla de poort unlockt.
Weet iemand wat er precies gebeurt met die weerstanden? Wordt de PP en de PE gewoon verbroken of moet ik 2 weerstandjes bijzetten? Zo ja, welke?

Laatste onderzoek leert me dat Tesla hier (weer) wat uitzonderlijks toepast. Blijkbaar zou je de brug tussen mPP en PE kunnen verbreken en dan zou de wagen unlocken. Ik hou jullie op de hoogte.

[Jan-tweak]

Hippe Lip schreef op zaterdag 20 december 2025 @ 22:41:
[...]

De standaard voor V2G (ISO 15118-20) is al jaren rond. Dat is het probleem niet.
Dat de V2L in jouw auto niet als V2G werkt is omdat de synchronisatie er niet is. De auto moet synchroon met het net lopen om terug te kunnen leveren.

Mijn overtuiging is dat het er wel allemaal in zit, maar simpelweg niet aan staat.

even een vraag, is het niet dat de basis norm wel sinds 2022 is uitgebracht maar dat de verdere noodzakelijke "Amendments (ISO 15118-20:2022/FDAmd 1)" nog onder in de ontwerpfase, ze zitten nu zo ver ik weet in de laaste fase tot goedkeuring. (Under development - in the approval phase).
helaas weet ik niet welke aanvullingen nu daarin worden vastgelegd.
mogelijk dat iemand hier hier verdere informatie kan geven.
en vooral voor de EU is dat belangrijk omdat deze deel uit maakt van de nieuwe AFIR-verordening (Alternative Fuels Infrastructure Regulation), waarbij juist de completeISO 15118-20, dus incl. de ISO 15118-20:2022/FDAmd 1 ervan deel uitmaakt. Deze AFIR is echter ook nog niet vrijgegeven, maar de final draft is dat wel al (2-4-2025).
Ik denk dat de hele markt daarop aan het wachten is. en dat kost gewoon tijd, zeker bij een internationale norm als een ISO, goedkeuring kan hier zelfs over jaren gaan.

[stegen]

Het stoppen van het laden gaat in twee stappen.
Eerst schakelt de controller het PWM signaal uit, daardoor weet de auto de EVSE wil het laden stoppen. (zie seq 9.1)
De lader in de auto zal nu de laadstroom snel terug laten lopen tot 0A, en het laden stoppen.
De auto geeft aan dat hij gestopt is door terug te schakelen naar state B.
Als de EVSE deze state ziet, zal hij het relais ook laten afvallen. (dit moet binnen 100ms)

Blijft de EV echter om wat voor reden dan ook doorladen (seq 10.2), dan zal de EVSE het laden na 6 seconden onderbreken door het relais te openen. Dit is echter een veiligheidsfunctie, en zal in de praktijk bijna niet voorkomen.




@JoooostB
Ja. Het kan voorkomen dat de auto gaat slapen. Meerdere EV's hebben hier last van.
In de SmartEVSE software zitten verschillende manieren om de auto wakker te maken:
De controller stuurt in state B (aangesloten, klaar om te laden) na 30 seconden een "Activate" signaal.
Bij het stoppen /wisselen tussen fases, wordt het communicatie signaal onderbroken. Zodat de auto denkt dat de kabel opnieuw is aangesloten.
Helaas werkt dit zelfs in 2025 niet met alle EV's even goed.

Andrehj schreef op zaterdag 20 december 2025 @ 10:36:
Hoe stopt het laden bij te weinig beschikbare stroom?

Stel dat het laden tussendoor moet stoppen, omdat er te weinig PV-stroom beschikbaar is (bij PV-laden) of omdat een fase overbelast dreigt te laden. Wat gebeurt er dan? Ik kan twee mogelijkheden bedenken:

1. De EVSE communiceert met de auto dat de laadstroom naar 0 moet, wacht tot dat gedaan is (via feedback vanuit de auto?, de EVSE kan immers zelf niet meten) en schakelt dan het relais uit of
2. De EVSE schakelt direct het relais uit zonder hierover met de lader in de auto te communiceren.

Optie 1 lijkt me aardiger voor de elektronica in de auto, maar kan wellicht falen doordat de communicatie niet lekker gaat en is wellicht te langzaam.
Optie 2 werkt natuurlijk altijd, maar wat vindt de laadelektronica in de auto hiervan?

Misschien dat iemand (@dingo35 of @stegen?) kan uitleggen hoe dit werkt?

[ Voor 9% gewijzigd door stegen op 22-12-2025 12:42 ]

[JoooostB]

stegen schreef op maandag 22 december 2025 @ 12:31:
@JoooostB
Ja. Het kan voorkomen dat de auto gaat slapen. Meerdere EV's hebben hier last van.
In de SmartEVSE software zitten verschillende manieren om de auto wakker te maken:
De controller stuurt in state B (aangesloten, klaar om te laden) na 30 seconden een "Activate" signaal.
Bij het stoppen /wisselen tussen fases, wordt het communicatie signaal onderbroken. Zodat de auto denkt dat de kabel opnieuw is aangesloten.
Helaas werkt dit zelfs in 2025 niet met alle EV's even goed.

Bedankt voor je reactie @stegen, heb je een suggestie hoe ik dit eventueel zou kunnen oplossen? Ik zag dat STATE_B1 standaard een PILOT_DISCONNECTED uitvoert. Ik heb als test geprobeerd dit uit te schakelen (zodat hij in State B / 9V blijft), maar helaas valt de Renault alsnog in een diepe slaap waar hij niet meer uit ontwaakt zonder handmatige actie.

Ik las op andere fora dat een vergelijkbaar issue optrad bij laadpalen van Ohme en zij hiervoor een patch hebben uitgebracht; al weet ik de technische details daarvan niet. De Zappi daarentegen lijkt standaard al een manier te hebben om de Renault actief te houden.

Ik ben erg benieuwd wat jouw ideeën zijn om zo'n zelfde "patch"/wijziging te doen waarbij we voorkomen dat de Renault 5 in een deep-sleep status terecht komt. Het lijkt me in ieder geval duidelijk dat de oorsprong van het probleem bij Renault ligt en niet bij de SmartEVSE. Alvast bedankt voor het meedenken!

[BazemanKM]

tukker999 schreef op zaterdag 20 december 2025 @ 18:17:
[...]
Een stukje script

code:

        -- Bepaal MAXIMAAL MOGELIJK niveau met MARGIN_UP
        if devices.availableEnergy >= (devices.powerLevels['16A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '16A'
        elseif devices.availableEnergy >= (devices.powerLevels['13A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '13A'
        elseif devices.availableEnergy >= (devices.powerLevels['10A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '10A'
        elseif devices.availableEnergy >= (devices.powerLevels['8A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '8A'
        elseif devices.availableEnergy >= (devices.powerLevels['6A'] + CONFIG.MARGIN_UP) then
             maxPotentialLevel = '6A'
        end

Kun je het hele script ook plaatsen?

[tukker999]

BazemanKM schreef op maandag 22 december 2025 @ 16:31:
[...]

Kun je het hele script ook plaatsen?

Dat is 608 regels. Ik stuur het in een PM

[O085105116N]

Ik heb eem Smart EVSE V3 met firmware Version: v3.8.5. Ik gebruik de Smart mode om de auto op te laden. In het menu heb ik de Capacity 75A, MAX 16A, MIN 6A, Circuit 16A, MAINS meter=API ingesteld. Ik stuur de MAINS data iedere 3sec.
Mijn verwachting, in Smart mode moduleert de de EVSE tussen 6 en 16A, naar gelang het totale verbruik in huis.
In werkelijkheid staat ie te klapperen, ongeveer 10x per uur, soms precies per minuut, wat de CAP limit is. Ik heb gezien dat ie dan ook "Waiting for Power" aangeeft.
Het klapperen heb ik nog niet eerder geconstateerd, dus ik heb de evse maar eens herstart voor de zekerheid. Ik heb de warmtepomp aan, die zit op F1, dus soms heb ik daar een verbruik van 13 a 14 A op, maar dan is er nog headroom van 11A, dat is niet het minimum van 6A.

Wat zie ik over het hoofd? Is de API niet snel genoeg hier, werk Smart niet zoals ik denk dat het zou moeten?

[tukker999]

O085105116N schreef op dinsdag 23 december 2025 @ 10:04:
Ik heb eem Smart EVSE V3 met firmware Version: v3.8.5. Ik gebruik de Smart mode om de auto op te laden. In het menu heb ik de Capacity 75A, MAX 16A, MIN 6A, Circuit 16A, MAINS meter=API ingesteld. Ik stuur de MAINS data iedere 3sec.
Mijn verwachting, in Smart mode moduleert de de EVSE tussen 6 en 16A, naar gelang het totale verbruik in huis.
In werkelijkheid staat ie te klapperen, ongeveer 10x per uur, soms precies per minuut, wat de CAP limit is. Ik heb gezien dat ie dan ook "Waiting for Power" aangeeft.
Het klapperen heb ik nog niet eerder geconstateerd, dus ik heb de evse maar eens herstart voor de zekerheid. Ik heb de warmtepomp aan, die zit op F1, dus soms heb ik daar een verbruik van 13 a 14 A op, maar dan is er nog headroom van 11A, dat is niet het minimum van 6A.

Wat zie ik over het hoofd? Is de API niet snel genoeg hier, werk Smart niet zoals ik denk dat het zou moeten?

Waarom zou je de SmartEVSE iedere 3 seconden willen aansturen.
Ik krijg de indruk dat velen hier het laatste joultje energie in hun EV willen persen.
In mijn ogen is dat zinloos geweld.
Je kunt je zelfs afvragen of je de EV bij 6A überhaupt wilt laden.
De OBC vraagt 200-250W. Als je dan laadt bij 1400 W, reken maar uit wat je laadverlies is.

Ik heb het zelf afgesteld op aansturen met standen 6A, 8A, 10A, 13A en 16A waarbij wordt gemeten met een interval van 1 minuut met een buffer voor het op en neer schakelen van 200W.

Daarmee vermijdt je dat de SmartEVSE voortdurend signalen stuurt naar de OBC die dan ook voortdurend bezig is om de stroomsterkte te wijzigen.

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 10:04:
Ik heb eem Smart EVSE V3 met firmware Version: v3.8.5. Ik gebruik de Smart mode om de auto op te laden. In het menu heb ik de Capacity 75A, MAX 16A, MIN 6A, Circuit 16A, MAINS meter=API ingesteld. Ik stuur de MAINS data iedere 3sec.
Mijn verwachting, in Smart mode moduleert de de EVSE tussen 6 en 16A, naar gelang het totale verbruik in huis.
In werkelijkheid staat ie te klapperen, ongeveer 10x per uur, soms precies per minuut, wat de CAP limit is. Ik heb gezien dat ie dan ook "Waiting for Power" aangeeft.
Het klapperen heb ik nog niet eerder geconstateerd, dus ik heb de evse maar eens herstart voor de zekerheid. Ik heb de warmtepomp aan, die zit op F1, dus soms heb ik daar een verbruik van 13 a 14 A op, maar dan is er nog headroom van 11A, dat is niet het minimum van 6A.

Wat zie ik over het hoofd? Is de API niet snel genoeg hier, werk Smart niet zoals ik denk dat het zou moeten?

Max main op 25A? Dat kan je enkel op de smartEVSE instellen, niet via webpage
Post hier anders de “raw data”
Die krijg je door met browser naar de webpage te gaan, knop “raw data” onderaan.

[Stefannn]

tukker999 schreef op dinsdag 23 december 2025 @ 10:27:
[...]

Waarom zou je de SmartEVSE iedere 3 seconden willen aansturen.
Ik krijg de indruk dat velen hier het laatste joultje energie in hun EV willen persen.
In mijn ogen is dat zinloos geweld.
Je kunt je zelfs afvragen of je de EV bij 6A überhaupt wilt laden.
De OBC vraagt 200-250W. Als je dan laadt bij 1400 W, reken maar uit wat je laadverlies is.

Ik heb het zelf afgesteld op aansturen met standen 6A, 8A, 10A, 13A en 16A waarbij wordt gemeten met een interval van 1 minuut met een buffer voor het op en neer schakelen van 200W.

Daarmee vermijdt je dat de SmartEVSE voortdurend signalen stuurt naar de OBC die dan ook voortdurend bezig is om de stroomsterkte te wijzigen.

Als je langere tussenpozen dan 10 sec hebt dan werkt de stroombewaking niet meer.
Dan is het nog wel een evse maar niet meer smart.

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 10:30:
[...]

Max main op 25A? Dat kan je enkel op de smartEVSE instellen, niet via webpage
Post hier anders de “raw data”
Die krijg je door met browser naar de webpage te gaan, knop “raw data” onderaan.

Ik zeg nergens dat in max main op 25A heb gezet, of bedoel je de Sum Mains, die staat op 75A. Ik heb 3x25A in huis.

Dit is de RAW data

{"version":"v3.8.5","serialnr":8xxx,"mode":"OFF","mode_id":0,"car_connected":false,"wifi":{"status":"WL_CONNECTED","ssid":"xxxxxi","rssi":-52,"bssid":"30:xxxxxxxx4:EC"},"evse":{"temp":15,"temp_max":60,"connected":false,"access":0,"mode":1,"loadbl":0,"pwm":1024,"custombutton":false,"solar_stop_timer":0,"state":"Ready to Charge","state_id":0,"error":"None","error_id":0,"rfidreader":"Disabled","rfid":"Not Installed"},"settings":{"charge_current":0,"override_current":0,"current_min":6,"current_max":16,"current_main":25,"current_max_circuit":16,"current_max_sum_mains":75,"max_sum_mains_time":1,"solar_max_import":0,"solar_start_current":6,"solar_stop_time":10,"enable_C2":"Always On","mains_meter":"API","starttime":0,"stoptime":0,"repeat":0,"lcdlock":0,"lock":0,"cablelock":0},"mqtt":{"host":"homeaxxxxant.local","port":xxxx,"topic_prefix":"SmartEVSE-8xxxx","username":"xxxxxxxxx","password_set":true,"status":"Connected"},"ocpp":{"mode":"Disabled","backend_url":"","cb_id":"","auth_key":"","auto_auth":"Disabled","auto_auth_idtag":"","status":"Disconnected"},"home_battery":{"current":0,"last_update":0},"ev_meter":{"description":"WAGO","address":15,"import_active_power":0,"total_kwh":11906.6,"charged_kwh":0,"currents":{"TOTAL":0,"L1":0,"L2":0,"L3":0},"import_active_energy":11906.6,"export_active_energy":0},"mains_meter":{"import_active_energy":0,"export_active_energy":0},"phase_currents":{"TOTAL":40,"L1":20,"L2":0,"L3":20,"last_data_update":1766483120,"original_data":{"TOTAL":40,"L1":20,"L2":0,"L3":20}},"backlight":{"timer":0,"status":"OFF"},"color":{"off":{"R":0,"G":0,"B":0},"normal":{"R":0,"G":255,"B":0},"smart":{"R":0,"G":255,"B":0},"solar":{"R":255,"G":170,"B":0},"custom":{"R":0,"G":0,"B":255}}}

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 10:48:
[...]


Ik zeg nergens dat in max main op 25A heb gezet, of bedoel je de Sum Mains, die staat op 75A. Ik heb 3x25A in huis.

Dit is de RAW data

{"version":"v3.8.5","serialnr":8xxx,"mode":"OFF","mode_id":0,"car_connected":false,"wifi":{"status":"WL_CONNECTED","ssid":"xxxxxi","rssi":-52,"bssid":"30:xxxxxxxx4:EC"},"evse":{"temp":15,"temp_max":60,"connected":false,"access":0,"mode":1,"loadbl":0,"pwm":1024,"custombutton":false,"solar_stop_timer":0,"state":"Ready to Charge","state_id":0,"error":"None","error_id":0,"rfidreader":"Disabled","rfid":"Not Installed"},"settings":{"charge_current":0,"override_current":0,"current_min":6,"current_max":16,"current_main":25,"current_max_circuit":16,"current_max_sum_mains":75,"max_sum_mains_time":1,"solar_max_import":0,"solar_start_current":6,"solar_stop_time":10,"enable_C2":"Always On","mains_meter":"API","starttime":0,"stoptime":0,"repeat":0,"lcdlock":0,"lock":0,"cablelock":0},"mqtt":{"host":"homeaxxxxant.local","port":xxxx,"topic_prefix":"SmartEVSE-8xxxx","username":"xxxxxxxxx","password_set":true,"status":"Connected"},"ocpp":{"mode":"Disabled","backend_url":"","cb_id":"","auth_key":"","auto_auth":"Disabled","auto_auth_idtag":"","status":"Disconnected"},"home_battery":{"current":0,"last_update":0},"ev_meter":{"description":"WAGO","address":15,"import_active_power":0,"total_kwh":11906.6,"charged_kwh":0,"currents":{"TOTAL":0,"L1":0,"L2":0,"L3":0},"import_active_energy":11906.6,"export_active_energy":0},"mains_meter":{"import_active_energy":0,"export_active_energy":0},"phase_currents":{"TOTAL":40,"L1":20,"L2":0,"L3":20,"last_data_update":1766483120,"original_data":{"TOTAL":40,"L1":20,"L2":0,"L3":20}},"backlight":{"timer":0,"status":"OFF"},"color":{"off":{"R":0,"G":0,"B":0},"normal":{"R":0,"G":255,"B":0},"smart":{"R":0,"G":255,"B":0},"solar":{"R":255,"G":170,"B":0},"custom":{"R":0,"G":0,"B":255}}}

Ik zie niet zo gauw wat raars maar ben geen expert.
Ik zou geloof ik de Solar als test disablen. Kijken of hij het op puur smart goed doet.

“Current main” staat op 25. Dat is goed

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 10:52:
[...]

Ik zie niet zo gauw wat raars maar ben geen expert.
Ik zou geloof ik de Solar als test disablen. Kijken of hij het op puur smart goed doet.

Wat bedoel je met disabelen? Ik selecteer smart als ik de auto oplaad, ik gebruik solar nergens.

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 10:53:
[...]

Wat bedoel je met disabelen? Ik selecteer smart als ik de auto oplaad, ik gebruik solar nergens.

Weet ik niet precies
Ik stuur doe alle intelligentie in mijn home automation.
Maar “Solar” zou kunnen interfereren. Dat is wel vaker een probleem. Ik weet niet precies wat de goede settings zijn.
Wellicht iemand anders hier.

Current mains staat op 25. Dat is in ieder geval goed.

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 10:56:
[...]

Weet ik niet precies
Ik stuur doe alle intelligentie in mijn home automation.
Maar “Solar” zou kunnen interfereren. Dat is wel vaker een probleem. Ik weet niet precies wat de goede settings zijn.
Wellicht iemand anders hier.

Current mains staat op 25. Dat is in ieder geval goed.

Ik stuur ook aan via Homeassistant, maar die zet feitelijk alleen de smartevse op Smart via een automation, zodra het juiste moment is aangebroken, dus ik laad op, met Smart, niet met Normal of Solar.

Het klopt wel dat in Smart de smartevse terug moet moduleren tot 6A, dan schakelt ie uit?

[m.eddy]

6A per fase is het minimum wat nodig is om te laden. Daaronder stopt het laadproces.
Log je je P1 ook in HA? Kijk dan op de momenten van klapperen ook in die log.
Mat HA kun je de tracés van beide over elkaar heenleggen. Wellicht is er verbruiker die kortstondig losgaat en zo het proces onderbreekt? Qooker ofzow die even 5 sec 2KW pakt om te verwarmen?

Edit: typo

[O085105116N]

m.eddy schreef op dinsdag 23 december 2025 @ 11:06:
6A per fase is het minimum wat nodig is om te laden. Daaronder stopt het laadproces.
Log je je P1 ook in HA? Kijk dan op de momenten van klapperen ook in die log.
Mat HA kun je de tracés van beide over elkaar heenleggen. Wellicht is er verbruiker die kortstondig losgaat en zo het proces onderbreekt? Qooker ofzow die even 5 sec 2KW pakt om te verwarmen?

Edit: typo

Ik weet precies wat er gebeurt op de fases ja. Dat log ik. Ik zie soms pieken van 28A, de appliances in huis verbruiken dan rond de 17A, dat is meer dan voldoende headroom voor de 6A, maar de smartevse zegt dan "No power available". Na 60 seconden begint het spel dan weer opnieuw en staat ie te klapperen. Ik heb het vermoeden dat via de API de updates te traag binnenkomen op de smartevse, of dat het gedrag anders is dan verwacht als je de API gebruikt. Ik kan niet met zekerheid zeggen of het ooit heeft gewerkt zoals ik denk dat het moet werken. Ik loop er nu pas tegen aan.

[Stefannn]

m.eddy schreef op dinsdag 23 december 2025 @ 11:06:
6A per fase is het minimum wat nodig is om te laden. Daaronder stopt het laadproces.
Log je je P1 ook in HA? Kijk dan op de momenten van klapperen ook in die log.
Mat HA kun je de tracés van beide over elkaar heenleggen. Wellicht is er verbruiker die kortstondig losgaat en zo het proces onderbreekt? Qooker ofzow die even 5 sec 2KW pakt om te verwarmen?

Edit: typo

@O085105116N
Goed punt hierboven.
Als de smartevse meer dan 10 seconden geen meter data krijgt dan schakelt hij af.
Je kan tijdens het laden de webpage in de gaten houden. Dan zie je wel wat er fout gaat.
kan aan HA liggen of aan de netwerkverbinding met de smartevse.

[tukker999]

Stefannn schreef op dinsdag 23 december 2025 @ 10:32:
Als je langere tussenpozen dan 10 sec hebt dan werkt de stroombewaking niet meer.
Dan is het nog wel een evse maar niet meer smart.

Het is wel smart maar niet passief smart. Bij jouw door de stroombewaking, bij mij wordt iedere minuut gekeken naar wat er beschikbaar is en met die informatie wordt 'besloten' op hoeveel A de SmartEVSE wordt gezet.
Als bij ons de wasmaschine of de waterkoker stroom vraagt dan is er minder beschikbaar voor de EV en gaat de SmartEVSE naar een lagere stand of uit.
Sowieso is er van november tm februari geen energie over voor de EV.

Ik regel het in Domoticz.

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 11:10:
[...]

Ik weet precies wat er gebeurt op de fases ja. Dat log ik. Ik zie soms pieken van 28A, de appliances in huis verbruiken dan rond de 17A, dat is meer dan voldoende headroom voor de 6A, maar de smartevse zegt dan "No power available". Na 60 seconden begint het spel dan weer opnieuw en staat ie te klapperen. Ik heb het vermoeden dat via de API de updates te traag binnenkomen op de smartevse, of dat het gedrag anders is dan verwacht als je de API gebruikt. Ik kan niet met zekerheid zeggen of het ooit heeft gewerkt zoals ik denk dat het moet werken. Ik loop er nu pas tegen aan.

op 6A proberen te laden terwijl er elders 17A wordt gebruikt is wel een beetje "tricky".
Het op&af regelen van het laden gaat met de nodige reactie tijden. Niet alleen van de smartevse maar ook van de auto. frequent op&af schakelen als je rond de nominaal 6A probeert te laden vind ik absoluut niet raar.

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 11:11:
[...]

@O085105116N
Goed punt hierboven.
Als de smartevse meer dan 10 seconden geen meter data krijgt dan schakelt hij af.
Je kan tijdens het laden de webpage in de gaten houden. Dan zie je wel wat er fout gaat.
kan aan HA liggen of aan de netwerkverbinding met de smartevse.

Als ie meer dan 10 seconden geen data krijgt, dan zegt ie Can't read mains meter, check confog or wiring. Die melding zie ik niet tijdens het laden, er staat echt No Power available.

[O085105116N]

tukker999 schreef op dinsdag 23 december 2025 @ 11:13:
[...]

Het is wel smart maar niet passief smart. Bij jouw door de stroombewaking, bij mij wordt iedere minuut gekeken naar wat er beschikbaar is en met die informatie wordt 'besloten' op hoeveel A de SmartEVSE wordt gezet.
Als bij ons de wasmaschine of de waterkoker stroom vraagt dan is er minder beschikbaar voor de EV en gaat de SmartEVSE naar een lagere stand of uit.
Sowieso is er van november tm februari geen energie over voor de EV.

Ik regel het in Domoticz.

Ik laat het volledig over aan de smartevse. Daar heb ik ook alles ingesteld. Stroomsturing doe ik dus niet via HA, ik zou ook niet weten hoe, want als je 10sec niks stuurt dan stop de smartevse.

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 11:13:
[...]

op 6A proberen te laden terwijl er elders 17A wordt gebruikt is wel een beetje "tricky".
Het op&af regelen van het laden gaat met de nodige reactie tijden. Niet alleen van de smartevse maar ook van de auto. frequent op&af schakelen als je rond de nominaal 6A probeert te laden vind ik absoluut niet raar.

Hoezo? 25A is de max. De zekering kan tijdelijk wel meer dan 25A hebben, dat is toch het hele idee van smart laden? terug moduleren en als het niet meer past stoppen met laden.

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 11:13:
[...]

op 6A proberen te laden terwijl er elders 17A wordt gebruikt is wel een beetje "tricky".
Het op&af regelen van het laden gaat met de nodige reactie tijden. Niet alleen van de smartevse maar ook van de auto. frequent op&af schakelen als je rond de nominaal 6A probeert te laden vind ik absoluut niet raar.

ik probeer niet rond de 6A te laden, ik wil max3x16 A laden en terug naar 6A moduleren en als dat niet meer past, want >25A dan stoppen.

[Robert-Jan]

O085105116N schreef op dinsdag 23 december 2025 @ 10:04:
...
Mijn verwachting, in Smart mode moduleert de de EVSE tussen 6 en 16A, naar gelang het totale verbruik in huis.
In werkelijkheid staat ie te klapperen, ongeveer 10x per uur, soms precies per minuut, wat de CAP limit is. Ik heb gezien dat ie dan ook "Waiting for Power" aangeeft.

Bij het laden van mijn twee auto's met SmartEVSE zag ik vergelijkbaar gedrag gisteren:

• De auto's starten met laden, maar het duurt even voordat er daadwerkelijk stroom gaat lopen.
• In die tijd schakelt SmartEVSE door naar de maximale instelling (16A, 3 fasen).
• Zodra de stroom op gang komt, blijkt de totale stroom boven de limiet van 25A uit te komen.
• SmartEVSE schakelt terug, maar de werkelijke stroom zakt niet direct mee.
• Daardoor schakelt SmartEVSE te snel af met de melding “Waiting for Power”.
• Vervolgens begint dit proces opnieuw.

De maximale stroom heb ik nu tijdelijk verlaagd naar 10A, het laden werkt dan stabiel.

Ik overweeg een EVMeter toe te voegen zodat de werkelijke stroom gemeten wordt. Mijn verwachting is dat dit het probleem oplost.

[O085105116N]

Robert-Jan schreef op dinsdag 23 december 2025 @ 12:15:
[...]


Bij het laden van mijn twee auto's met SmartEVSE zag ik vergelijkbaar gedrag gisteren:

• De auto's starten met laden, maar het duurt even voordat er daadwerkelijk stroom gaat lopen.
• In die tijd schakelt SmartEVSE door naar de maximale instelling (16A, 3 fasen).
• Zodra de stroom op gang komt, blijkt de totale stroom boven de limiet van 25A uit te komen.
• SmartEVSE schakelt terug, maar de werkelijke stroom zakt niet direct mee.
• Daardoor schakelt SmartEVSE te snel af met de melding “Waiting for Power”.
• Vervolgens begint dit proces opnieuw.

De maximale stroom heb ik nu tijdelijk verlaagd naar 10A, het laden werkt dan stabiel.

Ik overweeg een EVMeter toe te voegen zodat de werkelijke stroom gemeten wordt. Mijn verwachting is dat dit het probleem oplost.

[Afbeelding]

Ik stuur nu nog via ser2net de p1 data naar HA en dan naar de smartevse. Ik wil HA er tussenuit hebben als mitm. Ik zoek een oplossing om via de rpi met ser2net naar HA en de smartevse P1 data te sturen. Ik heb 2 smartevse's, waarvan 1 actief in gebruik, de tweede wil ik pas gebruiken als ik de 1e goed onder controle heb. Maar het begint toch wel te kraken links en rechts als je full electric gaat, met een matig gesisoleerd huis, je blijft wat aan de gang zeg.

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 12:22:
[...]

Ik stuur nu nog via ser2net de p1 data naar HA en dan naar de smartevse. Ik wil HA er tussenuit hebben als mitm. Ik zoek een oplossing om via de rpi met ser2net naar HA en de smartevse P1 data te sturen. Ik heb 2 smartevse's, waarvan 1 actief in gebruik, de tweede wil ik pas gebruiken als ik de 1e goed onder controle heb. Maar het begint toch wel te kraken links en rechts als je full electric gaat, met een matig gesisoleerd huis, je blijft wat aan de gang zeg.

Je stuurt data per 3 sec, maar is die ook "recent" per 3sec?
Oude meters geven data per 10sec. Die kan je wel per 3sec sturen maar dan stuur je steeds 3x a 4x dezelfde waarde en daarvan raakt het regel algoritme van de smartEVSE in de war.

Klopt dat als je 17A elders gebruikt er in principe 8A beschikbaar is voor de auto. Echter.... de reactietijden van smartEVSE; P1->HA->api; en auto tellen behoorlijk op. Als er maar 8A beschikbaar is dan is het niet raar dat de regelaar doorschiet naar onder de 6A en daarmee naar "uit".

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 13:27:
[...]

Je stuurt data per 3 sec, maar is die ook "recent" per 3sec?
Oude meters geven data per 10sec. Die kan je wel per 3sec sturen maar dan stuur je steeds 3x a 4x dezelfde waarde en daarvan raakt het regel algoritme van de smartEVSE in de war.

Klopt dat als je 17A elders gebruikt er in principe 8A beschikbaar is voor de auto. Echter.... de reactietijden van smartEVSE; P1->HA->api; en auto tellen behoorlijk op. Als er maar 8A beschikbaar is dan is het niet raar dat de regelaar doorschiet naar onder de 6A en daarmee naar "uit".

ik denk dat dit inderdaad de juiste conclusie is, het mechanisme hier is in zn totaliteit te traag. Ik ga kijken of ik ser2net kan afvangen en relayen direct naar andere "afnemers".

[tukker999]

O085105116N schreef op dinsdag 23 december 2025 @ 13:56:
[...]

ik denk dat dit inderdaad de juiste conclusie is, het mechanisme hier is in zn totaliteit te traag. Ik ga kijken of ik ser2net kan afvangen en relayen direct naar andere "afnemers".

Vandaar dat je beter met software en een buffer kunt regelen.

[O085105116N]

tukker999 schreef op dinsdag 23 december 2025 @ 14:43:
[...]

Vandaar dat je beter met software en een buffer kunt regelen.

Nee geen buffer. Ik wil dat de smartevse realtime op de hoogte is van het verbruik in huis en daar op kan reageren.

[ocaj]

Als je systeemreactie te traag is, dan helpt het misschien om data 1 keer per seconde te sturen (of zo vaak als je nieuwe data voorhanden hebt)?

Ik stuur de data van mijn hoofdaansluiting 1 x per sec via de API door en het regelt allemaal vlotjes. Er wordt snel teruggeschakeld als het nodig is en opschakelen doet de SmartEVSE sowieso in een paar stapjes en niet in één keer.

(overigens heb ik er wel een EV-Meter aan hangen, dus de SmartEVSE weet precies wat de auto doet, ik kan me voorstellen dat het algoritme iets minder strak regelt als de SmartEVSE het stroomverbruik van de auto af moet leiden uit de MAINS-data)

[Stefannn]

tukker999 schreef op dinsdag 23 december 2025 @ 14:43:
[...]

Vandaar dat je beter met software en een buffer kunt regelen.

Jouw setup vereist eigenlijk wel dat je alle gebruikers zelf stuurt of heel goed weet "wat er kan komen".
In mijn geval:
warmtepomp die 6A trekt
close in boiler die "naar eigen goeddunken" aanslaat en 10A trekt
Jacuzzi die "naar eigen goeddunken" aanslaat en 10A trekt
Nespresso apparaat dat zomaar 10A kan trekken.
Andere gebruikers op 1 a 2A basisload.

Kortom... een basisload van 6A..8A en onvoorspelbare 10A jumps erop.
Als ik sta te laden met 16A plus 8A basislood heb ik dus 24A op de mains zekering.
Als dan de close-in boiler of jacuzzi aanslaat of ik een Nespresso zet wordt dat opeens 34A, dus 34/25 =1,36x overload.
Dat kan de mains zekering ongeveer 60seconden hebben.
Met 1x/minuut regelen wordt het dan heel erg krap.

[Stefannn]

ocaj schreef op dinsdag 23 december 2025 @ 15:26:
Als je systeemreactie te traag is, dan helpt het misschien om data 1 keer per seconde te sturen (of zo vaak als je nieuwe data voorhanden hebt)?

Ik stuur de data van mijn hoofdaansluiting 1 x per sec via de API door en het regelt allemaal vlotjes. Er wordt snel teruggeschakeld als het nodig is en opschakelen doet de SmartEVSE sowieso in een paar stapjes en niet in één keer.

(overigens heb ik er wel een EV-Meter aan hangen, dus de SmartEVSE weet precies wat de auto doet, ik kan me voorstellen dat het algoritme iets minder strak regelt als de SmartEVSE het stroomverbruik van de auto af moet leiden uit de MAINS-data)

@O085105116N
1x per seconde zou het heel goed kunnen oplossen. De tijdconstantes van de smartEVSE zijn geoptimaliseerd voor 1x per seconde (omdat dat de verversing van de moderne P1 is). Dan is het heel voorstelbaar dat je bij een 3x tragere feed overschot krijgt.

[O085105116N]

Robert-Jan schreef op dinsdag 23 december 2025 @ 12:15:
[...]


Bij het laden van mijn twee auto's met SmartEVSE zag ik vergelijkbaar gedrag gisteren:

• De auto's starten met laden, maar het duurt even voordat er daadwerkelijk stroom gaat lopen.
• In die tijd schakelt SmartEVSE door naar de maximale instelling (16A, 3 fasen).
• Zodra de stroom op gang komt, blijkt de totale stroom boven de limiet van 25A uit te komen.
• SmartEVSE schakelt terug, maar de werkelijke stroom zakt niet direct mee.
• Daardoor schakelt SmartEVSE te snel af met de melding “Waiting for Power”.
• Vervolgens begint dit proces opnieuw.

De maximale stroom heb ik nu tijdelijk verlaagd naar 10A, het laden werkt dan stabiel.

Ik overweeg een EVMeter toe te voegen zodat de werkelijke stroom gemeten wordt. Mijn verwachting is dat dit het probleem oplost.

[Afbeelding]

ik heb even wat geknutseld. <Link weggehaald> Bij mij werkt dit, als in, de smartevse accepteert het zo, hij geeft geen fouten. Ik moet het laden zelf wel nog testen. Ik gebruik de rpi als een P1 splitter in feite. Wellicht voor de ontwikkelaar een idee om een modus op de API te zetten waarbij er naar changes wordt geluisterd, in plaats van continue een datastroom te gebruiken. In feite is het nog net geen netwerk spammen zo.

[ Voor 8% gewijzigd door O085105116N op 24-12-2025 11:46 ]

[O085105116N]

Stefannn schreef op dinsdag 23 december 2025 @ 16:17:
[...]

@O085105116N
1x per seconde zou het heel goed kunnen oplossen. De tijdconstantes van de smartEVSE zijn geoptimaliseerd voor 1x per seconde (omdat dat de verversing van de moderne P1 is). Dan is het heel voorstelbaar dat je bij een 3x tragere feed overschot krijgt.

Ja, dat zou je denken, maar uit mijn slimme meter komen de telegrammen om de circa 8 seconden. Althans, als ik dat direct monitor op de rpi.

[Stefannn]

O085105116N schreef op dinsdag 23 december 2025 @ 18:12:
[...]


Ja, dat zou je denken, maar uit mijn slimme meter komen de telegrammen om de circa 8 seconden. Althans, als ik dat direct monitor op de rpi.

Dat is raar,
bij mijn weten zijn. er 2 standaards:
1 seconde
10 seconde
Dus niet 8.

Anyway...
Het kan heel goed zijn dat dat de reden van de fluctuatie is.
Ik heb zelf 10 secondes en ook nog eens enkel het totaal (dus niet per fase).
Daarmee kreeg ik de smartEVSE niet aan de praat. inderdaad oscillerend gedrag.
Ik heb nu een eigen controller gemaakt en stuur de smartEVSE via de api override current aan.

[dingo35]

@O085105116N Als je niet in Belgie woont moet Capacity (=MaxSumMains) disabled staan, dat is alleen bedoeld om het EU capaciteitstarief te managen.

De toevoer van MaxMains moet zoveel mogelijk gebeuren in hetzelfde tempo als de ontvangst van de P1-telegrammen; als je dezelfde meting vaker verstuurt (bijv. om de 10s deadline te halen) krijg je een tweemaal zo "agressieve" regeling, die bovendien op nepdata gestoeld is....

De regelloop werkt bij een modbus meter of een sensorbox op een frequentie van ca. 1x per 2 seconden; ik zou zeker niet vaker nieuwe waardes toevoeren, dat is zinloos en kan tot overbelasting van de ESP32 leiden..

[ Voor 20% gewijzigd door dingo35 op 23-12-2025 21:51 ]

[O085105116N]

dingo35 schreef op dinsdag 23 december 2025 @ 21:48:
@O085105116N Als je niet in Belgie woont moet Capacity (=MaxSumMains) disabled staan, dat is alleen bedoeld om het EU capaciteitstarief te managen.

De toevoer van MaxMains moet zoveel mogelijk gebeuren in hetzelfde tempo als de ontvangst van de P1-telegrammen; als je dezelfde meting vaker verstuurt (bijv. om de 10s deadline te halen) krijg je een tweemaal zo "agressieve" regeling, die bovendien op nepdata gestoeld is....

De regelloop werkt bij een modbus meter of een sensorbox op een frequentie van ca. 1x per 2 seconden; ik zou zeker niet vaker nieuwe waardes toevoeren, dat is zinloos en kan tot overbelasting van de ESP32 leiden..

De ESP vraagt er om, ik doe dat niet uit vrije wil. Als ik het interval te groot maak, dan stopt ie gewoon met werken, zoals eerder al vermeld,

[dingo35]

Dan moet je een sensorbox aansluiten, die verstuurt het wél met de juiste frequentie; al dan niet met CT klemmen....

[master1104]

O085105116N schreef op dinsdag 23 december 2025 @ 18:05:
[...]

ik heb even wat geknutseld. https://github.com/simonsays-techtalk/p1tosmartevse Bij mij werkt dit, als in, de smartevse accepteert het zo, hij geeft geen fouten. Ik moet het laden zelf wel nog testen. Ik gebruik de rpi als een P1 splitter in feite. Wellicht voor de ontwikkelaar een idee om een modus op de API te zetten waarbij er naar changes wordt geluisterd, in plaats van continue een datastroom te gebruiken. In feite is het nog net geen netwerk spammen zo.

Interessant! Ik heb het uiteindelijk zo geregeld: via Ser2Net naar HA en dan bij ontvangst direct een automation die het via MQTT naar de SmartEVSE zet. Mijn idee is dat MQTT een stuk minder heavy voor het netwerk is.

Nog mooier is natuurlijk als de SmartEVSE een native koppeling met Ser2Net zou ondersteunen, dan kan HA er zonder enig script er gewoon tussenuit. @stegen @dingo35 , zou zoiets complex zijn om te implementeren? De broncode kan je wellicht van HA lenen, daar zit het al in de DSMR meter integratie.

[Refthoom]

O085105116N schreef op dinsdag 23 december 2025 @ 18:12:
[...]


Ja, dat zou je denken, maar uit mijn slimme meter komen de telegrammen om de circa 8 seconden. Althans, als ik dat direct monitor op de rpi.

Volgens mij is dat verschil door DSMR 4 en 5 die respectievelijk iedere 10 en 1 seconden telegrammen sturen.

[dingo35]

master1104 schreef op dinsdag 23 december 2025 @ 23:48:
[...]

Interessant! Ik heb het uiteindelijk zo geregeld: via Ser2Net naar HA en dan bij ontvangst direct een automation die het via MQTT naar de SmartEVSE zet. Mijn idee is dat MQTT een stuk minder heavy voor het netwerk is.

Nog mooier is natuurlijk als de SmartEVSE een native koppeling met Ser2Net zou ondersteunen, dan kan HA er zonder enig script er gewoon tussenuit. @stegen @dingo35 , zou zoiets complex zijn om te implementeren? De broncode kan je wellicht van HA lenen, daar zit het al in de DSMR meter integratie.

De SmartEVSE heeft daarvoor geen seriele poort meer vrij, dus er is een extra ESP32 nodig die de P1 poort uitleest en naar de SmartEVSE stuurt.
Dat ding zit in een kastje ingebouwd, kan ook met CT klemmen werken igv domme meter, en heet "sensorbox".

[O085105116N]

Ik kan iig concluderen dat de smartevse niet doet wat ik wil dat ie doet. Ik heb 2 smartevse, hoe ga ik die nu aansturen dan? Hoe moet ik de api gebruiken zodat ik dat klapperen kan voorkomen? Dit gaat dus bijna 2 uur zo door.

[dingo35]

Ook na het disablen van Capacity?

[ocaj]

O085105116N schreef op woensdag 24 december 2025 @ 04:56:
Ik kan iig concluderen dat de smartevse niet doet wat ik wil dat ie doet. Ik heb 2 smartevse, hoe ga ik die nu aansturen dan? Hoe moet ik de api gebruiken zodat ik dat klapperen kan voorkomen? Dit gaat dus bijna 2 uur zo door. [Afbeelding]

Je zegt dat je 2 SmartEVSE's hebt, maar in de ruwe data die je gisteren posste heb je staan "loadbl":0". Dat klinkt alsof Load Balancing/Power Share uit staat. Dat is de functie die er voor zorgt er voor dat de SmartEVSE's samenwerken.

Heb je de SmartEVSE's wel onderling via modbus verbonden zoals in de installatiehandleiding staat? Vervolgens wijs je er in de instelling één als master aan en de andere als een Node. Ik meen me te herinneren dat je de MAINS-data alleen naar de master hoeft te sturen, maar dat zou je moeten nakijken.

(ik heb er zelf maar 1, dus geen ervaring mee, maar dit is wat ik van de handleiding/documentatie begrepen heb)

p.s. had je misschien ook in eerdere posts even kunnen melden dat je twee SmartEVSE's hebt....

[ Voor 4% gewijzigd door ocaj op 24-12-2025 09:14 ]

[Refthoom]

dingo35 schreef op woensdag 24 december 2025 @ 03:35:
[...]

De SmartEVSE heeft daarvoor geen seriele poort meer vrij, dus er is een extra ESP32 nodig die de P1 poort uitleest en naar de SmartEVSE stuurt.
Dat ding zit in een kastje ingebouwd, kan ook met CT klemmen werken igv domme meter, en heet "sensorbox".

Volgens mij bedoelt @master1104 een software koppeling.

[O085105116N]

ocaj schreef op woensdag 24 december 2025 @ 09:12:
[...]

Je zegt dat je 2 SmartEVSE's hebt, maar in de ruwe data die je gisteren posste heb je staan "loadbl":0". Dat klinkt alsof Load Balancing/Power Share uit staat. Dat is de functie die er voor zorgt er voor dat de SmartEVSE's samenwerken.

Heb je de SmartEVSE's wel onderling via modbus verbonden zoals in de installatiehandleiding staat? Vervolgens wijs je er in de instelling één als master aan en de andere als een Node. Ik meen me te herinneren dat je de MAINS-data alleen naar de master hoeft te sturen, maar dat zou je moeten nakijken.

(ik heb er zelf maar 1, dus geen ervaring mee, maar dit is wat ik van de handleiding/documentatie begrepen heb)

p.s. had je misschien ook in eerdere posts even kunnen melden dat je twee SmartEVSE's hebt....

Ja dat klopt, ik heb er 2, maar momenteel maar 1 in gebruik, als ik er daadwerkelijk 2 in gebruik zou hebben, had ik dat zeker gemeld. De eerste wil ik eerst goed werkend hebben en begrijpen voordat ik de tweede in gebruik nemen, die is voor "gasten" of zelf zelf sporadisch laden en heeft geen vaste kabel, maar dat terzijde.Waar om ik dan meldde dat ik er 2 heb? Omdat ik geen zin heb om naar de tweede laadpaal een extra kabel te trekken voor een P1 meter/sensorbox. Ik moet wel nog even het laadgedrag controleren van vannacht, want het lijkt er op dat het nu wel beter gaat met de constructie die ik nu heb.

[O085105116N]

dingo35 schreef op woensdag 24 december 2025 @ 08:39:
Ook na het disablen van Capacity?

Die staat nog aan.

[dingo35]

Tsja als je mn adviezen niet opvolgt ga ik stoppen ze te geven....
Minder typen, meer LEZEN!

[O085105116N]

dingo35 schreef op woensdag 24 december 2025 @ 10:56:
Tsja als je mn adviezen niet opvolgt ga ik stoppen ze te geven....
Minder typen, meer LEZEN!

Ik wilde niet teveel aanpassingen tegelijk doen.

[dingo35]

Dan had je ipv je klaagzang van 4:56 te typen die setting aan kunnen passen, en pas als dat niet werkt je bevindingen posten.
Nu vermoei je honderden volgers met irrelevante posts, en neem je onnodige tijd van ontwikkelaars in beslag.

[thalx]

Ik denk dat het goed is als we met zijn allen blijven beseffen dat sommige ontwikkelaars het ook maar in hun vrije tijd erbij doen (en zonder betaling). En dat de kwaliteit en toon van het aanleveren van issues kan helpen bij het krijgen van een goed antwoord/oplossing en een blije ontwikkelaar met meer vrije tijd.

Puntje bij paaltje zijn we allemaal EV-laadpaal enthousiastelingen, en willen zoveel mogelijk tweaken ermee, met alle passie die daarbij komt kijken.

[ Voor 18% gewijzigd door thalx op 24-12-2025 11:53 ]

[master1104]

dingo35 schreef op woensdag 24 december 2025 @ 03:35:
[...]

De SmartEVSE heeft daarvoor geen seriele poort meer vrij, dus er is een extra ESP32 nodig die de P1 poort uitleest en naar de SmartEVSE stuurt.
Dat ding zit in een kastje ingebouwd, kan ook met CT klemmen werken igv domme meter, en heet "sensorbox".

Dank voor je reactie 👍 Zoals @Refthoom al stelde doel ik inderdaad op een software koppeling. Veel Tweakers gebruiken Ser2Net om de P1 data naar HA te sturen. Het mooie is dat Ser2Net meerdere sockets tegelijk kan onderhouden, waardoor je een directe verbinding met zowel HA als de SmartEVSE kan onderhouden. Dat scheelt latency en zal het regelgedrag van de SmartEVSE verbeteren. Ook zal het in HA enkele procenten CPU load schelen, die automation om de data te sturen kost best veel rekenkracht heb ik gemerkt.

code:

 +------------------------+
|     P1 DSMR METER      |
+-----------+------------+
            |
            |  P1 datakabel
            |
+-----------v------------+
|        Ser2Net         |
|   (serial -> network)  |
+-----------+------------+
            |
            |  Netwerkstream (TCP)
            |
        +---+---+
        |       |
        |       |
+-------v--+   +v------------------+
| SmartEVSE |   | Home Assistant   |
|  (TCP)    |   |  (DSMR integr.)  |
+-----------+   +------------------+

[ Voor 23% gewijzigd door master1104 op 24-12-2025 17:25 ]

[Refthoom]

En de idee erbij is dat er voor de SmartEVSE hopelijk niet veel verschil is of een telegram via MQTT binnenkomt of via Ser2Net.

[manusjevanalles]

master1104 schreef op woensdag 24 december 2025 @ 17:17:
[...]

Dank voor je reactie 👍 Zoals @Refthoom al stelde doel ik inderdaad op een software koppeling. Veel Tweakers gebruiken Ser2Net om de P1 data naar HA te sturen. Het mooie is dat Ser2Net meerdere sockets tegelijk kan onderhouden, waardoor je een directe verbinding met zowel HA als de SmartEVSE kan onderhouden. Dat scheelt latency en zal het regelgedrag van de SmartEVSE verbeteren. Ook zal het in HA enkele procenten CPU load schelen, die automation om de data te sturen kost best veel rekenkracht heb ik gemerkt.

code:

 +------------------------+
|     P1 DSMR METER      |
+-----------+------------+
            |
            |  P1 datakabel
            |
+-----------v------------+
|        Ser2Net         |
|   (serial -> network)  |
+-----------+------------+
            |
            |  Netwerkstream (TCP)
            |
        +---+---+
        |       |
        |       |
+-------v--+   +v------------------+
| SmartEVSE |   | Home Assistant   |
|  (TCP)    |   |  (DSMR integr.)  |
+-----------+   +------------------+

Op welk device draai je ser2net? Kan dat gewoon op een esp?

[thalx]

ser2net kun je op linux-based systemen draaien zoals Raspberry Pi's, computers, etc.
Een ESP helaas niet, maar daar zijn wel custom firmwares voor op internet om óók als serial-to-TCP bridge te dienen (maar vaak niet multi-connection)

[dingo35]

Volgens mij is een kant-en-klare sensorbox een stuk goedkoper dan een Raspberry Pi + voeding + SD card + kastje, heeft de mogelijkheid zowel via modbus als via wifi met de SmartEVSE en/of HomeAssistant te communiceren, ondersteunt ook MQTT voor de rest van je domotica.

Zelfs als je op zoek bent naar een nuttige tijdsbesteding kun je m.i. beter een sensorbox nabouwen, zowel hardware als software volledig opensource https://github.com/SmartEVSE/Sensorbox-2

EDIT: Het is eenieder inmiddels duidelijk dat een zuiver softwarematige oplossing om P1 naar SmartEVSE te krijgen niet bestaat, dat je op zn minst een SlimmeLezer of RPI of ESP32 nodig hebt, om je ser2net of wat dan ook op te draaien?

[ Voor 20% gewijzigd door dingo35 op 25-12-2025 13:42 ]

[Refthoom]

dingo35 schreef op donderdag 25 december 2025 @ 13:39:
Volgens mij is een kant-en-klare sensorbox een stuk goedkoper dan een Raspberry Pi + voeding + SD card + kastje, heeft de mogelijkheid zowel via modbus als via wifi met de SmartEVSE en/of HomeAssistant te communiceren, ondersteunt ook MQTT voor de rest van je domotica.

Zelfs als je op zoek bent naar een nuttige tijdsbesteding kun je m.i. beter een sensorbox nabouwen, zowel hardware als software volledig opensource https://github.com/SmartEVSE/Sensorbox-2

EDIT: Het is eenieder inmiddels duidelijk dat een zuiver softwarematige oplossing om P1 naar SmartEVSE te krijgen niet bestaat, dat je op zn minst een SlimmeLezer of RPI of ESP32 nodig hebt, om je ser2net of wat dan ook op te draaien?

Hebben de Sensorbox V2 en SmartEVSE met de nieuwste firmware versies nog steeds DSMR5 met iedere seconde een telegram als een vereiste?

Als ik het goed begrijp kwamen we namelijk zover in dit draadje omdat de SmartEVSE per seconde een telegram wil hebben zoals DSMR5 levert. De extra spullen (rpi etc) zorgen ervoor dat de lagere frequentie van telegrammen van lagere DSMR versies verhoogd wordt door berichten iedere seconde te herhalen.

Het is iedereen denk ik wel duidelijk dat de slimme meter zelf geen wifi o.i.d. heeft en er dus altijd iets tussen moet wat de telegrammen van de P1 leest.

Als de sensorbox via wifi de telegrammen naar de SmartEVSE kan sturen is dat natuurlijk prachtig. Er zal wel eerst via modbus (eenmalig?) verbinding moeten zijn om de wifi te enablen en of de firmware te upgraden, toch?

[thalx]

Volgens mij was er in eerdere reacties hier al aangegeven dat het niet slim is om een DSMR4 telegram meerdere keren te versturen omwille van de timeout, omdat ook de SMART/SOLAR sturing hier niet lekker op gaat omdat je doet alsof 5 seconde later het verbruik nog steeds hetzelfde is tegenover bijvoorbeeld de dan huidige EV-meter waardes die wél elke seconde misschien update (geen idee of dit zo is).
Ik deed dit zelf ook eerst (Python script van ser2net > MQTT > SmartEVSE) door het DSMR4 telegram 3x te verzenden, maar dit werkte niet lekker, waardoor ik het ook heb teruggezet naar 1x per DSMR4 telegram doorsturen naar MQTT. Aan de ene kant zou je willen dat de time-out instelbaar zou zijn bij SmartEVSE misschien, maar aan de andere kant is 10 seconden al erg lang als je op bijvoorbeeld 11+ kW aan het laden bent, een droger aanschiet + warmtepomp, etc. Omwille van je hoofdzekering is 10 seconde al heel lang, indien je ver boven je aansluiting verbruikt 10 seconde lang. Door het karakteristiek zal hij er echt niet direct uitklappen bij 10 seconde 26A ipv 25, maar met hogere uitschieters gaat het wel sneller

Zoals al aangegeven kom je dan uit op een andere oplossing dan P1, zoals de sensorbox met CT-clamps of een andere DIY oplossing met CT-clamps of modbus meter.

[ Voor 23% gewijzigd door thalx op 25-12-2025 16:16 ]

[Refthoom]

Blijft wel lastig dat het me nog niet gelukt is om de netbeheerder mijn DSMR4 slimme meter te vervangen door een DSMR5 exemplaar. Daarom heb ik het laden beperkt vanuit de auto app en is solar geen optie.

[stefxx]

Refthoom schreef op donderdag 25 december 2025 @ 16:08:
Blijft wel lastig dat het me nog niet gelukt is om de netbeheerder mijn DSMR4 slimme meter te vervangen door een DSMR5 exemplaar.

Ik heb bij Liander vorig jaar online gewoon een nieuwe meter aangevraagd, terwijl ik een prima functionerende (DSMR4) meter had. Was iets van 75 euro, en een week of 4 later hing deze in mijn meterkast. Niemand heeft ooit gevraagd waarom.

[Refthoom]

Zoiets wilde ik doen inderdaad maar Stedin heeft de 'klantenservice' goed dichtgetimmerd. Sowieso een week gewacht op de code per snail mail voordat mijn account geldig was, maar er zijn alleen voorgebakken opties om te kiezen. Bijvoorbeeld een slimme meter aanvragen, maar dat werkt niet want ik heb al een slimme meter. In het nieuwe jaar ga ik nog wel eens een poging wagen denk ik.

[janblok1162]

Refthoom schreef op donderdag 25 december 2025 @ 16:28:
Zoiets wilde ik doen inderdaad maar Stedin heeft de 'klantenservice' goed dichtgetimmerd. Sowieso een week gewacht op de code per snail mail voordat mijn account geldig was, maar er zijn alleen voorgebakken opties om te kiezen. Bijvoorbeeld een slimme meter aanvragen, maar dat werkt niet want ik heb al een slimme meter. In het nieuwe jaar ga ik nog wel eens een poging wagen denk ik.

Ik heb begin vorig jaar een nieuwe meter aangevraagd. Had een verzoek ingediend omdat ik graag dsmr 5 wilde en gelezen had dat de meter die wij hadden in de komende 10 jaar vervangen zou worden omdat er een grps module inzit. Proberen kan altijd was de gedachtegang. Onze oude meter was van 2014 dacht ik.

Heb een nieuwe elektrameter en gasmeter gekregen, ze deden bij mij helemaal niet moeilijk en heb me geen cent gekost. Had dit van te voren ook nog wel heel duidelijk gevraagd, want had weinig zin in een rekening van paar honderd euro.

[Refthoom]

janblok1162 schreef op donderdag 25 december 2025 @ 21:23:
[...]


Ik heb begin vorig jaar een nieuwe meter aangevraagd. Had een verzoek ingediend omdat ik graag dsmr 5 wilde en gelezen had dat de meter die wij hadden in de komende 10 jaar vervangen zou worden omdat er een grps module inzit. Proberen kan altijd was de gedachtegang. Onze oude meter was van 2014 dacht ik.

Heb een nieuwe elektrameter en gasmeter gekregen, ze deden bij mij helemaal niet moeilijk en heb me geen cent gekost. Had dit van te voren ook nog wel heel duidelijk gevraagd, want had weinig zin in een rekening van paar honderd euro.

Dankjewel, dat is goed om te lezen. Hoe ben je met ze in contact gekomen? Want ik zie geen contactformulier of telefoonnummer op de Site van Stedin.

[janblok1162]

Refthoom schreef op donderdag 25 december 2025 @ 21:27:
[...]

Dankjewel, dat is goed om te lezen. Hoe ben je met ze in contact gekomen? Want ik zie geen contactformulier of telefoonnummer op de Site van Stedin.

Meen me te herinneren dat ik via klantenportaal aanvraag voor slimme meter heb gedaan. daarna heb ik een belletje gegeven denk ik om er zeker van te zijn dat ik niks hoefde te betalen.

Tel: [phone] (zorg wel dat je de tijd hebt, wachtrij kan best lang duren)

Het ging bij mij dus wel om een meter die in de komende 10 jaar vervangen zou moeten worden vanwege technische levensduur.
Proberen kan altijd i.i.g., nee heb je, ja kun je krijgen. Succes!

[Stefannn]

janblok1162 schreef op vrijdag 26 december 2025 @ 00:02:
[...]


Meen me te herinneren dat ik via klantenportaal aanvraag voor slimme meter heb gedaan. daarna heb ik een belletje gegeven denk ik om er zeker van te zijn dat ik niks hoefde te betalen.

Tel: [phone] (zorg wel dat je de tijd hebt, wachtrij kan best lang duren)

Het ging bij mij dus wel om een meter die in de komende 10 jaar vervangen zou moeten worden vanwege technische levensduur.
Proberen kan altijd i.i.g., nee heb je, ja kun je krijgen. Succes!

Bij enexis kost vervangen op eigen verzoek t.b.v. hogere dsmr 212 euro.
Mijn meter moet sowieso de komende paar jaar vervangen vanwege gprs. Ik heb vorig jaar gebeld of ze dat niet gratis eerder konden doen maar dat deden ze niet.
Misschien inmiddels wel, proberen kan altijd.
Hier anderen die het niet lukt bij enexis.

[ Voor 6% gewijzigd door Stefannn op 26-12-2025 07:46 ]

[dingo35]

Refthoom schreef op donderdag 25 december 2025 @ 15:29:
[...]

Hebben de Sensorbox V2 en SmartEVSE met de nieuwste firmware versies nog steeds DSMR5 met iedere seconde een telegram als een vereiste?

Als ik het goed begrijp kwamen we namelijk zover in dit draadje omdat de SmartEVSE per seconde een telegram wil hebben zoals DSMR5 levert. De extra spullen (rpi etc) zorgen ervoor dat de lagere frequentie van telegrammen van lagere DSMR versies verhoogd wordt door berichten iedere seconde te herhalen.

Het is iedereen denk ik wel duidelijk dat de slimme meter zelf geen wifi o.i.d. heeft en er dus altijd iets tussen moet wat de telegrammen van de P1 leest.

Als de sensorbox via wifi de telegrammen naar de SmartEVSE kan sturen is dat natuurlijk prachtig. Er zal wel eerst via modbus (eenmalig?) verbinding moeten zijn om de wifi te enablen en of de firmware te upgraden, toch?

Als iedereen nu maar steeds blijft herhalen dat de SmartEVSE elke seconde data nodig heeft, dan gaan talloze oppervlakkige lezers dat geloven én weer herhalen.
Ik heb het nog geen drie dagen geleden gepost dingo35 in "Zelfbouw Laadpaal ervaringen" , maar nu nóg maar weer een keer:

De SmartEVSE update via modbus ongeveer 1x per 2 seconden. Dus als je data via de API toevoert moet je dat niet vaker doen dan 1x per 2 seconden, maar uiterlijk elke 10 seconden, anders krijg je een timeout.

Natuurlijk werkt de Sensorbox van Stegen met (zover nu bekend) elke gangbare DSMR meter in NL; die geven typisch elke 5-10 seconden een waarde af.

Het feit dat posters hier dan tóch timeouts krijgen heeft alles te maken met de latency van de zelf geknutselde "oplossing". HomeAssistant is python gedreven, en dat is, zeker op een RPI, niet de snelste oplossing. Een sensorbox, met een PIC chip die elke zoveel ms de P1 bus staat af te luisteren, en het telegram dan aan een dedicated ESP32 doorgeeft die het dan, via wired modbus of via wifi doorgeeft, is gewoon veel sneller en veel betrouwbaarder.

Ik heb zelf al tijden geen sensorbox besteld, maar volgens mij wordt deze nu met de nieuwste firmware uitgeleverd en is dan direct via wifi bereikbaar. Ik dacht dat ook daar de ESPtouch app overbodig gemaakt is en dat via een tijdelijk AP je wifi password ingegeven kan worden.

[ Voor 6% gewijzigd door dingo35 op 26-12-2025 12:07 ]

[dingo35]

Merk op dat HomeAssistant voor de meeste sensoren "poll" gedreven is, en dat de poll interval vaak 1 minuut is. Dat betekent dat het gemiddeld al 30 seconden duurt voor HA überhaupt door heeft dat er nieuwe data klaar staat.
Het interval kun je korter configureren maar ik zie vaak dat dit vergeten wordt, en dat bij zware HA configuraties dit een te zware belasting voor de RPI wordt.

HA is ontworpen voor domotica toepassingen, niet voor realtime signaal verwerking.

[ocaj]

Dank voor de mooie toelichting dingo35.
Op dit moment stuur ik de data (vanuit eigen script, geen HomeAssitant) via MQTT naar de SmartEVSE. Dat is wel weer een extra schakel (MQTT-broker) in de keten t.o.v. direct via de HTTP-REST API.

Wat is zwaarder voor de SmartEVSE? Mains-API-data via MQTT doorsturen of via HTTP/REST? Of zit daar geen significant verschil in?

[ben144]

ocaj schreef op vrijdag 26 december 2025 @ 12:51:
.....
Wat is zwaarder voor de SmartEVSE? Mains-API-data via MQTT doorsturen of via HTTP/REST? ...

Via MQTT werkt heel stabiel.
Zelf al ondervonden dat als ik met eigen scripts de REST-api teveel ging belasten het na een tijd (lees 1 tot anderhalve dag) smartevse raar begon te doen (reboot loste het dan op).

[dingo35]

MQTT is beduidend lichter, en is ook veel geschikter voor near-realtime toepassingen.

In volgorde van aflopende preferentie:
-modbus - realtime met gedefinieerde response/timeout tijden
-mqtt - bovenop IP dus geen gedefinieerde latency e.d., maar nog steeds geschikt voor near realtime toepassingen (10-100ms)
-http(s) - totaal niets gedefinieerd / gegarandeerd, maar werkt desalniettemin in licht belaste omgevingen

[Refthoom]

dingo35 schreef op vrijdag 26 december 2025 @ 12:02:
[...]
<knip>
Natuurlijk werkt de Sensorbox van Stegen met (zover nu bekend) elke gangbare DSMR meter in NL; die geven typisch elke 5-10 seconden een waarde af.
<knip>

De gedrukte handleiding (de mijne is van 2022) die bij de sensorbox zit zegt dat hij alleen met DSMR5 werkt. Denk dat veel mensen daar nog van uitgaan. Daar komt ook dat 1x per seconde vandaan wat een verschil is met DSMR4 met 1x per 10 seconden.

[ Voor 34% gewijzigd door Refthoom op 26-12-2025 14:14 ]

[ocaj]

dingo35 schreef op vrijdag 26 december 2025 @ 14:07:
MQTT is beduidend lichter, en is ook veel geschikter voor near-realtime toepassingen.

In volgorde van aflopende preferentie:
-modbus - realtime met gedefinieerde response/timeout tijden
-mqtt - bovenop IP dus geen gedefinieerde latency e.d., maar nog steeds geschikt voor near realtime toepassingen (10-100ms)
-http(s) - totaal niets gedefinieerd / gegarandeerd, maar werkt desalniettemin in licht belaste omgevingen

Goed om te weten, dan houdt ik het lekker bij MQTT.
Iets minder direct, maar inderdaad wel lekker licht en snel.

[dingo35]

Omdat je in de toekomst waarschijnlijk op meer plekken je P1 data nodig hebt (SmartEVSE laadpaal, Deye hybride accusysteem/inverter, warmtepomp, energie management systeem) is MQTT vooralsnog de beste manier van "splitten" (verdelen naar meerdere devices) van je data.

Daarbij zal het van belang worden dat je MQTT broker topics/subtopics en
misschien zelfs topic values kan vertalen naar de behoeftes van de diverse devices. Helaas blinkt het veelgebruikte Mosquitto daar (nog) niet in uit....

[Refthoom]

dingo35 schreef op vrijdag 26 december 2025 @ 14:12:
Omdat je in de toekomst waarschijnlijk op meer plekken je P1 data nodig hebt (SmartEVSE laadpaal, Deye hybride accusysteem/inverter, warmtepomp, energie management systeem) is MQTT vooralsnog de beste manier van "splitten" (verdelen naar meerdere devices) van je data.

Daarbij zal het van belang worden dat je MQTT broker topics/subtopics en
misschien zelfs topic values kan vertalen naar de behoeftes van de diverse devices. Helaas blinkt het veelgebruikte Mosquitto daar (nog) niet in uit....

NodeRed is een mooie aanvulling op MQTT voor dat soort vertaling.

[dingo35]

Refthoom schreef op vrijdag 26 december 2025 @ 14:08:
[...]

De gedrukte handleiding (de mijne is van 2022) die bij de sensorbox zit zegt dat hij alleen met DSMR5 werkt.

Ok dat is nieuw voor mij, ik meen in de code ook dsmr4 code gezien te hebben, maar dat is alweer een jaar of wat geleden.

Overigens zijn er door de open structuur van de SmartEVSE nog veel meer oplossingsrichtingen:
-modbus kWh meter in de mterkast erbij, zie handleiding voor de ondersteunde merken, Eastron SDM72DMv2 is populair
-sensorbox
-slimme lezer (zie repo)
-HomeWizard wordt native ondersteund (details zie handleiding)

Welke hiervan DSMR4 of zelfs 2.2 ondersteunen moet iemand even uitzoeken, maar ik had al die jaren nog niet gehoord van SmartEVSE gebruikers die hun DSMR4 meter lieten upgraden naar v5 om de SmartEVSE te kunnen voeden; het klinkt eem beetje als met een kanon op een mug schieten...

[dingo35]

Refthoom schreef op vrijdag 26 december 2025 @ 14:17:
[...]

NodeRed is een mooie aanvulling op MQTT voor dat soort vertaling.

Idd, ik zoek alleen nog een alternatief dat niet op dat enorm logge node.js gebaseerd is...

[tukker999]

dingo35 schreef op vrijdag 26 december 2025 @ 14:07:
MQTT is beduidend lichter, en is ook veel geschikter voor near-realtime toepassingen.

In volgorde van aflopende preferentie:
-modbus - realtime met gedefinieerde response/timeout tijden
-mqtt - bovenop IP dus geen gedefinieerde latency e.d., maar nog steeds geschikt voor near realtime toepassingen (10-100ms)
-http(s) - totaal niets gedefinieerd / gegarandeerd, maar werkt desalniettemin in licht belaste omgevingen

MQTT is supersimpel en failsafe.

code:

        if currentLevel == 'Off' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 0')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Off')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/ColorOff" -m 0,250,0')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '6A'  then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 60')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '8A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 80')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '10A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 100')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '13A' then
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 130')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        elseif currentLevel == '16A' then
            domoticz.executeShellCommand('mosquitto_pub  -h 192.168.2.110 -t "SmartEVSE/Set/Mode" -m Normal')
            domoticz.executeShellCommand('mosquitto_pub  -h 192.168.2.110 -t "SmartEVSE/Set/CurrentOverride" -m 160')
            domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)
        end

        -- domoticz.log('Charging set to : ' .. currentLevel, domoticz.LOG_DEBUG)

P1 meter, SmartEVSE en draaien maar.

[Hermarcel]

tukker999 schreef op vrijdag 26 december 2025 @ 22:31:
[...]

MQTT is supersimpel en failsafe.

Helemaal mee eens. Hier vanuit ESPhome (stukje C-code):

YAML:

###############################################################################################
# Send GridMeter and EVMeter data to SmartEVSE-xxxx
###############################################################################################
  - platform: template
    name: "Send data to SmartEVSE-xxxx"
    internal: true
    update_interval: 5.0s
    lambda: |-
      // See: https://github.com/dingo35/SmartEVSE-3.5/blob/master/docs/configuration.md#mqtt-api
      char buf[100];

      snprintf(buf, sizeof(buf), "%.0f:%.0f:%.0f",            // MainsMeter
            (10 * id(MgridWattsL1).state / id(MgridVoltsL1).state),   // deci-Amps (Active only)
            (10 * id(MgridWattsL2).state / id(MgridVoltsL2).state),
            (10 * id(MgridWattsL3).state / id(MgridVoltsL3).state));
      id(mqttClient).publish("SmartEVSE-xxxx/Set/MainsMeter", buf);

      snprintf(buf, sizeof(buf), "%.0f:%.0f:%.0f:%.0f:%.0f",  // EvMeter
            (10 * id(EvAmpsL1).state),     // deci-Amps only (Active only)
            (10 * id(EvAmpsL2).state),
            (10 * id(EvAmpsL3).state),
            (id(EvWatts).state),
            (id(EvWatthours).state));
      id(mqttClient).publish("SmartEVSE-xxxx/Set/EVMeter", buf);
      }
      return(0);

Draait bij mij op een mainboard (L1) met twee addon-boards (L2+L3) voor een totaal van zes 3-fasen meters.