Zelfbouw Laadpaal ervaringen

[ruud76]

dingo35 schreef op woensdag 6 mei 2026 @ 14:49:
Page refresh?

Dan krijg ik opnieuw deze 3 schermen 😀

Update: lijkt niet te gebeuren op mijn desktop, alleen op mijn iPhone. Onder de stable versie (3.8.5) werkte het prima op de iPhone.

[ Voor 29% gewijzigd door ruud76 op 06-05-2026 21:02 ]

[Jorn]

Toch hier even advies vragen, ik heb afgelopen weekend een EVBOX omgebouwd naar 1fase smartEVSE met MID meter. Deze leek goed te werken, alleen wanneer ik het laden start(met RFID) dan stopt hij vrij snel(na 1 tot 1,5kWh met laden en gaat dan ook niet weer verder. De auto is dan (nog lang)niet vol, wanneer ik het laden dan opnieuw start laad hij wel door tot vol. De auto is een VW Passat GTE.

Ik laad nu in normal mode met 10 Ampere, er zit geen mains meter aangesloten, alleen een EV meter.

Ik heb zojuist de laatste versie geflashed incl. debug, maar ik zie er zo niets in, heeft iemand misschien een idee of hier ook ervaring mee? Bijgevoed een stuk uit de debug log waar hij stopt met het laden, eventueel heb ik uiteraard een uitgebreidere log.

code:

[0m[1;33m(I) (loop)(C1) STATE: C Error: 0 StartCurrent: -4 ChargeDelay: 0 SolarStopTimer: 0 NoCurrent: 0 Imeasured: 0.0 A IsetBalanced: 10.0 A, MainsMeter.Timeout=11, EVMete[0mr.Timeout=62.
[0m[1;33m(I) (loop)(C1) L1: 0.0 A L2: 0.0 A L3: 0.0 A Isum: 0.0 A
[0m[1;32m(D) (CalcBalancedCurrent)(C1) Normal mode is always 3-phase
[0m[1;32m(D) (CalcBalancedCurrent)(C1) Checkpoint b: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=10.0A, ActiveEVSE=1.
[0m[1;33m(I) (loop)(C1) STATE: C Error: 0 StartCurrent: -4 ChargeDelay: 0 SolarStopTimer: 0 NoCurrent: 0 Imeasured: 0.0 A IsetBalanced: 10.0 A, MainsMeter.Timeout=11, EVMete[0mr.Timeout=63.
[0m[1;33m(I) (loop)(C1) L1: 0.0 A L2: 0.0 A L3: 0.0 A Isum: 0.0 A
[0m(setState)(C0) 20:45:36 STATE C -> B
[0m(CheckSwitchingPhases)(C0) No need to switch to 1P !
[0m[1;32m(D) (CheckSwitchingPhases)(C0) NrPhasesCharging:1
[0m(setState)(C0) @MSG: Switching Contactor1 OFF.
[0m(setState)(C0) @MSG: Switching Contactor2 OFF.
[0m(Timer10ms_singlerun)(C0) Diode OK
[0m[1;32m(D) (ModbusRequestLoop)(C1) ModbusRequest 4: Request Energy Node 0
[0m[1;32m(D) (ModbusRequestLoop)(C1) ModbusRequest 20: Request EVMeter Current Measurement Node 0
[0m [1;32m(D) (ModbusRequestLoop)(C1) ModbusRequest 20: Request EVMeter Current Measurement Node 0
[0m[1;32m(D) (CalcBalancedCurrent)(C1) Normal mode is always 3-phase
[0m[1;32m(D) (CalcBalancedCurrent)(C1) Checkpoint c: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=10.0A, saveActiveEVSE=0.
[0m[1;33m(I) (loop)(C1) STATE: B Error: 0 StartCurrent: -4 ChargeDelay: 0 SolarStopTimer: 0 NoCurrent: 0 Imeasured: 0.0 A IsetBalanced: 10.0 A, MainsMeter.Timeout=11, EVMete[0mr.Timeout=64.
[0m[1;33m(I) (loop)(C1) L1: 0.0 A L2: 0.0 A L3: 0.0 A Isum: 0.0 A

[Robert-Jan]

ruud76 schreef op woensdag 6 mei 2026 @ 14:47:
[...]
Ik heb hem er zojuist op gezet (ik heb een EtherLCD hier liggen dus ik bouw ‘m binnenkort om), maar ik krijg nu foutmeldingen op het LCD scherm via de webbrowser. Op dit moment draai ik dus een SmartEVSE *zonder* EtherLCD.

Dit probleem probeer ik te reproduceren. Ik heb zowel HTTP als HTTPS getest en ik ervaar geen verbindingsproblemen. Ik gebruik iOS 26.4.2.

Welke iOS versie? In de mobile Safari browser? Misschien extensions zoals een add-blocker actief? of een VPN of andere niet standaard instellingen?

[zonnepaneelxl]

Ik ben op zoek naar soort van cp emulator / elektronica.

Wie kan mij hier bij helpen?

Ik wil namelijk met een standaard laadpaal 3 fase en mobiel accupakket op een asnhangwagen kunnen laden.

Aan deze mobiele accu zit een laad socket net zoals op een auto echter is er geen cp communicatie aanwezig op dit moment en gaat de laadpaal niet laden.

Is dit eenvoudig te maken?

[Wolly]

zonnepaneelxl schreef op donderdag 7 mei 2026 @ 12:11:
Ik ben op zoek naar soort van cp emulator / elektronica.

Wie kan mij hier bij helpen?

Ik wil namelijk met een standaard laadpaal 3 fase en mobiel accupakket op een asnhangwagen kunnen laden.

Aan deze mobiele accu zit een laad socket net zoals op een auto echter is er geen cp communicatie aanwezig op dit moment en gaat de laadpaal niet laden.

Is dit eenvoudig te maken?

Wolly schreef op vrijdag 28 maart 2025 @ 13:45:
Dat kan gewoon. Je kan het ook zelf maken met 3 weerstandjes, een diode en de stekker.

[mukky]

Ik heb eind 2023 een setup gebouwd met 4 SmartEVSE's (v3) die konden load balancen tussen elkaar en ook rekening hielden met het verbruik van het pand. Dat werkte in eerste instantie niet naar behoren en toen heeft @stegen een speciale firmwareversie gemaakt (3.0.1m) die voldoet.

Ik ben binnenkort weer op die locatie, kan ik deze installatie zonder problemen bijwerken naar de laatste vesie van SmartEVSE (oftwel hebben anderen een soortgelijke setup op een nieuwere firmware)?

[Martijn02]

Ik heb een vraag. Ik heb via Amazon een Eastron SDM54-M besteld, deze is zojuist geleverd. Bij het open maken van de verpakking bleek het een Eastron SDM54-2T zijn. Het is me niet helemaal duidelijk of deze nou wel of niet MID certified is. Hoe kan ik dat controleren? (voordat ik hem onnodig terugstuur)

[Driehoek]

Vind niet meteen iets met de search. Sinds gisteren springt de smartevse regelmatig automatisch van Solar naar smart. Iemand enig idee hoe dit zou komen? Via google vond ik een linkje dat de lader automatisch naar smart gaat als er teveel stroom geïnjecteerd wordt? Zou dan verwachten dat die erna weer terug gaat.

Het enige wat er recent veranderd is, zijn extra zonnepanelen op het dak. Maar geen idee of het gerelateerd is.

[ben144]

Martijn02 schreef op vrijdag 8 mei 2026 @ 17:10:
Ik heb een vraag. Ik heb via Amazon een Eastron SDM54-M besteld, deze is zojuist geleverd. Bij het open maken van de verpakking bleek het een Eastron SDM54-2T zijn. Het is me niet helemaal duidelijk of deze nou wel of niet MID certified is. Hoe kan ik dat controleren? (voordat ik hem onnodig terugstuur)


[Afbeelding]

MID https://xn--stromzhler-v5a.eu/media/b1/17/cb/1696582677/mid_sdm54.pdf?ts=1702977891

De 2T is gewoon de versie met 2 tarieven, dag/nacht

[ruud76]

Robert-Jan schreef op donderdag 7 mei 2026 @ 10:18:
[...]

Dit probleem probeer ik te reproduceren. Ik heb zowel HTTP als HTTPS getest en ik ervaar geen verbindingsproblemen. Ik gebruik iOS 26.4.2.

Welke iOS versie? In de mobile Safari browser? Misschien extensions zoals een add-blocker actief? of een VPN of andere niet standaard instellingen?

Ik denk dat in het gereproduceerd heb: als ik connect naar het ip adres van de SmartEVSE dan werkt het display niet, als ik connect naar de mdns naam dan werkt het wel.

Ik gebruik iOS 26.3.1 (23D8133) met de mobiele Safari browser. Ik heb een adblocker actief maar als ik materiaalblokkeringen uit zet dan krijg ik geen ander resultaat. Mijn iPhone zit gewoon op het wifi netwerk waar de smartEVSE ook op zit, geen VPN.

Update 9/5 - ik heb mijn iOS bijgewerkt naar de versie die jij ook gebruikt (26.4.2). Dat lijkt het tot mijn verbazing op te lossen. Ook als ik naar het IP adres verbind werkt het nu (en net voor de update nog niet)

[ Voor 18% gewijzigd door ruud76 op 09-05-2026 19:33 ]

[Bontje Blauw]

Kan ik deze "locking actuator" op de Smart EVSE aansluiten?
lijkt mij Vcc + GND + signal (blue), correct?
Het is een New Motion Lolo type 2 donor paal

[Frankyy]

Bontje Blauw schreef op zaterdag 9 mei 2026 @ 20:12:
Kan ik deze "locking actuator" op de Smart EVSE aansluiten?
lijkt mij Vcc + GND + signal (blue), correct?
Het is een New Motion Lolo type 2 donor paal

[Afbeelding]

Uit documentatie (en ik heb de zelfde lock):

The Ratio lock has 3 wires, connect them as follows:

B: Blue R: Black W: Red

Set the Lock option in the menu to SOLENOID

[m.eddy]

Miste de laadsessie van gisteren en vandaag in de E-Flux online omgeving. Chatbot gaf aan de laadpaal te herstarten. Laadpaal stond gewoon connected bij E-Flux. Toch maar herstart en prompt kwam de sessie van gisteren en vandaag binnen. Had geen debug meelopen dus weet niet wat er precies allemaal gebeurde, maar puik dat dit werkt. 😃👍

[superyupkent]

Goedemiddag,

Heb een klein maandje naast Tap Electric als primaire backend ook de lokale Joulo ocpp-proxy draaien en daarbij de Joulo ERE koppeling.

Het viel me op dat er een paar keer per dag drops zijn van de verbinding. De heren bij Joulo hebben mij. Logs gematched aan hun eigen onderhoud en komen op een redelijk groot aantal disconnects die ze aan mijn kant toeschrijven. De volgende suggesties zijn gedaan om aanpassingen te doen in de firmware. Omdat deze suggesties niet direct mogelijk zijn in de settings vermoed ik dat je dan zelf een versie moet builden.

Kan @dingo35 dat bevestigen?

Info Joulo: "Dit zijn de twee oorzaken die we kunnen aanwijzen aan jouw zijde:

1. HeartbeatInterval verlagen in de SmartEVSE-config (bv. 60s). Door regelmatig OCPP-verkeer blijft de WS-socket warm en sluiten routers/ISP'en hem niet idle af, een meer gangbare standaard is echter 300s maar je zou hier eens mee kunnen "spelen", lager moet je ook niet doen dat levert weer veel belasting op.


2. WiFi power-save uitzetten in de SmartEVSE-firmware (voor ESP32 een bekend issue: korte WiFi-haperingen die je niet ziet, maar de TCP-sessie wel afkappen). In SmartEVSE-firmware staat dat onder de WiFi-instellingen.


Hoe dan ook, er is geen sessieverlies, al je laadsessies komen netjes door, ook na een reconnect. Maar als je de drops weg wilt hebben zijn dit mogelijke oorzaken."

[dingo35]

Ja daarvoor moet je zelf compileren. Nu ben ik geen netwerkspecialist, maar opmerking 1, verlagen van de heartbeat interval, leidt tot sluiten van de verbindingen (en dus het verhogen van de "drops").

Het nut van het constant openhouden van deze verbinding ontgaat mij, "if it aint broke dont fix it", maar het leuke van open source is dat je je eigen gang kan gaan...

[diamanten]

Een vraag (of is het een bugje) over de Solarmode na een week de SmartEVSE in gebruik (mooie oplossing!):

Het automatisch terugschakelen van 3P-> 1P ging goed in de solarmode. Nadat de bewolking weg was en er weer genoeg zonne energie was, duurde het automatisch terugschakelen mij iets te lang (zag geen teller lopen?!) en heb ik zelf maar het laden gepauzeerd voor 30 seconden en toen weer aangezet in de solarmode. Volgens het scherm werd er weer op 'SOLAR 3P' geladen maar volgens de data niet: laadvermogen 2.8 kW dus het laden werd met 1P en niet met 3P gedaan.

Wat is de reden van deze inconsistentie?

Nb. Ook nog even de HA-log bijgevoegd van het aantal fasen en van het laadvermogen: vanaf 16.30 zou er geladen zijn met 3P, dat klopt niet, want toen was er onvoldoende zonne energie. Ik zie trouwens nu ook dat er vandaag daadwerkelijk maar een korte periode 3P is geladen: tussen 13.30 en 14.30. Dus dat klopt ook niet met de info van 'NrOfPhases'.

[ Voor 38% gewijzigd door diamanten op 11-05-2026 13:38 ]

[adjego]

superyupkent schreef op zondag 10 mei 2026 @ 15:58:
Goedemiddag,

Heb een klein maandje naast Tap Electric als primaire backend ook de lokale Joulo ocpp-proxy draaien en daarbij de Joulo ERE koppeling.

Het viel me op dat er een paar keer per dag drops zijn van de verbinding. De heren bij Joulo hebben mij. Logs gematched aan hun eigen onderhoud en komen op een redelijk groot aantal disconnects die ze aan mijn kant toeschrijven. De volgende suggesties zijn gedaan om aanpassingen te doen in de firmware. Omdat deze suggesties niet direct mogelijk zijn in de settings vermoed ik dat je dan zelf een versie moet builden.

Kan @dingo35 dat bevestigen?

Info Joulo: "Dit zijn de twee oorzaken die we kunnen aanwijzen aan jouw zijde:

1. HeartbeatInterval verlagen in de SmartEVSE-config (bv. 60s). Door regelmatig OCPP-verkeer blijft de WS-socket warm en sluiten routers/ISP'en hem niet idle af, een meer gangbare standaard is echter 300s maar je zou hier eens mee kunnen "spelen", lager moet je ook niet doen dat levert weer veel belasting op.


2. WiFi power-save uitzetten in de SmartEVSE-firmware (voor ESP32 een bekend issue: korte WiFi-haperingen die je niet ziet, maar de TCP-sessie wel afkappen). In SmartEVSE-firmware staat dat onder de WiFi-instellingen.


Hoe dan ook, er is geen sessieverlies, al je laadsessies komen netjes door, ook na een reconnect. Maar als je de drops weg wilt hebben zijn dit mogelijke oorzaken."

Ik heb nu juist met hun proxy er tussen problemen maar rechtstreeks naar TapElectic ervaar ik geen problemen. Dus dan lijkt het me niet te liggen aan de SmartEVSE

[Bontje Blauw]

Het zou in theorie net passen in de breedte.
Kabels kunnen nog achterlangs doorgevoerd worden.
Smart EVSE ga ik via LAN aansluiten.

Is het bezwaarlijk alles strak tegen elkaar te plaatsen?
Op deze manier heb ik wat meer ruimte onder en boven de apparaten.

[superyupkent]

adjego schreef op zondag 10 mei 2026 @ 20:50:
[...]

Ik heb nu juist met hun proxy er tussen problemen maar rechtstreeks naar TapElectic ervaar ik geen problemen. Dus dan lijkt het me niet te liggen aan de SmartEVSE

Op zich werkt alles, de verbinding naar TAP blijft altijd intact. En alle sessies worden realtime inzichtelijk, zowel tap als Joulo. Enige is dus de 1006 disconnects. Vooral cosmetisch dus.

[riberts]

Ik had eerst geen backend in gebruik. maar toch wil ik graag OCPP connecten met Joulo voor de ere certificaten.
Er waren veel problemen bij mij met connecten.

dit was trouwens specifiek met joulo. Tap werkte prima.

Na veel chatten met github copilot blijkt het een "bug" in mongoose te zijn.
het verplaatsen van 1 regel code blijkt de verbindingsproblemen op te lossen.

Mocht iemand geïnteresseerd zijn in de change, dan zal ik dit even op mijn github zetten.
@dingo35 ik verwacht dat veranderingen in de mongoose library liever niet in jou repo worden gezet?

[dingo35]

Nee beter naar mongoose -> upstream, daar ligt blijkbaar de oorzaak.

[riberts]

dingo35 schreef op maandag 11 mei 2026 @ 08:53:
Nee beter naar mongoose -> upstream, daar ligt blijkbaar de oorzaak.

ik had al een vraag gesteld op hun github pagina, maar die werd direct gesloten met: als je geen betalende klant bent, moet je eerst updaten naar de nieuwste versie...

[Frums]

Bontje Blauw schreef op zondag 10 mei 2026 @ 22:50:

[Afbeelding]

Wellicht een domme vraag, maar waar wordt het kleine relais aan de linker zijde voor gebruikt?

[Wolly]

Frums schreef op maandag 11 mei 2026 @ 09:01:
[...]

Wellicht een domme vraag, maar waar wordt het kleine relais aan de linker zijde voor gebruikt?

Om te kunnen laden met 1 fase in het geval er weinig opwek van de zonnepanelen is.

[Frums]

Ok, maar wat is daar dan het voordeel van?

[dingo35]

@riberts Ik heb mongoose even van 7.17 naar 7.21 geupdated, je kunt een test versie hier vinden:

https://github.com/dingo35/SmartEVSE-3.5/discussions/376

Lost dat het probleem op?

[ Voor 5% gewijzigd door dingo35 op 11-05-2026 09:12 ]

[Martijn02]

Frums schreef op maandag 11 mei 2026 @ 09:07:
Ok, maar wat is daar dan het voordeel van?

Zonder de kleine relais kan je in de meeste gevallen de laadstroom van de auto varieren tussen 6 en 16A. (sommige palen/auto's kunnen meer, maar dit komt volgens mij het meest voor) Met 3-fase komt dat neer op 4140W - 11040W. Met die 2e relais kan je 2 van de 3 fases uitzetten, waardoor de auto op 1 fase gaat laden en dan kan je het vermogen ook regelen tussen 1380W - 3680W. Die laatste range sluit vaak beter aan bij de opbrengst van je zonnepanelen, waardoor het mogelijk is om de auto te laden met 100% zelf opgewekte zonnestroom die vaak (zeker vanaf volgend jaar) zo goed als gratis is.

[THM0]

Frums schreef op maandag 11 mei 2026 @ 09:07:
Ok, maar wat is daar dan het voordeel van?

Dat je een lager minimum laadvermogen hebt (6Ax230V ipv 3*6A*230V)

[benthouse]

Ik heb sinds 2 weken een ETH-Display op de EVSE van Stegen, draai met versie 3.10.3. Sinds paar dagen veel uitval van de bekabelde verbinding; enige manier om weer leven te krijgen in de connectie is de EVSE spanningsloos maken en weer opnieuw opstarten waarna hij weer normaal werkt en er ook toegang is tot de interne webserver van de EVSE. Meer mensen met dit issue?

[Stufipower]

benthouse schreef op maandag 11 mei 2026 @ 10:43:
Ik heb sinds 2 weken een ETH-Display op de EVSE van Stegen, draai met versie 3.10.3. Sinds paar dagen veel uitval van de bekabelde verbinding; enige manier om weer leven te krijgen in de connectie is de EVSE spanningsloos maken en weer opnieuw opstarten waarna hij weer normaal werkt en er ook toegang is tot de interne webserver van de EVSE. Meer mensen met dit issue?

Verstuur je daarbij veel netwerkverkeer naar de smartevse? (Bijv mainsmeter, ocpp, evcc polling)

[jpiscaer]

Frums schreef op maandag 11 mei 2026 @ 09:07:
Ok, maar wat is daar dan het voordeel van?

Zoals al benoemd door anderen in antwoord op je vraag: om eerder met zonneladen te kunnen beginnen (6A is het minimum, 6A op 1 fase is minder dan 6A op 3 fases). Ik had moeite dat helemaal te begrijpen, dus nog wat extra uitleg: de elektriciteitsmeter van de netbeheer doet een nettosom van de drie fases: er mag een onbalans tussen de fases zijn. Dat betekent dat de lader op 1 fase stroom gebruikt, en de zonnepalenen op de andere twee fases stroom terugleveren.

[benthouse]

Stufipower schreef op maandag 11 mei 2026 @ 11:24:
[...]

Verstuur je daarbij veel netwerkverkeer naar de smartevse? (Bijv mainsmeter, ocpp, evcc polling)

nope, niet meer dan in de voorgaande situatie met Wifi. Geen OCPP, geen EVCC etc. Ook de MQTTS naar HA werkt niet meer zodra de ethernet eruit ligt (is ook logisch want de MQTT draait op Raspberry PI via HA.

[diamanten]

diamanten schreef op zondag 10 mei 2026 @ 19:29:
Een vraag (of is het een bugje) over de Solarmode na een week de SmartEVSE in gebruik (mooie oplossing!):

Het automatisch terugschakelen van 3P-> 1P ging goed in de solarmode. Nadat de bewolking weg was en er weer genoeg zonne energie was, duurde het automatisch terugschakelen mij iets te lang (zag geen teller lopen?!) en heb ik zelf maar het laden gepauzeerd voor 30 seconden en toen weer aangezet in de solarmode. Volgens het scherm werd er weer op 'SOLAR 3P' geladen maar volgens de data niet: laadvermogen 2.8 kW dus het laden werd met 1P en niet met 3P gedaan.

Wat is de reden van deze inconsistentie?

Nb. Ook nog even de HA-log bijgevoegd van het aantal fasen en van het laadvermogen: vanaf 16.30 zou er geladen zijn met 3P, dat klopt niet, want toen was er onvoldoende zonne energie. Ik zie trouwens nu ook dat er vandaag daadwerkelijk maar een korte periode 3P is geladen: tussen 13.30 en 14.30. Dus dat klopt ook niet met de info van 'NrOfPhases'.


[Afbeelding]

[Afbeelding]
[Afbeelding]

[Afbeelding]

Kan iemand mij met bovenstaande helpen? Ik merk nu ook dat het laden op 1P bij geen zon doorloopt na de ingestelde 10 minuten (totdat ik het zelf afbreek na 30 minuten). Het gaat om een Smart EVSE V3 - Version:v3.11.0

Tevens blijft nu de SmartEVSE hangen op het 1P->3P scherm, zonder daadwerkelijk te laden.

[ Voor 13% gewijzigd door diamanten op 11-05-2026 14:34 ]

[Frums]

jpiscaer schreef op maandag 11 mei 2026 @ 11:29:
[...]

Zoals al benoemd door anderen in antwoord op je vraag: om eerder met zonneladen te kunnen beginnen (6A is het minimum, 6A op 1 fase is minder dan 6A op 3 fases). Ik had moeite dat helemaal te begrijpen, dus nog wat extra uitleg: de elektriciteitsmeter van de netbeheer doet een nettosom van de drie fases: er mag een onbalans tussen de fases zijn. Dat betekent dat de lader op 1 fase stroom gebruikt, en de zonnepalenen op de andere twee fases stroom terugleveren.

Helder, bedankt voor de toelichting.

[Epsilon]

diamanten schreef op maandag 11 mei 2026 @ 13:43:
[...]

Kan iemand mij met bovenstaande adviseren? Ik merk nu ook dat het het laden op 1P (bij geen zon) doorloopt na de ingestelde 10 minuten. Het gaat om een Smart EVSE V3 - Version:v3.11.0

Zie je wel de tijd aftellen als er geen zon meer is? Staat je start A op "0" of hoger?

Ik post hier later meer detail over, maar met start "0" krijg ik vreemd gedrag.

Wat is je laadstroom naar je EV toe op het moment dat deze af zou moeten gaan schakelen? De werkelijke stroom bedoel ik, niet de 6A die de EVSE aan probeert te sturen .

[diamanten]

Epsilon schreef op maandag 11 mei 2026 @ 14:43:
[...]

Zie je wel de tijd aftellen als er geen zon meer is? Staat je start A op "0" of hoger?

Ik post hier later meer detail over, maar met start "0" krijg ik vreemd gedrag.

Wat is je laadstroom naar je EV toe op het moment dat deze af zou moeten gaan schakelen? De werkelijke stroom bedoel ik, niet de 6A die de EVSE aan probeert te sturen .

Nee, ik zie geen tijd aftellen. Start A staat op '0'. De werkelijke stroom was (gegevens uit HA) iets boven de 6A.

Nb. Ik heb trouwens een Kia Niro EV, ooit gelezen dat deze minimaal 7A per fase nodig heeft, maar weet niet of dit waar is (en wat het effect daarvan zou kunnen zijn, behalve dat min A op 7A zou moeten staan ipv de standaard 6A).

[ Voor 15% gewijzigd door diamanten op 11-05-2026 15:39 ]

[Epsilon]

Hmm en de EVSE stuurt "6A" naar de auto, wat resulteert in werkelijk 6.2A?

Het is in ieder geval duidelijk dat er geen voorwaarde gezien wordt om te stoppen. Ik zie hetzelfde gedrag. Naar start A op 1 zetten is nu de oplossing voorlopig.

Ik kom later terug met een een hypothese in een langere reactie .

[ Voor 36% gewijzigd door Epsilon op 11-05-2026 15:54 ]

[diamanten]

Epsilon schreef op maandag 11 mei 2026 @ 15:53:
Hmm en de EVSE stuurt "6A" naar de auto, wat resulteert in werkelijk 6.2A?

Het is in ieder geval duidelijk dat er geen voorwaarde gezien wordt om te stoppen. Ik zie hetzelfde gedrag. Naar start A op 1 zetten is nu de oplossing voorlopig.

Ik kom later terug met een een hypothese in een langere reactie .

Graag! Wellicht kijk ik niet goed naar de stroom waarde, welke HA-sensor zou ik daarvoor moeten nemen? Ik heb nu deze genomen: sensor.smartevse_8870_smartevse_charge_current

[ Voor 8% gewijzigd door diamanten op 11-05-2026 16:14 ]

[jfoverdijk]

diamanten schreef op maandag 11 mei 2026 @ 16:01:
[...]

Graag! Wellicht kijk ik niet goed naar de stroom waarde, welke HA-sensor zou ik daarvoor moeten nemen? Ik heb nu deze genomen: sensor.smartevse_8870_smartevse_charge_current

De gemeten laadstromen worden met MQTT gepubliceerd als: EVCurrentL1, EVCurrentL2, EVCurrentL3

[Hmmbob]

jfoverdijk schreef op maandag 11 mei 2026 @ 16:46:
[...]

De gemeten laadstromen worden met MQTT gepubliceerd als: EVCurrentL1, EVCurrentL2, EVCurrentL3

En in Home Assistant terug te vinden als sensor.smartevse_xxxx_evcurrentl1 (en l2 en l3 natuurlijk)

[diamanten]

Hmmbob schreef op maandag 11 mei 2026 @ 17:20:
[...]

En in Home Assistant terug te vinden als sensor.smartevse_xxxx_evcurrentl1 (en l2 en l3 natuurlijk)

OK, dank. Hierbij het overzicht. L1 was dus 5.5A:

[Epsilon]

Bevestigd mijn gedrag gelukkig.

In mijn geval EVSE stuurt "6A" naar de auto, wat resulteert in werkelijkheid 5.2A wordt (nogmaals, ik kom hier op terug!).

De EVSE gaat in dat specifieke geval niet uit. Want mijn huis verbruikt is zeg "0.5A". En 5.2A + 0.5A is lager dan de 6A die de EVSE denkt te sturen.

Maw: mijn hypothese (zonder in de code gekeken te hebben) is dat de EVSE de stroom die hij stuurt pakt en de Mains total om te berekenen of er overschot is tijdens laden. Niet de werkelijke stroom. Wat in het geval dat die er is, wel zou moeten IMHO . Ja dit is een keuze, maar kan tot vreemd gedrag leiden in specifieke gevallen. In mijn geval denkt de EVSE dat er nog steeds 0.2A overschot is en gaat niet uit.

Ik zet het nog wat verder uiteen op een ander moment, want ik heb nog een issue wat dit gedrag versterkt

[ Voor 24% gewijzigd door Epsilon op 11-05-2026 18:14 ]

[Hermarcel]

Een EVSE laat aan een EV weten welke stroom er maximaal mag lopen. Hoeveel de auto daadwerkelijk gebruikt is aan de auto (tot aan die limiet dus).

Er is afgesproken om een minimum van 6A te communiceren. Maar een EV mag rustig minder afnemen.

[ Voor 25% gewijzigd door Hermarcel op 11-05-2026 19:06 ]

[diamanten]

Epsilon schreef op maandag 11 mei 2026 @ 18:11:
Bevestigd mijn gedrag gelukkig.

In mijn geval EVSE stuurt "6A" naar de auto, wat resulteert in werkelijkheid 5.2A wordt (nogmaals, ik kom hier op terug!).

De EVSE gaat in dat specifieke geval niet uit. Want mijn huis verbruikt is zeg "0.5A". En 5.2A + 0.5A is lager dan de 6A die de EVSE denkt te sturen.

Maw: mijn hypothese (zonder in de code gekeken te hebben) is dat de EVSE de stroom die hij stuurt pakt en de Mains total om te berekenen of er overschot is tijdens laden. Niet de werkelijke stroom. Wat in het geval dat die er is, wel zou moeten IMHO . Ja dit is een keuze, maar kan tot vreemd gedrag leiden in specifieke gevallen. In mijn geval denkt de EVSE dat er nog steeds 0.2A overschot is en gaat niet uit.

Ik zet het nog wat verder uiteen op een ander moment, want ik heb nog een issue wat dit gedrag versterkt

Ok, interessante hypothese! Hoor graag je vervolg. Wat vinden de makers @dingo35 en @stegen hiervan? Hopelijk komt er op termijn een goede structurele oplossing, want blijkbaar hebben meer mensen een dergelijk probleem. Als korte termijn fix ga ik de start A verhogen naar > 0.

[Epsilon]

Hermarcel schreef op maandag 11 mei 2026 @ 19:05:
Een EVSE laat aan een EV weten welke stroom er maximaal mag lopen. Hoeveel de auto daadwerkelijk gebruikt is aan de auto (tot aan die limiet dus).

Er is afgesproken om een minimum van 6A te communiceren. Maar een EV mag rustig minder afnemen.

En in beide gevallen zou de werkelijke stroom gebruikt moeten worden om het overschot te berekenen. Maar mijn hypothese is dat het in het tweede geval niet gebeurt omdat er "minimaal 6A" is afgesproken.

Goed, komt vast iemand op terug als in de code is gekeken. Dit ga ik zelf ook doen als ik er aan toe kom overigens .

[Bontje Blauw]

Vandaag met intern bekabelen bezig geweest. Alle stroomkabels naar contactdoos in 4mm2. Al met al best wat adereindhulsjes gekrompen.

Elektricien heeft vandaag voor mij de 3 fasen aardlekautomaat geplaatst. Zal max. met 16A / 11kW gaan laden

Voor nu de EV nog even opladen in de buurt, binnenkort vanaf de oprit.

[dingo35]

Voor de bepaling van beschikbare stroom wordt idd uitgegaan van ChargeCurrent (ter beschikking gestelde stroom) en Mainsmeter current; simpelweg omdat niet iedereen een EVMeter heeft.

[Bontje Blauw]

Kan je op een of andere manier de locking actuator testen via een commando of via web interface?Test open and close.

En ik twijfel nog aan de Smart EVSE naar kWh meter (Eastron SMD630-modbus V2) bedrading.

Ik heb nu van kWh meter B- en A+ bedraad naar respectivelijk B en A op de Smart EVSE.

Is configureren Eastron meter verder noodzakelijk? Hij zit ingebouwd en is verder niet meer zichtbaar.

[jfoverdijk]

Bontje Blauw schreef op dinsdag 12 mei 2026 @ 11:55:
Kan je op een of andere manier de locking actuator testen via een commando of via web interface?Test open and close.

En ik twijfel nog aan de Smart EVSE naar kWh meter (Eastron SMD630-modbus V2) bedrading.

Ik heb nu van kWh meter B- en A+ bedraad naar respectivelijk B en A op de Smart EVSE.

Is configureren Eastron meter verder noodzakelijk? Hij zit ingebouwd en is verder niet meer zichtbaar.

[Afbeelding]

[Afbeelding]

[Afbeelding]

Het modbus aansluiten van de SMD630 is correct.

Je moet op de SMD630 het juiste modbus adres instellen, zodat het overeenkomt met wat je instelt in de SmartEVSE (default 12). De SMD630 staat vanaf fabriek ingesteld op 1.

[Epsilon]

dingo35 schreef op dinsdag 12 mei 2026 @ 04:51:
Voor de bepaling van beschikbare stroom wordt idd uitgegaan van ChargeCurrent (ter beschikking gestelde stroom) en Mainsmeter current; simpelweg omdat niet iedereen een EVMeter heeft.

Thanks voor de bevestiging. Deze keuze snap ik en nu ik er over nadenk is dat ook de beste optie. De regeling zorgt er dan zelf voor dat er naar MainsMeterCurrent (weet de naam niet, maar zal vast zoiets heten ) naar 0 gaat.

Het rare gedrag wat je krijgt bij 0A start is een gevolg. Start op 1A zetten lost dit op.

Ik kom er echt op terug, maar mijn verwachting is dat er ergens iets mis gaat in de regeling die dit probleem versterkt.

[dingo35]

Het is ook niet logisch om StartCurrent op 0 te zetten, een waarde tussen 6 en 1 is veel logischer: je wil immers dat er Solar geladen wordt als er teruggeleverd wordt, niet als er niets verbruikt wordt....

Maar het verklaart het "vreemde" gedrag niet, wel dat na al die jaren niemand er last van gehad heeft :-)

[Epsilon]

dingo35 schreef op dinsdag 12 mei 2026 @ 15:01:
Het is ook niet logisch om StartCurrent op 0 te zetten, een waarde tussen 6 en 1 is veel logischer: je wil immers dat er Solar geladen wordt als er teruggeleverd wordt, niet als er niets verbruikt wordt....

Maar het verklaart het "vreemde" gedrag niet, wel dat na al die jaren niemand er last van gehad heeft :-)

Nou ja, 0 betekent niet dat er niets wordt verbruikt. 0 betekent dat de opwekking en verbruik in balans is. Goed, dat hoef ik je niet uit te leggen.

Dat 0 een te kritische setting is ben ik met je eens overigens. Als de ChargeCurrent gepakt wordt is het geen "vreemd" gedrag, maar verklaarbaar, daar ben ik het ook mee eens.

Dat niemand er last van heeft gehad en nu ineens 2 man onafhankelijk van elkaar is wel toeval.

[diamanten]

dingo35 schreef op dinsdag 12 mei 2026 @ 15:01:
Het is ook niet logisch om StartCurrent op 0 te zetten, een waarde tussen 6 en 1 is veel logischer: je wil immers dat er Solar geladen wordt als er teruggeleverd wordt, niet als er niets verbruikt wordt....

Maar het verklaart het "vreemde" gedrag niet, wel dat na al die jaren niemand er last van gehad heeft :-)

Ik ben geen (goede) programmeur ( ), maar het al dan niet gebruik of aanwezigheid van een EV-meter is toch een SMART-Evse instelling? Dus: een simpele IF ... THEN ... ELSE ... constructie toevoegen in de code?

[ Voor 4% gewijzigd door diamanten op 12-05-2026 15:33 ]

[Stefannn]

diamanten schreef op dinsdag 12 mei 2026 @ 15:31:
[...]

Ik ben geen (goede) programmeur ( ), maar het al dan niet gebruik of aanwezigheid van een EV-meter is toch een SMART-Evse instelling? Dus: een simpele IF ... THEN ... ELSE ... constructie toevoegen in de code?

Dat is veel meer werk...
want het is een actieve regellus, dus die moet je heel goed met meerdere autos testen.

Daarbij gaat het je maar matig helpen.
- als de auto minder afneemt dan dat wat de smartEVSE aanbiedt dan zal de auto niet meer gaan gebruiken als je de smartEVSE meer laat aanbieden "omdat de meter dat aangeeft".
- als de auto meer afneemt dan de smartEVSE aanbiedt is het beter te wachten want dan gaat de auto terugregelen. Als de smartEVSE zou terugregelen dan krijg je twee regellussen die tegen elkaar in werken en dat is vragen om problemen (oscillaties).
- als de auto afneemt wat de smartEVSE aanbiedt dan maakt het niet uit.

[Bontje Blauw]

jfoverdijk schreef op dinsdag 12 mei 2026 @ 12:48:
[...]

Het modbus aansluiten van de SMD630 is correct.

Je moet op de SMD630 het juiste modbus adres instellen, zodat het overeenkomt met wat je instelt in de SmartEVSE (default 12). De SMD630 staat vanaf fabriek ingesteld op 1.

Hmm, 1 is geen optie op de Smart EVSE.

Dan bijvoorbeeld op de SMD630 het adres aanpassen naar 12?

[Grondgebonden]

Bontje Blauw schreef op dinsdag 12 mei 2026 @ 11:55:
Kan je op een of andere manier de locking actuator testen via een commando of via web interface?Test open and close.

Zie https://github.com/dingo35/SmartEVSE-3.5/issues/263. Het is een feature request.

[jfoverdijk]

Bontje Blauw schreef op dinsdag 12 mei 2026 @ 18:52:
[...]

Hmm, 1 is geen optie op de Smart EVSE.

Dan bijvoorbeeld op de SMD630 het adres aanpassen naar 12?

Ja, dat zal werken.

[Bontje Blauw]

Vandaag de laadpaal afgemonteerd en het laden is al gelukt op 3 fasen in "normal mode"
Ik moet alleen het "smart" en "solar" laden nog uitvogelen.

P1 meter HomeWizard ingesteld in de Smart EVSE config, maar loadbalacing werkt nog niet.
De Eastron kWh meter moet ik ook nog configureren, maar dan moet de laadpaal weer deels uit elkaar

[ Voor 55% gewijzigd door Bontje Blauw op 12-05-2026 20:56 ]

[Geim]

Dan bijvoorbeeld op de SMD630 het adres aanpassen naar 12?

Ja, 11 of hoger. Ikzelf heb hem op 112 staan. Weet ook niet waarom. Werkt prima, zelfde adres ook instellen op je smsrtEVSE.

Zie ook: https://github.com/dingo35/SmartEVSE-3.5/blob/master/docs/installation.md

[Bontje Blauw]

Ik ben door de documentatie aan het lezen, ik zag dit inderdaad voorbij komen.
Adres 1-10 op de Smart EVSE is gereserveerd voor communicatie met de "sensorbox"

Inmiddels ook Home Assistant, MQTT aan het werk via een voorbeeld yaml file op github.
Smart EVSE ziet nu live de status op alle fasen.

Nu nog de SMD630 aan de praat krijgen

[Driehoek]

Ik probeer de thuisbatterij te laten communiceren met de smartevse via Set/HomeBatteryCurrent. Ik heb een sensor die de stroom berekent en deze wordt dan via een automation die om de 5 seconden wordt getriggerd gepublisht.

Als ik uitluister zie ik de berichten ook (correct) langskomen:

code:

Message 933 received on SmartEVSE-6967/Set/HomeBatteryCurrent at 15:12:
40

(de **** is juist ingesteld)

Helaas lijkt de informatie niet gebruikt te worden:

"home_battery":{"current":0,"last_update":0}

Weet toevallig iemand wat ik verkeerd doe?

[Driehoek]

Driehoek schreef op vrijdag 8 mei 2026 @ 17:14:
Vind niet meteen iets met de search. Sinds gisteren springt de smartevse regelmatig automatisch van Solar naar smart. Iemand enig idee hoe dit zou komen? Via google vond ik een linkje dat de lader automatisch naar smart gaat als er teveel stroom geïnjecteerd wordt? Zou dan verwachten dat die erna weer terug gaat.

Het enige wat er recent veranderd is, zijn extra zonnepanelen op het dak. Maar geen idee of het gerelateerd is.

Hier even op terugkomen. Ben niet 100% zeker maar het lijkt erop dat het zat in de configuratie van de knoppen van de smartevse's. Eentje heeft een button en de andere een switch, deze waren als dusdanig ingesteld (en werkt al maanden goed) maar omdat master en slave elkaar volgen bij het wisselen van de modus sloeg deze tilt met ongevraagde wissels tussen smart en solar.

[Driehoek]

Driehoek schreef op woensdag 13 mei 2026 @ 15:12:
Ik probeer de thuisbatterij te laten communiceren met de smartevse via Set/HomeBatteryCurrent. Ik heb een sensor die de stroom berekent en deze wordt dan via een automation die om de 5 seconden wordt getriggerd gepublisht.

Als ik uitluister zie ik de berichten ook (correct) langskomen:

code:

Message 933 received on SmartEVSE-6967/Set/HomeBatteryCurrent at 15:12:
40

(de **** is juist ingesteld)

Helaas lijkt de informatie niet gebruikt te worden:

"home_battery":{"current":0,"last_update":0}

Weet toevallig iemand wat ik verkeerd doe?

Wellicht een erg domme vraag maar mag/moet je enkel naar de master smartevse publishen? Dat doe ik nu en de batterij informatie komt er in de webpagina bij te staan. Weliswaar enkel op de pagina van de master, niet op de slave. Ook in de raw data staat deze enkel bij de master en niet bij de slave. Is dit verwacht gedrag?

[Martijn02]

Driehoek schreef op woensdag 13 mei 2026 @ 15:12:
Ik probeer de thuisbatterij te laten communiceren met de smartevse via Set/HomeBatteryCurrent. Ik heb een sensor die de stroom berekent en deze wordt dan via een automation die om de 5 seconden wordt getriggerd gepublisht.

Als ik uitluister zie ik de berichten ook (correct) langskomen:

code:

Message 933 received on SmartEVSE-6967/Set/HomeBatteryCurrent at 15:12:
40

(de **** is juist ingesteld)

Helaas lijkt de informatie niet gebruikt te worden:

"home_battery":{"current":0,"last_update":0}

Weet toevallig iemand wat ik verkeerd doe?

Ik zie dat je berichten pushed naar

code:

SmartEVSE-6967/Set/HomeBatteryCurrent

Ik push mijn battery current naar:

code:

SmartEVSE/8760/Set/HomeBatteryCurrent # (dus met een slash ipv dash)

En dat werkt voor mij probleemloos. (Maar misschien heb jij een andere firmware, waar nog een dash gebruikt werd?)

[ Voor 4% gewijzigd door Martijn02 op 13-05-2026 17:36 ]

[diamanten]

Epsilon schreef op maandag 11 mei 2026 @ 15:53:
Hmm en de EVSE stuurt "6A" naar de auto, wat resulteert in werkelijk 6.2A?

Het is in ieder geval duidelijk dat er geen voorwaarde gezien wordt om te stoppen. Ik zie hetzelfde gedrag. Naar start A op 1 zetten is nu de oplossing voorlopig.

Ik kom later terug met een een hypothese in een langere reactie .

Dank voor de tip! Vandaag goed met start A op 1 kunnen testen en dat werkt nu inderdaad prima.

[Kaspers]

10us10 schreef op zaterdag 25 april 2026 @ 08:21:
Het is nogal een verhaal geworden maar daar gaan we...

Ik was begonnen met aansturen van mijn smarEvse via EVCC maar heb liever dat de Evse zelf de solar en smart mode doet. Sneller en direct contact met mijn slimmelezer.

Ik ben benieuwd naar jouw rationale waarom je dit niet (meer) overlaat aan EVCC. Je zou zeggen dat dat de 'core business' is van EVCC. Je schrijft:

Sneller en direct contact met mijn slimmelezer.

In hoeverre heb je geprobeerd om juist hier een oplossing voor te vinden? Ik moet je bekennen dat het uitlezen van DSMR via een seriele interface over tcp behoorlijk stabiel en goed werkt. Al heb je een punt dat deze (default) maar 1 keer per 30 seconde bijwerkt. Ik heb hem op 10 seconde staan.

Voor wat betreft de snelheid van LoadBalancing: met dit mergerequest is het inmiddels mogelijk geworden de loadbalancing aan SmartEVSE over te laten:



Dit maakt mijns inziens de combinatie evcc+smartevse ideaal: SmartEVSE handelt Loandbalancing af, op basis van MAINS (dus houdt rekening met PV) en eventueel een subpanel via CIRCUIT (want kan sneller acteren dan evcc). En evcc is leidend voor wat betreft het 'charging plan' obv solar forecasting en evt dynamische energieprijzen.

Ik ben erg benieuwd in hoeverre jouw opzet toch nog voordelen heeft ten opzichte van wat ik hier beschrijf.

[Stufipower]

Hoe krijgen jullie betrouwbaar de mainsmeter waardes in smartevse, zonder dat die http server overloaded raakt? Ik had met ocpp + een script dat via api elke 5 seconden L1L2L3 postte en nog evcc die regelmatig de waardes ophaalde bij smartevse dat ie periodiek in een soort crash kwam ivm comms error met mains meter.

[ Voor 76% gewijzigd door Stufipower op 14-05-2026 21:30 ]

[b01]

dingo35 schreef op zondag 19 april 2026 @ 12:16:
Ik juich parallelle ontwikkeling overigens van harte toe, "may the best version win"; ik vind het alleen jammer dat @b01 geen eigen release-nummering hanteert (bijv. 26.04) maar op die van ons voortborduurt, wat garant staat voor verwarring ("ik zit op v3.13.1", "dat kan niet want die is nog niet uit", etc)

Hoi dingo,

ik zou graag de contributies stuk voor stuk terug overdragen. Ben zoekende naar wat de handigste manier hiervoor is. Het lijkt me zonde meerdere versie te onderhouden.

Wat zou als waardevolle aanvullingen worden ervaren? ( features, test automatisering, documentatie, …)

Wat zou een praktische manier zijn om terug bij te dragen?

Hartelijke groet Bas

[ruud76]

Stufipower schreef op donderdag 14 mei 2026 @ 21:14:
Hoe krijgen jullie betrouwbaar de mainsmeter waardes in smartevse, zonder dat die http server overloaded raakt? Ik had met ocpp + een script dat via api elke 5 seconden L1L2L3 postte en nog evcc die regelmatig de waardes ophaalde bij smartevse dat ie periodiek in een soort crash kwam ivm comms error met mains meter.

Ik ben net over naar MQTT, ook omdat ik de indruk had dat HTTP te belastend is. Dat lijkt heel goed te werken! Ik had Eclipse Mosquitto toch al op mijn NAS draaien voor Zigbee2MQTT, en ik laat de slimmelezer nu elke 2 seconden een MQTT topic posten met L1-L3 voor mijn SmartEVSE.

[tukker999]

MQTT is een ondergewaardeerde optie. Zo simpel en zo betrouwbaar.

Ik zie mensen met MODBUS rommelen en denk dan: waarom?

[ Voor 30% gewijzigd door tukker999 op 15-05-2026 01:09 ]

[Epsilon]

tukker999 schreef op vrijdag 15 mei 2026 @ 01:07:
MQTT is een ondergewaardeerde optie. Zo simpel en zo betrouwbaar.

Ik zie mensen met MODBUS rommelen en denk dan: waarom?

Simpele reden: Stand-alone

Ik heb nog geen MQTT infra draaien (ook geen HA). Komt allemaal, maar is er nog ik niet.

Mijn slimme meter helpt ook niet mee; die is nog DSMR4 en kan niet de stromen per fase uitlezen (en update slecht elke 10 sec). Ik ben dus aangewezen op iets met klemmen. In dit geval, via ModBus direct naar de EVSE.

Er zijn meer wegen naar Rome en modbus is niet direct "rommelen". Het is niet flexibel, maar wel betrouwbaar en niet afhankelijk van WiFi/Ethernet .

[ Voor 10% gewijzigd door Epsilon op 15-05-2026 13:58 ]

[Epsilon]

Minor dingetje waar ik net tegenaanliep na een update naar nieuwe firmware.

Wat is er gebeurd:
* OCPP enabled vinkje aangezet (rest van velden leeg gelaten; was nog niet zo ver aan de Tap registratie kant )
* Firmware update van 3.10.3 naar 3.11.0
* Reboot (geen effect, maar toch)
* Er staat Out of Order op display
* Webserver: OCPP vinkje staat UIT
* in /Settings: OCPP staat DISABLED

OCPP vinkje aan en weer uit zetten en het werkte weer.
Klein issue, maar goed om te melden denk ik .

[Hmmbob]

b01 schreef op donderdag 14 mei 2026 @ 22:18:
...
Wat zou een praktische manier zijn om terug bij te dragen?

(Losse, per verbetering) pull requests op de repo?

https://github.com/dingo35/SmartEVSE-3.5/pulls

[ Voor 5% gewijzigd door Hmmbob op 15-05-2026 13:58 ]

[Kaspers]

Stufipower schreef op donderdag 14 mei 2026 @ 21:14:
Hoe krijgen jullie betrouwbaar de mainsmeter waardes in smartevse, zonder dat die http server overloaded raakt? Ik had met ocpp + een script dat via api elke 5 seconden L1L2L3 postte en nog evcc die regelmatig de waardes ophaalde bij smartevse dat ie periodiek in een soort crash kwam ivm comms error met mains meter.

Zoals anderen ook noemen: MQTT.
De keten is idd in mijn geval zeker niet 'high available':
DSMR -> P1 reader met telnet server op poort 23 -> 'realtime' (elke seconde) lookups door home assistant -> mqtt publish naar mosquitto (elke seconde) -> smartevse via mqtt subscription

Maar het lijkt stabiel te werken en zoals genoemd, de webserver van de smartevse wordt niet overbelast.

[Hmmbob]

Stufipower schreef op donderdag 14 mei 2026 @ 21:14:
Hoe krijgen jullie betrouwbaar de mainsmeter waardes in smartevse, zonder dat die http server overloaded raakt? Ik had met ocpp + een script dat via api elke 5 seconden L1L2L3 postte en nog evcc die regelmatig de waardes ophaalde bij smartevse dat ie periodiek in een soort crash kwam ivm comms error met mains meter.

Primair mqtt, fallback http.post vanaf mijn slimme lezer. Die fallback is langzamer/meer belastend dan mqtt, maar soms zit ik met mijn server (incl HA) te klooien en dan is het wel fijn dat de mains meter gegevens gewoon nog steeds doorgegeven worden.

Code staat op GitHub: https://github.com/hmmbob...b/master/slimmelezer.yaml

[rvdgaag]

Ik heb gisteren mijn beide Smart-EVSE's geupgrade met de ethernet upgrade, was goed te doen.

Blij dat ze van wifi af zijn, wil in huis zo veel mogelijk bedraad werken, wifi is alleen voor macbooks, iphone's etc.

[Beekforel]

Hmmbob schreef op vrijdag 15 mei 2026 @ 17:44:
[...]

Primair mqtt, fallback http.post vanaf mijn slimme lezer. Die fallback is langzamer/meer belastend dan mqtt, maar soms zit ik met mijn server (incl HA) te klooien en dan is het wel fijn dat de mains meter gegevens gewoon nog steeds doorgegeven worden.

Code staat op GitHub: https://github.com/hmmbob...b/master/slimmelezer.yaml

Slim dit, ik heb het overgenomen naar mijn eigen config.

[Kaspers]

Hmmbob schreef op vrijdag 15 mei 2026 @ 17:44:
[...]

Primair mqtt, fallback http.post vanaf mijn slimme lezer. Die fallback is langzamer/meer belastend dan mqtt, maar soms zit ik met mijn server (incl HA) te klooien en dan is het wel fijn dat de mains meter gegevens gewoon nog steeds doorgegeven worden.

Code staat op GitHub: https://github.com/hmmbob...b/master/slimmelezer.yaml

Mooier dan dit wordt het niet!

[tukker999]

Epsilon schreef op vrijdag 15 mei 2026 @ 11:03:
Mijn slimme meter helpt ook niet mee; die is nog DSMR4 en kan niet de stromen per fase uitlezen (en update slecht elke 10 sec). Ik ben dus aangewezen op iets met klemmen. In dit geval, via ModBus direct naar de EVSE.

Ik zie meer mensen die graag iedere seconde willen regelen.
Waarom eigenlijk, denk ik dan. Een wolkje voor de zon en dan hup omlaag en weer iets anders en weer anders.
Zijn de mensen er op uit om het laatste drupje energie van de zon in de EV te persen?

Bekijk het wat groter en zie wat je directe gebruik door het jaar heen is. (bij mij 46%) Bedenk bijvoorbeeld ook eens dat de OBC vaak 250W pakt. Waarom dan zonodig meteen laden zodra er 6A beschikbaar is en 2 seconden later weer uitschakelen.
Ik heb het spul zo ingeregeld dat het laden pas begint als er 10A is en die stand houdt 'ie vast ook als het daarna even naar 8A zakt. Er is ook een buffer naar boven. Dat geeft een beetje rust in de tent. Niet dat voortdurende geschakel.
In de zomer bijvoorbeeld ben ik blij dat er niet gelijk bij 6A geladen wordt en dat er meer op 13A en 16A geladen wordt, want dan zijn de laadverliezen een stuk minder. In de winter valt er sowieso niet op de zon te laden en die enkele minuut vroeg in het voorjaar of laat in het najaar dat er 6A beschikbaar is; dat kost meer energie dan er geladen wordt.

[ Voor 16% gewijzigd door tukker999 op 16-05-2026 00:03 ]

[Stefannn]

tukker999 schreef op vrijdag 15 mei 2026 @ 23:59:
[...]

Ik zie meer mensen die graag iedere seconde willen regelen.
Waarom eigenlijk, denk ik dan. Een wolkje voor de zon en dan hup omlaag en weer iets anders en weer anders.
Zijn de mensen er op uit om het laatste drupje energie van de zon in de EV te persen?

Bekijk het wat groter en zie wat je directe gebruik door het jaar heen is. (bij mij 46%) Bedenk bijvoorbeeld ook eens dat de OBC vaak 250W pakt. Waarom dan zonodig meteen laden zodra er 6A beschikbaar is en 2 seconden later weer uitschakelen.
Ik heb het spul zo ingeregeld dat het laden pas begint als er 10A is en die stand houdt 'ie vast ook als het daarna even naar 8A zakt. Er is ook een buffer naar boven. Dat geeft een beetje rust in de tent. Niet dat voortdurende geschakel.
In de zomer bijvoorbeeld ben ik blij dat er niet gelijk bij 6A geladen wordt en dat er meer op 13A en 16A geladen wordt, want dan zijn de laadverliezen een stuk minder. In de winter valt er sowieso niet op de zon te laden en die enkele minuut vroeg in het voorjaar of laat in het najaar dat er 6A beschikbaar is; dat kost meer energie dan er geladen wordt.

Snel regelen, en met name “per fase” is voor het “PV volgen” ook niet zo essentieel. Het is wel essentieel voor bewaken van maximale grid-load om te voorkomen dat de hoofdzekering eruit klapt.
Per seconde is dan echter niet nodig, sterker… dat gaat niet eens. De auto is veel langzamer met reageren. Mijn auto heeft 4 a 5 seconden nodig. De smartEVse heeft dacht ik liefst data per 2 seconden. Ik zelf doe de load-control in mijn home automation en regel per 5 seconden (met een emergency dial-down op 2 seconden). Als een 25A hoofdzekering met 16A wordt overbelast (dat is het maximum dat de evse kan leveren dus ook het maximum dat die kan oplossen), dan zou die dat volgens de afschakel curve minimaal 20 seconden moeten uithouden.
De regeling baseren op die 20 seconden is wel heel erg het randje opzoeken en niet aan te bevelen. Maar…. Het geeft aan dat regelen per seconde niet nodig is. Per 5 seconden is wel genoeg.

[Epsilon]

Rust in de tent kan ik begrijpen. Maar aan de andere kant: je hebt er ook geen omkijken naar, dus rust voor wie. De auto? Die zal het een worst wezen . En uiteraard raad ik aan om de timer te bruiken, zodat pas na bijvoorbeeld 5min of 10min minder dan <ingesteld> overschot het laden stopt. Op bewolkte dagen kom ik (en vele met mij) niet op 8A/10A overschot. En er zijn niet genoeg dagen met dat overschot om alleen dan te laden.

Keuzes worden gebaseerd op je situatie en die van mij is anders dan die van jou. Er "moet" bij mij 300kWh per maand de EV in om te rijden. Als het een paar dagen niet zonnig is, moet ik ook importen. Het zou in mijn geval jammer om 1000W aan overschot verloren te laten gaan.

En elke druppel zon in de auto? Graag, als die anders "verloren" gaat. Dat is voor mijn situatie gewenst.

Het laadverlies is overigens wel een goed punt .

Dat wil ik voor mijn auto eens uittesten, om het verschil in laadverlies tussen 6A, 16A, 3x10A en 3x16A bijvoorbeeld te bekijken.

Maar als overschot niets opbrengt, is laadverlies irrelevant qua kosten natuurlijk. Als je alles importeert of stuurt op kosten maak je andere keuzes.

Kortom: Alles ligt aan de situatie waarin je zit .

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 1% gewijzigd door Epsilon op 16-05-2026 15:34 . Reden: Typos en lopende zinnen ]