Zelfbouw Laadpaal ervaringen

[Stufipower]

Kan ik terecht concluderen dat indien de smartevse met ocpp gekoppeld is en daarna op smart mode wordt gezet:

- Dat hij dan aan dynamisch loadbalancing doet (en overige features van smart toepast)

- maar ook daarbij “OFF” weergeeft als instelling (hij springt terug), terwijl die dus eigenlijk op smart staat

- en dat dit bij mensen verwarring oplevert?

[ Voor 8% gewijzigd door Stufipower op 17-06-2026 19:39 ]

[thalx]

Stufipower schreef op woensdag 17 juni 2026 @ 19:36:
Kan ik terecht concluderen dat indien de smartevse met ocpp gekoppeld is en daarna op smart mode wordt gezet:

- Dat hij dan aan dynamisch loadbalancing doet (en overige features van smart toepast)

- maar ook daarbij “OFF” weergeeft als instelling (hij springt terug), terwijl die dus eigenlijk op smart staat

- en dat dit bij mensen verwarring oplevert?

Ik draai al een half jaar via Tap, en ik heb dat nog niet meegemaakt. Ik kan gewoon als mijn lader via Tap is verbonden Smart laden, waarbij de webinterface én home assistant (MQTT) 'Smart' aangeven. Hetzelfde voor Solar.
Enige belangrijke is dat je na het beëindigen van je sessie ('Off') op de SmartEVSE weer een RFID autorize moet zien te triggeren. Dit kan door opnieuw je auto aan te sluiten, of via de 'nieuwe' API functie hiervoor. Zonder re-autorize kan ik niet opnieuw starten. (en dat is logisch), en ik heb bij de auto-authorize functie van de SmartEVSE gewoon het RFID van mijn laadpas ingesteld (die staat op 'free use' bij Tap).

[thalx]

sandergar schreef op woensdag 17 juni 2026 @ 10:14:


Yup, het was leuk geweest als de OCPP functionaliteit van de SmartEVSE hiervoor gebruikt had kunnen worden. Mijn auto wordt van maart t/m oktober alleen maar geladen in de Solar-Only modus. Ik heb daar geen 3e partij voor nodig die mij gaat vertellen dat ik mijn auto op een andere manier moet gaan laden of dat ik mijn auto geheel niet mag laden, ook niet met mijn eigen PV opwekking, omdat het druk is op het net. Het is mijn Smart EVSE en ik bepaal zelf wat ik daarmee wil doen. Als ik externe sturing had gewild dan had ik wel een gewone laadpaal opgehangen.

Kortom, SmartEVSE is gewoon weer ontkoppeld en is gewoon weer bedienbaar! Voor mij is de OCPP functionaliteit (SmartEVSE versie v3.10.2) niet geschikt op deze manier.

In je screenshot zie ik bij de OCPP auto-authorize functie nog geen RFID, bij mij werkte niets zonder een RFID (pak gewoon bijvoorbeeld de waarde van je eigen laadpas, en zet die bij Tap voor gratis gebruik). Tevens moet je na inschakelen wel ook triggeren dat er een autorisatie plaats gaat vinden van dat RFID laadpas-nummer, vanaf SmartEVSE naar Tap (of andere OCPP aanbieder). Dit kan door je auto opnieuw aan te sluiten, of via de API/MQTT (/Set/RFID).
Het werkt bij mij al een half jaar perfect, ook met Solar/Smart laden, en daarnaast Home Assistant via MQTT én nog een koppeling via Node Red met mijn Victron omvormer (thuisaccu) en Victron grid-meter 3P75CT in de meterkast.

[ Voor 8% gewijzigd door thalx op 17-06-2026 21:48 ]

[Stufipower]

Dan ligt het misschien aan de specifieke OCPP koppeling (backoffices gedragen zich divers)?

Welke firmware versie draai je op je smartevse?

[ Voor 20% gewijzigd door Stufipower op 17-06-2026 21:45 ]

[dingo35]

Als je OCPP aan zet en je autoriseert je eigen sessie niet, dan krijg je "available" op je LCD scherm (in geval van auto-authorize) of "please authorize" (met RFID reader op Rmt/OCPP of disabled) en OFF op je dashboard. Als je dan autoriseert krijg je de mode waar je in zat (dus VOORdat je autoriseert), zoals je gewend was het bekende Ready scherm, al dan niet met zonnetje.

Als je problemen hebt met je backendprovider, maak dan een gratis account bij Tap Electric aan, koppel daar aan, dan zie je hoe het behoort te werken, en kun je na die leerfase overstappen maar je favoriete backend, dan weet je (beter) hoe te configureren en welke acties/schermen je kunt verwachten.


Ik heb twee jaar geleden met veel OCPP providers getest op een jaarlijks test-event, en daar kwamen we glansrijk doorheen (niet mijn verdienste), alleen Joulo had een probleem met hun specifieke serverconfiguratie, verder zijn mij geen incompatibiliteiten bekend.

[ Voor 23% gewijzigd door dingo35 op 18-06-2026 08:12 ]

[Ferrox1]

Wellicht interessant, ik schakel tussen 2 meters (SAP & PAP). Hierdoor valt enkele MS de spanning weg. Alles blijft aan in huis, ook de smartEVSE. Maar als ik schakel moet ik vaak (niet altijd) opnieuw autoriseren heb ik gemerkt. Waarom dit is ben ik nog niet achter gekomen. Een UPS er tussen gaat niet vanwege de hoge stromen. Dus ik heb voor nu maar even geaccepteerd dat het zo is. (en zo vaak schakel ik ook niet) Mogelijk dat een dergelijke situatie ook bij jou speelt door een slechte aansluiting @Stufipower ?

Wat ik wel mis in de MQTT koppeling is de autorisatiestatus. Nu schakel ik op de MQTT RFID topic die dan heel kort naar Present Schiet. Daarna lees ik de code uit. Wat fijner zou zijn is dat de autorisatiestatus in de MQTT zou zitten. Bijvoorbeeld met de statussen authorised, read card, car not connected. Nu schiet volgens mij de EVSE status kort naar Deny, maar is dat hetzelfde?

Op basis hiervan kan ik na het schakelen de eerder verstuurde RFID via MQTT opnieuw sturen. Dan lost het dat probleem op.

Als ik sec via home asisstant kijk op de MQTT berichten dan kan ik er niet direct uithalen dat de sessie vervallen is. (om wat voor reden dan ook). En dat opnieuw de RFID aangeboden moet worden. Hij staat dan in pauze, zet je hem op smart en dan schiet hij gelijk terug naar pauze. Tot ik de RFID aangeboden heb, dan wil hij wel naar SMART.

Wellicht zie ik iets over het hoofd kwa functionaliteit? Of pak ik het verkeerd aan?

[ Voor 13% gewijzigd door Ferrox1 op 18-06-2026 11:22 ]

[Stufipower]

@Ferrox1 Die melding bij mij is er omdat ik nog geen mains meter waarden doorstuur naar de SmartEVSE, dus dat is logisch. Ben dit nog aan het optuigen via mqtt.

Mogelijk dat je toch (gedeeltelijke) spanningsuitval hebt bij het schakelen. En hij stuurt ook geen berichten als er geen spanning is? OCPP sessies worden in ieder geval zeker beeindigd bij een powercycle.

[cyclone]

Mmmm ik heb ook al maanden geen issue meer gehad met TAP en auto autherise maar kom net bij een halfvolle Tesla en een melding not authorized op de smart evse.

gaat toch iets niet lekker weer bij TAP want kan verder niets geks vinden meer mensen hier last van ?

Draai versie 3.11.0 al tijden zonder enig probleem dus geen idee wat nu de aanleiding is.

[dingo35]

Wifi probleem en/of stroomonderbreking? Je kunt de uptime ik meen via MQTT opvragen...

EDIT: Ik heb gisteravond toevallig een delayed laadsessie bij Tap ingezet en hij is vanochtend keurig op tijd gaan laden, sessie is nu nog bezig. Dus als het een Tap probleem was dan is het zeker niet voor alle aansluitingen!

[ Voor 57% gewijzigd door dingo35 op 19-06-2026 06:46 ]

[cyclone]

Alles gechecked en operationeel, net even via de TAP app een remote start gegeven en hopla hij start direct met laden.

Dus gaat ergens mis met de auto authorise blijkbaar. Al een keer eerder gehad maar opeens was dat ook weer opgelost zonder duidelijke aanleiding.

Toch maar eens de debug versie erop zetten en wat logs verzamelen want de logs van TAP zijn niet gedetailleerd genoeg.

[dingo35]

In 3.11.0 zie je de OCPP messages alleen nog op de USB poort, als je ze via telnet wil zien moet je de master branch compileren en flashen...

[RonJ]

Bij mij wilde ie vanochtend (of eigenlijk sinds gisteravond wat blijkbaar niet gelukt was) ineens ook niet meer authoriseren met TAP (+RFID). Uiteindelijk de evse maar gereboot na een aantal keer tevergeefs de tag aangeboden te hebben en toen werkte het meteen weer zoals het hoort. Verder niet ingedoken nog.

[ Voor 32% gewijzigd door RonJ op 19-06-2026 14:20 ]

[thalx]

Hier ook issues vandaag, is meer Tap gerelateerd gok ik, het gaat hier zelfs zover dat hij steeds disconnected aangeeft voor de laadkabel, heel vreemd. (ik heb gecheckt op oververhitting met een warmtebeeldcamera op de connector, aangezien de EV6 daar een sensor voor heeft).
Na een reboot van de EVSE werkt het dan weer even.
Later vandaag maar even het debug versie op de SmartEVSE zetten als dit doorzet.

[ Voor 6% gewijzigd door thalx op 19-06-2026 14:24 ]

[sandergar]

sandergar schreef op woensdag 17 juni 2026 @ 11:26:
Wat ik wil is gewoon een Smart EVSE hebben die niet belemmerd wordt in het gebruik door een 3e partij. Hoeveel storingen zijn er wel niet de laatste tijd?

Ook met TAP kan je dus belemmerd worden

[cyclone]

100% zeker dat het TAP was nu, kom net thuis en gooi de auto aan de lader en werkt meteen. Niks gewijzigd vanochtend (want was veels te vroeg) en nu is er weer geen vuiltje aan de lucht.

Wel het grote nadeel van OCPP als je het mij vraagt want je zal maar net wel een volle accu nodig hebben en erachter komen 10 minuten voor vertrek dat TAP de laadsessie niet authoriseerde.

[sjoerd-p]

cyclone schreef op vrijdag 19 juni 2026 @ 18:06:
100% zeker dat het TAP was nu, kom net thuis en gooi de auto aan de lader en werkt meteen. Niks gewijzigd vanochtend (want was veels te vroeg) en nu is er weer geen vuiltje aan de lucht.

Wel het grote nadeel van OCPP als je het mij vraagt want je zal maar net wel een volle accu nodig hebben en erachter komen 10 minuten voor vertrek dat TAP de laadsessie niet authoriseerde.

Ik heb ook al een keer gehad dat ik persé wilde laden, maar OCPP niet wilde verbinden. Ook niet na reboot. Dus uiteindelijk OCPP uitgezet en geladen (geen ERE inkomsten, behalve als mijn meterstand telt?) en daarna een firmwareupdate van SmartEVSE en alles werkte weer. WEet dus niet of het de SmartEVSE was, of Tap in dit geval. Maar was spontaan ontstaan.

[cyclone]

@sjoerd-p er was een issue met een certificaat in SmartEvse paar maanden geleden klinkt alsof dit die issue was die jij beschrijft.

Dat was wel een Smart evse issue is in dit topic ook aan de orde geweest en werd idd met de update verholpen.

Dat is wel een andere issue dan die we vandaag gezien hebben.

[Conrado]

Phantone schreef op donderdag 19 maart 2026 @ 18:32:
Net een Thuisbatterij besteld en die kan niet met de SlimmeLezer+ overweg, wel met de HomeWizard P1.
Nu had ik geen zin in een splitter dus heb even de HomeWizard V1 API toegevoegd aan de SlimmeLezer+
Toen zag ik dat de nieuwe SmartEVSE firmware deze tegenwoordig ook support dus dacht ik laat ik even hier de yaml delen.


[...]

Geweldig!
Vraagje, hoe programmeer ik de yaml in de SlimmeLezer+? Ik heb gezocht maar kwam geen duidelijke handleiding tegen.

[ruud76]

@stegen @dingo35 enorm bedankt voor dit fantastische systeem en het solar laden (met een extra contactor) dat echt perfect werkt! Het netto stroomverbruik van het huis wordt (mits mogelijk) keurig op nagenoeg 0 gehouden.

[ Voor 8% gewijzigd door ruud76 op 21-06-2026 08:48 ]

[ruud76]

Conrado schreef op zaterdag 20 juni 2026 @ 15:54:
[...]

Geweldig!
Vraagje, hoe programmeer ik de yaml in de SlimmeLezer+? Ik heb gezocht maar kwam geen duidelijke handleiding tegen.

Je hebt ESPHome nodig. Daarin adopteer je de slimmelezer en daarna kun je ‘m updaten en van een aangepast programma voorzien. Ik heb zelf esphome op mijn NAS draaien in een Docker container. Daar ga ik dan vanuit een browser naar toe om de slimmelezer te herprogrammeren. Maar je kunt ‘m natuurlijk ook gewoon op je computer installeren.

[ Voor 7% gewijzigd door ruud76 op 21-06-2026 09:25 ]

[Phantone]

Conrado schreef op zaterdag 20 juni 2026 @ 15:54:
[...]

Geweldig!
Vraagje, hoe programmeer ik de yaml in de SlimmeLezer+? Ik heb gezocht maar kwam geen duidelijke handleiding tegen.

In HA dmv ESP Home Builder, check hier voor meer info https://esphome.io/

[zonnepaneelxl]

Kan iemand mij uitleggen hoe een laadpaal precies werkt kwa aansturing?

Ik heb namelijk een zaptec go 2 ervaar het volgende probleem.

Zodra ik onze auto ga laden is er niks aan aan de hand en werkt alles prima op 3 fase laden 11kw.

We hebben een aanhangwagen (voor mobiele stroom naar de bouwplaats) voorzien van een accupakket met 3x een victron multiplus 5000/48

Hier zit een vaste laadkabel aan gemonteerd 3fase 5x6mm2

Tussen aarde en pp zit een weerstand van 220ohm in de stekker( welke in de laadpaal gaat)(dus geschikt voor 32A)

Tussen CP en PE zit een diode en weerstand van 680ohm

Dit is de volgorde van aansluiten
Stekker in de laadpaal
Doormiddel van relais 1 word de diode en weerstand 680ohm actief
Laadpaal gaat starten
Victron Multiplus gaat accus laden circa 10-12kw echter zodra 1 van de 3 fase boven de circa +-16A komt valt de zaptec go 2 in storing.

Melding is:
Limieten van het laadstation zijn overschreden ( aansluiting staat ingesteld als 40A en limiet per fase op 32A)

Mijn vraag is dan ook.

Moet ik een andere weerstand gebruiken tussen PE en CP?/

Kan iemand mij vertellen welke waardes een auto stuurt naar de laadpaal tussen PE en CP?

Hoe werkt het dan bij voorbeeld zonnestroom laden in detail?
Er is volgens de p1 /sense meter maar 2000w beschikbaar.
Hoe weet de auto dan dat deze met maximaal 2000w mag laden?

edit:
Of zit ik helemaal verkeerd met de 680 ohm weerstand tussen CP en PE? (Als je tussen PP en PE 680ohm gebruikt is je kabel geschikt voor 20A

Als ik me dan goed ingelezen heb moet het een weerstand van 2700ohm en 1300ohm parallel zijn of is het 880ohm?

[ Voor 10% gewijzigd door zonnepaneelxl op 22-06-2026 19:39 ]

[Solarsparc]

Het lijkt erop dat je überhaupt niks weet van een control pilot-signaal. De weerstand tussen PP en PE geeft de maximale stroom van de kabel aan, als extra veiligheidslimiet, maar wat de EV mag afnemen, leest deze in het CP-signaal, wat door de laadpaal gemoduleerd wordt. Jouw Victron-setup lijkt hier niets mee te doen.

Een laadpaal heeft geen enkel mechanisme om zelf stroom te begrenzen. Deze kan alleen constateren dat de afgenomen stroom hoger is dan 1 van de instellingen of het CP-signaal en dan de boel afschakelen.

Wat hier gebeurt, geen idee, daarvoor is de Peblar-melding te onduidelijk.
Jouw setup doet niet eens een poging om IEC 61851 te implementeren, dus het kan vanalles zijn.
Als het strak op 16A is, klinkt het overigens wel eerder alsof een ingestelde limiet van de Peblar overschreden wordt.

Edit: je laadpaal is 11kW dus er mag niet meer dan 16A lopen als dit zo is ingesteld. Je moet je Victron zo instellen dat ie niet meer dan 16A trekt. 11kW op 3 fasen is maximaal 3.7kW/16A per fase, je kunt niet optellen naar 1 fase.

Wat je aan het doen bent, is gezien je kennisniveau, niet ongevaarlijk.

[ Voor 15% gewijzigd door Solarsparc op 22-06-2026 19:54 ]

[prein2]

zonnepaneelxl schreef op maandag 22 juni 2026 @ 18:47:
Kan iemand mij uitleggen hoe een laadpaal precies werkt kwa aansturing?

Ik heb namelijk een zaptec go 2 ervaar het volgende probleem.

Zodra ik onze auto ga laden is er niks aan aan de hand en werkt alles prima op 3 fase laden 11kw.

We hebben een aanhangwagen (voor mobiele stroom naar de bouwplaats) voorzien van een accupakket met 3x een victron multiplus 5000/48

Hier zit een vaste laadkabel aan gemonteerd 3fase 5x6mm2

Tussen aarde en pp zit een weerstand van 220ohm in de stekker( welke in de laadpaal gaat)(dus geschikt voor 32A)

Tussen CP en PE zit een diode en weerstand van 680ohm

Dit is de volgorde van aansluiten
Stekker in de laadpaal
Doormiddel van relais 1 word de diode en weerstand 680ohm actief
Laadpaal gaat starten
Victron Multiplus gaat accus laden circa 10-12kw echter zodra 1 van de 3 fase boven de circa +-16A komt valt de zaptec go 2 in storing.

Melding is:
Limieten van het laadstation zijn overschreden ( aansluiting staat ingesteld als 40A en limiet per fase op 32A)

Mijn vraag is dan ook.

Moet ik een andere weerstand gebruiken tussen PE en CP?/

Kan iemand mij vertellen welke waardes een auto stuurt naar de laadpaal tussen PE en CP?

Hoe werkt het dan bij voorbeeld zonnestroom laden in detail?
Er is volgens de p1 /sense meter maar 2000w beschikbaar.
Hoe weet de auto dan dat deze met maximaal 2000w mag laden?

edit:
Of zit ik helemaal verkeerd met de 680 ohm weerstand tussen CP en PE? (Als je tussen PP en PE 680ohm gebruikt is je kabel geschikt voor 20A

Als ik me dan goed ingelezen heb moet het een weerstand van 2700ohm en 1300ohm parallel zijn of is het 880ohm?

Laadpaal heeft een cp signaal waarmee.hij met de lader in de auto communiceert. Is een heel basic signaal. Als je dat niet implementeert dan moet je zorgen dat je binnen de limiet van de laadpaal blijft. Als de laadpaal dus 16A wil uitsturen (wat hij dus uit stuurt op de cp pin) en je victron pakt 17 dan gaat ie (blijkbaar) in beveiliging.

Vraag is dus: als je de mp instelt om op 15A te laden. Gaat het dan wel goed?

[joosie]

joosie schreef op vrijdag 12 juni 2026 @ 13:36:
...

Ik heb ook gezocht op het resetten van de SMartSVSE naar fabrieksinstellingen, zodat ik zeker weet dat ook alle data weg is, maar daar kom ik niet uit, heeft iemand daar een stappenplan voor?

...

Voor degenen die ook hiernaar zoeken, ik heb het gevonden. Je gaat naar het IP van de SmartEVSE en achter het IP zet je "/erasesettings". Daarna komt de melding: "Erasing settings, rebooting", daarna moet je ook de WiFi opnieuw instellen.

[Conrado]

Phantone schreef op maandag 22 juni 2026 @ 16:00:
[...]

In HA dmv ESP Home Builder, check hier voor meer info https://esphome.io/

Bedankt @Phantone!

Gisteren ESP Home Builder for desktop in een VM-omgeving geïnstalleerd. Het is even wat gedoe met de yaml en het programmeren naar een vast IP-adres. En na het compileren liep de download vast omdat mijn SlimmeLeze de poort niet ondersteunt. Logisch achteraf, want ik heB een SlimmeMeter en niet de SlimmeMeter+. Mijn variant draait standaard nog zonder ESPhome. Kortom, wordt vervolgd

Voor nu maar even de P1 waardes via Home Assistant en MQTT naar de SmartEVSE gestuurd. Is ook gedoe om aan de praat te krijgen, maar dat werkt nu. Eind van de middag mijn EV opgehaald en die is na even laden mooi in Wait for Solar modus gesprongen.

[zonnepaneelxl]

@prein2

Dat snap ik.

Alleen welke waarde verwacht de laadpaal terug?

Is dit dan die 880 ohm? 2700 en 1300 parallel?
Zo ja hoeveel afwijking mag hier inzitten?

Ik ga morgen eens testen met een lager laadvermogen.

[Solarsparc]

De lader schakelt dus blijkbaar is het goed genoeg om state C over te brengen.

Ik raad je aan om wat meer te lezen over die states, maar in principe doet dat niet meer dan aan, uit of error, het communiceert niks over stroomsterktes.

[prein2]

Dat cp is een 1kHz blok golf dat de laadpaal genereert. De duty cycle van die blok golf is een maat voor de hoeveelheid stroom die de auto mag afnemen.

Als de auto meer afneemt, dan luistert hij dus niet. Het lijkt erop dat de lader dan stopt met die foutmelding. Gaat dus om communicatie nadat er met weerstandjes iets is gestart

[dingo35]

@zonnepaneelxl Je victrons gewoon op de conventionele manier laden en niet via je laadpaal. Dit ruikt naar ERE fraude!

[zonnepaneelxl]

Dit slaat weer helemaal nergens op...

Toevallig heb ik het nu over een zaptec go 2 laadpaal maar we moeten ook kunnen laden bij een openbare laadpaal dus het protocol moet goed zijn.

Dit heeft niks met ERE te maken

[Conrado]

Conrado schreef op maandag 22 juni 2026 @ 21:04:
[...]

Eind van de middag mijn EV opgehaald en die is na even laden mooi in Wait for Solar modus gesprongen.

Dat ging gisterenavond precies zoals bedoeld. Vanochtend had ik verwacht dat íe weer verder zou gaan met laden, echter dat gebeurde niet. De EVSE stond op Ready maar startte niet, ondanks ruim voldoende zonnestroom.
Bleek dat de auto in error stand en de lading 'onderbroken' was. Reboot EVSE hielp niet, maar liet wel de foutmelding verdwijnen. Kabel ui/in hielp ook niet, Uiteindelijk de auto 20 cm naar achteren/voren gereden en daarna begon 'ie weer te laden.

Is dat normaal gedrag? Wat kun je hier tegen doen?

[dingo35]

zonnepaneelxl schreef op dinsdag 23 juni 2026 @ 09:24:
Dit slaat weer helemaal nergens op...

Toevallig heb ik het nu over een zaptec go 2 laadpaal maar we moeten ook kunnen laden bij een openbare laadpaal dus het protocol moet goed zijn.

Dit heeft niks met ERE te maken

Nee het laden van victrons via een laadpaal slaat helemaal nergens op. Tak dan de voeding van de laadpaal netjes af via een alamat, dan doe je het netjes conform de voorschriften.

Als je gaat lopen rommelen door CP en PP lijnen te faken, loop je nu eenmaal risico's, zeker als je, blijkens je posts, geen idee hebt hoe het werkt.

[dingo35]

Conrado schreef op dinsdag 23 juni 2026 @ 10:08:
[...]

Dat ging gisterenavond precies zoals bedoeld. Vanochtend had ik verwacht dat íe weer verder zou gaan met laden, echter dat gebeurde niet. De EVSE stond op Ready maar startte niet, ondanks ruim voldoende zonnestroom.
Bleek dat de auto in error stand en de lading 'onderbroken' was. Reboot EVSE hielp niet, maar liet wel de foutmelding verdwijnen. Kabel ui/in hielp ook niet, Uiteindelijk de auto 20 cm naar achteren/voren gereden en daarna begon 'ie weer te laden.

Is dat normaal gedrag? Wat kun je hier tegen doen?

Ik had precies hetzelfde gedrag na een firmware update van mijn Enyaq: blijkt dat de laadmodule van het EV gereset had moeten worden (zekeringetje er uit en er weer in) na de update, maar dat de dealer dat niet wist.

Dit soort zaken worden alleen door fanatieke hobbyisten en een enkele goede EV monteur opgemerkt; zoek op fora voor je EV op "diepe slaap", "ontwaken", en hopen dat je daar een oplossing vindt.

Ik zocht het probleem in de SmartEVSE firmware, versie v3.11.0 helemaal nagelopen en die doet alles keurig volgens de standaarden om de EV te doen ontwaken; daar zat het dus niet in

[sjoerd-p]

zonnepaneelxl schreef op maandag 22 juni 2026 @ 18:47:
Kan iemand mij uitleggen hoe een laadpaal precies werkt kwa aansturing?

I<knip>

Als ik me dan goed ingelezen heb moet het een weerstand van 2700ohm en 1300ohm parallel zijn of is het 880ohm?

Ik kan je aanraden deze pagina te lezen en dit schema over te nemen: https://evsim.gonium.net/. Ik heb zelf het printplaatje besteld dat ze aanbieden, dat maakt het iets makkelijker. Ik heb de schakelaars ingevouwd in een oude stekker van een Mitsubishi Outlander PHEC en andere andere kant een normaal stopcontact. Maar er zijn ook genoeg verloopkabels naar Schuko te bestellen als je dit regelmatig gaat gebruiken. Dan is dat wellicht veiliger dan zelfbouw als je niet weet wat je aan het doen bent. Ik heb het vooral gebruikt om laadpalen te kunnen testen en te zien hoe hij reageert op alle mogelijke signalen. En om te zien (met drie ledjes) of het een één fase of drie fase laadpaal is.

[dingo35]

Merk op dat Schuko niet geschikt is om langdurig stromen groter dan 10A door te leiden; óók stekkers/WCD's die 16A als opschrift hebben, dat is (vreemd genoeg) eerder bedoeld als maximale piekbelasting, niet als continu belasting.

Voor continue stromen zijn die blauwe CEE campingstekkers bedoeld.

[joosie]

Zo, jullie weten dit natuurlijk allang, maar ik kom er net achter dat de knoppen onder het scherm op de webinterface ook werken!

[Stufipower]

Feature request: alles wat instelbaar is via de knoppen mogelijk maken via de web interface zonder dat je door (virtuele) knopjes moet drukken.

[dingo35]

Het is een bewuste keuze om m.n. features die met de hardware-configuratie te maken hebben, bijv. MaxCurrent, NIET via het webdashboard en/of de API toegankelijk te maken; dat zijn zaken die je eenmalig instelt, en waarvan (per ongeluk) wijziging tot onveilige situaties zou kunnen leiden.

De fabrikant was eigenlijk ook niet voor de bediening van het LCD scherm via het web dashboard, om precies die reden, maar ik/de fraaie uitvoering van de auteur/de pincode die ik er op gezet heb hebben hem overtuigd. Daar zul je het dus mee moeten doen.

[martijn_van_eck]

Het lijkt erop dat Tibber de stekker eruit heeft getrokken voor onze smartevse koppeling. Laadpaal is niet meer zichtbaar in de app

[peterpannekoek]

Ik heb een adapter gemaakt van type 2 naar cee 32A

Het is namelijk om stroom te gebruiken van een openbare laadpaal.
Echter werkt het niet zoals ik gehoopt had.

220ohm tussen PP en PE 32A rating kabel
2K7ohm tussen CP en PE lader word geactiveerd.
1K2ohm tussen CP en PE met schakelaar voor laden starten.

Het probleem is nu als volgt "laden" werkt alles bij meer dan 10A per fase word er afgeschakeld.
Blijven we onder de 10A per fase gaat het goed.

Meerdere openbare laadpalen geprobeerd zowel 11 als 22kw

Kan iemand ons op weg helpen waar het mis gaat en een oplossing voor bedenken?

[Solarsparc]

Het antwoord vind je waarschijnlijk in het CP-signaal wat je keihard negeert.

Mijn vermoeden is dat die laadpaal aan iets van load balancing doet.

Weer zo'n slecht idee.

[ Voor 39% gewijzigd door Solarsparc op 23-06-2026 22:56 ]

[peterpannekoek]

Kan je me op weg helpen in plaats van kritiek te leveren?

Ik lees en zie namelijk meerdere aansluitschema's op het internet. (Zoals nu aangesloten)

Wat ik begrijp moet deze kabel werken via mode 3.

Hoe kan je dan in vredesnaam zorgen dat de laadpaal wel het juiste cp-signaal terug krijgt die ik volgens jou dan keihard negeer?

Ik heb namelijk al 2 van deze adapter kabels gekocht bij voldt en amazon en deze doen precies hetzelfde op een laadpaal.

[Solarsparc]

Een EV leest het CP-signaal en past aan de hand daarvan de laadstroom aan. Zo'n adapter, ook al "simuleert" ie "mode 3", heeft geen manier om die stroom te regelen.
Mijn vermoeden is dat de laadpaal via CP aangeeft dat je niet meer dan 10A mag afnemen, wellicht zelfs als test om te kijken of de afnemer zich aan het CP-signaal houdt. Een laadpaal moet hier op kunnen vertrouwen als hij bijv. aan loadbalancing moet doen. Dit i.v.m. netcapaciteit maar ook bijv. als er 2 auto's aan dezelfde paal hangen. Jouw adapter zal dat negeren en wat jij aan je adapter hebt hangen, kan dan alsnog de volle 16A of 32A trekken.

Je kwestie is simpel en het antwoord is dat eigenlijk ook: als de laadpaal zegt dat je niet meer dan 10A af mag nemen, doe dat op dat moment dan ook niet. Maar je hebt daar wel electronica voor nodig die het CP-signaal kan interpreteren en aan de hand daarvan de stroomafname kan regelen. Met alleen zo'n stekker kom je daar nooit. Je verbruiker moet kunnen afstemmen met de lader, net als een EV dat doet. Dat kan niet een simpel stopcontact zijn.

Als je wilt bevestigen dat de laadpaal een CP-signaal stuurt wat de limiet stelt, moet je het CP-signaal lezen met een oscilloscoop, multimeter met duty-cycle-functie of iets wat speciaal voor het analyzeren van EV-laden is gemaakt.

Het internet staat vol met artikelen over hoe dit allemaal werkt. Als je met deze materie bezig bent en dat niet op kunt zoeken, lever ik kritiek. Je kunt serieuze schade aanrichten op deze manier.
Je bent zonder kennis beveiligingen aan het omzeilen. Dat je dat thuis doet is nog tot daaraan toe, maar op een laadpaal van een ander is wel een nieuw dieptepunt.

[ Voor 20% gewijzigd door Solarsparc op 24-06-2026 02:45 ]

[dingo35]

Beste moderator gaan we nu van "zelfbouw laadpaal ervaringen" naar "zelfbouw EV simulator ervaringen om een laadpaal te misleiden" ?

[Stefannn]

zonnepaneelxl schreef op maandag 22 juni 2026 @ 18:47:
Kan iemand mij uitleggen hoe een laadpaal precies werkt kwa aansturing?

Ik heb namelijk een zaptec go 2 ervaar het volgende probleem.

Zodra ik onze auto ga laden is er niks aan aan de hand en werkt alles prima op 3 fase laden 11kw.

We hebben een aanhangwagen (voor mobiele stroom naar de bouwplaats) voorzien van een accupakket met 3x een victron multiplus 5000/48

Hier zit een vaste laadkabel aan gemonteerd 3fase 5x6mm2

Tussen aarde en pp zit een weerstand van 220ohm in de stekker( welke in de laadpaal gaat)(dus geschikt voor 32A)

Tussen CP en PE zit een diode en weerstand van 680ohm

Dit is de volgorde van aansluiten
Stekker in de laadpaal
Doormiddel van relais 1 word de diode en weerstand 680ohm actief
Laadpaal gaat starten
Victron Multiplus gaat accus laden circa 10-12kw echter zodra 1 van de 3 fase boven de circa +-16A komt valt de zaptec go 2 in storing.

Melding is:
Limieten van het laadstation zijn overschreden ( aansluiting staat ingesteld als 40A en limiet per fase op 32A)

Mijn vraag is dan ook.

Moet ik een andere weerstand gebruiken tussen PE en CP?/

Kan iemand mij vertellen welke waardes een auto stuurt naar de laadpaal tussen PE en CP?

Hoe werkt het dan bij voorbeeld zonnestroom laden in detail?
Er is volgens de p1 /sense meter maar 2000w beschikbaar.
Hoe weet de auto dan dat deze met maximaal 2000w mag laden?

edit:
Of zit ik helemaal verkeerd met de 680 ohm weerstand tussen CP en PE? (Als je tussen PP en PE 680ohm gebruikt is je kabel geschikt voor 20A

Als ik me dan goed ingelezen heb moet het een weerstand van 2700ohm en 1300ohm parallel zijn of is het 880ohm?

Google “evse cp” doet wonderen:

[prein2]

peterpannekoek schreef op dinsdag 23 juni 2026 @ 23:50:
Kan je me op weg helpen in plaats van kritiek te leveren?

Ik lees en zie namelijk meerdere aansluitschema's op het internet. (Zoals nu aangesloten)

Wat ik begrijp moet deze kabel werken via mode 3.

Hoe kan je dan in vredesnaam zorgen dat de laadpaal wel het juiste cp-signaal terug krijgt die ik volgens jou dan keihard negeer?

Ik heb namelijk al 2 van deze adapter kabels gekocht bij voldt en amazon en deze doen precies hetzelfde op een laadpaal.

in de ocpp standaard staat dat zonder communicatie er max 10A per fase getrokken mag worden.

Jij probeert het zonder communicatie te doen (zonder CP signaal) en dus is 10A per fase de max.

afhankelijk van de laadpaal doet ie het gewoon, of gaat ie in storing. edit: dit zal bij de kabels vanvoldt ook zo zijn..

[ngommers]

Sinds maart heb ik mijn SmartEVSE verbonden met tap, werkte perfect.
Tot ik problemen kreeg dat hij de verbinding kwijt was, ik las toen hier dat ik naar WS: moest ipv WSS:.

Inmiddels draai ik op versie 3.11.0 en heb nog steeds dat de verbinding (via Wifi) met tap instabiel is op zowel WS als WSS. Meer personen hier last van? en iemand een tip waar ik nog naar kan kijken?

[THM0]

ngommers schreef op woensdag 24 juni 2026 @ 19:39:
Sinds maart heb ik mijn SmartEVSE verbonden met tap, werkte perfect.
Tot ik problemen kreeg dat hij de verbinding kwijt was, ik las toen hier dat ik naar WS: moest ipv WSS:.

Inmiddels draai ik op versie 3.11.0 en heb nog steeds dat de verbinding (via Wifi) met tap instabiel is op zowel WS als WSS. Meer personen hier last van? en iemand een tip waar ik nog naar kan kijken?

Bij mij is het hartstikke stabiel over wifi naar het wss endpoint, op firmware 3.11.0.

[CyberEspresso]

ngommers schreef op woensdag 24 juni 2026 @ 19:39:
Inmiddels draai ik op versie 3.11.0 en heb nog steeds dat de verbinding (via Wifi) met tap instabiel is op zowel WS als WSS. Meer personen hier last van? en iemand een tip waar ik nog naar kan kijken?

Ja, hier hetzelfde. De wifi verbinding op zichzelf is stabiel, dat kan ik zien aan de data die ik van de Smartevse binnenkrijg op HomeAssistant. Op diezelfde HomeAssistant is er een sensor voor de OCPP koppeling die continue van connected naar disconnected en weer terug springt. Met gevolg dat de auto op random momenten niet wil laden omdat er dan een RFID swipe nodig is, terwijl er normaal gesproken een auto-authorize plaatsvindt.

[ngommers]

CyberEspresso schreef op woensdag 24 juni 2026 @ 20:49:
[...]

Ja, hier hetzelfde. De wifi verbinding op zichzelf is stabiel, dat kan ik zien aan de data die ik van de Smartevse binnenkrijg op HomeAssistant. Op diezelfde HomeAssistant is er een sensor voor de OCPP koppeling die continue van connected naar disconnected en weer terug springt. Met gevolg dat de auto op random momenten niet wil laden omdat er dan een RFID swipe nodig is, terwijl er normaal gesproken een auto-authorize plaatsvindt.

exact dit heb ik inderdaad

[dingo35]

Ik wacht nog even op een reactie van @stegen op mijn laatste wijziging, dan zal ik een nieuwe release uitbrengen waarin ook de OCPP messages in de telnet debug log te zien zijn; hopelijk geeft dat meer duidelijkheid.

Voor de volledigheid: mijn wifi verbinding is tegenwoordig niet optimaal, ik heb het idee dat de access points van een aantal buren en de mijne aan het vechten zijn om beschikbare kanalen, maar desalniettemin heb ik nog nooit een gemiste auto-authorize gehad.

Beetje lastig foutzoeken als ik het niet kan reproduceren...

[dingo35]

@ngommers @CyberEspresso Is jullie koppeling met HA via MQTT? Je zou ook eens het MQTT topic kunnen checken dat meldt of de SmartEVSE qua MQTT offline/online is, dat is op een wat hoger netwerk-niveau dan de wifi verbinding

[CyberEspresso]

dingo35 schreef op donderdag 25 juni 2026 @ 06:39:
@ngommers @CyberEspresso Is jullie koppeling met HA via MQTT? Je zou ook eens het MQTT topic kunnen checken dat meldt of de SmartEVSE qua MQTT offline/online is, dat is op een wat hoger netwerk-niveau dan de wifi verbinding

Ja, inderdaad via MQTT. De MQTT verbinding wordt zelf niet verbroken. De SmartEVSE meldt via MQTT wel netjes dat de verbinding met OCPP disconnect en weer connect. Draai versie v3.11.0 en heb de verbinding met tap nu op WS staan in plaats van WSS omdat ik dacht dat dat wellicht stabieler zou zijn, maar lijkt niet heel veel uit te maken. Overigens had ik dit probleem de afgelopen 4 dagen continue, sinds gisteren gaat het weer goed en daarvoor ging het ook een tijdje prima. Ik sluit ook niet uit dat de problemen aan de kant van TAP zitten. Om dit hele probleem te omzeilen heb ik liever helemaal geen OCPP, maar je moet wat voor je ERE credits. Ik overweeg nog een lokale OCPP proxy op te tuigen om het verder te troubleshooten, maar daar moet ik even tijd voor maken.

[DanTm]

Mijn auto wou net ook niet laden omdat de auto-authorize niet werkte. Ik heb de OCPP verbinding uit en weer aan gezet, en daarna ging het wel goed.

Ik zag in het dashboard van Tap dat hij al enige tijd stond te switchen tussen online/offline (paar minuten online, paar minute offline). De wifi verbinding is stabiel.

Heb dit al een paar keer eerder gehad, maar of het nu aan Tap of de smartevse ligt kan ik ook niet helemaal beoordelen. Wat wel apart is dat na het aan en uitzetten van OCPP het wel weer stabiel lijkt te zijn.

[DanTm]

dingo35 schreef op donderdag 25 juni 2026 @ 06:39:
@ngommers @CyberEspresso Is jullie koppeling met HA via MQTT? Je zou ook eens het MQTT topic kunnen checken dat meldt of de SmartEVSE qua MQTT offline/online is, dat is op een wat hoger netwerk-niveau dan de wifi verbinding

Bij mij blijft de SmartEvse zelf prima online.

Ik heb in de log van Home Assistant gekeken en zie dat de OCPPConnection status al wel 4 dagen lang aan en uit ging (paar minuten aan, paar minuten uit).

[adjego]

Ik ervaar bovenstaande ook met SmartEvse v3.11.0 en TapElectric in samenwerking met MQTT connectie met de SmartEvse. Er ontstaat op een gegeven moment iets geks, en daar komt de connectie met Tap niet meer te boven. Reboot van de SmartEvse lost het altijd op voor een hoeveelheid dagen.

[ Voor 13% gewijzigd door adjego op 25-06-2026 10:07 ]

[CyberEspresso]

adjego schreef op donderdag 25 juni 2026 @ 10:02:
Reboot van de SmartEvse lost het altijd op voor een hoeveelheid dagen.

Nu ik erover nadenk is bij mij de stabiliteit van de OCPP verbinding inderdaad ook weer teruggekomen na een reboot.

[dingo35]

Kijk eens bij Tap Electric, lader, geavanceerde settings, Heartbeatinterval; die staat bij mij op 900.

Volgens Claude moet StaleTimeout in de door ons gebruikte MicroOcppMongoose library groter zijn dan de heartbeat interval; StaleTimeout staat default op 300, dus:

A) wissel hier uit op hoeveel je heartbeatinterval staat, en

B) Zet m eens op 150 om te kijken of dat helpt.

Naar mijn ervaring heeft AI hetzelfde niveau als een stagiaire, soms heel goed, maar nooit betrouwbaar.

Het verklaart niet waarom de boel na een reboot weer stabiel is...

[benthouse]

dingo35 schreef op donderdag 25 juni 2026 @ 10:47:
Kijk eens bij Tap Electric, lader, geavanceerde settings, Heartbeatinterval; die staat bij mij op 900.

Volgens Claude moet StaleTimeout in de door ons gebruikte MicroOcppMongoose library groter zijn dan de heartbeat interval; StaleTimeout staat default op 300, dus:

A) wissel hier uit op hoeveel je heartbeatinterval staat, en

B) Zet m eens op 150 om te kijken of dat helpt.

Naar mijn ervaring heeft AI hetzelfde niveau als een stagiaire, soms heel goed, maar nooit betrouwbaar.

Het verklaart niet waarom de boel na een reboot weer stabiel is...

Allen, nu wil ik mijzelf niet onder de 'domme' mensen scharen maar wat hier rond gaat is abracadabra voor mij :-)

Is er ergens een duidelijke 'handleiding' of stappenplan om de EVSE voor OCPP te koppelen aan Road/E-flux.

Ik heb daarnaast een extra kWh meter besteld (Eastron SDM54-M MID, slechts 54mm breed ipv 72, ik worstel met ruimte) die ik binnekort in het kastje van de EVSE ga plaatsen. Dan moet eea ook gereed zijn voor ERE in mijn beleving omdat dan alles echt in 1 behuizing zit. Heb nu ook al een Eastron kWh meter maar die zit in de onderverdeler (is wel dedicated voor de EVSE maar kan dat onvoldoende aantonen voor ERE, dus maar even wat extra geld er tegenaan gegooid....).



De klemmen links onderin ga ik vervangen voor de Eastron kWh meter, gehele rail gaat stukje naar beneden voor extra ruimte.

Iemand dus een stappenplan voor OCPP backbone via E-flux? (ik heb reeds 2 tags voor onze auto's voor registratie / afhandeling bij openbare laadpalen).

gr. Benthouse

[DanTm]

dingo35 schreef op donderdag 25 juni 2026 @ 10:47:
Kijk eens bij Tap Electric, lader, geavanceerde settings, Heartbeatinterval; die staat bij mij op 900.

Volgens Claude moet StaleTimeout in de door ons gebruikte MicroOcppMongoose library groter zijn dan de heartbeat interval; StaleTimeout staat default op 300, dus:

A) wissel hier uit op hoeveel je heartbeatinterval staat, en

B) Zet m eens op 150 om te kijken of dat helpt.

Naar mijn ervaring heeft AI hetzelfde niveau als een stagiaire, soms heel goed, maar nooit betrouwbaar.

Het verklaart niet waarom de boel na een reboot weer stabiel is...

die van mij stond ook op 900, nu op 200 gezet

en een notificatie in HA aangemaakt als de state van de OCPP connectie wijzigd

[ Voor 5% gewijzigd door DanTm op 25-06-2026 12:26 ]

[sjoerd-p]

benthouse schreef op donderdag 25 juni 2026 @ 11:21:
[...]

Ik heb daarnaast een extra kWh meter besteld (Eastron SDM54-M MID, slechts 54mm breed ipv 72, ik worstel met ruimte) die ik binnekort in het kastje van de EVSE ga plaatsen.

Deze kast lijkt echt héél veel groter dan de New Motion paal die ik heb hergebruikt en daar past alles met gemak in, inclusief de 72mm brede MID meter. Ik begrijp ook niet waarom je zoveel klemmen hebt, want eigenlijk heb je er maar vijf smalle nodig: 3P+N+aarde. Of eigenlijk maar drie: 1P+N+aarde, want de andere fases kun je gewoon rechtstreeks van apparaat naar apparaat doorverbinden i.p.v. via een klem, want die hoeven niet gesplitst.

Bij mij past dat precies in de breedte van de New Motion laadpaal samen met een 4Din MID meter en met de normale contactor én de extra contactor voor fase 2+3. Dan heb ik op een DIN rail erboven nog de SmartEVSE zelf zitten. Ik heb dus het idee dat je heel veel ruimte kunt winnen door alles even net wat handiger in te delen en vooral héél veel minder klemmen te gebruiken. En mijn DC beveiliging zit niet op de DIN rail, maar erachter. Scheelt ook weer ruimte. De kast is er diep genoeg voor.



Inmiddels is alles nog even wat netter bedraad, maar je kunt uit bovenstaande foto zien dat er nog heel wat ruimte te winnen valt bij jou om toch een normale meter te kunnen plaatsen.

Met je andere problemen kan ik je helaas niet helpen. Ik heb een verbinding met Tap via OCPP en dat werkt gewoon gelukkig.

[adjego]

dingo35 schreef op donderdag 25 juni 2026 @ 10:47:
Kijk eens bij Tap Electric, lader, geavanceerde settings, Heartbeatinterval; die staat bij mij op 900.

Volgens Claude moet StaleTimeout in de door ons gebruikte MicroOcppMongoose library groter zijn dan de heartbeat interval; StaleTimeout staat default op 300, dus:

A) wissel hier uit op hoeveel je heartbeatinterval staat, en

B) Zet m eens op 150 om te kijken of dat helpt.

Naar mijn ervaring heeft AI hetzelfde niveau als een stagiaire, soms heel goed, maar nooit betrouwbaar.

Het verklaart niet waarom de boel na een reboot weer stabiel is...

Veranderd van 900 naar 200. Als ik kijk naar de heartbeat berichten zie ik hem daar niet veranderen naar 200

[Elissen]

sjoerd-p schreef op donderdag 25 juni 2026 @ 12:21:
[...]

Deze kast lijkt echt héél veel groter dan de New Motion paal die ik heb hergebruikt en daar past alles met gemak in, inclusief de 72mm brede MID meter. Ik begrijp ook niet waarom je zoveel klemmen hebt, want eigenlijk heb je er maar vijf smalle nodig: 3P+N+aarde. Of eigenlijk maar drie: 1P+N+aarde, want de andere fases kun je gewoon rechtstreeks van apparaat naar apparaat doorverbinden i.p.v. via een klem, want die hoeven niet gesplitst.

Bij mij past dat precies in de breedte van de New Motion laadpaal samen met een 4Din MID meter en met de normale contactor én de extra contactor voor fase 2+3. Dan heb ik op een DIN rail erboven nog de SmartEVSE zelf zitten. Ik heb dus het idee dat je heel veel ruimte kunt winnen door alles even net wat handiger in te delen en vooral héél veel minder klemmen te gebruiken. En mijn DC beveiliging zit niet op de DIN rail, maar erachter. Scheelt ook weer ruimte. De kast is er diep genoeg voor.

[Afbeelding]

Inmiddels is alles nog even wat netter bedraad, maar je kunt uit bovenstaande foto zien dat er nog heel wat ruimte te winnen valt bij jou om toch een normale meter te kunnen plaatsen.

Met je andere problemen kan ik je helaas niet helpen. Ik heb een verbinding met Tap via OCPP en dat werkt gewoon gelukkig.

Ik heb mijn Newmotion laadpaal op exact deze manier ook omgebouwd, maar met dit warme weer schiet nu de temperatuur bescherming er op dat die gewoon te warm wordt. Ik denk dat het plaatsen van een ventilator ook niet gaat helpen; het is een gesloten kast. Heb jij (of iemand anders) hier toevallig ideeën voor?

Error: Temperature High
Temp: 62 °C / 65 °C

[m.eddy]

benthouse schreef op donderdag 25 juni 2026 @ 11:21:
[...]

Allen, nu wil ik mijzelf niet onder de 'domme' mensen scharen maar wat hier rond gaat is abracadabra voor mij :-)

Is er ergens een duidelijke 'handleiding' of stappenplan om de EVSE voor OCPP te koppelen aan Road/E-flux.

Ik heb daarnaast een extra kWh meter besteld (Eastron SDM54-M MID, slechts 54mm breed ipv 72, ik worstel met ruimte) die ik binnekort in het kastje van de EVSE ga plaatsen. Dan moet eea ook gereed zijn voor ERE in mijn beleving omdat dan alles echt in 1 behuizing zit. Heb nu ook al een Eastron kWh meter maar die zit in de onderverdeler (is wel dedicated voor de EVSE maar kan dat onvoldoende aantonen voor ERE, dus maar even wat extra geld er tegenaan gegooid....).

[Afbeelding]

De klemmen links onderin ga ik vervangen voor de Eastron kWh meter, gehele rail gaat stukje naar beneden voor extra ruimte.

Iemand dus een stappenplan voor OCPP backbone via E-flux? (ik heb reeds 2 tags voor onze auto's voor registratie / afhandeling bij openbare laadpalen).

gr. Benthouse

1 Abbo afsluiten.

2 Daarna in de chat vragen hoe je de smartevse aan kunt melden.

[RonJ]

Elissen schreef op donderdag 25 juni 2026 @ 13:41:
[...]

Ik heb mijn Newmotion laadpaal op exact deze manier ook omgebouwd, maar met dit warme weer schiet nu de temperatuur bescherming er op dat die gewoon te warm wordt. Ik denk dat het plaatsen van een ventilator ook niet gaat helpen; het is een gesloten kast. Heb jij (of iemand anders) hier toevallig ideeën voor?


[...]

Is het een witte? Of antraciet? Die laatste zou je wit kunnen spuiten, dat scheelt nogal. Of er op een andere manier schaduw op creeeren met een dakje oid. Het enige andere dat ik zo kan bedenken is de EVSE op de onderste rail plaatsen. Je wil zeker niet gaan ventileren, want dat betekent ook vocht, insecten, etc. en dat gaat vroeg of laat fout.

[DanTm]

Elissen schreef op donderdag 25 juni 2026 @ 13:41:
[...]

Ik heb mijn Newmotion laadpaal op exact deze manier ook omgebouwd, maar met dit warme weer schiet nu de temperatuur bescherming er op dat die gewoon te warm wordt. Ik denk dat het plaatsen van een ventilator ook niet gaat helpen; het is een gesloten kast. Heb jij (of iemand anders) hier toevallig ideeën voor?


[...]

ik heb de max temp op 70 gezet.. als het heel warm is en de zon staat erop te branden wil die van mij ook wel eens erg warm worden.

[Martijn02]

Ik heb ook last van de high-temp-error state..

Mijn SmartEVSE zit in een zwarte evhub kast, die vanaf een uur of 1 tot 's avonds in de zon hangt.

Gisteren is het laden om 15:30 gestopt omdat de temperatuur de 65 graden overschreed, maar ook daarna stijgt de temperatuur nog door tot een piek van 73 graden zo rond 18:30. Pas rond 21:00 is de temp weer gezakt tot onder de 55 graden.

Met de MID meter erbij zit de kast ook bestwel heel erg vol, dus er is niet echt ruimte om de verschillende componenten een stukje uit elkaar te zetten.



Morgen misschien eens proberen of het verschil maakt als ik een witte kussensloop over de kast hang. Verder zie ik niet echt opties om dit op te lossen. Ben een beetje huiverig om de max temp te verhogen, en een witte kast op die donkere muur is ook geen mooi gezicht.

Mogelijk dat ik de smartevse naar links breng op de rails.. (dat ik de klemmenstrook en MID-meter wat naar rechts schuif om ruimte te maken) Dan zit de SmartEVSE in ieder geval niet tegen de relais aan (die ook best wat warmte afgeeft)

[ Voor 13% gewijzigd door Martijn02 op 25-06-2026 15:17 ]

[Frankyy]

Mijn newmotion paal werd ook een beetje warm, mag ook wel als die de hele dag in de zon staat.
10eu een witte kap op de kop getikt . Of het echt effectief is moet nog blijken.

[ Voor 5% gewijzigd door Frankyy op 25-06-2026 21:56 ]

[dingo35]

Een van de twee firmware bouwers van de serkri repo had de max temp al jaren op 70C gezet, zonder problemen, zover ik weet.

Ik stond er op t instelbaar te maken omdat mijn EVSE binnen hangt, en als die 70C bereikt dan is er écht iets fout...

[ Voor 33% gewijzigd door dingo35 op 25-06-2026 16:41 ]

[Elissen]

Ik heb inderdaad een antracieten kap, om die wit te gaan spuiten dat staat niet op een donkere muur. Ik heb de max temp maar even op 70 gezet. Hopelijk lost het probleem zich ook volgende week zelf weer op 😁

[Conrado]

Mijn auto wil nog steeds niet herstarten met laden nadat de EVSE het laden heeft stopgezet in Solar-mode, en geeft een Laden onderbroken-fout. Toevallig kwam ik op een ander forum juist het verhaal tegen dat iemand solar laadt met een andere laadbox. Het lijkt dus wel te werken.

Ik wil daarom de sessie debuggen, en probeerde de EVSE via Telnet (poort 23) te benaderen. Maar die sessie werd niet geaccepteerd. Wat doe ik verkeerd?

[Solarsparc]

Conrado schreef op donderdag 25 juni 2026 @ 23:19:
Ik wil daarom de sessie debuggen, en probeerde de EVSE via Telnet (poort 23) te benaderen. Maar die sessie werd niet geaccepteerd. Wat doe ik verkeerd?

Wel even debug-versie van de firmware installeren als je dat niet al gedaan had.

[sjoerd-p]

Elissen schreef op donderdag 25 juni 2026 @ 13:41:
[...]

Ik heb mijn Newmotion laadpaal op exact deze manier ook omgebouwd, maar met dit warme weer schiet nu de temperatuur bescherming er op dat die gewoon te warm wordt. Ik denk dat het plaatsen van een ventilator ook niet gaat helpen; het is een gesloten kast. Heb jij (of iemand anders) hier toevallig ideeën voor?


[...]

Deze hele hete temperaturen komen niet heel vaak voor. Ik heb een groene kast en die wordt ook te warm. Mijn oplossing was een handdoek erover en even nat maken. Dat werkte uitstekend. Voelt een beetje gek om water over een lader te gooien, maar hij kan ook in de regen staan



Mijn auto rijdt nu dus op Water-Stof (handdoek)

[ Voor 19% gewijzigd door sjoerd-p op 26-06-2026 08:55 ]

[Bontje Blauw]

Haha, maar verdamping ontrekt warmte inderdaad. Slim!

Hier op dit moment in de volle zon en ruim 31 graden -> 59 °C / 60 °C. Heb deze week 1 moment stopzetting gehad. Nu maar weer op default 65C gezet. Mijn Newmotion Lolo paadpaal is antraciet RAL 7021.
Wel heb ik de MID meter tussen de relais en de Smart EVSE zitten, maar alles zit wel strak tegen elkaar aan.

[ Voor 7% gewijzigd door Bontje Blauw op 26-06-2026 13:09 ]

[ocaj]

Langzamer laden wil ook wel helpen, dus zet hem even op 3x6A ipv 3x16A. Scheelt aardig wat warmteproductie.

[sjoerd-p]

ocaj schreef op vrijdag 26 juni 2026 @ 22:12:
Langzamer laden wil ook wel helpen, dus zet hem even op 3x6A ipv 3x16A. Scheelt aardig wat warmteproductie.

Maar met een dynamisch contact wil ik zoveel mogelijk laden in de goedkoopste uren 😅. Dat zal veranderen zodra salderen stopt. Dan is het langzaam laden op Solar overschot.

[dingo35]

Voor alle SmartEVSE gebruikers, zojuist release v3.11.1 uitgebracht:

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


WARNING:

If you have sub-panel configuration, your EVMeter was used to guard MaxCircuit. Since version v3.11.0 a separate CircuitMeter can be defined, and THAT meter is used to guard MaxCircuit. EVMeter then will be used what it was intended for, to measure the number of kWh that goes into your EV.So if you have sub-panel (garage-) configuration, reconfigure your current EVMeter to the new CircuitMeter!!IF YOU DONT CHANGE THIS YOUR MAXCIRCUIT WILL NO LONGER BE GUARDED!!!


Improvements

• esp32.cpp: fix delayed charging with OCPP
• Generalized support for networked meters and expanded HomeWizard support (#372) -thx Racquemis
• platformio.ini, esp32.cpp: send OCPP debug messages to telnet if DBG==1
• add discovery topic for /StateID - thx Demerstraat
• docs: improve home battery API info
• docs: update feeding power and energy mainsmeter values via MQTT API
• give CircuitMeter its own TIMEOUT and increase it from 11s to 20s since on modbus its too slow sometimes
• esp32.cpp: show CircuitMeter timeout in debug message

BugFixes

• main.cpp: Fix energy meter polling in ModbusRequestLoop
• show the Websocket failed error only when the SmartEVSE is offline, not when the browser tab is hibernating.
• Lcd via websocket - reconnect when tab is back in focus.
• index.html: also refresh stale statuspage when tab is back in focus
• power_day: stream JSON via HTTP chunked encoding
• Change mbedtls context size to 8kb in, 4kb out
• glcd: use static ram buffer for the web-LCD
• esp32, network_common: major heap-fragmentation & flash cleanup
• esp32.cpp: fix JSON response on /currents and /ev_meter endpoints
• update2.html: smaller upload chunk
• esp32.cpp: fix mojibake in temperature
• etherlcd.cpp: make sure to check spi_device_acquire_bus() lock status
• fix v4 bug
• Replace localtime() with thread-safe localtime_r()
• esp32.cpp: get rid of settingsCache because most of NVS's page is already in RAM
• esp32.cpp: reduce OCPP MaxCurrent overhead
• esp32.cpp: set MaxSumMains to 0 when CapacityMode is disabled
• feed_circuit.sh: send every 2s instead of 5

[rvdgaag]

dingo35 schreef op zaterdag 27 juni 2026 @ 08:29:
Voor alle SmartEVSE gebruikers, zojuist release v3.11.1 uitgebracht:

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

Zonet op bij laadpunten geladen, bedankt weer voor je inspanningen voor dit mooie product !

[Geim]

Zie: download: SmartEVSE 3.11.1

[Hmmbob]

Geim schreef op zaterdag 27 juni 2026 @ 14:36:
Zie: download: SmartEVSE 3.11.1

Zie: 2 posts boven je

[Alwik]

martijn_van_eck schreef op dinsdag 23 juni 2026 @ 21:39:
Het lijkt erop dat Tibber de stekker eruit heeft getrokken voor onze smartevse koppeling. Laadpaal is niet meer zichtbaar in de app

Ja, ik heb hetzelfde net gemerkt... :/
Zijn er alternatieve methodes bekend? Als ik hem probeer opnieuw aan te maken moet ik nu inloggen in een niet-bestaand myenergi account...

[martijn_van_eck]

Alwik schreef op zaterdag 27 juni 2026 @ 20:56:
[...]

Ja, ik heb hetzelfde net gemerkt... :/
Zijn er alternatieve methodes bekend? Als ik hem probeer opnieuw aan te maken moet ik nu inloggen in een niet-bestaand myenergi account...

Nee er zijn geen andere mogelijkheden bij Tibber. Volgens mij lopen al hun nieuwe api’s via Enode. Ik heb zelf nu maar EVCC geïnstalleerd op mij NAS om het laadplan te maken. Werkt prima, alleen geen grid rewards.

[Geim]

Hmmbob schreef op zaterdag 27 juni 2026 @ 19:05:
[...]

Zie: 2 posts boven je

Ik plaatste ter aanvulling een link naar het Tweakers artikel.

[Hmmbob]

Geim schreef op zondag 28 juni 2026 @ 07:05:
[...]

Ik plaatste ter aanvulling een link naar het Tweakers artikel.

Dat zagen we. Je mist blijkbaar het punt dat dat 0 toegevoegde waarde had, omdat de maintainer 2 posts eerder dezelfde informatie had geplaatst.

Anyways....

[Martijn02]

sjoerd-p schreef op vrijdag 26 juni 2026 @ 08:49:
[...]

Deze hele hete temperaturen komen niet heel vaak voor. Ik heb een groene kast en die wordt ook te warm. Mijn oplossing was een handdoek erover en even nat maken. Dat werkte uitstekend. Voelt een beetje gek om water over een lader te gooien, maar hij kan ook in de regen staan

[Afbeelding]

Mijn auto rijdt nu dus op Water-Stof (handdoek)

Ik heb vrijdagmiddag hetzelfde gedaan:



Dat werkt echt als een tierelier! scheelt zo 10 graden op de ESP in de brandende middagzon.

[sjoerd-p]

dingo35 schreef op zaterdag 27 juni 2026 @ 08:29:
Voor alle SmartEVSE gebruikers, zojuist release v3.11.1 uitgebracht:

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

Fijn dat jullie zo actief blijven doorontwikkelen!

En even een feature request (of uitleg waarom dit een dom idee zou zijn ): Een aantal van ons hebben de lader via OCPP aan een backend gekoppeld. Als nu mijn Wifi ontvangst even niet goed is of er is iets anders niet goed met de OCPP koppeling, kan ik ook niet laden. Zou het mogelijk zijn om de laadsessie wel te starten met de laadpas (desnoods na twee keer aanbieden van dezelfde pas als teken dat je wilt overrulen) en dat hij de sessie lokaal opslaat en later alsnog via OCPP doorstuurt? Het risico bestaat op zo'n moment dat iemand probeert te laden met een nietbestaande pas waardoor je niet uitbetaald krijgt, maar dat is dan maar het risico. OCPP kent de concepten offline laden en fallback. Eventueel zou je zelfs alleen de RFID whitelist toe kunnen staan in offline modus.

Wat lost dit op? Laadpaal kan ALTIJD gestart worden, ook als OCPP even niet werkt. De laadsessie wordt dan later gesynct met de backend provider via OCPP, dus je verrekening of ERE registratie heeft dan geen gat. En voor leaserijders krijg je dan later alsnog je vergoeding voor de laadsessie die offline gedraaid heeft.

OCPP ondersteunt dit al, dus de grootste uitdaging is een nette offline cache maken en zodra je online komt weer syncen via OCPP? Best een flinke klus lijkt me, maar zorgt er wel voor dat je altijd kunt laden als dat nodig is. Nu al twee keer gehad dat ik niet kon laden (één keer lag Odido internet eruit en één keer de TAP OCPP koppeling).

Relevante toevoeging?

[dingo35]

Interessant idee; ik heb de OCPP stack niet zelf ontwikkeld, zo te zien heb jij er meer verstand van; PR?

P.S: Geen AI vibe-coding aub

[ Voor 13% gewijzigd door dingo35 op 29-06-2026 11:51 ]

[sjoerd-p]

dingo35 schreef op maandag 29 juni 2026 @ 11:50:
Interessant idee; ik heb de OCPP stack niet zelf ontwikkeld, zo te zien heb jij er meer verstand van; PR?

P.S: Geen AI vibe-coding aub

Ik ben helaas geen programmeur. Kan dus alleen bijdragen aan de mogelijkheden die OCPP kan bieden en hoe zo'n CPR dan tijdelijk opgeslagen moet worden en later afgeleverd moet worden. Ik hobby wel regelmatig met ESP32's, maar mijn code skills (al dan niet met hulp van AI) halen echt de kwaliteit niet die nodig is voor een mooie code base zoals SmartEVSE.

Als je op deze pagina op "offline" zoekt, zie je al wat voorbeelden. Offline ondersteuning zit al in OCPP 1.6 (dus upgrade naar 2.0 is niet nodig): Open Charge Point Protocol

Op deze pagina staat uitleg van OCPP en welke velden en authenticatie logic je dan moet toepassen. Zoek specifiek even op het stukje "Authorization Flow". Waar dus een andere flow nodig is om ook offline toe te staan. Daar staat ook dat je in kunt stellen of je wel of niet onbekende RFID's wil toe staan en zo.

Wellicht dat er iemand anders op basis van dit idee kan inschatten of het haalbaar is en kan bijdragen? Er zijn andere merken die dit al succesvol geïmplementeerd hebben en OCPP ondersteunt het. Maar ik kan niet inschatten hoe complex het is dit toe te voegen. Nuttig lijkt het me wel, want beschikbaarheid is bij een laadpaal toch wel het belangrijkste punt!

[ Voor 23% gewijzigd door sjoerd-p op 29-06-2026 12:12 ]

[benthouse]

sjoerd-p schreef op donderdag 25 juni 2026 @ 12:21:
[...]

Deze kast lijkt echt héél veel groter dan de New Motion paal die ik heb hergebruikt en daar past alles met gemak in, inclusief de 72mm brede MID meter. Ik begrijp ook niet waarom je zoveel klemmen hebt, want eigenlijk heb je er maar vijf smalle nodig: 3P+N+aarde. Of eigenlijk maar drie: 1P+N+aarde, want de andere fases kun je gewoon rechtstreeks van apparaat naar apparaat doorverbinden i.p.v. via een klem, want die hoeven niet gesplitst.

Bij mij past dat precies in de breedte van de New Motion laadpaal samen met een 4Din MID meter en met de normale contactor én de extra contactor voor fase 2+3. Dan heb ik op een DIN rail erboven nog de SmartEVSE zelf zitten. Ik heb dus het idee dat je heel veel ruimte kunt winnen door alles even net wat handiger in te delen en vooral héél veel minder klemmen te gebruiken. En mijn DC beveiliging zit niet op de DIN rail, maar erachter. Scheelt ook weer ruimte. De kast is er diep genoeg voor.

[Afbeelding]

Inmiddels is alles nog even wat netter bedraad, maar je kunt uit bovenstaande foto zien dat er nog heel wat ruimte te winnen valt bij jou om toch een normale meter te kunnen plaatsen.

Met je andere problemen kan ik je helaas niet helpen. Ik heb een verbinding met Tap via OCPP en dat werkt gewoon gelukkig.

Ik had het RVS kastje beschikbaar, ben geschoold als elektromonteur, dat maakt dat ik eea in het kastje gemaakt heb ipv in een oude laadpaal (die ik zowiezo niet beschikbaar had). Daarnaast wilde ik MODBUS en TCP-IP verbinding over 1 kabeltje gooien, vandaar het groene printje met de RJ-45 connector erop.

Inmiddels hangt de EVSE ook via de ombouwkit bekabeld aan het netwerk, is toch beter te vertrouwen dan de WiFi verbinding.

De klemmen aan de linkerzijde gaan eruit, daar komt straks de smallere kWh meter. De klemmen voor de afgaande bedrading naar de auto laat ik vooralsnog zitten. In basis hou ik ervan om de interne bedrading in het kastje te splitsen van bedrading die naar buiten gaat, vandaar de klemmenstrook. Op die wijze blijft alles overzichtelijk.

Zodra ik eea erin gemaakt heb zal ik foto posten. :-)

[sjoerd-p]

benthouse schreef op maandag 29 juni 2026 @ 14:16:
[...]

Inmiddels hangt de EVSE ook via de ombouwkit bekabeld aan het netwerk, is toch beter te vertrouwen dan de WiFi verbinding.

Dit ken ik nog niet! Hoe werkt dat? Misschien voor mij ook handig. En dan moet ik ook de 8 aderige UTP kabel gaan misbruiken om via 4 aders ethernet en via de andere aders modbus te transporteren.... Maar lijkt me wel vet handig, want Wifi gaat niet altijd goed en vervelend als daardoor een OCPP sessie niet lukt en je de auto dus niet kunt laden.

Inmiddels gevonden! Upgrade kit

[ Voor 9% gewijzigd door sjoerd-p op 29-06-2026 15:27 ]

[adjego]

adjego schreef op donderdag 25 juni 2026 @ 10:02:
Ik ervaar bovenstaande ook met SmartEvse v3.11.0 en TapElectric in samenwerking met MQTT connectie met de SmartEvse. Er ontstaat op een gegeven moment iets geks, en daar komt de connectie met Tap niet meer te boven. Reboot van de SmartEvse lost het altijd op voor een hoeveelheid dagen.

[Afbeelding]

adjego schreef op donderdag 25 juni 2026 @ 13:00:
[...]

Veranderd van 900 naar 200. Als ik kijk naar de heartbeat berichten zie ik hem daar niet veranderen naar 200

Even voor de goede orde, mijn laadpaal is nog steeds up sinds 23 juni bij TapElectric.

[dingo35]

Het hangt er vanaf waar je naar kijkt: ik heb nog geen enkele verhinderde of verstoorde laadsessie met Tap gehad; ook heeft de ERE registratie nog geen enkele laadsessie gemist.

Maar als ik naar de uptime op de Tap Electric website kijk, zie ik vele online/offline schakelingen; idem als ik via MQTT de OCPP connected sensor in HomeAssistant uitlees.

Ook de fabrikant (Stegen) ziet dit gedrag in zijn test bank inmiddels, dus we zijn aan het zoeken waar dit door komt.

Interessant daarbij is de melding van een gebruiker die het online/offline schakelen niet alleen bij zijn SmaelrtEVSE ziet, maar ook bij zijn andere merk laadpaal; dat suggereert dat t probleem bij Tap ligt.

[Adze]

dingo35 schreef op dinsdag 30 juni 2026 @ 07:48:
Het hangt er vanaf waar je naar kijkt: ik heb nog geen enkele verhinderde of verstoorde laadsessie met Tap gehad; ook heeft de ERE registratie nog geen enkele laadsessie gemist.

Maar als ik naar de uptime op de Tap Electric website kijk, zie ik vele online/offline schakelingen; idem als ik via MQTT de OCPP connected sensor in HomeAssistant uitlees.

Ook de fabrikant (Stegen) ziet dit gedrag in zijn test bank inmiddels, dus we zijn aan het zoeken waar dit door komt.

Interessant daarbij is de melding van een gebruiker die het online/offline schakelen niet alleen bij zijn SmaelrtEVSE ziet, maar ook bij zijn andere merk laadpaal; dat suggereert dat t probleem bij Tap ligt.

Ik ben ook al heel lang aan het stoeien met Tap en OCPP uptime. Maar sinds ik plugchoice tussen beide heb gezet is voor mij opgelost. Wel krijg ik nog steeds offline meldingen in Tap dashboard, maar vroeger kwam het nog wel eens voor dat de OCPP sessie niet meer terug kwam. Met Plugchoice ertussen is dat volledig verdwenen.

Misschien niet de mooiste oplossing, maar voor mij prima.

[Chris96]

jjonkie schreef op woensdag 17 juni 2026 @ 12:19:
Ik heb mijn Smart Evse een poosje aan TAP gehad met OCCP, is niet betrouwbaar. Werkt niet altijd en mijn vrouw snapt er niks van. Tevens zie ik geen kWh maar dat komt omdat mijn meter van Homewizard niets uitstuurt dus die moet ik vervangen helaas. Maar dan zit ik nog steeds met bovenstaande probleem. Heeft iemand dit al wel netjes werkend? Anders kan ik me het geld en gedoe beter besparen...

Ik heb dit netjes werkend bij tap met een ABB kWh meter, Tevens ook bij joulo!

[dingo35]

Ik heb, geheel tegen mijn gewoonte, de NIET debug versie v3.11.1 (dus de "standaard" versie) geflashed en die is sindsdien onafgebroken met Tap verbonden; het lijkt erop dat het telnet/debug gedeelte teveel resources verbruikt of op een andere manier de verbinding verstoort...

[ Voor 21% gewijzigd door dingo35 op 01-07-2026 07:24 ]

[RonJ]

Gewoon even ter bevestiging, ik heb met de reguliere 3.11.1 (en .0) geen disconnects met TAP.

[jpiscaer]

dingo35 schreef op woensdag 17 juni 2026 @ 23:34:
Als je OCPP aan zet en je autoriseert je eigen sessie niet, dan krijg je "available" op je LCD scherm (in geval van auto-authorize) of "please authorize" (met RFID reader op Rmt/OCPP of disabled) en OFF op je dashboard. Als je dan autoriseert krijg je de mode waar je in zat (dus VOORdat je autoriseert), zoals je gewend was het bekende Ready scherm, al dan niet met zonnetje.

Als je problemen hebt met je backendprovider, maak dan een gratis account bij Tap Electric aan, koppel daar aan, dan zie je hoe het behoort te werken, en kun je na die leerfase overstappen maar je favoriete backend, dan weet je (beter) hoe te configureren en welke acties/schermen je kunt verwachten.


Ik heb twee jaar geleden met veel OCPP providers getest op een jaarlijks test-event, en daar kwamen we glansrijk doorheen (niet mijn verdienste), alleen Joulo had een probleem met hun specifieke serverconfiguratie, verder zijn mij geen incompatibiliteiten bekend.

Denk dat ik net even een gedachtegang mis om dit te snappen..

Ik heb m'n SmartEVSE ingesteld met OCPP (naar SteVe), met auto authorize ingesteld op een tag die 'ocpp' heet. Deze tag is bekend in SteVe. Na een reboot van de SmartEVSE krijg ik 'please authorize' op het scherm te zien, en moet ik in SteVe een 'Remote Start Transaction' doen. Mijn SmartEVSE heeft de meegeleverde RFID lezer van Stegen, maar tot op heden heb ik 'm op Disabled staan in de config. Ik wil laden zonder dat ik een pas moet swipen.

Moet ik, om die 'please authorize' melding te voorkomen, de RFID configuratie op Rmt/OCPP zetten? Werkt het dan nog zo dat ik geen pas hoef te swipen om het laden te starten?

[dingo35]

Ja, op Rmt/OCPP werkt t zeker (waarom probeer je dat niet eerst vóórdat je op tweakers post?!?), op Disable moet hij t volgens mij ook doen, volop gebruikers die OCPP zonder RFID reader gebruiken. Lijkt me eerder iets van Steve dan van je SmartEVSE config.

[dingo35]

Voor de SmartEVSE gebruikers die een instabiele OCPP verbinding ervaren: het lijkt aan de mbedtls stack te liggen; tot we het gefixed hebben kun je misschien beter een ws:// ipv wss:// url opgeven bij je OCPP parameters, dan is het (in ieder geval bij Tap) super stabiel.