Zelfbouw Laadpaal ervaringen

[dannyll]

Driek schreef op maandag 25 mei 2026 @ 11:56:
Inmiddels heb ik de smartevse gekoppeld aan Joulo voor ERE.
Nu heb ik op de smartevse de auto-authorise enabled, alleen betekent dit dat de auto direct gaat laden als ik hem aankoppel. Op zich prima, maar betekent ook dat iedere willekeurige auto direct gaat laden. Dit wil ik niet, daarom heb ik aan de smartevse een Knop gekoppeld.
Ik kon voorheen de laadsessie starten door op de knop te klikken, of via home assistant de switch.smartevse_power op on te zetten.

Na elke laadsessie zet home assistant die switch ook automatisch op off.

Het lijtk erop dat dit met occp dit meer werkt. Iemand een idee hoe ik dit weer zo in kan stellen, in combi met occp?

Dit herken ik inderdaad. Het kunnen omzetten van modus wanneer de auto nog verbonden is, is niet mogelijk. Als dit auto los is en weer gekoppeld wel.

[marcel3]

dingo35 schreef op dinsdag 26 mei 2026 @ 06:26:
Het is echt complete onzin dat je "de controle uit handen geeft" op het moment dat je OCPP inschakelt. Je moet gewoon je automations in HA aanpassen.

Hint: zoek eens op /Set/RFID in de handleiding of dit topic.

In de eerste plaats enorme waardering voor jouw bijdragen aan dit project. Ik hoefde me niet eerder hier te melden, omdat alles tot nu toe gewoon out of the box werkt. Net als ongetwijfeld vele anderen heel veel plezier gehad van alle nieuwe functionaliteiten die er de afgelopen jaren bij zijn gekomen.

Maar dit is voor iemand die tot nu toe zonder RFID en OCPP werkte toch niet helemaal vanzelfsprekend. En zoeken op bovenstaand onderwerp levert niet meteen de oplossing. Het lijkt me daarom goed om het ook voor anderen die hier ongetwijfeld tegenaan gaan lopen even goed neer te zetten. Wat ik net heb gedaan is:

- RFID instelling in configuratie op 'Rmt/OCPP'

- script in home assistant aangemaakt dat publiceert naar het /Set/RFID topic

- versturen van een willekeurige code (zelfde als uit de github docs)

- instelling 'Laden zonder pasje toestaan' bij joulo uitgezet

Resultaat is dat de smartEVSE inderdaad wacht op authorisatie en wordt vrijgegeven na de gesimuleerde swipe. Ik kreeg wel nog een paar keer de melding 'service offline' (oid) op de display en pas na onderbreken van de OCPP verbinding lukte het. Ik zal de komende dagen nog wel blijven experimenteren hiermee, maar als je nog hints hebt in de tussentijd dan van harte welkom uiteraard.

[Deikke]

dingo35 schreef op dinsdag 26 mei 2026 @ 06:26:
Het is echt complete onzin dat je "de controle uit handen geeft" op het moment dat je OCPP inschakelt. Je moet gewoon je automations in HA aanpassen.

Hint: zoek eens op /Set/RFID in de handleiding of dit topic.

Bijna, je moet ook bij het afsluiten van de sessie nog een keer 'swipen' om de sessie te beeindigen (of 2x om een nieuwe sessie te starten). Alleen de laadkabel ontkoppelen is niet genoeg (bij Auto Authorize wel). Wat mij betreft zou de auto ontkoppelen (of SmartEvSE naar OFF) ook mogen betekenen dat de autorisatie beeindigd wordt.

[Driek]

marcel3 schreef op dinsdag 26 mei 2026 @ 08:37:
[...]

In de eerste plaats enorme waardering voor jouw bijdragen aan dit project. Ik hoefde me niet eerder hier te melden, omdat alles tot nu toe gewoon out of the box werkt. Net als ongetwijfeld vele anderen heel veel plezier gehad van alle nieuwe functionaliteiten die er de afgelopen jaren bij zijn gekomen.

Maar dit is voor iemand die tot nu toe zonder RFID en OCPP werkte toch niet helemaal vanzelfsprekend. En zoeken op bovenstaand onderwerp levert niet meteen de oplossing. Het lijkt me daarom goed om het ook voor anderen die hier ongetwijfeld tegenaan gaan lopen even goed neer te zetten. Wat ik net heb gedaan is:

- RFID instelling in configuratie op 'Rmt/OCPP'

- script in home assistant aangemaakt dat publiceert naar het /Set/RFID topic

- versturen van een willekeurige code (zelfde als uit de github docs)

- instelling 'Laden zonder pasje toestaan' bij joulo uitgezet

Resultaat is dat de smartEVSE inderdaad wacht op authorisatie en wordt vrijgegeven na de gesimuleerde swipe. Ik kreeg wel nog een paar keer de melding 'service offline' (oid) op de display en pas na onderbreken van de OCPP verbinding lukte het. Ik zal de komende dagen nog wel blijven experimenteren hiermee, maar als je nog hints hebt in de tussentijd dan van harte welkom uiteraard.

Hi @marcel3
Ik zal er de komende dagen ook eens proberen in te duiken.
Ik denk dat ik snap wat er moet gebeuren, maar dit vertalen naar yaml is dan nog een volgende. Ik ben redelijk technisch maar dit from scratch bedenken is vaak een brug te ver. En dan is het nog te hopen dat ik het proces inderdaad goed heb begrepen.

[Jfwiet]

Ik ga me zeker nog wel even inlezen op het hele verhaal, maar als gebruiker van Homey zit ik denk ik nog wat meer klem. Maar ik ga wel kijken of ik via een API call naar SteVe de boel kan bedienen.

[Netraam]

Jfwiet schreef op dinsdag 26 mei 2026 @ 11:34:
Ik ga me zeker nog wel even inlezen op het hele verhaal, maar als gebruiker van Homey zit ik denk ik nog wat meer klem. Maar ik ga wel kijken of ik via een API call naar SteVe de boel kan bedienen.

Of een MQTT publish naar de SmartEVSE

[Jfwiet]

Netraam schreef op dinsdag 26 mei 2026 @ 11:37:
[...]

Of een MQTT publish naar de SmartEVSE

Ook als ik OCCP heb ingeschakeld?

Want gisteren zat ik te kijken naar een authorisatie scherm op de EVSE en dan kon ik hem niet handmatig van Off naar Normal zetten. Wat ik nu terug lees is bij het OCCP dat de kapitein en niet de normale bediening via de knoppen/MQTT.

Dus als ik mijn slimmigheid van Homey wil gebruiken zal ik de OCCP moeten beinvloeden is volgens mij nu waar ik mij op moet verdiepen. En OCCP ivm logging.

[Netraam]

Jfwiet schreef op dinsdag 26 mei 2026 @ 11:43:
[...]

Ook als ik OCCP heb ingeschakeld?

Want gisteren zat ik te kijken naar een authorisatie scherm op de EVSE en dan kon ik hem niet handmatig van Off naar Normal zetten. Wat ik nu terug lees is bij het OCCP dat de kapitein en niet de normale bediening via de knoppen/MQTT.

Dus als ik mijn slimmigheid van Homey wil gebruiken zal ik de OCCP moeten beinvloeden is volgens mij nu waar ik mij op moet verdiepen. En OCCP ivm logging.

Ik weet niet of het ook in Homey kan maar ik stuur vanuit Home Assistant een tag door naar de SmartEVSE door een bericht te publiceren op /Set/RFID en daarmee stuurt de SmartEVSE het startsignaal via OCPP.

[Jfwiet]

Netraam schreef op dinsdag 26 mei 2026 @ 11:56:
[...]

Ik weet niet of het ook in Homey kan maar ik stuur vanuit Home Assistant een tag door naar de SmartEVSE door een bericht te publiceren op /Set/RFID en daarmee stuurt de SmartEVSE het startsignaal via OCPP.

Daar bevestig je mijn vermoeden denk ik. Want die RFID tag is een call naar de door jou gebruikte OCPP? (waardoor daarna de EVSE naar de juiste stand gaat.) Daarmee fake je dus dat er iemand een tag aanbied?

[Geim]

Netraam schreef op dinsdag 26 mei 2026 @ 11:56:
[...]

Ik weet niet of het ook in Homey kan maar ik stuur vanuit Home Assistant een tag door naar de SmartEVSE door een bericht te publiceren op /Set/RFID en daarmee stuurt de SmartEVSE het startsignaal via OCPP.

Ja hoor, kan prima met Homey. Ik heb een Ikea zigbee schakelaar in de garage. Na plaatsen kabel 1x kort drukken is smart laden authorisatie met m’n anwb rfid laadpas code naar Plugchoice, 1x lang drukken is solar laden met dezelfde authorisatie.

[adjego]

Jfwiet schreef op dinsdag 26 mei 2026 @ 12:28:
[...]

Daar bevestig je mijn vermoeden denk ik. Want die RFID tag is een call naar de door jou gebruikte OCPP? (waardoor daarna de EVSE naar de juiste stand gaat.) Daarmee fake je dus dat er iemand een tag aanbied?

De "/Set/RFID" doe je naar de smartEVSE en niet naar de OCPP. Die call doe je via MQTT of via een rest command naar de SmartEVSE en daarna wordt dit door de laadpaal doorgegeven aan de OCPP backend.

[CyberEspresso]

marcel3 schreef op dinsdag 26 mei 2026 @ 08:37:
[...]
- RFID instelling in configuratie op 'Rmt/OCPP'
- script in home assistant aangemaakt dat publiceert naar het /Set/RFID topic
- versturen van een willekeurige code (zelfde als uit de github docs)
- instelling 'Laden zonder pasje toestaan' bij joulo uitgezet

Ik krijg dit in combinatie met Tap toch nog niet voor elkaar. Ik heb zowel 'Rmt/OCPP', 'EnableAll' en 'Disabled' geprobeerd als RFID instelling. Een MQTT publish sturen naar /Set/RFID met de tag die ik ook bij 'Auto Authorize' heb ingesteld doet helemaal niks.

De 'Auto Authorize' zelf werkt overigens prima, stekker inpluggen en de EV begint te laden. Als ik echter de laadmodus op 'Off' zet en dan het laden weer opnieuw wil starten heb ik twee opties: de stekker opnieuw fysiek inpluggen of in de Tap webinterface op 'Remote Start' drukken, dat werkt wel goed.

Het liefst stuur ik het geheel helemaal aan vanuit Home Assistant. Heeft iemand hier dezelfde setup en dit wel aan de praat gekregen?

[Netraam]

@CyberEspresso zie je bij Tap wel een authorize voorbij komen in de logs? Misschien dat de tag net iets anders wordt doorgegeven dan via auto authorize.

[marcel3]

CyberEspresso schreef op dinsdag 26 mei 2026 @ 14:30:
[...]

Ik krijg dit in combinatie met Tap toch nog niet voor elkaar. Ik heb zowel R'mt/OCPP', 'EnableAll' en 'Disabled' geprobeerd als RFID instelling. Een MQTT publish sturen naar /Set/RFID met de tag die ik ook bij 'Auto Authorize' heb ingesteld doet helemaal niks.

De 'Auto Authorize' zelf werkt overigens prima, stekker inpluggen en de EV begint te laden. Als ik echter de laadmodus op 'Off' zet en dan het laden weer opnieuw wil starten heb ik twee opties: de stekker opnieuw fysiek inpluggen of in de Tap webinterface op 'Remote Start' drukken, dat werkt wel goed.

Het liefst stuur ik het geheel helemaal aan vanuit Home Assistant. Heeft iemand hier dezelfde setup en dit wel aan de praat gekregen?

Bij Joulo heb ik het vandaag nu met een paar laadsessies getest en het werkt vooralsnog allemaal. Auto authorize gebruik ik hier niet, ik wil in principe nooit dat de auto direct start met laden na inpluggen. Of dat bij joulo wel werkt weet ik dus niet. Weet je wel zeker dat er iets gebeurt met de tag aan de kant van Tap? Bij mij startte het laden namelijk ook automatisch zonder auto authorize ingesteld icm een instelling bij Joulo dat laden zonder laadpas was toegestaan. Misschien dus even testen met auto authorize uit, voor zover nog niet gedaan.

[marcel3]

Driek schreef op dinsdag 26 mei 2026 @ 10:05:
[...]

Hi @marcel3
Ik zal er de komende dagen ook eens proberen in te duiken.
Ik denk dat ik snap wat er moet gebeuren, maar dit vertalen naar yaml is dan nog een volgende. Ik ben redelijk technisch maar dit from scratch bedenken is vaak een brug te ver. En dan is het nog te hopen dat ik het proces inderdaad goed heb begrepen.

Laat maar weten als we kunnen helpen, het valt allemaal wel mee. En ik moet toegeven, AI geeft ook prima hints Maar wel blijven opletten natuurlijk, ik heb pas nog een uur lang zitten piekeren waarom een MQTT bericht niet werkte, bleek de AI nogal slordig te zijn met gebruik van hoofdletters/kleine letters. Het is dus SmartEVSE-xxxxx en niet smartEVSE

[FatalError]

Voor de afwisseling heb ik mijn nieuwe laadpaal gebaseerd op een Phoenix Contact CHARX SEC-3050 controller:



Deze heeft ISO 15118 ondersteuning. Plug&Charge is onlangs toegevoegd. V2G ondersteuning staat op de planning. Ik gebruik TAP Electric als backend. Werkt prima!

Ik heb een Ecotap paal als donor gebruikt voor de behuizing en wat kleine onderdelen.

Er zijn nog wat kleine dingen die ik moet verbeteren. Denk aan het deel beneden met de zekeringen/automaat, de LEDs moeten nog aangesloten en geconfigureerd worden en loadbalancing lijkt het nog niet te doen.

[ Voor 16% gewijzigd door FatalError op 26-05-2026 16:25 ]

[CyberEspresso]

Netraam schreef op dinsdag 26 mei 2026 @ 14:56:
@CyberEspresso zie je bij Tap wel een authorize voorbij komen in de logs? Misschien dat de tag net iets anders wordt doorgegeven dan via auto authorize.

Nee, de authorize (met het juiste tag ID) komt wel langs bij het inpluggen van de stekker en het 'auto authorizen'. Via MQTT het RFID tag aanbieden lijkt helemaal niks te doen, zowel aan de SmartEVSE kant als de Tap kant. Heb gecheckt met MQTT Explorer dat het bericht op de juiste plek terecht komt en gebruik versie v3.11.0 van de firmware.

[Hmmbob]

FatalError schreef op dinsdag 26 mei 2026 @ 16:12:
Er zijn nog wat kleine dingen die ik moet verbeteren. Denk aan het deel beneden met de zekeringen/automaat,

Tof, een keer wat anders!

Een van die kleine dingen is een bruggetje over de automaten L1/L2/L3... Ze moeten tegelijk afschakelen.

edit: herstel, dat zijn glaszekeringen? Hoe gaan die tegelijk afschakelen dan? Dat is wel noodzakelijk voor een 3F apparaat....
En ook je nul schakelt niet mee af - dat is vziw ook een requirement. Beter zet je er gewoon een 3f aardlekautomaat in....

[ Voor 26% gewijzigd door Hmmbob op 26-05-2026 17:14 ]

[FatalError]

Hmmbob schreef op dinsdag 26 mei 2026 @ 17:08:
[...]

Een van die kleine dingen is een bruggetje over de automaten L1/L2/L3... Ze moeten tegelijk afschakelen.

edit: herstel, dat zijn glaszekeringen? Hoe gaan die tegelijk afschakelen dan? Dat is wel noodzakelijk voor een 3F apparaat....
En ook je nul schakelt niet mee af - dat is vziw ook een requirement. Beter zet je er gewoon een 3f aardlekautomaat in....

Dat zijn inderdaad glas zekeringen. Een overblijfsel uit de donorpaal. Waarschijnlijk haal ik ze er uit. In de groepenkast is de paal fatsoenlijk afgezekerd met een aardlekautomaat.

[FatalError]

Oeps

[ Voor 162% gewijzigd door FatalError op 26-05-2026 20:12 ]

[Pim57]

Driek schreef op vrijdag 22 mei 2026 @ 13:59:
[...]

ik heb me ook aangemeld, maar de occp lijtk niet te conencten, en smartevse geeft nu out of order aan.

[Afbeelding] Iemand een idee?

Ik had eenzelfde probleem met ‘out of order’ bij Plugchoice.

Mijn oplossing was om even een werkende verbinding met evseadmin te maken. Daarna weer terug gezet naar Plugchoice en alles werkt weer goed. Beetje vreemd, maar werkt wel.

[Driek]

marcel3 schreef op dinsdag 26 mei 2026 @ 15:17:
[...]

Bij Joulo heb ik het vandaag nu met een paar laadsessies getest en het werkt vooralsnog allemaal. Auto authorize gebruik ik hier niet, ik wil in principe nooit dat de auto direct start met laden na inpluggen. Of dat bij joulo wel werkt weet ik dus niet. Weet je wel zeker dat er iets gebeurt met de tag aan de kant van Tap? Bij mij startte het laden namelijk ook automatisch zonder auto authorize ingesteld icm een instelling bij Joulo dat laden zonder laadpas was toegestaan. Misschien dus even testen met auto authorize uit, voor zover nog niet gedaan.

Welke stappen heb je dan precies met joulo gedaan?
De basis heb ik nu werkend, maar dus met auto autorize, maar graag wil ik dit Home Asisstant of mijn gekoppelde knop dit laten regelen. Maar die zullen dan waarschijnlijk een dummy rfid-id mee moeten geven ofzo.

[Deikke]

CyberEspresso schreef op dinsdag 26 mei 2026 @ 16:14:
[...]

Nee, de authorize (met het juiste tag ID) komt wel langs bij het inpluggen van de stekker en het 'auto authorizen'. Via MQTT het RFID tag aanbieden lijkt helemaal niks te doen, zowel aan de SmartEVSE kant als de Tap kant. Heb gecheckt met MQTT Explorer dat het bericht op de juiste plek terecht komt en gebruik versie v3.11.0 van de firmware.

Heb je toevallig een 4 byte rfid tag? Dan moet je nog met 2 nul bytes padden. (dus 4 nullen erachter zetten).

[Kaspers]

FatalError schreef op dinsdag 26 mei 2026 @ 16:12:
Voor de afwisseling heb ik mijn nieuwe laadpaal gebaseerd op een Phoenix Contact CHARX SEC-3050 controller:

[Afbeelding]

Deze heeft ISO 15118 ondersteuning. Plug&Charge is onlangs toegevoegd. V2G ondersteuning staat op de planning. Ik gebruik TAP Electric als backend. Werkt prima!

Ik heb een Ecotap paal als donor gebruikt voor de behuizing en wat kleine onderdelen.

Er zijn nog wat kleine dingen die ik moet verbeteren. Denk aan het deel beneden met de zekeringen/automaat, de LEDs moeten nog aangesloten en geconfigureerd worden en loadbalancing lijkt het nog niet te doen.

Mooi werk! Ben je bekend met het spul van phoenixcontact? Of flink aan het spitten gegaan in de documentatie? (wat ze goed op orde hebben maar wel een flink boekwerk is) En wat waren andere overwegingen om hiermee aan de slag te gaan ipv een smartevse controller?

[FatalError]

Nee. Ik was nog niet bekend met hun laadcontrollers. Ik werd enthousiast vanwege de features en het feit dat ze gratis software updates bieden. Toen vond ik de controller, geschikte energiemeter en geschikte rfid lezer voor een schappelijk bedrag en ging ik overstag.

[marcel3]

Driek schreef op dinsdag 26 mei 2026 @ 18:26:
[...]

Welke stappen heb je dan precies met joulo gedaan?
De basis heb ik nu werkend, maar dus met auto autorize, maar graag wil ik dit Home Asisstant of mijn gekoppelde knop dit laten regelen. Maar die zullen dan waarschijnlijk een dummy rfid-id mee moeten geven ofzo.

Ervan uitgaande dat je je smart-EVSE al via MQTT kan benaderen in HA, dan werkt het als volgt.

Aan de kant van de smart-EVSE staat auto authorize uit en in het instellingenmenu is de knop op 'custom' ingesteld.

Voor de knop heb ik dan de volgende automatisering:

alias: smartEVSE_buttonpushed
description: ""
triggers:
  - device_id: bcfa...
    domain: select
    entity_id: 0f5e...
    type: current_option_changed
    trigger: device
conditions: []
actions:
  - action: script.smartEVSE_simulateRFIDswipe
    metadata: {}
    data: {}
mode: single

(Voor de duidelijkheid: de trigger die je zoekt in de visuele editor is 'Apparaat' en dan selecteer je in de lijst je smartevse, dan onder trigger 'Smart-EVSE-xxxxx Custom Button optie veranderd.)

En die roept dus het volgende scriptje aan. Uiteraard kan je dit ook direct in de action opnemen, maar ik roep deze uit meerdere automatiseringen aan, dan is dit handiger.

sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-xxxxx/Set/RFID
      payload: "112233445566"
alias: smartEVSE_simulateRFIDswipe
description: ""

Bovenstaande kan vast nog beter, maar voor nu werkt het.

[Femme]

Kaspers schreef op dinsdag 26 mei 2026 @ 20:57:
[...]


Mooi werk! Ben je bekend met het spul van phoenixcontact? Of flink aan het spitten gegaan in de documentatie? (wat ze goed op orde hebben maar wel een flink boekwerk is) En wat waren andere overwegingen om hiermee aan de slag te gaan ipv een smartevse controller?

Ik heb een integratie gedaan van de Chargepoint Europe Cobalt die een Phoenix Contact Charx aan boord heeft. Het draait inmiddels betrouwbaar bij diverse bedrijven en VvE's (waaronder een VvE met 18 laadpunten op 16 kW gecontracteerd vermogen).

De Charx heeft een nette webUI en heeft zowel MQTT als Modbus TCP. Praktisch voor laadpleinen is dat de netwekverbinding gedaisychained kan worden van de eerste naar de volgende laadpaal. Nogal jammer voor thuisgebruik is dat de laadstroom als integer met een nauwkeurigheid van een hele ampère wordt gestuurd. Op 3-fase stuur je dus in stappen van ongeveer 700 W. Omschakelen van 3- naar 1-fase laden zit er niet in voor zover ik weet.

[FatalError]

Femme schreef op woensdag 27 mei 2026 @ 08:26:
[...]

Omschakelen van 3- naar 1-fase laden zit er niet in voor zover ik weet.

Misschien kan je dat met evcc.io en een beetje hardware wel voor elkaar krijgen. De CHARX heeft slechts 1 uitgang om 230v relais te schakelen, maar wel meerdere IO poorten. evcc.io kan je gewoon op de controller zelf installeren (deze draait gewoon linux).

Blijft een beetje een knutseloplossing dan..

[CyberEspresso]

Deikke schreef op dinsdag 26 mei 2026 @ 20:38:
Heb je toevallig een 4 byte rfid tag? Dan moet je nog met 2 nul bytes padden. (dus 4 nullen erachter zetten).

Je bent een held! Dit was het probleem inderdaad. Heb de RFID instelling van Smartevse nu op 'Rmt/OCPP' staan en 4 nullen padding achter de tagid en nu werkt het starten via MQTT wel.

[Driek]

marcel3 schreef op dinsdag 26 mei 2026 @ 22:12:
[...]

Ervan uitgaande dat je je smart-EVSE al via MQTT kan benaderen in HA, dan werkt het als volgt.

Aan de kant van de smart-EVSE staat auto authorize uit en in het instellingenmenu is de knop op 'custom' ingesteld.

Voor de knop heb ik dan de volgende automatisering:

alias: smartEVSE_buttonpushed
description: ""
triggers:
  - device_id: bcfa...
    domain: select
    entity_id: 0f5e...
    type: current_option_changed
    trigger: device
conditions: []
actions:
  - action: script.smartEVSE_simulateRFIDswipe
    metadata: {}
    data: {}
mode: single

(Voor de duidelijkheid: de trigger die je zoekt in de visuele editor is 'Apparaat' en dan selecteer je in de lijst je smartevse, dan onder trigger 'Smart-EVSE-xxxxx Custom Button optie veranderd.)

En die roept dus het volgende scriptje aan. Uiteraard kan je dit ook direct in de action opnemen, maar ik roep deze uit meerdere automatiseringen aan, dan is dit handiger.

sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-xxxxx/Set/RFID
      payload: "112233445566"
alias: smartEVSE_simulateRFIDswipe
description: ""

Bovenstaande kan vast nog beter, maar voor nu werkt het.

Bedankt.

De knop instellen op de smartevse, klopt het dat je instellen bij Switch bedoeld?
Ik kan daar kiezne uit:
Custom B: A momentary push button can be used for external integrations.
Custom S: A toggle switch can be used for external integrations.

Custom B klinkt als logisch?

Heb je RFID ook aangezet, met functie:
Rmt/OCPP: Authorize remotely over OCPP and bypass the SmartEVSE's local RFID storage.

[ Voor 3% gewijzigd door Driek op 27-05-2026 18:22 ]

[Geim]

Stufipower schreef op zaterdag 23 mei 2026 @ 11:51:
Deze doet ‘t ook prima met ABB als profiel, voor 60 euro.

https://www.sandervunderi...b23-112-10e-din-rail.html

Dank je, net besteld. Nog steeds €60.

[Stufipower]

Geim schreef op woensdag 27 mei 2026 @ 18:29:
[...]

Dank je, net besteld. Nog steeds €60.

Fijn. Zoals in documentatie staat: je moet de A en B draden omdraaien. Heb hem zelf op modbus adres 11 gezet ivm de 1-10 voor smartevse dingen gereserveerd.

En stroomdraden aan bovenkant invoer, onderkant uitvoer. Toen ik dat verkeerd deed verbruikte die -11kW . Hij telde niet negatief, want hij heeft geen export register, dus hij bleef op 0 totaal verbruik staan.

[Geim]

Stufipower schreef op woensdag 27 mei 2026 @ 19:03:
[...]

Fijn. Zoals in documentatie staat: je moet de A en B draden omdraaien. Heb hem zelf op modbus adres 11 gezet ivm de 1-10 voor smartevse dingen gereserveerd.

En stroomdraden aan bovenkant invoer, onderkant uitvoer. Toen ik dat verkeerd deed verbruikte die -11kW . Hij telde niet negatief, want hij heeft geen export register, dus hij bleef op 0 totaal verbruik staan.

Bedankt voor de tips. Duurt nog even. 9 juni krijg ik 3 fase, moet nog een stuk 5x4mm kopen, oude kabel opgraven dan de laadpaal ombouwen. Oh ja, ook nog een 2 polig relais aanschaffen.

[marcel3]

Driek schreef op woensdag 27 mei 2026 @ 18:14:
[...]

Bedankt.

De knop instellen op de smartevse, klopt het dat je instellen bij Switch bedoeld?
Ik kan daar kiezne uit:
Custom B: A momentary push button can be used for external integrations.
Custom S: A toggle switch can be used for external integrations.

Custom B klinkt als logisch?

Heb je RFID ook aangezet, met functie:
Rmt/OCPP: Authorize remotely over OCPP and bypass the SmartEVSE's local RFID storage.

De automatisering zou met beide moeten werken. Ik zou op basis hiervan verwachten dat Custom B zich niet gedraagt als toggle, maar dat doet hij bij mij nu wel. Maar of hij nou op 'aan' of 'uit' staat maakt verder dus niet uit, zolang je maar triggert op de verandering van de één naar de ander.

Verder inderdaad de RFID optie op Rmt/OCPP ingesteld.

En gisteren heb ik voor uitschakelen nog het volgende toegevoegd na de swipe, omdat de smartEVSE toch weer niet altijd naar 'Off' ging:

  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - device_id: bcfa...
    domain: select
    entity_id: 8e37...
    type: select_option
    option: "Off"
    enabled: true

[Bontje Blauw]

In zie het in de readme.md op github niet staan.
Maar L1 en L3 omdraaien is geen probleem toch?
Mijn PV installatie zit op L3 en in Solar Mode kan ik op 3P laden of op 1P op L1. (nu heb ik het hardware schema aangehouden)

Ik zie liever de PV opbrengst direct in de EV gaan.
Voor ERE-regeling en salderen zal het niet uitmaken, maar voor netspanning wel.
En voor terugleverkosten of boete? Salderen is nu achter de meter, maar in 2027 ook?

[Martijn02]

Bontje Blauw schreef op donderdag 28 mei 2026 @ 14:25:
In zie het in de readme.md op github niet staan.
Maar L1 en L3 omdraaien is geen probleem toch?
Mijn PV installatie zit op L3 en in Solar Mode kan ik op 3P laden of op 1P op L1. (nu heb ik het hardware schema aangehouden)

Ik zie liever de PV opbrengst direct in de EV gaan.
Voor ERE-regeling en salderen zal het niet uitmaken, maar voor netspanning wel.
En voor terugleverkosten of boete? Salderen is nu achter de meter, maar in 2027 ook?

Als je L1 en L3 verwisselt draai je de draairichting om, maar dat is volgens mij verder geen probleem. Je zou ook L1 -> L2, L2 -> L3, L3 -> L1 kunnen doorschuiven om zeker te zijn.

Voor de auto is er geen verschil of de fase die hij met 1-fase krijgt aangeboden in jouw huis L1, L2 of L3 heet. Voor 3-fase laden is het van belang dat je daadwerkelijk 3 verschillende fases aanbied (anders overbelast je de 0) maar welke fase waar zit maakt voor de auto niet uit.

En qua salderen tussen de fases: Zolang de meter alleen totalen levering en teruglevering per tarief bijhoud (en dus geen getallen per fase) is er voor de energeleverancier/netbeheerder geen manier om te zien hoeveel jij tussen fases gesaldeerd hebt. Als ze dat op korte termijn zouden willen veranderen zou dat een gigantische klus zijn, want dan zouden voor die tijd alle slimme meters vervangen/geupdate moeten worden. Ik zeg niet dat dat nooit gaat gebeuren, maar op korte termijn maak ik me daar weinig zorgen over.

[ Voor 20% gewijzigd door Martijn02 op 28-05-2026 15:56 ]

[Kaspers]

Onlangs de SmartEVSE installatie afgerond. Betreft een installatie met de ethernet adapter. Ik zit echter met een klein probleem op de SmartEVSE zoals je in de foto kunt zien:



De SmartEVSE lijkt niet meer verbonden te zijn op ethernet. Dat bevestigt ook mijn managed switch: geen verkeer.

Wanneer ik de SmartEVSE tijdelijk spanningsloos maak komt de ethernet verbinding weer tot stand, en werkt hij weer naar behoren:



Waar zou ik mogelijk de oplossing kunnen zoeken? En zijn er tweakers met een vergelijkbare ervaring? Ik durf nog even niet te zeggen hoe snel het probleem weer optreedt. Het is inmiddels een aantal keer voorgekomen. Ik zal eens in de gaten houden hoe snel het zich weer voor doet.

Voor de tweaker die van aansluitdiagrammen houdt, dit is het uiteindelijk geworden:

[ Voor 12% gewijzigd door Kaspers op 28-05-2026 16:36 ]

[FatalError]

Je gebruikt een afgeschermde netwerkkabel. dat zou het probleem _kunnen_ zijn.. Heb je de mogelijkheid om deze eens te verlengen (koppelblokje) met een stukje UTP kabel?

[Kaspers]

FatalError schreef op donderdag 28 mei 2026 @ 16:39:
Je gebruikt een afgeschermde netwerkkabel. dat zou het probleem _kunnen_ zijn.. Heb je de mogelijkheid om deze eens te verlengen (koppelblokje) met een stukje UTP kabel?

Zeker, ga ik proberen! Zou je mij evt nog wat context kunnen geven waarom dit mogelijk van invloed zou kunnen zijn? (en ik maar denken: alles in de verdeler zo goed mogelijk isoleren...)

Ik moet wel zeggen dat de utp-tester aangaf dat er geen sprake is van aarding: en dat klopt: ik heb er ook geen ge-aarde RJ45 erop zitten (behuizing is van plastic, ipv een metalen shield).

[ Voor 16% gewijzigd door Kaspers op 28-05-2026 16:44 ]

[FatalError]

Ik ben geen elektrotechnicus maar... Als de aarding niet klopt en/of er bepaalde ontwerpkeuzes gemaakt worden in netwerkapparatuur mbt de aarding van de ethernet connector dan kunnen er ongewenste stromen kan lopen door die aardmantel en daarmee de boel instabiel maken.

Ik moet wel zeggen dat de utp-tester aangaf dat er geen sprake is van aarding: en dat klopt: ik heb er ook geen ge-aarde RJ45 erop zitten (behuizing is van plastic, ipv een metalen shield).

Weet je het zeker? Ik zie een metalen connector aan de netwerkkabel. Heeft de SmartEVSE een metalen RJ45 connector? Als deze van plastic is mag je mijn berichtje negeren

[ Voor 41% gewijzigd door FatalError op 28-05-2026 16:55 ]

[tsjoender]

Kaspers schreef op donderdag 28 mei 2026 @ 16:34:
Onlangs de SmartEVSE installatie afgerond. Betreft een installatie met de ethernet adapter. Ik zit echter met een klein probleem op de SmartEVSE zoals je in de foto kunt zien:

[Afbeelding]

De SmartEVSE lijkt niet meer verbonden te zijn op ethernet. Dat bevestigt ook mijn managed switch: geen verkeer.

Wanneer ik de SmartEVSE tijdelijk spanningsloos maak komt de ethernet verbinding weer tot stand, en werkt hij weer naar behoren:

[Afbeelding]

Waar zou ik mogelijk de oplossing kunnen zoeken? En zijn er tweakers met een vergelijkbare ervaring? Ik durf nog even niet te zeggen hoe snel het probleem weer optreedt. Het is inmiddels een aantal keer voorgekomen. Ik zal eens in de gaten houden hoe snel het zich weer voor doet.

Voor de tweaker die van aansluitdiagrammen houdt, dit is het uiteindelijk geworden:

[Afbeelding]

Je gebruikt geen smartbox zo te zien en stuurt de mains meter waarden door via API of MQTT? Als die waarden een minuut lang niet bijgewerkt worden dan kun je deze fout ook zien.

[Stefannn]

Martijn02 schreef op donderdag 28 mei 2026 @ 15:51:
[...]

Als je L1 en L3 verwisselt draai je de draairichting om, maar dat is volgens mij verder geen probleem. Je zou ook L1 -> L2, L2 -> L3, L3 -> L1 kunnen doorschuiven om zeker te zijn.

Voor de auto is er geen verschil of de fase die hij met 1-fase krijgt aangeboden in jouw huis L1, L2 of L3 heet. Voor 3-fase laden is het van belang dat je daadwerkelijk 3 verschillende fases aanbied (anders overbelast je de 0) maar welke fase waar zit maakt voor de auto niet uit.

En qua salderen tussen de fases: Zolang de meter alleen totalen levering en teruglevering per tarief bijhoud (en dus geen getallen per fase) is er voor de energeleverancier/netbeheerder geen manier om te zien hoeveel jij tussen fases gesaldeerd hebt. Als ze dat op korte termijn zouden willen veranderen zou dat een gigantische klus zijn, want dan zouden voor die tijd alle slimme meters vervangen/geupdate moeten worden. Ik zeg niet dat dat nooit gaat gebeuren, maar op korte termijn maak ik me daar weinig zorgen over.

En @Bontje Blauw
Op zich klopt het dat het voor de afrekening niet uitmaakt,
Maar…..
Er is wel degelijk een voordeel aan “van zelfde fase laden als dat de PV levert”.
Want dan heb je een veel lagere stroom door de aansluiting. Als je dan op dezelfde fase een waterkoker aanzet hoeft de stroom begrenzer niet in te grijpen,

[THM0]

Stefannn schreef op donderdag 28 mei 2026 @ 18:06:
[...]

En @Bontje Blauw
Op zich klopt het dat het voor de afrekening niet uitmaakt,
Maar…..
Er is wel degelijk een voordeel aan “van zelfde fase laden als dat de PV levert”.
Want dan heb je een veel lagere stroom door de aansluiting. Als je dan op dezelfde fase een waterkoker aanzet hoeft de stroom begrenzer niet in te grijpen,

Plus dat de Smart mode in de SmartEVSE kijkt naar de drie fasen, en de laadstroom dusdanig beperkt dat de zwaarst belastte fase niet overbelast kan raken door de laadpaal, zonder te kijken welke fase de SmartEVSE precies belast. Er is verder geen logica die het onderscheid maakt dat 1-fase laden op L1 de fase L3 nooit kan overbelasten.

Bijv als PV op L2 zit, maar op L3 een wasmachine en droger volop staan te draaien en samen bijv 20A trekken, dan zal een 3-fase SmartEVSE niet gaan laden bij een 3x25A hoofdzekering begrenzing.

[Bontje Blauw]

Ook de netspanning was voor mij een punt al lijkt de netbeheerder dat dit jaar beter voor elkaar te hebben.
Vorig jaar zat ik met PV op L2 tegen de 250V aan. Bij 253V gaat de omvormer uit.
Daarom heb ik PV nu op L3 zitten.
Auto laad op L1 maar dat is al de laagste fase. Met EV laden daalt hij op de P1 meter zelfs met nog 1.3V.

Maar bedankt voor de reacties. Ik ga even schuiven met de fasen zodat ik PV en EV op dezelfde fase krijg.

[Kaspers]

tsjoender schreef op donderdag 28 mei 2026 @ 17:12:
[...]

Je gebruikt geen smartbox zo te zien en stuurt de mains meter waarden door via API of MQTT? Als die waarden een minuut lang niet bijgewerkt worden dan kun je deze fout ook zien.

Klopt. De oorzaak vinden van de foutmelding is ook niet de uitdaging: wanneer de netwerkconnectie plat ligt, valt ook het MQTT verkeer uiteraard weg.

[Stufipower]

Kaspers schreef op donderdag 28 mei 2026 @ 22:00:
[...]


Klopt. De oorzaak vinden van de foutmelding is ook niet de uitdaging: wanneer de netwerkconnectie plat ligt, valt ook het MQTT verkeer uiteraard weg.

Een oorzaak naar mijn weten kan zijn dat de http server overloaded is. Als je de waarden via http stuurt en nog de web UI open hebt kan die het te druk krijgen en errort ie. Volgens mij moet je zelfs elke 10 seconden de mains meter data versturen? En mqtt zou de oplossing zijn, veel minder overhead in dat protocol.

[edwin2021]

FatalError schreef op donderdag 28 mei 2026 @ 16:52:
Ik ben geen elektrotechnicus maar... Als de aarding niet klopt en/of er bepaalde ontwerpkeuzes gemaakt worden in netwerkapparatuur mbt de aarding van de ethernet connector dan kunnen er ongewenste stromen kan lopen door die aardmantel en daarmee de boel instabiel maken.


[...]

Weet je het zeker? Ik zie een metalen connector aan de netwerkkabel. Heeft de SmartEVSE een metalen RJ45 connector? Als deze van plastic is mag je mijn berichtje negeren

Daarom monteer ik de aarde ook altijd maar aan één kant, meestal de patchkast/rack die op zijn beurt netjes aan aarde ligt.

[Driek]

marcel3 schreef op woensdag 27 mei 2026 @ 22:52:
[...]

De automatisering zou met beide moeten werken. Ik zou op basis hiervan verwachten dat Custom B zich niet gedraagt als toggle, maar dat doet hij bij mij nu wel. Maar of hij nou op 'aan' of 'uit' staat maakt verder dus niet uit, zolang je maar triggert op de verandering van de één naar de ander.

Verder inderdaad de RFID optie op Rmt/OCPP ingesteld.

En gisteren heb ik voor uitschakelen nog het volgende toegevoegd na de swipe, omdat de smartEVSE toch weer niet altijd naar 'Off' ging:

  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - device_id: bcfa...
    domain: select
    entity_id: 8e37...
    type: select_option
    option: "Off"
    enabled: true

Bedankt, ik ga vanmiddag eens testen.

Heb je ook een rfid id geregistreerd in de smartevse?

[Kaspers]

Stufipower schreef op donderdag 28 mei 2026 @ 22:19:
Een oorzaak naar mijn weten kan zijn dat de http server overloaded is. Als je de waarden via http stuurt en nog de web UI open hebt kan die het te druk krijgen en errort ie. Volgens mij moet je zelfs elke 10 seconden de mains meter data versturen? En mqtt zou de oplossing zijn, veel minder overhead in dat protocol.

Ah, dit is idd ook een scenario waar ik nog niet aan had gedacht. Maar er is 1 ding waar ik nog aan twijfel: het lijkt mij niet meteen een logisch gevolg dat ik vervolgens de SmartEVSE niet meer kan pingen danwel dat de ethernet connectie breekt. Dat lijkt mij op een andere systeemlaag te zitten dan een service (de http server) die overbelast raakt en crasht.

FatalError schreef op donderdag 28 mei 2026 @ 16:52:
Weet je het zeker? Ik zie een metalen connector aan de netwerkkabel. Heeft de SmartEVSE een metalen RJ45 connector? Als deze van plastic is mag je mijn berichtje negeren

Je hebt volkomen gelijk!:


Mijn geheugen liet mij even in de steek...

Als het nog een keer gebeurt hang ik er even een losse netwerkkabel zonder aarding tussen, de switch is gelukkig vlakbij :

[ Voor 43% gewijzigd door Kaspers op 29-05-2026 08:45 ]

[m.eddy]

Kaspers schreef op vrijdag 29 mei 2026 @ 08:41:
[...]


Ah, dit is idd ook een scenario waar ik nog niet aan had gedacht. Maar er is 1 ding waar ik nog aan twijfel: het lijkt mij niet meteen een logisch gevolg dat ik vervolgens de SmartEVSE niet meer kan pingen danwel dat de ethernet connectie breekt. Dat lijkt mij op een andere systeemlaag te zitten dan een service (de http server) die overbelast raakt en crasht.


[...]


Je hebt volkomen gelijk!:
[Afbeelding]

Mijn geheugen liet mij even in de steek...

Als het nog een keer gebeurt hang ik er even een losse netwerkkabel zonder aarding tussen, de switch is gelukkig vlakbij :

[Afbeelding]

Check bij dit soort storingen ook de netwerkkabel zelf. Zit er een solid kabel naar de smartevse vanaf de switch? Beter is om solid vanuit de wanden naar patch af te monteren met keystones bijvoorbeeld. Dan naar switch en eindapparaten gewoon met patchkabels.

[marcel3]

Driek schreef op vrijdag 29 mei 2026 @ 08:26:
[...]

Bedankt, ik ga vanmiddag eens testen.

Heb je ook een rfid id geregistreerd in de smartevse?

Nee heb ik niet gedaan, zie ook de eerdere voorbeelden van de automatisering. Het enige dat je doet is een willekeurige RFID code versturen naar Joulo. Aan die kant vindt er ook geen check plaats. De hele autorisatie is een formaliteit die nodig is om weer controle te krijgen over het moment van starten. Ik blijf het een beetje jammer vinden dat het niet anders kan, maar als het werkt dan werkt het.

[michels911]

Wellicht doe ik iets helemaal fout?

smartEVSE met 3.11.0
MainsMeter Sensorbox via modbus
EVMeter, nu Homewizard via Homeassistant dus API

Ik dacht native Homewizard wordt ondersteund dus ik zoek in EV Meter naar Homewizrd maar die optie zie ik niet?

Bij MainsMet kan ik wel Homewizrd P1 kiezen maar zie dan ook niet de optie:
MAINS HST: Select a networked meter through a list of mDNS discovered hosts.

Verdere integratie: OCPP Tap electric (of Laadloon)

Wat doe ik fout? Waarom kan ik geen Homewizard EVMeter selecteren? Heeft dat iets te maken met de API koppeling via HomeAssistant die ik niet heb uitgezet voordat de direct koppeling naar Homewizard 3F kWh meter werkt?

[Kaspers]

m.eddy schreef op vrijdag 29 mei 2026 @ 11:12:
[...]

Check bij dit soort storingen ook de netwerkkabel zelf. Zit er een solid kabel naar de smartevse vanaf de switch? Beter is om solid vanuit de wanden naar patch af te monteren met keystones bijvoorbeeld. Dan naar switch en eindapparaten gewoon met patchkabels.

Er zit een UTP (solid) van smartevse naar patchkast (met keystones), en van patchkast naar switch middels patchkabel. UTP Solid is getest met een kabeltester, want daar heb ik een RJ45 opgeknepen.

[racquemis]

michels911 schreef op vrijdag 29 mei 2026 @ 18:57:
Ik dacht native Homewizard wordt ondersteund dus ik zoek in EV Meter naar Homewizrd maar die optie zie ik niet?

Bij MainsMet kan ik wel Homewizrd P1 kiezen maar zie dan ook niet de optie:
MAINS HST: Select a networked meter through a list of mDNS discovered hosts.

Verdere integratie: OCPP Tap electric (of Laadloon)

Wat doe ik fout? Waarom kan ik geen Homewizard EVMeter selecteren?

De ondersteuning is al gecommit in het project maar er is nog geen nieuwe release ervan gemaakt omdat er nog een paar puntjes op de i gezet moeten worden. Ik heb nog een 'duurtest' lopen met een test-build die mogelijk stabiliteitsissue met de homewizard ondersteuning i.c.m. OCCP oplost. Ik verwacht morgen de laatste pull request voor review aan te bieden bij dingo35. Dan zou de ondersteuning met de volgende release erin moeten zitten als alles goed gaat.

[edwin2021]

Kaspers schreef op vrijdag 29 mei 2026 @ 21:10:
[...]


Er zit een UTP (solid) van smartevse naar patchkast (met keystones), en van patchkast naar switch middels patchkabel. UTP Solid is getest met een kabeltester, want daar heb ik een RJ45 opgeknepen.

En ook de juiste kleurcode (568B) gevolgd? Connectoren gebruikt die geschikt zijn voor de kabel (er zijn diverse RJ45 versies solid, stranded, awg23, awg24 enz)

[ Voor 14% gewijzigd door edwin2021 op 29-05-2026 22:40 ]

[Allewijn]

Allewijn schreef op vrijdag 22 mei 2026 @ 11:59:
Dankjewel voor je foto @Beekforel

Ik ben gelijk met een knoopcel gaan testen.
Omdat ik weet dat voor de draadloze zender echt een dedicated 3.3v ader hoort te zijn en niet over pp of cp moet gaan, koos ik voor de enige ader die bij mij ongeduid was: mintgroen.

Hoppa. Laadklep ging meteen open.
Dus voor TWC3 kabels is het mintgroen voor + en PE voor -

Oranje is PP
Paars is CP
Wit is NTC temp sensor

Blij mee. Werkend.
Nu op zoek naar een interessante slimme laadpaal.

Vandaag mijn gekozen laadpaal uitvoerig getest.
Is een fraai model van Webasto geworden die echt alles kan. Automatisch 1p3p, DLB, modbus tcp, HA en EVCC, MID, occp, etc.

Nu aan het testen op testbank 1 fase 10A en alles werkt briljant. Evcc alles samengebracht en hij staat al keurig te zonneladen en bij te regelen bij wolkjes etc. Blij mee. Voor maar 300 euro geen alternatief mogelijk.

Morgen de vaste donor Tesla kabel er in bouwen ipv de huidige type 2 socket. Zoek nog een 3.3v output ergens op een pcb. Maar zag wel al een interne usb socket (voor service) en daar staat natuurlijk fraai stabiel 5v op. Zou die 3.3v voor het Tesla draadloze zendertje ook 5V mogen zijn?
Dan wordt het wel appeltje eitje met een mooi usb-a naar 2 aders kabeltje wat ik heb.
Kan natuurlijk altijd een ldo ams117-3.3 er tussen zetten oid om 3.3v te maken... Maar als 5v mag...

Meet overigens ook 3.3v ergens op een los wifi pcb'tje dus kan daar ook aftakken. Maar die usb is zo lekker non-destructief...

[ Voor 7% gewijzigd door Allewijn op 30-05-2026 17:37 ]

[edwin2021]

Dat is geen geld. Welk model is dat en welke ha integratie gebruik je?

[Allewijn]

Het is een Webasto Unite.
Ik gebruik nu evcc zonder HA. Ben nog verkennende of ik evcc via HA ga laten lopen, helemaal alles via HA doe zonder evcc of het zo laat. Evcc is qua UI gewoon voor mij heel erg fijn en begrijpelijk.


Kan ook via HA, daar is zelfs een tweaker die een integratie heeft geschreven: zie topic
Webasto Unite Laadstation

Overigens heb ik nu een vraag aan jullie omdat ik net die vaste Tesla donor kabel al even had getest, dus socket kabels van de Webasto Unite allemaal los en dan L1, L2, L3, N, PE rechtstreeks op de matchende pcb terminals.

En dan zat ik met PP en CP.
Heb geprobeerd ze beiden aan te sluiten op matchende aansluitingen pcb en ook geprobeerd met enkel CP, dus PP los.
Maar helaas, de EV (Tesla) gaat niet laden. De lader start niet.
De extra kabeltjes die in de donor Tesla kabel zitten heb ik niet gebruikt. Dat is mintgroen voor 3.3v om draadloos laadklep te openen via de Tesla button op de type2 stekker (dat wil ik later nog aansluiten) en een witte ader die iets van een Tesla temp monitoring specifiek zou zijn.

Dus enkel de basis kabels aangesloten waarmee elke EV en lader normaal werkt...
Niet dus... Mis ik iets? Willen jullie mee denken?

[ Voor 12% gewijzigd door Allewijn op 30-05-2026 21:09 ]

[Stufipower]

Allewijn schreef op zaterdag 30 mei 2026 @ 20:50:
Het is een Webasto Unite.
Ik gebruik nu evcc zonder HA. Ben nog verkennende of ik evcc via HA ga laten lopen, helemaal alles via HA doe zonder evcc of het zo laat. Evcc is qua UI gewoon voor mij heel erg fijn en begrijpelijk.


Kan ook via HA, daar is zelfs een tweaker die een integratie heeft geschreven: zie topic
Webasto Unite Laadstation

Overigens heb ik nu een vraag aan jullie omdat ik net die vaste Tesla donor kabel al even had getest, dus socket kabels van de Webasto Unite allemaal los en dan L1, L2, L3, N, PE rechtstreeks op de matchende pcb terminals.

En dan zat ik met PP en CP.
Heb geprobeerd ze beiden aan te sluiten op matchende aansluitingen pcb en ook geprobeerd met enkel CP, dus PP los.
Maar helaas, de EV (Tesla) gaat niet laden. De lader start niet.
De extra kabeltjes die in de donor Tesla kabel zitten heb ik niet gebruikt. Dat is mintgroen voor 3.3v om draadloos laadklep te openen via de Tesla button op de type2 stekker (dat wil ik later nog aansluiten) en een witte ader die iets van een Tesla temp monitoring specifiek zou zijn.

Dus enkel de basis kabels aangesloten waarmee elke EV en lader normaal werkt...
Niet dus... Mis ik iets? Willen jullie mee denken?

[Afbeelding]

Je hebt een interessante opzet! Ik weet het antwoord niet. Je gaat dus van socketed naar vaste kabel. Daarin is AI ook vast behulpzaam. Dat zullen vast meer mensen gedaan hebben.

Zou het een goede denkrichting zijn om die webasto te laten denken dat er iig de originele socket aan zit die er aan zat? En, bovendien de webasto te laten denken dat er dan een female plug in geschoven wordt? (Ivm weerstanden tussen bepaalde pennen).

Proximity Pilot is dan volgens mij ook nodig.

Kloppen de weerstands waarden tussen draden? (CP / PP?)

Ik zou ook even die oude socket uitmeten, dan kan je kijken naar welke oude situatie je terug moet.

[Allewijn]

@Stufipower Ik denk dat je in de juiste richting zit, dank!, en met dezelfde gedachten werd ik deze ochtend ook wakker: Bij een losse (type 2) kabel zitten er normaal in beide stekkers (male en female) losse weerstanden tussen PP en PE. Bijv 220ohm om aan te geven dat de kabel 3x32A aan kan.
Er loopt bij dat type kabels helemaal geen fysieke PP kabel van de ene naar de andere kant.
In mijn Tesla donor kabel is dat anders en mist weerstand aan de open eind zijde.
Ik denk dus dat ik bij de laadpaal een weerstandje moet plaatsen zodat ook die zijde weet 'wat voor dikte kabel' er gekoppeld zit.

Ga een 220ohm weerstandje opsnorren...

[Stufipower]

@Allewijn hoop dat het lukt! Mijn suggestie zou zijn om eerst even alles zeker te weten hoe de weerstandswaarden, tussen welke pinnen allemaal veranderen bij het inschuiven van de kabel aan de webasto en aan de autokant voor het te proberen.

Het zou jammer zijn als iets kapot gaat, of als het gevaar oplevert.

Moet er trouwens nog iets met die locking actuator bij webasto?

[ Voor 13% gewijzigd door Stufipower op 31-05-2026 09:47 ]

[Allewijn]

@Stufipower ik ga vandaag alle weerstanden meten/interpreteren.
De locking actuator in de socket van de Webasto bestudeerd. Die lijkt 'dom'. Lees: die heeft niet door of een originele male type2 kabel in de socket zit. Hij kan via de software wel elektrisch een pin uit/inschuiven om de kabel (permanent) te locken. Denk niet dat ik daar iets hoef te 'foppen' voor de ombouw naar mijn vaste open eind kabel.

[Stufipower]

@Allewijn klinkt dan alsof permanent de actuator in software in lock zetten ideaal zou kunnen zijn. Het “slimme” deel in de webasto, mochten daar checks plaatsvinden, wordt dan misschien tevreden gehouden met het idee dat er iets in zit. En dan beweegt die iig nooit meer.

[sandergar]

Zojuist mail ontvangen :

Beste S.,

Goed nieuws! Uw Laadpaal #xxxx is goedgekeurd en actief.
U kunt nu inboekingen aanmaken met deze gegevens.

Bekijk uw acties: https://app.laadloon.nl/mijn-verificaties

Met vriendelijke groet,
Team Laadloon.nl
www.laadloon.nl

Geen OCPP koppeling. Smart EVSE in een kast met Eastron MID meter en een vaste kabel. Heb met foto's duidelijk moeten aantonen dat de meter goed in het circuit zit en er geen andere verbruikers achter de meter zitten. Hier nu akkoord op gekregen!

[Stufipower]

@sandergar dus wel een dedicated kast voor de laadpaal?

[tukker999]

sandergar schreef op zondag 31 mei 2026 @ 09:56:
Zojuist mail ontvangen :


[...]


Geen OCPP koppeling. Smart EVSE in een kast met Eastron MID meter en een vaste kabel. Heb met foto's duidelijk moeten aantonen dat de meter goed in het circuit zit en er geen andere verbruikers achter de meter zitten. Hier nu akkoord op gekregen!

Ja, alleen als de MID meter in de kast ingebouwd is. (antwoord op de vraag van @Stufipower )

Wat mooi @sandergar

Ik volg je komende week. Foto's uploaden en MQTT gegevens naar CDR en dat weer naar de CVS data.Doorgeven aan Laadloon. Ik verwacht dat het in een keer goed zal gaan, gezien jouw ervaring.

[sandergar]

Stufipower schreef op zondag 31 mei 2026 @ 10:05:
@sandergar dus wel een dedicated kast voor de laadpaal?

[sandergar]

tukker999 schreef op zondag 31 mei 2026 @ 10:16:
[...]

Ja, alleen als de MID meter in de kast ingebouwd is. (antwoord op de vraag van @Stufipower )

Wat mooi @sandergar

Ik volg je komende week. Foto's uploaden en MQTT gegevens naar CDR en dat weer naar de CVS data.Doorgeven aan Laadloon. Ik verwacht dat het in een keer goed zal gaan, gezien jouw ervaring.

Ze willen overduidelijk zien dat er na de kast geen andere verbruikers dan de auto zijn. Zorg dus voor foto's waar dit overduidelijk uit blijkt. Dan kunnen ze jouw situatie in 1x goed beoordelen. Ik was daar in 1e instantie niet in geslaagd dus heb aanvullende foto's moeten maken. Met de extra foto's nu goedkeuring gekregen.

Aparte kast, MID meter in de kast, vaste laadkabel direct in de kast aangesloten. Kan niets anders dan een auto op worden aangesloten.

[Driek]

marcel3 schreef op woensdag 27 mei 2026 @ 22:52:
[...]

De automatisering zou met beide moeten werken. Ik zou op basis hiervan verwachten dat Custom B zich niet gedraagt als toggle, maar dat doet hij bij mij nu wel. Maar of hij nou op 'aan' of 'uit' staat maakt verder dus niet uit, zolang je maar triggert op de verandering van de één naar de ander.

Verder inderdaad de RFID optie op Rmt/OCPP ingesteld.

En gisteren heb ik voor uitschakelen nog het volgende toegevoegd na de swipe, omdat de smartEVSE toch weer niet altijd naar 'Off' ging:

  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - device_id: bcfa...
    domain: select
    entity_id: 8e37...
    type: select_option
    option: "Off"
    enabled: true

Welke acties voor je precies uit als je de auto loskoppelt?

Ik wil als smartevse_car_connected weer op false klikt alles blokkeren.
Betekent dus de smartevse_7157_custombutton of ook op off zetten? of moet er meer gebeuren.

[Pim57]

Hier ook goedgekeurd voor laadloon. Alles in een aparte kast met een zelf bedachte sticker erop.

[m.eddy]

Pim57 schreef op maandag 1 juni 2026 @ 12:57:
Hier ook goedgekeurd voor laadloon. Alles in een aparte kast met een zelf bedachte sticker erop.

[Afbeelding]

Top, hoever moest je gaan met de bewijslast?

En deel die sticker svp als we die allemaal gaan gebruiken hebben we toch een soort van standaard

[edwin2021]

Pim57 schreef op maandag 1 juni 2026 @ 12:57:
Hier ook goedgekeurd voor laadloon. Alles in een aparte kast met een zelf bedachte sticker erop.

[Afbeelding]

Ook wel benieuwd naar de binnenkant 🧐

[humulus]

@m.eddy Ik heb deze gemaakt voor op m'n laadpaal:



Maar misschien dat @stegen een beter schaalbaar SVG alternatief kan maken?

[ Voor 17% gewijzigd door humulus op 01-06-2026 16:45 ]

[sandergar]

humulus schreef op maandag 1 juni 2026 @ 16:31:
@m.eddy Ik heb deze gemaakt voor op m'n laadpaal:

[Afbeelding]

Maar misschien dat @stegen een beter schaalbaar SVG alternatief kan maken?

Mijn laadinstallatie is goedgekeurd zonder sticker
Het zou eenvoudiger zijn als de Smart EVSE in het lijstje met geaccepteerde laadinstallaties komt te staan bij Laadloon, wellicht iets voor @stegen om even te regelen met de mannen van Laadloon?

[Driek]

Driek schreef op zondag 31 mei 2026 @ 12:00:
[...]

Welke acties voor je precies uit als je de auto loskoppelt?

Ik wil als smartevse_car_connected weer op false klikt alles blokkeren.
Betekent dus de smartevse_7157_custombutton of ook op off zetten? of moet er meer gebeuren.

@marcel3 ik krijg het helaas niet werkend.

Ik heb op de smartevse de autoautorise uitgezet. En rfid op "rmt/occp", en de switch op "custom b"


Ik heb dit script aangemaakt

YAML:

sequence:

  - action: mqtt.publish

    metadata: {}

    data:

      evaluate_payload: false

      qos: 0

      retain: false

      topic: SmartEVSE-xxxx/Set/RFID

      payload: "112233445566"

alias: smartEVSE_simulateRFIDswipe

description: smartEVSE_simulateRFIDswipe

Als ik dan de auto aansluit, dan springt de smartevse op "please authorise".
Als ik dan het script in HA start dan zie ik de publish op mqtt, maar er gebeurt verder niks.

Moet ik nog iets bij Joulo doen?

[Epsilon]

Klein verslagje van mijn ombouw met een SmartEVSE voor het nageslacht . De paal draait ondertussen iets meer dan een maandje en ik ga in een aantal posts wat ervaringen delen.

Donor
Ook ik heb een Newmotion Home Advanced 2.1 22kW van marktplaats gehaald. Deze had een locking Type 2 stekker aansluiting.

Deze laadpaal is gunstig om te bruiken als basis. Deze komt met
- Locking Actuator
- 6mA DC detector (kabeltje is anders, maar je kan zelf een kabeltje maken, want er is een onderdeel met de juiste stekker in de laadpaal!).
- INEPRO 380 MID


Uit een tweede donor Newmotion gebruik ik nu tijdelijk alleen het bovenste frame en dummy-stekker. Het frame met locking stekker gebruik ik nu niet. Ik heb er een vaste kabel aan gezet.

Resulaat:




Wat heb ik gebruikt:
- Controller (Smart EVSE v3)
- 2x contactors.van ISKRA (4p en 2p)
- Sensorbox V2 met klemmen omdat mijn slimme meter nog DSMR4 is en geen stroom per fase aanlevert + slechts elke 10 seconden update.
- Een type 2 kabel (van 8 meter)
- DIN rail om het in de laadpaal te monteren

De Sensorbox en MID zitten via modbus aangesloten. De Sensorbox zit paar meter weg dus die aansluiting loopt nu zo:
- Sensorbox 4 draden naar Ethernet stekker
- CAT6 met keystone in meterkast naar keystone verderop.
- Patchkabel naar Laadpaal (Ubiquiti)
- Keystone met 4 draden naar EVSE
- Als "WAGO" ingesteld in de EVSE

De Keystone in de laadpaal zit in deze 3d-print Keystone houder:
https://www.printables.co...din-rail-keystone/related

Op de volgende DIN rail:
https://www.elektramat.nl...l-7-5x116-7mm-hxl-vkg59t/

Welke gemonteerd zit op deze 3d-print backplate:
https://makerworld.com/en...charger#profileId-1423816

Annekdote buildlog:
Eerst de EVSE op USB gestart en WiFi ingesteld. Later alles ingebouwd en gevoed met 230V om comfortabel op het bureau alles in te stellen, inclusief de Inepro MID.

Grappig dat ik even niet begreep hoe ik de MID in kon stellen. De kast is namelijk HELEMAAL DICHT en kon geen knoppen ontdekken. Aan stroom hangen helpt . zijn capacitieve knoppen . De bediening is niet intuïtief, de manual is noodzakelijk.

Sensorbox manual moest ik er ook even er bij pakken. De stekker die er aan zit is niet voor voeding, maar om aan fase 1 te hangen. Stopcontact in meterkast zodoende van fase gewisseld. Want anders heb je rare waarden.

Meterkast heb ik een B20 aardlekautomaat gezet en een HomeWizard kWh meter. Dit is ook een MID maar gebruik ik niet als zodanig. Deze is ondersteboven gemonteerd, dan kan ik hem wel gewoon mooi onder invoeden en boven uit.:+. Dit is een Eastron onderhuids, dus kon ook in de laadpaal gezet worden verwacht ik.



Het Solar laden op 1 fase:
Ik heb 4500W aan omvormers in huis en kom praktisch gezien op 4300W max teruglevering ongeveer, verdeeld over 2 fases (13A en 6A. Dat is op een zonnige dag, dus met een spanning van 243V oid = 17.6A. Op 233V is dit 18A.


Ik heb de EVSE en de auto op max. 19A gezet. Zodat ik op 1 fase al het overschot kan laden.
C2 staat op Solar Off. Hoogste wat ik heb gezien is 4280W. Blijft in de praktijk onder de 18A; mijn auto neemt altijd minder dan waar op gestuurd wordt.

Bedankt voor het idee @sandergar in deze post:
sandergar in "Zelfbouw Laadpaal ervaringen"

Alles om dit soort mooie grafiekjes te kunnen produceren: Het overschot de auto in gooien



Future todo:
- Automaatje in laadpaal voor los afzekeren EVSE.
- RFID lezer monteren
- Drukknop monteren

--
De tweede donor Newmotion (ander type)
met vaste kabel, waar ik dit moment alleen het frame waar de stekker zit en de dummy connector van gebruik, ga ik nog een keer terug bouwen zodat deze weer op marktplaats kan .

[racquemis]

Epsilon schreef op dinsdag 2 juni 2026 @ 01:37:
Meterkast heb ik een B20 aardlekautomaat gezet

Ik heb de EVSE en de auto op max. 19A gezet. Zodat ik op 1 fase al het overschot kan laden.

Let op dat automaten volgens de NEN normering in principe bij continu belasting maar voor 80% belast mogen worden om geen risico op doorbranden en oververhitting te hebben. Dus een B20 mag een continu belasting hebben van 16A. Je moet het zelf weten maar ik zou het risico, hoe klein ook niet willen lopen, dat er iets in de fik vliegt. Die regel bestaat niet voor niets. Kan je beter een B25 toepassen als je echt op 19A wil laden en de bekabeling ervoor geschikt is.

[marcel3]

Driek schreef op maandag 1 juni 2026 @ 21:05:
[...]

@marcel3 ik krijg het helaas niet werkend.

Ik heb op de smartevse de autoautorise uitgezet. En rfid op "rmt/occp", en de switch op "custom b"


Ik heb dit script aangemaakt

YAML:

sequence:

  - action: mqtt.publish

    metadata: {}

    data:

      evaluate_payload: false

      qos: 0

      retain: false

      topic: SmartEVSE-xxxx/Set/RFID

      payload: "112233445566"

alias: smartEVSE_simulateRFIDswipe

description: smartEVSE_simulateRFIDswipe

Als ik dan de auto aansluit, dan springt de smartevse op "please authorise".
Als ik dan het script in HA start dan zie ik de publish op mqtt, maar er gebeurt verder niks.

Moet ik nog iets bij Joulo doen?

Das gek. Aan jouw kant doe je precies hetzelfde als ik hier. Enige zou dus nog de Joulo kant kunnen zijn. Daar staat bij mij het onderstaande:

[michels911]

Pim57 schreef op maandag 1 juni 2026 @ 12:57:
Hier ook goedgekeurd voor laadloon. Alles in een aparte kast met een zelf bedachte sticker erop.

[Afbeelding]

Mijn eigenbouw in losse kast was ook 'goedgekeurd' maar ze vragen nu, naast de fotos van kWh meter in declaratie toch ook om de CDR van 'provider'. Toch OCPP nodig dus. Ik heb gelukkig al een tijdje Tap Electric werkend.

Ook Laadloon ocpp koppeling direct geprobeerd maar die ondersteunt kennelijk geen onderbroken sessie (Tibber smartladen). Na eerste keer stoppen van laden door auto zegt de smartEVSE ' laden gereed' en wil niet meer verder als de auto weer opdracht krijgt te laden. Bij Tap gaat dit wel goed. Iemand van Laadloon die mee leest?

[m.eddy]

michels911 schreef op dinsdag 2 juni 2026 @ 08:49:
[...]

Mijn eigenbouw in losse kast was ook 'goedgekeurd' maar ze vragen nu, naast de fotos van kWh meter in declaratie toch ook om de CDR van 'provider'. Toch OCPP nodig dus. Ik heb gelukkig al een tijdje Tap Electric werkend.

Ook Laadloon ocpp koppeling direct geprobeerd maar die ondersteunt kennelijk geen onderbroken sessie (Tibber smartladen). Na eerste keer stoppen van laden door auto zegt de smartEVSE ' laden gereed' en wil niet meer verder als de auto weer opdracht krijgt te laden. Bij Tap gaat dit wel goed. Iemand van Laadloon die mee leest?

Wil ook gaan inboeken en heb laadloon gevraagd wat er nodig is om vanaf een bestaande E-Flux koppeling in te boeken. Naast validatie laadpaal kun je de sessie's van E-Flux exporteren en declareren bij LaadLoon. Zal bij Tap ook moeten kunnen waardoor je gewoon die koppeling in stand kunt houden.

[Driek]

marcel3 schreef op dinsdag 2 juni 2026 @ 08:23:
[...]

Das gek. Aan jouw kant doe je precies hetzelfde als ik hier. Enige zou dus nog de Joulo kant kunnen zijn. Daar staat bij mij het onderstaande:

[Afbeelding]

ook dit stond bij mij zo ingesteld.

Ik zal Joulo eens mailen of ze kunnen zien wat er misgaat.

Bij Joulo staat wel dat tag A000000 geregistreerd is, geen idee waar die vandaan komt.

Staat er bij jou wel 112233445566?

[marcel3]

Driek schreef op dinsdag 2 juni 2026 @ 10:23:
[...]

ook dit stond bij mij zo ingesteld.

Ik zal Joulo eens mailen of ze kunnen zien wat er misgaat.

Bij Joulo staat wel dat tag A000000 geregistreerd is, geen idee waar die vandaan komt.

Staat er bij jou wel 112233445566?

Ik zie nergens iets over geregistreerde tags. Je zou ook zeggen dat dat alleen aan de orde is als je wel kiest voor 'Alleen toegestane tags'.

Bij mij zie ik het fake tagnummer inderdaad steeds terugkomen in de kolom 'Tag' in het overzicht dat je krijgt als je op 'Bekijk alle laadsessies' klikt.

[Driek]

marcel3 schreef op dinsdag 2 juni 2026 @ 10:50:
[...]

Ik zie nergens iets over geregistreerde tags. Je zou ook zeggen dat dat alleen aan de orde is als je wel kiest voor 'Alleen toegestane tags'.

Bij mij zie ik het fake tagnummer inderdaad steeds terugkomen in de kolom 'Tag' in het overzicht dat je krijgt als je op 'Bekijk alle laadsessies' klikt.

Dit bedoel ik, ergens wordt A000000 doorgegeven, ipv het fakenummer

[marcel3]

Driek schreef op dinsdag 2 juni 2026 @ 10:52:
[...]

[Afbeelding]

Dit bedoel ik, ergens wordt A000000 doorgegeven, ipv het fakenummer

Vreemd. Hier staat bij mij idd het fakenummer. Je kan ook nog even kijken naar het MQTT topic RFIDLastRead. Daarin moet ook jouw zelfbedachte tagnummer staan.

[Driek]

marcel3 schreef op dinsdag 2 juni 2026 @ 11:40:
[...]

Vreemd. Hier staat bij mij idd het fakenummer. Je kan ook nog even kijken naar het MQTT topic RFIDLastRead. Daarin moet ook jouw zelfbedachte tagnummer staan.

Ja ik meende te zien dat die leeg bleef. Zal vanavond weer eens kijken.
dan lijkt er iets mis te gaan in de smartevse in het doorgeven van die tag richting Joulo

[marcel3]

Driek schreef op dinsdag 2 juni 2026 @ 11:44:
[...]

Ja ik meende te zien dat die leeg bleef. Zal vanavond weer eens kijken.
dan lijkt er iets mis te gaan in de smartevse in het doorgeven van die tag richting Joulo

Dan is het vast nog iets kleins, maar wsl wel aan jouw kant. Kijk ook even in het script of het nummer van jouw SmartEVSE goed staat op de plek van de 'xxxx'.

[Epsilon]

racquemis schreef op dinsdag 2 juni 2026 @ 06:52:
[...]

Let op dat automaten volgens de NEN normering in principe bij continu belasting maar voor 80% belast mogen worden om geen risico op doorbranden en oververhitting te hebben. Dus een B20 mag een continu belasting hebben van 16A. Je moet het zelf weten maar ik zou het risico, hoe klein ook niet willen lopen, dat er iets in de fik vliegt. Die regel bestaat niet voor niets. Kan je beter een B25 toepassen als je echt op 19A wil laden en de bekabeling ervoor geschikt is.

Daarom zit een een B20, zodat er 3x16A geladen kan worden.

Bekabeling is allemaal prima .
19A is de instelling, mijn auto "neemt" minder.
Er gaat hoogstens 18A lopen, maar maar waarschijnlijker 17.6A door verhoogde spanning.

Ik ben hier comfortabel mee omdat:
- Het is 1 fase.
- Het is zeldzaam en kortstondig. Als de panelen warm zijn haal ik het al niet meer .
- Het is realistisch gezien 17.6A

Dus als het om warmte in de behuizing gaat zit ik goed denk ik . Hele volksstammen laden 11kW op een B16. Daar zou ik niet zo comfortabel mee zijn.

Een B25 gaat wat ver ivm selectiviteit (C25 mains).

Ik post later een testje van stromen door de EVSE versus werkelijk met mijn auto (n=1).

[ Voor 10% gewijzigd door Epsilon op 03-06-2026 14:17 ]

[Driek]

marcel3 schreef op dinsdag 2 juni 2026 @ 12:46:
[...]

Dan is het vast nog iets kleins, maar wsl wel aan jouw kant. Kijk ook even in het script of het nummer van jouw SmartEVSE goed staat op de plek van de 'xxxx'.

Die staat goed want die zie ik op de goede plek verschijnen in de mqtt berichten. Daar staat oa ook de P1 input.
Helaas kan ik niet goed zien wat er in de smartevse verder gebeurt.
@dingo35 is er goede logging beschikbaar om te zien waarom een rfid signaal niet verstuurd wordt richting de occp ontvanger?

[dingo35]

Als je de huidige repository versie in debug kunt compileren, dan zie je in de telnet debug logs de berichten die naar de OCPP server gestuurd worden.

En LastRFIDRead uiteraard, kun ke ook via web dashboard "Raw Data" button bekijken.

[Driek]

dingo35 schreef op dinsdag 2 juni 2026 @ 14:45:
Als je de huidige repository versie in debug kunt compileren, dan zie je in de telnet debug logs de berichten die naar de OCPP server gestuurd worden.

En LastRFIDRead uiteraard, kun ke ook via web dashboard "Raw Data" button bekijken.

dit is wat ik zie op mqtt



ook als ik dit script draai, het lijtk er dus op dat in de smartevse de tag die binnenkomt niet wordt doorgegeven.

YAML:

 sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-7157/Set/RFID
      payload: "112233445567"
alias: smartEVSE_simulateRFIDswipe
description: smartEVSE_simulateRFIDswipe

dit zie ik dan ook in de raw data

code:

rfidreader":"Rmt/OCPP","rfid":"Ready to read card","rfid_lastread":"00000000000000"}

ik gebruik versie v3.8.5

[dingo35]

De tag komt dus niet binnen, je syntax is dus verkeerd. Probeer eens een swipe simulatie met mosquitto_pub, zoals beschreven in de handleiding.

[Driek]

dingo35 schreef op dinsdag 2 juni 2026 @ 19:17:
De tag komt dus niet binnen, je syntax is dus verkeerd. Probeer eens een swipe simulatie met mosquitto_pub, zoals beschreven in de handleiding.

maar ik zie de berichten wel voorbij komen als ik naar de mqtt berichten kijk.

Heb je een link naar hoe ik mosquitto_pub gebruik? ik krijg het op github niet direct gevonden


ik heb nu deze geprobeerd, maar lijkt ook niet te werken

YAML:

  simulate_rfid_smartevse: >
    curl -X POST "http://192.168.178.86/rfid?rfid=112233445566"

-d toevoegen leek ook niet te werken

@dingo35 ideen?

[ Voor 21% gewijzigd door Driek op 03-06-2026 09:59 ]

[Epsilon]

Ok, even een testje gedaan met mijn auto (Polestar 2). Auto reageert zoals je zou verwachten: Vergevingsgezind.

Mode:
Normal met override.
Procedure:
Pause - Select override - Normal/Smart

EV current uit MID, geverifieerd met andere inline Homewizard meter (ook een MID).
De PWM waarde in EVSE is ~17*A. Deze matched zoals je zou verwachten met de aangegeven laadsnelheid door de EVSE. Dus 6A = PWM 102.
Wat ik niet weet, is hoe de PWM output echt is. Dit bepaalt uiteindelijk wat de auto "Ziet".

Test is op 1 fase.

code:

Override (A)    EV Current
----------------------------------------------------
6A              5.8A
7A              6.5A
8A              7.5A
9A              8.3A
10A             9.4A
11A             10.0A
12A             11.4A
-- Vanaf hier naar Smart ivm loadbalancing 
-- op 25A mains en 20A automaat
10A Smart       9.3A
11A Smart       10.1A
12A Smart       11.2A
13A Smart       12.4A
14A Smart       13.4A
15A Smart       14.1A
16A Smart       15.4A
17A Smart       16.1A           
18A Smart       17.0A       
19A Smart       17.9A       (No override)

[Epsilon]

De test in de vorige post is gedaan om wat data te vergaren voor het volgende:

Wat mij opvalt in Solar mode:
Het gebeurt wel eens, wanneer het overschot weg valt, de auto langzamer laadt dan 6A. Soms wel rond de 4.7A. Dit terwijl de EVSE zegt 6A te sturen (PWM 108).

Meestal is het 5.2A. Wat hierin opvalt, dat dit vrijwel altijd is als er geen overschot is, of net even gecorrigeerd werd.

Als er 6A overschot is, dan wordt er nog steeds 6A naar de auto gestuurd, maar dan laadt de auto met 5.8/5.9A.

De PWM waarde in de \settings is netjes 108 in alle gevallen (6A).

Heeft iemand hetzelfde gedrag?

Het lijkt er bijna op dat er een (over) correctie plaats vindt en met deze waarde een stuk code 1 keer uitgevoerd wordt, maar daarna niet meer. Gevolg: Laadsnelheid wordt niet meer bij geregeld.

Puur een gevoel op het gedrag wat ik zie . Dit kan ook in de auto zitten. Gezien de PWM waarde wel klopt, kan het alleen zitten in de vertaling hiervan naar de aansturing, of in de auto.

[ Voor 3% gewijzigd door Epsilon op 02-06-2026 23:12 ]

[jfoverdijk]

Driek schreef op dinsdag 2 juni 2026 @ 21:29:
Heb je een link naar hoe ik mosquitto_pub gebruik? ik krijg het op github niet direct gevonden


https://github.com/dingo35/SmartEVSE-3.5/blob/master/docs/configuration.md

zoek naar MQTT API

[Driek]

jfoverdijk schreef op woensdag 3 juni 2026 @ 13:49:
[...]

Thanks.

Ik heb nu 3 manieren geprobeerd, maar tot nu toe geen succes:

Script met mqtt publish

YAML:

sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-7157/Set/RFID
      payload: "112233445567"
alias: smartEVSE_simulateRFIDswipe
description: smartEVSE_simulateRFIDswipe

Dit lijkt in ieder geval op de mqtt op de juiste plek te publishen, maar de smartevse accepteert hem niet



Ik heb dit in de configuration yaml geprobeerd:

YAML:

shell_command:
  simulate_rfid_smartevse: >
    curl -X POST "http://192.168.178.86/rfid?rfid=112233445566" -d

als ik deze probeer in de developer tools krijg ik:

YAML:

stdout: ""
stderr: |-
  curl: option -d: requires parameter
  curl: try 'curl --help' or 'curl --manual' for more information
returncode: 2

optie 3 in yaml

YAML:

shell_command:
  simulate_rfid_smartevse_mqtt: >
    mosquitto_pub -h 192.168.178.96 -u driek -P pasw -t 'SmartEVSE-7157/Set/RFID' -m 1234567890

dit geeft deze error in developertools

code:

Failed to perform the action shell_command.simulate_rfid_smartevse_mqtt. Unknown error

Het gekke is dus dat de eerste optie het juiste lijtk te doen als ik de documentatie mag geloven, het publiceert namelijk op de juiste topic, met de verwachtte inhoud, maar er gebeurt niks.

[Adze]

Driek schreef op woensdag 3 juni 2026 @ 16:19:
[...]

Thanks.

Ik heb nu 3 manieren geprobeerd, maar tot nu toe geen succes:

Script met mqtt publish

YAML:

sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-7157/Set/RFID
      payload: "112233445567"
alias: smartEVSE_simulateRFIDswipe
description: smartEVSE_simulateRFIDswipe

Dit lijkt in ieder geval op de mqtt op de juiste plek te publishen, maar de smartevse accepteert hem niet

[Afbeelding]

Ik heb dit in de configuration yaml geprobeerd:

YAML:

shell_command:
  simulate_rfid_smartevse: >
    curl -X POST "http://192.168.178.86/rfid?rfid=112233445566" -d

als ik deze probeer in de developer tools krijg ik:

YAML:

stdout: ""
stderr: |-
  curl: option -d: requires parameter
  curl: try 'curl --help' or 'curl --manual' for more information
returncode: 2

optie 3 in yaml

YAML:

shell_command:
  simulate_rfid_smartevse_mqtt: >
    mosquitto_pub -h 192.168.178.96 -u driek -P pasw -t 'SmartEVSE-7157/Set/RFID' -m 1234567890

dit geeft deze error in developertools

code:

Failed to perform the action shell_command.simulate_rfid_smartevse_mqtt. Unknown error

Het gekke is dus dat de eerste optie het juiste lijtk te doen als ik de documentatie mag geloven, het publiceert namelijk op de juiste topic, met de verwachtte inhoud, maar er gebeurt niks.

Om even zeker te zijn: 192.168.178.96 is je MQTT server ip adres, niet per ongeluk de SmartEVSE?

[Driek]

Adze schreef op woensdag 3 juni 2026 @ 16:44:
[...]

Om even zeker te zijn: 192.168.178.96 is je MQTT server ip adres, niet per ongeluk de SmartEVSE?

yes, dat is mijn HA server, waar ook mqtt opdraait

[Grondgebonden]

Driek schreef op woensdag 3 juni 2026 @ 16:19:
[...]

Thanks.

Ik heb nu 3 manieren geprobeerd, maar tot nu toe geen succes:

Script met mqtt publish

YAML:

sequence:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: false
      qos: 0
      retain: false
      topic: SmartEVSE-7157/Set/RFID
      payload: "112233445567"
alias: smartEVSE_simulateRFIDswipe
description: smartEVSE_simulateRFIDswipe

Dit lijkt in ieder geval op de mqtt op de juiste plek te publishen, maar de smartevse accepteert hem niet

[Afbeelding]

Ik heb dit in de configuration yaml geprobeerd:

YAML:

shell_command:
  simulate_rfid_smartevse: >
    curl -X POST "http://192.168.178.86/rfid?rfid=112233445566" -d

als ik deze probeer in de developer tools krijg ik:

YAML:

stdout: ""
stderr: |-
  curl: option -d: requires parameter
  curl: try 'curl --help' or 'curl --manual' for more information
returncode: 2

optie 3 in yaml

YAML:

shell_command:
  simulate_rfid_smartevse_mqtt: >
    mosquitto_pub -h 192.168.178.96 -u driek -P pasw -t 'SmartEVSE-7157/Set/RFID' -m 1234567890

dit geeft deze error in developertools

code:

Failed to perform the action shell_command.simulate_rfid_smartevse_mqtt. Unknown error

Het gekke is dus dat de eerste optie het juiste lijtk te doen als ik de documentatie mag geloven, het publiceert namelijk op de juiste topic, met de verwachtte inhoud, maar er gebeurt niks.

Je bent wat single quotjes vergeten in je POST commando. Dit staat er in de documentatie:

code:

Examples:
 
   # 6 byte UID (12 hex characters)
    curl -X POST "http://ipaddress/rfid?rfid=112233445566" -d ''
    
    # 7 byte UID (14 hex characters)
    curl -X POST "http://ipaddress/rfid?rfid=11223344556677" -d ''

Ik ben niet thuis in yawl. Onder Ubuntu kan ik in een terminal window gewoon dat mosquitto_pub commando uitvoeren. Misschien kun je dat ook eerst eens uitproberen voordat je verder gaat met je script?

[Geim]

Driek schreef op woensdag 3 juni 2026 @ 16:19:
[...]

Ik heb nu 3 manieren geprobeerd, maar tot nu toe geen succes:

En als je nu eens een externe client zoals MQTTX probeert?