Zelfbouw Laadpaal ervaringen

[Xoliul]

Stefannn schreef op donderdag 21 augustus 2025 @ 13:46:
[...]

Interessant.
Ik regel ook zelf aangezien mijn meter een oud dsmr protocol heeft met enkel totaal power per 10 secondes in plaats van per fase per seconde.
Ik heb geen home assistant maar compleet home brew from scratch (omdat ik in 2008 begon en toen was er geen home assistant.

Voor jou werkt dit waarschijnlijk prima, maar ik wil wat kanttekeningen zetten voor algemeen gebruik.
Correct me if I’m wrong, niet de bedoeling om te beleren maar wel om ellende te voorkomen.
Ik zeg dit dus omdat ik zelf hetzelfde heb gemaakt en op een aantal punten toch echt wel wat complexere code heb.
1/ de “per fase mains bewaking” (Sommigen noemen dat loadbalancing maar die term is geloof ik enkel correct in geval van meerdere smartEVSE’s, maar.. “who cares”). Heb je er niet in zitten. Voor jou in België is dat geen probleem want je “max rider” functie blijft binnen de max kwartier power. Daarmee regel je netjes binnen een laag tarief. Dat is echter wat anders dan de mains bewaking in de smartEVSE. Die regelt strak tegen de max mains aan.
Dat lijkt vergelijkbaar maar dat is het niet. De mains is namelijk afgezekerd dus je moet enerzijds snel terug regelen en anderzijds niet overshooten bij opregelen. In de smartEVSE software zitten daartoe wat filters (is niet extreem moeilijk,.. maar het moet er wel in).
2/ zonder informatie per fase zal je toch moeten zorgen dat alle fases onder de max blijven. Ik heb dat zelf opgelost met een “fail safe” “Max per fase” model. Dat model gaat uit van de totale mains power. Vervolgens worden alle bekende loads (zoals de smartEVSE) daar “met correcte fase allocatie” van af getrokken, dan blijft een “residual mains power over” waarvan je niet weet hoe die over de fases verdeeld is. Ik gebruik dan de “worst case” assumptie dat dat allemaal op 1 fase zit. En vervolgens zorg ik dat die fase onder de max mains blijft.
3/ de waardes komen (bij mij) elke 10 secondes. Dan heb je behoorlijk weinig reactietijd ter beschikking. De hoofd stop kan er uit klappen bij 10 seconden op dubbele Max, of 20 seconden op 1.7x Max. Als je strak op 25A zit en er schakelt ergens een groep van 16A bij dan moet je dus echt binnen 20 seconden terug regelen. En als de meter daar al 10 seconden van opsnoept blijft er voor de api communicatie, regelaar en auto reactie nog maar 10 seconden over.
Kortom… dat heb ik behoorlijk uitgekiend en ook getest door op Max te regelen en grote loads bij te schakelen en naar het stroomverloop te kijken. (Tijdens test de Max instelling ver onder de waarde van de hoofd stop om geen brokken te maken).

Ik weet vrij zeker dat @dingo35 vergelijkbare testen heeft gedaan waardoor het nu bij iedereen goed gaat.

Resumé…..
- Met de “Max rider” blijf je (neem ik aan) ver onder de max mains en dan is dat niet zo belangrijk.
- Ik weet niet of je het gedrag van je regelaar geanalyseerd hebt. Ik mis eigenlijk de nodige informatie met betrekking tot timing. Dan kan je “toevallig” goed zitten maar de timings zijn vrij kritisch, met andere timing kan je zomaar oscillaties hebben (ik heb vrij veel versies moeten maken voordat dat goed zat)
- Ik heb derhalve (op basis van wat je gedeeld hebt) met name grote zorg om dit als “algemene oplossing” te zien.

Er onbtreekt idd wat kritieke info.
Mijn EV lader is 1 fase, maar mijn systeem thuis is 230v 3fase, grote verbruikers zijn dus gespreid.
Mijn DSMR rapporteert om de seconde.
Mijn PV is max 5KW, dus realistisch 20A daarvan.

Kwa terugschakkelen doet hij dat naar wat ik kan zien erg snel, de vertraging zit m helemaal in de link met SmartEVSE, zowel REST als MQTT zijn niet razendsnel. Als de auto de hele dag laadde ontsnapt er zo'n 10% toch naar het net (91% solar self consumption), maar dat heeft ook te maken dat ik met hele amperes werk.
Dat is inderdaad dus wel een nadeel tov built-in balanceren, maar daar heb je mogelijks vertraging van de gerapporteerde cijfers, tenzij je met sensorbox werkt.

Verder was het hele doel van dit systeem net geen hoge pieken trekken, de piektarieven hier willen zeggen dat ik beter even naar een snellader ga als het echt nodig is, ipv dan maandelijks 9Kw piek te hebben (dat zou me 300euro op jaarbasis extra kosten puur aan nettarieven).
Verder kreeg ik de auto met gemak vol op een zonnige dag + nacht aan Solar + 6A boost.

Valt natuurlijk nog te zien wat de winter geeft...

[ Voor 29% gewijzigd door Xoliul op 21-08-2025 16:51 ]

[Stefannn]

Xoliul schreef op donderdag 21 augustus 2025 @ 16:50:
[...]


Er onbtreekt idd wat kritieke info.
Mijn EV lader is 1 fase, maar mijn systeem thuis is 230v 3fase, grote verbruikers zijn dus gespreid.
Mijn DSMR rapporteert om de seconde.
Mijn PV is max 5KW, dus realistisch 20A daarvan.

Kwa terugschakkelen doet hij dat naar wat ik kan zien erg snel, de vertraging zit m helemaal in de link met SmartEVSE, zowel REST als MQTT zijn niet razendsnel. Als de auto de hele dag laadde ontsnapt er zo'n 10% toch naar het net (91% solar self consumption), maar dat heeft ook te maken dat ik met hele amperes werk.
Dat is inderdaad dus wel een nadeel tov built-in balanceren, maar daar heb je mogelijks vertraging van de gerapporteerde cijfers, tenzij je met sensorbox werkt.

Verder was het hele doel van dit systeem net geen hoge pieken trekken, de piektarieven hier willen zeggen dat ik beter even naar een snellader ga als het echt nodig is, ipv dan maandelijks 9Kw piek te hebben (dat zou me 300euro op jaarbasis extra kosten puur aan nettarieven).
Verder kreeg ik de auto met gemak vol op een zonnige dag + nacht aan Solar + 6A boost.

Valt natuurlijk nog te zien wat de winter geeft...

Dank,
Met 1 seconde meter-data zal je inderdaad minder last van oscillatie hebben. Ik dacht dat er geen dsmr zonder informatie per fase op 1 seconde bestond. Dat ze na de Total/10sec naar per_fase/10sec en daarna naar per_fase/sec waren gegaan.
Je zit in België met het kwartier-max systeem. Ik ken het niet exact maar genoeg om de logica van je aanpak te begrijpen.
Blijft staan dat je voor zover ik kan zien geen bewaking op Max stroom per fase hebt om de hoofdstop te beveiligen.
Is voor jou geen probleem omdat je ofwel op de pv, danwel onder je contract limiet wil blijven.
Is wel een probleem als iemand anders dit zonder veel nadenken overneemt.

[Refthoom]

dingo35 schreef op woensdag 20 augustus 2025 @ 20:50:
Ja en vanaf het begin meldde je ook dat je 3.9.1 er overheen geflashed had...
En omdat je geen LCD scherm had is het dan dus gissen of op de achtergrond 3.0.0 of 3.9.1 draait; vandaar dat ik je wees op de 3.9.1 wifi-configuratie mogelijkheden, het komt wel eens voor dat het LCD scherm vreemd doet maar dat de webserver gewoon toegankelijk is.
En ik corrigeer alle foute uitspraken op dit forum, want ik heb meer dan 7000 gebruikers; als die met jouw foutieve flash adressen aan de slag gaan krijgen zij net zo'n puinhoop als jij gecreëerd hebt: bootloader overschreven, partitie-tabel weg en waarschijnlijk is ook je serienummer weg.
Maar goed, hopelijk krijg je eea met platformio weer recht gezet.
Tip: als je serienummer gewist is werkt mDNS niet meer, dus dan moet je op je router kijken welk ip adres hij uitgedeeld heeft....

Je hebt mijn respect om met 7000 gebruikers te dealen.

Ik zou graag iets proberen om platformio te vermijden, wat wellicht ook voor anderen nuttig is die net als ik niet comfortabel zijn in programmeer omgevingen.

Met de espressif tool kan ik nog steeds de esp flashen, als het goed is, en deze tool lijkt de mogelijkheid te hebben om meerdere bin's in te voeren voor het flashen, met voor iedere bin een eigen adres. De firmware zip bevat o.a. firmware.bin, bootloader.bin en partition.bin, die zou ik dan alledrie tegelijk kunnen invoeren om zo hopelijk weer een werkende SmartEVSE te krijgen.

Vraag 1: Zijn deze 3 bin's voldoende of is er meer nodig?
Vraag 2: Welke adres zou ik bij iedere bin moeten opgeven?

Als het lukt zal ik hier een handleiding plaatsen met screenshot zodat anderen er ook iets aan hebben.

[Xoliul]

Stefannn schreef op donderdag 21 augustus 2025 @ 17:42:
[...]

Dank,
Met 1 seconde meter-data zal je inderdaad minder last van oscillatie hebben. Ik dacht dat er geen dsmr zonder informatie per fase op 1 seconde bestond. Dat ze na de Total/10sec naar per_fase/10sec en daarna naar per_fase/sec waren gegaan.
Je zit in België met het kwartier-max systeem. Ik ken het niet exact maar genoeg om de logica van je aanpak te begrijpen.
Blijft staan dat je voor zover ik kan zien geen bewaking op Max stroom per fase hebt om de hoofdstop te beveiligen.
Is voor jou geen probleem omdat je ofwel op de pv, danwel onder je contract limiet wil blijven.
Is wel een probleem als iemand anders dit zonder veel nadenken overneemt.

Ja, correct, had ik misschien moeten vermelden. Mijn doel was eerder om te laten zien dat je een speciaal geval zelf kan creeren via Home Assistant, moesten anderen net zoals mij helemaal verloren geraken in de "API Mains meter" methodes.

[Phyt_]

databeestje schreef op zondag 17 augustus 2025 @ 22:21:
[...]

Aha, als jouw kabel de PP draad doortrekt naar de kast en de 680 ohm niet in de stekker zit kan je dit gewoon weer op die manier aansluiten.

Voor de duidelijkheid, deze weerstand hoeft enkel tussen de PP en de aarde, niet in de SmartEVSE. Sommige laad controllers hebben ook deze zelfde weerstand nodig om te weten hoeveel stroom de kabel kan dragen.

Zover ik weet heeft de SmartEVSE deze aansluiting niet.

Alles werkt, aangesloten zonder weerstand de CP kabel op de SmartEVSE.
Nu alles verder opbouwen.

[Stefannn]

Xoliul schreef op vrijdag 22 augustus 2025 @ 09:41:
[...]


Ja, correct, had ik misschien moeten vermelden. Mijn doel was eerder om te laten zien dat je een speciaal geval zelf kan creeren via Home Assistant, moesten anderen net zoals mij helemaal verloren geraken in de "API Mains meter" methodes.

Ja super,
Begrijp me goed, ik vind de post oprecht leuk.
Erg leerzaam dat je dit "zonder echt een programma te schrijven maar in scriptvorm" met HA voor elkaar hebt gekregen.
Het is meer dat de "tweaker gemeenschap" gevarieerder is dan je zou denken.
Letterlijk... In het ene forum voelde ik me een beetje een klungel mbt tot mijn http kennis, op het ander forum vond men mij een hele piet omdat ik zelfstandig mijn zonneboiler met rockzool had geïsoleerd.
Kortom: "je post is inderdaad heel leerzaam", "maar ik wilde waarschuwen tegen klakkeloos overnemen".

[dingo35]

@Refthoom Dit is het commando dat platformio verstuurt bij het flashen:

"/home/hans/.local/share/pipx/venvs/platformio/bin/python" "/home/hans/.platformio/packages/tool-esptoolpy@1.40501.0/esptool.py" --chip esp32 --port "/dev/ttyUSB0" --baud 460800 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 /usr/local/src/SmartEVSE-3.5/SmartEVSE-3/.pio/build/release/bootloader.bin 0x8000 /usr/local/src/SmartEVSE-3.5/SmartEVSE-3/.pio/build/release/partitions.bin 0xe000 /home/hans/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin 0x10000 .pio/build/release/firmware.bin

[Beer070]

Goedeavond, l
Ik zit op aanraden van @sandergar te kijken naar een smartevse oplossing. Ziet er technisch heel leuk uit. Ik ben nu nog aan het uitzoeken of onze bmw i4 überhaupt 22kw AC laden ondersteunt.
Het andere probleem waar ik mee te maken krijg is de WAF. Niet de Web Application Firewall maar de Wife Acceprance Factor. Hoe hebben jullie dit zo gemaakt dat mijn wederhelft en CEO van ons huishouden zal zeggen: “oh, dat is een leuk kastje bij de voordeur, daar ben ik blij mee”. (Ik heb een 3 fase multi RS Solar met accu’s ook in de kelderkast gekregen, dus je mag uitgaan van buitengewone overredingskracht 😇)

[databeestje]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:00:
Goedeavond, l
Ik zit op aanraden van @sandergar te kijken naar een smartevse oplossing. Ziet er technisch heel leuk uit. Ik ben nu nog aan het uitzoeken of onze bmw i4 überhaupt 22kw AC laden ondersteunt.
Het andere probleem waar ik mee te maken krijg is de WAF. Niet de Web Application Firewall maar de Wife Acceprance Factor. Hoe hebben jullie dit zo gemaakt dat mijn wederhelft en CEO van ons huishouden zal zeggen: “oh, dat is een leuk kastje bij de voordeur, daar ben ik blij mee”. (Ik heb een 3 fase multi RS Solar met accu’s ook in de kelderkast gekregen, dus je mag uitgaan van buitengewone overredingskracht 😇)

Koop een oude EVBox multiline ding of wat het ook was, een nondescript zwart grijze kast waar alles in past. Herkenbaar als een laadpaal, maar zonder een hoog zelfbouw gehalte.

Staan diverse modellen van laadpalen op MP.

[ruud76]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:00:
Hoe hebben jullie dit zo gemaakt dat mijn wederhelft en CEO van ons huishouden zal zeggen: “oh, dat is een leuk kastje bij de voordeur, daar ben ik blij mee”.

Kwestie van geduld: even wachten op een dag met slecht weer waarop de auto bijna leeg is in de ochtend waardoor de CEO toch echt met de fiets door weer en wind moet. Daarna is het kastje een hamerstuk op het directie-overleg verwacht ik.

Zonder gekkigheid: er zijn legio oplossingen. Zelf heb ik het kastje uit het zicht hangen en is alleen dit zichtbaar…

[ Voor 3% gewijzigd door ruud76 op 22-08-2025 22:18 ]

[BarryH]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:00:
Goedeavond, l
Ik zit op aanraden van @sandergar te kijken naar een smartevse oplossing. Ziet er technisch heel leuk uit. Ik ben nu nog aan het uitzoeken of onze bmw i4 überhaupt 22kw AC laden ondersteunt.
Het andere probleem waar ik mee te maken krijg is de WAF. Niet de Web Application Firewall maar de Wife Acceprance Factor. Hoe hebben jullie dit zo gemaakt dat mijn wederhelft en CEO van ons huishouden zal zeggen: “oh, dat is een leuk kastje bij de voordeur, daar ben ik blij mee”. (Ik heb een 3 fase multi RS Solar met accu’s ook in de kelderkast gekregen, dus je mag uitgaan van buitengewone overredingskracht 😇)

Welk kastje?

[Beer070]

ruud76 schreef op vrijdag 22 augustus 2025 @ 22:15:
[...]


Kwestie van geduld: even wachten op een dag met slecht weer waarop de auto bijna leeg is in de ochtend waardoor de CEO toch echt met de fiets door weer en wind moet. Daarna is het kastje een hamerstuk op het directie-overleg verwacht ik.

Zonder gekkigheid: er zijn legio oplossingen. Zelf heb ik het kastje uit het zicht hangen en is alleen dit zichtbaar…

[Afbeelding]

Dat ziet er al heel netjes uit.
Ik mag officieel aan mijn straat niet opladen dus ik zal zoiets in de hal bij de voordeur moeten maken. Met een beetje geluk vraagt ze een keer om een tuinslang voor het geveltuintje en hang ik deze er gewoon stiekem bij.

[BarryH]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:24:
[...]

Dat ziet er al heel netjes uit.
Ik mag officieel aan mijn straat niet opladen dus ik zal zoiets in de hal bij de voordeur moeten maken. Met een beetje geluk vraagt ze een keer om een tuinslang voor het geveltuintje en hang ik deze er gewoon stiekem bij.

Gewoon een brievenbus naast de voordeur waarvan de voordeur open kan en en een kabel in zit

[sandergar]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:00:
Goedeavond, l
Ik zit op aanraden van @sandergar te kijken naar een smartevse oplossing. Ziet er technisch heel leuk uit. Ik ben nu nog aan het uitzoeken of onze bmw i4 überhaupt 22kw AC laden ondersteunt.

De Smart EVSE kan ook laden op 1 fase 6A hoor ...
Er is nog geen auto geweest die problemen heeft met de Smart EVSE.

Suc6 met het directie overleg

[Beer070]

BarryH schreef op vrijdag 22 augustus 2025 @ 22:26:
[...]


Gewoon een brievenbus naast de voordeur waarvan de voordeur open kan en en een kabel in zit

Dat is ook wel een goed idee. Brengt misschien wel verwarring voor de postbode. Als er zo’n zelfde systeem als voor waterleiding zou zijn voor laadkabels met zo’n haspel… dat zou helemaal mooi zijn. Dat kan ik binnen wel wegwerken met een kastje of een paar plankjes, profieltje er in freezen en het lijkt net origineel echt.

[Stefannn]

Beer070 schreef op vrijdag 22 augustus 2025 @ 22:00:
Goedeavond, l
Ik zit op aanraden van @sandergar te kijken naar een smartevse oplossing. Ziet er technisch heel leuk uit. Ik ben nu nog aan het uitzoeken of onze bmw i4 überhaupt 22kw AC laden ondersteunt.
Het andere probleem waar ik mee te maken krijg is de WAF. Niet de Web Application Firewall maar de Wife Acceprance Factor. Hoe hebben jullie dit zo gemaakt dat mijn wederhelft en CEO van ons huishouden zal zeggen: “oh, dat is een leuk kastje bij de voordeur, daar ben ik blij mee”. (Ik heb een 3 fase multi RS Solar met accu’s ook in de kelderkast gekregen, dus je mag uitgaan van buitengewone overredingskracht 😇)

Mijn oplossing.
Alle electronica binnen. Enkel een plug buiten.
Saillant detail, ik wilde hem dwars op de oprit plaatsen maar mijn vrouw vond parallel beter. En ze had heel erg gelijk.
Ook,… slechts 1.50 meter kabel. De paal staat exact naast de plek waar de laadpaal van de auto is. Dat betekent: “geen kabel oprollen”, “geen kabel rotzooi”.
Verder geen enkele authenticatie. In principe kan iedereeen er mee laden. Dat gebeurt echter nooit. Als ik een weekje weg ga schakel ik hem wel af in de meterkast. Hoge WAF: inpluggen en verder geen gedoe. (De dop heb ik er inmiddels ook vanaf geknipt).

Overigens: 11kW laden is zat. Dat is van 0 tot 100% tussen 23:00 en 7:00. Meer heb je eigenlijk nooit nodig.

[ Voor 4% gewijzigd door Stefannn op 22-08-2025 22:39 ]

[Pim57]

Ik ben in Victron NodeRed een OCPP 1.6 test omgeving aan het maken om mijn oude SmartEVSE v1 aan de praat te krijgen met OCPP en Tibber. https://flows.nodered.org...e-red-contrib-ocpp-client

Met tapelectric kan ik verbinding maken en tapelectric ziet mijn gesimuleerde laadpaal ook. OCPP commands uitwisselen werkt hier goed.

Echter met Tibber lukt de connectie niet. Dit heeft te maken dat deze connectie (WebSocket) een AuthorizationToken nodig heeft. Ik heb al de nodige combinaties geprobeerd, maar nog geen succes. In nodered kun je alleen een url opgeven.
Bijvoorbeeld met url wss://zappi.ocpp-s.tibber.com?AuthorizationToken=u4viecm

Heeft iemand dit met nodered wel voor elkaar gekregen? Of weet wat je aan de url mee moet geven?

[dingo35]

Volgens mij maken al velen gebruik van Tibber via OCPP: https://github.com/dingo3...aster/docs/ocpp.md#tibber

[Pim57]

dingo35 schreef op zaterdag 23 augustus 2025 @ 08:09:
Volgens mij maken al velen gebruik van Tibber via OCPP: https://github.com/dingo3...aster/docs/ocpp.md#tibber

Die link ken ik, echter heb ik een oude SmartEVSE v1 zonder OCPP instellingen.

Misschien kan ik het in de source van SmartEVSE vinden hoe je een WebSocket met Authorize kan openen? Weet jij in welk stukje source ik kan gaan zoeken?

[dingo35]

We gebruiken twee libraries van MicroOCPP, daar moet het ergens in verscholen liggen.

Maar als je nog een v1 hebt liggen zou ik toch eens een upgrade naar v3.1 overwegen, de duizenden uren die daarin geïnvesteerd zijn kun je in je eentje niet zo maar inhalen...

[TorpedoX_88]

Heb sinds een aantal weken het volgende gedrag in mijn SmartEVSE (v3.9.1) parameters tijdens het laden van een Seat Mii Electric op 2 fasen en 10 A:



Ik neig een beetje naar iets met de kWh meter (Eastron SDM72D-M V2), wat denken jullie en heeft iemand dit vaker gehad?

[gastje01]

dingo35 schreef op donderdag 21 augustus 2025 @ 15:36:
@sandergar @RonJ Hebben jullie deze versie getest? Geen idee wie gastje01 is ..?
EDIT: Deze versie bedoel ik
https://github.com/dingo35/SmartEVSE-3.5/issues/260

Ik heb deze versie van github nu een paar dagen getest en voor mij werkt t prima nu, schakelt sneller terug wanneer de PV opbrengst instort (wolk). Op deze manier kan ik maximaal m’n overschot in de auto dumpen. Mocht ik meer lading nodig hebben dan m’n PV overschot was die dag, heb ik via HA een automaton die in de nacht naar Smart schakelt om de gewenste SOC te bereiken.

[AirwinB]

@Beer070
Om de laadpaal te obfusceren ...

Zo heb ik het gedaan:


En zonder mandje:


Of je zegt tegen je vrouw: "Ik wil twee laadpalen gaan plaatsen, ééntje voor in de inrit, de ander bij het huis.
Vrouw: "Is dat niet overbodig? Kun je niet beter met één paal beginnen?"
Jij: "Ja, dat is misschien beter ...".

[ Voor 2% gewijzigd door AirwinB op 25-08-2025 07:41 . Reden: De juiste persoon getagged ]

[Beer070]

AirwinB schreef op maandag 25 augustus 2025 @ 07:37:
@Beer070
Om de laadpaal te obfusceren ...

Zo heb ik het gedaan:
[Afbeelding]

En zonder mandje:
[Afbeelding]

Of je zegt tegen je vrouw: "Ik wil twee laadpalen gaan plaatsen, ééntje voor in de inrit, de ander bij het huis.
Vrouw: "Is dat niet overbodig? Kun je niet beter met één paal beginnen?"
Jij: "Ja, dat is misschien beter ...".

Deze heb ik net aan mijn vrouw laten zien met positief resultaat

[Blackraven]

TorpedoX_88 schreef op zondag 24 augustus 2025 @ 19:29:
Heb sinds een aantal weken het volgende gedrag in mijn SmartEVSE (v3.9.1) parameters tijdens het laden van een Seat Mii Electric op 2 fasen en 10 A:

[Afbeelding]

Ik neig een beetje naar iets met de kWh meter (Eastron SDM72D-M V2), wat denken jullie en heeft iemand dit vaker gehad?

Als ik dit zo zie, zou ik zeggen tussen de Eastron en je logging. Want die gele lijn is waarschijnlijk van je P1 meter en die is wel constant.
Hoe log je, direct via Modbus of zitten er nog allerlei stappen tussen zoals de SmartEVSE, MQTT, etc.?
En wat is de polling interval, lijkt op wat gemiste polls.

[Hmmbob]

AirwinB schreef op maandag 25 augustus 2025 @ 07:37:
Of je zegt tegen je vrouw: "Ik wil twee laadpalen gaan plaatsen, ééntje voor in de inrit, de ander bij het huis.
Vrouw: "Is dat niet overbodig? Kun je niet beter met één paal beginnen?"
Jij: "Ja, dat is misschien beter ...".

Onderhandelen als getrouwde man

[creon]

Kan ik ook ergens kiezen om op 1 fase te laden?
Ik heb 2 relais in mijn laadpaal zitten (voor 1 fase en voor 3 fase)
Maar ik zou graag zelf willen kiezen (of home assistant laten bepalen) of er op 1 of op 3 fases geladen wordt
Maar ik zie zo geen keuze knop voor een voorkeur

[Beekforel]

creon schreef op maandag 25 augustus 2025 @ 16:25:
Kan ik ook ergens kiezen om op 1 fase te laden?
Ik heb 2 relais in mijn laadpaal zitten (voor 1 fase en voor 3 fase)
Maar ik zou graag zelf willen kiezen (of home assistant laten bepalen) of er op 1 of op 3 fases geladen wordt
Maar ik zie zo geen keuze knop voor een voorkeur

Dit kun je beinvloeden met de C2 selector. Always off = 1 fase, Always On = 3 fases. Auto = automatisch schakelen.

[creon]

Beekforel schreef op maandag 25 augustus 2025 @ 16:41:
[...]

Dit kun je beinvloeden met de C2 selector. Always off = 1 fase, Always On = 3 fases. Auto = automatisch schakelen.

Dat kan volgens mij alleen als je bij de controller staat?
Ik zie het iig niet terug bij de mqtt en ook niet op de webserver

[Beekforel]

creon schreef op maandag 25 augustus 2025 @ 16:43:
[...]


Dat kan volgens mij alleen als je bij de controller staat?
Ik zie het iig niet terug bij de mqtt en ook niet op de webserver

Ik doe het via HA, wat via MQTT verloopt. Het kan ook via de rest api (enable_C2'.

[creon]

Beekforel schreef op maandag 25 augustus 2025 @ 16:50:
[...]

Ik doe het via HA, wat via MQTT verloopt. Het kan ook via de rest api (enable_C2'.

Heb jij iets aangepast dan?
Ik zie het bij mij er echt niet bij staan

[tukker999]

Beekforel schreef op maandag 25 augustus 2025 @ 16:41:
[...]

Dit kun je beinvloeden met de C2 selector. Always off = 1 fase, Always On = 3 fases. Auto = automatisch schakelen.

Je kunt het hier allemaal lezen.
Ik lees hier regelmatig over het schakelen van 1 naar 3 fase en terug.
Als je het met Domoticz of met HomeAssistant regelt , loop je niet tegen die problemen aan.

[ Voor 18% gewijzigd door tukker999 op 25-08-2025 18:32 ]

[Beekforel]

creon schreef op maandag 25 augustus 2025 @ 17:33:
[...]

Heb jij iets aangepast dan?
Ik zie het bij mij er echt niet bij staan

Ik gebruik deze integratie https://github.com/dingo35/ha-SmartEVSEv3

[TorpedoX_88]

Blackraven schreef op maandag 25 augustus 2025 @ 07:52:
[...]

Als ik dit zo zie, zou ik zeggen tussen de Eastron en je logging. Want die gele lijn is waarschijnlijk van je P1 meter en die is wel constant.
Hoe log je, direct via Modbus of zitten er nog allerlei stappen tussen zoals de SmartEVSE, MQTT, etc.?
En wat is de polling interval, lijkt op wat gemiste polls.

Die gele lijn is inderdaad van de P1 meter.

Loggen gaat via SmartEVSE en via de HA integratie ervan, maar in de SmartEVSE zie ik dezelfde afwijkende waarden.

Polling interval zou ik niet weten, waar zou ik day kunnen zien en/of aan kunnen passen?

[Blackraven]

Ik durf het niet te zeggen, ik heb sinds de installatie van HA m'n meter losgekoppeld van de SmartEVSE en direct met een RS485 dongle aan HA gehangen. Die bepaalt de polling interval van de meter.
Je zou nog de bedrading kunnen controleren of tijdens het laden de display van de meter vergelijken met je HA logging. Heb zelf al eens gehad dat ik een draadje niet onder de klem, maar net naast de klem had zitten, werkte ook niet zo best.

[dingo35]

Voor alle SmartEVSE gebruikers, zojuist release v3.9.2 uitgebracht.

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

Changes:

• fix Slave sticks at 6A when Master not charging in Solar mode
• improved phase switching for enableC2=AUTO, so we switch back to single phase earlier, which improves use of solar power
• initalize Nr_Of_Phases_Charging to prevent unnecessary phase switching after boot
• only correct BatteryCurrent on first phase when EnableC2 is set to <Always Off>
• we got rid of ESPtouch app, now we setup wifi via a rudimentary AP instead of via SmartConfig
• we now have to reboot after having solved an RCM error

[Stefannn]

dingo35 schreef op dinsdag 26 augustus 2025 @ 08:59:
Voor alle SmartEVSE gebruikers, zojuist release v3.9.2 uitgebracht.

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

Changes:

• fix Slave sticks at 6A when Master not charging in Solar mode
• improved phase switching for enableC2=AUTO, so we switch back to single phase earlier, which improves use of solar power
• initalize Nr_Of_Phases_Charging to prevent unnecessary phase switching after boot
• only correct BatteryCurrent on first phase when EnableC2 is set to <Always Off>
• we got rid of ESPtouch app, now we setup wifi via a rudimentary AP instead of via SmartConfig
• we now have to reboot after having solved an RCM error

Ah! Dat de ESPtouch niet meer nodig is vind ik heel erg prettig!
Toen ik mijn smartEVse 2 jaar geleden aanschafte was dat niet nodig.
Op een gegeven moment wel. Vanwege overstap van internet provider moest ik de smartEVSE opnieuw instellen en ik kreeg het aan de praat maar vond het erg vervelend van iets afhankelijk te zijn dat op geen enkele manier gegarandeerd was te blijven bestaan, cq incompatibele wijzigingen zou krijgen.
Top dat het nu niet meer nodig is!
Heel prettig dat alle software nu weer onder eigen beheer is.

[Tassadar32]

Beekforel schreef op maandag 25 augustus 2025 @ 19:04:
[...]

Ik gebruik deze integratie https://github.com/dingo35/ha-SmartEVSEv3

Die lijkt inderdaad wat opties te missen die wel in de API en op mqtt beschikbaar zijn.

[Tassadar32]

Tassadar32 schreef op vrijdag 1 augustus 2025 @ 21:30:
Hier een smartEVSE lader aan het bouwen en loop tegen een probleem aan.

Wat werkt
Laden met fixed kabel, C1 en tijdelijk een Schuko stekker om de box van stroom te voorzien (op max 6A).
RFID reader aansluiten en pas inleren (werkt dus).
Verbinden aan Tap Electric OCPP backend.
Nieuwste Dingo firmware update gedaan.
Home Assistant custom component gekoppeld.

Waar ik klem loop
Ik heb voor de OCPP een EV meter aangesloten, namelijk een Eastron SDM72D-M V2. A en B van de modbus met het groen/groen-wit paar van een solid core CAT6 kabel op elkaar aangesloten en ook de ground van de EVSE en de meter op elkaar aangesloten. In de smartEVSE EV meter op Eastron3F gezet.

Ik kwam er achter dat de meter standaard op modbus address 1 staat terwijl de bij de smartEVSE het address van de EV meter 10 of hoger moet zijn. Dus beide op 20 (decimaal) gezet. Ik krijg nu echter nog steeds een "Can't read EV meter" melding op het scherm van de smartEVSE.

Ik heb met een multimeter gecontroleerd dat alle aansluitingen vanaf de smartEVSE naar de meter goed contact maken en geen weerstand hebben.

Wat is de volgende stap die ik kan nemen om te achterhalen wat hier fout gaat?

Voor anderen die hier mogelijk tegenaan lopen: blijkt een kleine verandering in de SmartEVSE hardware te zijn wat bij een aantal exemplaren van de laatste batch problemen geeft. Op te lossen door omruilen bij Stegen of een pull-up weerstandje op de print bij te solderen. Meer info op github.

[Beekforel]

Tassadar32 schreef op dinsdag 26 augustus 2025 @ 15:03:
[...]


Die lijkt inderdaad wat opties te missen die wel in de API en op mqtt beschikbaar zijn.

Wanneer je wat mist kun je dat bij @dingo35 op die Git repo aanvragen volgens mij.

[Hmmbob]

Beekforel schreef op dinsdag 26 augustus 2025 @ 15:32:
[...]

Wanneer je wat mist kun je dat bij @dingo35 op die Git repo aanvragen volgens mij.

Nee, die adviseert juist van deze integratie naar MQTT over te stappen.

quote: https://github.com/dingo3.../tree/master/integrations

Easy integration with Home Assistant
If you want to integrate your SmartEVSE with Home Asisstant, the preferred way is to have the HA MQTT integration installed, and interface with SmartEVSE through MQTT.

The SmartEVSE custom_component for Home Assistant is considered deprecated.

[Beekforel]

Hmmbob schreef op dinsdag 26 augustus 2025 @ 16:12:
[...]

Nee, die adviseert juist van deze integratie naar MQTT over te stappen.


[...]

Ooo my bad, ik zat op het verkeerde spoor.
Ik gebruik inderdaad ook de MQTT variant.

[Hmmbob]

Beekforel schreef op dinsdag 26 augustus 2025 @ 16:30:
[...]

Ooo my bad, ik zat op het verkeerde spoor.
Ik gebruik inderdaad ook de MQTT variant.

Ik heb wat documentatie PRs ingediend bij @dingo35 om beter aan te duiden dat MQTT de voorkeur heeft. Scheelt mogelijk weer verwarring.

[Tassadar32]

Hmmbob schreef op dinsdag 26 augustus 2025 @ 17:08:
[...]

Ik heb wat documentatie PRs ingediend bij @dingo35 om beter aan te duiden dat MQTT de voorkeur heeft. Scheelt mogelijk weer verwarring.

Zag inderdaad dat de HA integratie nog steeds als eerste in de docs stond.

Weet iemand ook of C2 aan/uit via MQTT te doen is? Heb de smartEVSE nu in HA maar zie geen entity om de C2 te schakelen (wisselen tussen 1/3-fase).

[dingo35]

https://github.com/dingo3...configuration.md#mqtt-api

[Tassadar32]

dingo35 schreef op dinsdag 26 augustus 2025 @ 19:56:
https://github.com/dingo3...configuration.md#mqtt-api

Duidelijk, ik zat alleen bij entities te kijken en er word voor C2 dus geen entity aangemaakt waardoor deze niet by default in HA zichtbaar (en wijzigbaar) is. Zal eens in de code gaan bladeren om te kijken of ik daar een pull request voor kan maken.

[RonJ]

dingo35 schreef op dinsdag 26 augustus 2025 @ 08:59:
Voor alle SmartEVSE gebruikers, zojuist release v3.9.2 uitgebracht.

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

Changes:

• fix Slave sticks at 6A when Master not charging in Solar mode
• improved phase switching for enableC2=AUTO, so we switch back to single phase earlier, which improves use of solar power
• initalize Nr_Of_Phases_Charging to prevent unnecessary phase switching after boot
• only correct BatteryCurrent on first phase when EnableC2 is set to <Always Off>
• we got rid of ESPtouch app, now we setup wifi via a rudimentary AP instead of via SmartConfig
• we now have to reboot after having solved an RCM error

Hiermee even getest, ik zie 'm iig terugschakelen naar 1P en weer terug naar 3P op solar.


Ik blijf nu alleen op Smart mode vasthangen op 1-fase laden, zie ook niet echt een mogelijkheid om weer naar 3-fase laden te switchen.

[dingo35]

In Smart mode met C2=AUTO start hij altijd in 3p; als je tussendoor van mode switched zonder via OFF te gaan kan het zijn dat je in 1p terecht komt, maar dan zou hij op moeten schakelen....
Misschien moet ik C2=AUTO maar negeren in Smart mode, het is uiteindelijk voornamelijk nuttig in Solar mode ...

[RonJ]

Misschien heb ik te kort gewacht, zag na een paar minuten nog geen indicatie/aanstalten om op te gaan schakelen. Ga ik via OFF, dan mag ik weer opnieuw de tag gaan aanbieden want dan knalt ie de OCPP sessie eruit.

Ik verwacht (maar dat is ook maar mijn verwachting) in Smart iig dat ie meteen dan wel zsm naar 3P gaat, voor mij heeft het iig weinig nut om phase switching te hebben in smart, maar dat kan voor anderen natuurlijk weer anders zijn (als je écht grote verbruikers naast de EV hebt). Dus misschien juist wel beter om daar gewoon dezelfde code te gebruiken als in solar, maar dan met MAX mains als target ipv zero import. Ik zal het nog eens proberen te testen en wat langer wachten.

[ Voor 16% gewijzigd door RonJ op 27-08-2025 18:09 ]

[TorpedoX_88]

Blackraven schreef op dinsdag 26 augustus 2025 @ 08:53:
Ik durf het niet te zeggen, ik heb sinds de installatie van HA m'n meter losgekoppeld van de SmartEVSE en direct met een RS485 dongle aan HA gehangen. Die bepaalt de polling interval van de meter.
Je zou nog de bedrading kunnen controleren of tijdens het laden de display van de meter vergelijken met je HA logging. Heb zelf al eens gehad dat ik een draadje niet onder de klem, maar net naast de klem had zitten, werkte ook niet zo best.

Bedankt voor je reactie!

Bedoel je qua bedrading die van de communicatie of van de voeding? Dat laatste kan ik me bijna niet voorstellen, want dan zou de P1 meter ook geen volledig vermogen moeten meten toch?

[Tassadar32]

Laadpaal aangesloten op de plek waar de oude hing. Nu ook 3-fase kunnen testen (werkt!) en wat zitten spelen. Observatie: als je geen mains meter hebt en je zet de lader op "Smart" zal deze altijd maar met 6A laden. Verbaasde me even aangezien ik em op 10A gezet had en de auto aangaf dat er maar 6A per fase beschikbaar was. Op de "Normal" mode volgt ie wel gewoon netjes de max amperage.

Morgen even verder knutselen om de P1 meter waardes naar de smartEVSE te sturen zodat de smart modus als het goed is ook helemaal werkt.

[jpiscaer]

dingo35 schreef op woensdag 27 augustus 2025 @ 17:55:
In Smart mode met C2=AUTO start hij altijd in 3p; als je tussendoor van mode switched zonder via OFF te gaan kan het zijn dat je in 1p terecht komt, maar dan zou hij op moeten schakelen....
Misschien moet ik C2=AUTO maar negeren in Smart mode, het is uiteindelijk voornamelijk nuttig in Solar mode ...

Dit gedrag heb ik ook eerder gemerkt, dat als 'ie een solar sessie eindigt in 1P, de smart sessie daarna ook 1P is/blijft.

[dingo35]

Wat gebruikers van C2=AUTO zich moeten realiseren is dat je niet van 1p naar 3p of omgekeerd kunt schakelen zonder de sessie te beēindigen!

Het domweg aan of uit schakelen van het C2 relais veroorzaakt onvoorspelbare fouten, afhankelijk van het EV. Dus om betrouwbaar te schakelen moet de laadsessie beēindigd en weer opnieuw opgebouwd worden.

[Beekforel]

dingo35 schreef op donderdag 28 augustus 2025 @ 07:56:
Wat gebruikers van C2=AUTO zich moeten realiseren is dat je niet van 1p naar 3p of omgekeerd kunt schakelen zonder de sessie te beēindigen!

Het domweg aan of uit schakelen van het C2 relais veroorzaakt onvoorspelbare fouten, afhankelijk van het EV. Dus om betrouwbaar te schakelen moet de laadsessie beēindigd en weer opnieuw opgebouwd worden.

Dat regelt de software toch?

Op een wat wisselende dag bestookt de Tesla app mij met notificaties over gestopte laadsessies. Maar ach er zijn ergere dingen.

[jpiscaer]

dingo35 schreef op donderdag 28 augustus 2025 @ 07:56:
Wat gebruikers van C2=AUTO zich moeten realiseren is dat je niet van 1p naar 3p of omgekeerd kunt schakelen zonder de sessie te beēindigen!

Het domweg aan of uit schakelen van het C2 relais veroorzaakt onvoorspelbare fouten, afhankelijk van het EV. Dus om betrouwbaar te schakelen moet de laadsessie beēindigd en weer opnieuw opgebouwd worden.

goede verduideljking inderdaad, maar volgens mij blijft mijn punt staan dat de laadpaal regelmatig een 1P Smart sessie start terwijl ik een 3P Smart sessie zou verwachten?

[RonJ]

jpiscaer schreef op woensdag 27 augustus 2025 @ 20:44:
[...]

Dit gedrag heb ik ook eerder gemerkt, dat als 'ie een solar sessie eindigt in 1P, de smart sessie daarna ook 1P is/blijft.

Dat is precies wat er gebeurde idd, solar stond op 1P, auto was nog niet vol genoeg dus schakelde naar Smart, die dan op 1P bleef hangen. Wat op zich helemaal niet erg is, als ie dan na enkele minuten oid maar opschakelt naar 3P (uiteraard door eerst het laden te stoppen richting de auto, schakelen onder load is een slecht idee). Maar dat gebeurde (nog) niet gisteren.

Heb gisteren geen tijd meer gehad (moest weg) om het nog eens te testen en wat langer te wachten, dat zal ik v/d week nog even doen. Gisteravond een nieuwe sessie op Smart gestart en dan was het natuurlijk wel weer goed op 3P.

[ Voor 7% gewijzigd door RonJ op 28-08-2025 09:20 ]

[THM0]

jpiscaer schreef op donderdag 28 augustus 2025 @ 09:09:
[...]

goede verduideljking inderdaad, maar volgens mij blijft mijn punt staan dat de laadpaal regelmatig een 1P Smart sessie start terwijl ik een 3P Smart sessie zou verwachten?

1P Smart heeft weinig zin. De SmartEVSE heeft geen weet van de eigen belasting op een individuele fase en zal de laadstroom gaan knijpen als één van de fases overbelast stijgt te raken. Ook als deze op 1-fase laadt en die fase niet overbelast raakt.

[Blackraven]

TorpedoX_88 schreef op woensdag 27 augustus 2025 @ 19:48:
[...]

Bedankt voor je reactie!

Bedoel je qua bedrading die van de communicatie of van de voeding? Dat laatste kan ik me bijna niet voorstellen, want dan zou de P1 meter ook geen volledig vermogen moeten meten toch?

Van de communicatie, want zo te zien aan je P1 meter werkt je lader wel continu.

[adjego]

RonJ schreef op donderdag 28 augustus 2025 @ 09:18:
[...]


Dat is precies wat er gebeurde idd, solar stond op 1P, auto was nog niet vol genoeg dus schakelde naar Smart, die dan op 1P bleef hangen. Wat op zich helemaal niet erg is, als ie dan na enkele minuten oid maar opschakelt naar 3P (uiteraard door eerst het laden te stoppen richting de auto, schakelen onder load is een slecht idee). Maar dat gebeurde (nog) niet gisteren.

Heb gisteren geen tijd meer gehad (moest weg) om het nog eens te testen en wat langer te wachten, dat zal ik v/d week nog even doen. Gisteravond een nieuwe sessie op Smart gestart en dan was het natuurlijk wel weer goed op 3P.

Om dit dus wel naar 3P te laten gaan moet je eerst even het laden stoppen, en dan vervolgens smart starten. Alleen Solar modus doet iets met het schakelen tussen 1 en 3 fase. Precies dus ook want @dingo35 aangeeft.

Hoe lang had je gewacht tussen het uitschakelen en het laden weer starten?

[ Voor 8% gewijzigd door adjego op 28-08-2025 10:39 ]

[RonJ]

adjego schreef op donderdag 28 augustus 2025 @ 10:37:
[...]


Om dit dus wel naar 3P te laten gaan moet je eerst even het laden stoppen, en dan vervolgens smart starten. Alleen Solar modus doet iets met het schakelen tussen 1 en 3 fase. Precies dus ook want @dingo35 aangeeft.

Hoe lang had je gewacht tussen het uitschakelen en het laden weer starten?

Ja, maar dat zou de firmware dus automatisch moeten doen wanneer je van solar naar smart schakelt, meteen naar 3P (geen 1/3P schakellogica) of na een x seconde timerperiode (hergebruik schakellogica van solarmode) is me verder om het even.

In dit geval bleef toen dus de Smart mode op 1P hangen. Toen drukte ik uit gewoonte (of eigenlijk omdat de HA integratie niet meer bijgewerkt wordt met bijv. de paused mode en ik (nog) geen zin/tijd heb gehad alles opnieuw op te bouwen met MQTT) op Off ipv Paused maar dan wordt de OCPP sessie afgebroken en kan je niet meer laden. Toen moest ik dus naar buiten lopen met de RFID tag om weer te kunnen herstarten.

[BarryH]

Beetje offtopic, maar ik denk dat ik hier de grootste kans op een goed antwoord heb:

Omvormers hebben een beveiliging zodat ze bij overvoltage en/of te hoge AC wisselstroom frequentie terugregelen/afslaan (voorkomt overbelasting net)
Laadpalen/EVs hebben - voorzover ik weet - niet iets vergelijkbaars bij te laag voltage/ te lage frequentie.
Klopt dit of zijn daar wel regels/mechanismes voor?

[RonJ]

BarryH schreef op donderdag 28 augustus 2025 @ 10:55:
Beetje offtopic, maar ik denk dat ik hier de grootste kans op een goed antwoord heb:

Omvormers hebben een beveiliging zodat ze bij overvoltage en/of te hoge AC wisselstroom frequentie terugregelen/afslaan (voorkomt overbelasting net)
Laadpalen/EVs hebben - voorzover ik weet - niet iets vergelijkbaars bij te laag voltage/ te lage frequentie.
Klopt dit of zijn daar wel regels/mechanismes voor?

Dat is allemaal aan de auto, waar de daadwerkelijke lader in zit. Dat zal per fabrikant verschillen.

Een laadpaal is in feite alleen een veredeld relais en een simpel PWM-stuursignaaltje naar de auto met hoeveel A's er getrokken mogen worden.

[mukky]

BarryH schreef op donderdag 28 augustus 2025 @ 10:55:
Beetje offtopic, maar ik denk dat ik hier de grootste kans op een goed antwoord heb:

Omvormers hebben een beveiliging zodat ze bij overvoltage en/of te hoge AC wisselstroom frequentie terugregelen/afslaan (voorkomt overbelasting net)
Laadpalen/EVs hebben - voorzover ik weet - niet iets vergelijkbaars bij te laag voltage/ te lage frequentie.
Klopt dit of zijn daar wel regels/mechanismes voor?

Hangt van de laadpaal af. Ik had eens een (OEM) Ratio laadpaal en deze signaleerde keurig een te lage spanning en meldde dat via OCPP. De Alfen laadpaal die ik hier heb detecteert ook de frequentie.

[BarryH]

mukky schreef op donderdag 28 augustus 2025 @ 14:15:
[...]


Hangt van de laadpaal af. Ik had eens een (OEM) Ratio laadpaal en deze signaleerde keurig een te lage spanning en meldde dat via OCPP. De Alfen laadpaal die ik hier heb detecteert ook de frequentie.

Maar is er ook een actie? (b.v. laadvermogen reduceren, beetje het omgekeerde van de zonnepanelenomvormer)

[mukky]

BarryH schreef op donderdag 28 augustus 2025 @ 14:22:
[...]


Maar is er ook een actie? (b.v. laadvermogen reduceren, beetje het omgekeerde van de zonnepanelenomvormer)

Niet naar mijn weten. Spanningsval (of overspanning) kan vele oorzaken hebben en die zijn door een laadpaal niet na te gaan

[Tassadar32]

Hier vandaag weinig zon helaas. Probeerde net de SmartEVSE van Solar naar Smart te schakelen maar deze start niet met laden. Mogelijk een bug met switchen van Solar naar Smart als laden gepauzeerd is wegens niet genoeg vermogen beschikbaar?

[BarryH]

Tassadar32 schreef op vrijdag 29 augustus 2025 @ 15:38:
Hier vandaag weinig zon helaas. Probeerde net de SmartEVSE van Solar naar Smart te schakelen maar deze start niet met laden. Mogelijk een bug met switchen van Solar naar Smart als laden gepauzeerd is wegens niet genoeg vermogen beschikbaar?

even via off?

[Tassadar32]

BarryH schreef op vrijdag 29 augustus 2025 @ 16:33:
[...]

even via off?

Geprobeerd, dat werkte ook niet. Ook auto loskoppelen en een nieuwe laadsessie werkte niet. Op het scherm bleef "1p -> 3p" staan. Uiteindelijk een herstart gegeven en toen werkte het weer. Zal kijken of ik het morgen kan reproduceren en dan met de debug build info verzamelen voor een bug report.

[jpiscaer]

Tassadar32 schreef op vrijdag 29 augustus 2025 @ 20:00:
[...]


Geprobeerd, dat werkte ook niet. Ook auto loskoppelen en een nieuwe laadsessie werkte niet. Op het scherm bleef "1p -> 3p" staan. Uiteindelijk een herstart gegeven en toen werkte het weer. Zal kijken of ik het morgen kan reproduceren en dan met de debug build info verzamelen voor een bug report.

ja, dat gedrag herken ik, alleen met een reboot gaat 'ie terug naar 3P als een solar 1P gestopt is en ik daarna een smart sessie start.

[Tassadar32]

In dit geval was het dus tijdens een Solar sessie die gepauzeerd was op 1P dat ik probeerde te switchen naar Smart, maar het lijkt inderdaad alsof daar nog ergens een bug zit.

[m.eddy]

Tassadar32 schreef op zaterdag 30 augustus 2025 @ 14:56:
In dit geval was het dus tijdens een Solar sessie die gepauzeerd was op 1P dat ik probeerde te switchen naar Smart, maar het lijkt inderdaad alsof daar nog ergens een bug zit.

Dat gaat bij 3.9.0 iig prima. Solar -> pause -> Smart werkt prima binnen een ocpp sessie. Wel handmatig uiteraard.

[sanderb2001]

sanderb2001 schreef op donderdag 21 augustus 2025 @ 12:48:
Mijn zelfbouw-laadpaalproject heeft weer wat aandacht gekregen, maar ik krijg het helaas nog steeds niet werkend zoals ik denk dat het zou moeten/kunnen. Misschien kunnen jullie nog eens meedenken.

Ik loop tegen het probleem aan dat ik de koppeling met TAP niet goed werkend krijg. Tenminste, er is wel een koppeling, maar de RFID-communicatie lijkt niet goed te gaan. Er was eerder een andere user @Adze die ongeveer hetzelfde probleem had. Dit is op GitHub verder uitgezocht en hiervoor is een "fix" geplaatst (https://github.com/dingo35/SmartEVSE-3.5/issues/247). Helaas heeft dit bij mij ook niet geholpen. Ik ben net wat gaan experimenteren en zie daarbij wat vreemd gedrag waar ik jullie feedback op wil vragen.

Als ik alle RFID’s verwijder via het menu en "DeleteAll" doe, accepteert hij nog steeds alle RFID’s. Zelfs als ik de instelling op "EnableOne" zet, accepteert hij nog steeds alle kaarten. Wat ik ook apart vind, is dat ik SWITCH op Disabled heb staan. In de help docs staat: A push button can be used to stop charging.
Maar met de instelling op Disabled kan ik alsnog het laden starten via de push button. Ook kan ik het laden stoppen met elke willekeurige RFID-kaart...

Klopt dit gedrag?
Ik herinner me nog dat toen ik alles bij Stegen had besteld en wat aan het testen was, ik ook problemen had met de RFID-lezer. Toen kreeg ik in Home Assistant bij RFIDLastRead alleen FFFFFFFFFFFF. Stegen heeft toen voor mij een custom firmware gemaakt. Daarna leek het goed te werken. Nu krijg ik bij RFIDLastRead echter alleen nog maar 00000000000000.

Ik heb de laatste firmware erop staan, en de push button en RFID-lezer zijn direct bij Stegen gekocht.
Het zou fijn zijn als ik het toch ooit werkend krijg :-)

Alvast bedankt!

Mijn update over het 1-Wire probleem
Ik denk dat ik eindelijk weet waar mijn issues vandaan komen: de kabels. Misschien heb ik de extremen wat opgezocht.
Ik heb de socket, drukknop en RFID-lezer in een apart kastje zitten, met ±20 m kabel ertussen.

Voor de knop en RFID gebruik ik deze Cat6 F/UTP grondkabel:
https://www.elektramat.nl...at-6-grondkabel-per-meter

Voor PP, CP en de lockmotor gebruik ik deze signaalkabel:
https://www.elektramat.nl...-s2-d0-a3-groen-per-meter

Op de werkbank, vóór het trekken van de kabels door de mantelbuis, werkte alles prima.

Maar omdat het gedrag zo vreemd was ben ik eerst gaan uitzoeken hoe een 1-Wire signaal er normaal uitziet. Het blijkt een soort PWM-achtig patroon te zijn waarbij een ‘1’ een korte LOW-puls is (~6 µs) en een ‘0’ een langere. Dat triggerde me om de scoop erbij te pakken.

Eerst heb ik besloten om de boel te resetten en opnieuw te beginnen, met de RFID-lezer direct (kort kabeltje) op de SmartEVSE aangesloten. Toen werkte het ook meteen prima.

Met de PicoScope kon ik de pulsen netjes zien: korte kabel → mooi signaal.

Met 20 m UTP ertussen → de opgaande flank werd te traag. De puls haalt soms de 3,3 V niet binnen het tijdslot → bit wordt niet herkend?

Belangrijk: mijn probe is 1× (dus voegt zelf ook capacitantie toe). Met een 10× probe zou het beeld waarschijnlijk iets beter zijn.

Wat me verbaast:
Met een simpel huishoudsnoer van 10 m werkte het ineens wél.

Die heeft een lagere weerstand (0,8 Ω over 10 m) dan de UTP (2,5 Ω over 20 m), maar mijn gevoel zegt dat vooral de capaciteit van de kabel het verschil maakt.

In theorie: de tijdconstante is τ = R·C. Na 3·τ zit je pas rond 95% van de uiteindelijke spanning.

Bij hoge capaciteit → trage stijgflank → signaal haalt logische “1” niet op tijd.

Ik heb geprobeerd de capaciteit van de UTP te meten met mijn Fluke, maar daar kwam niks bruikbaars uit (te laag voor dat toestel?).

Vraag:
Ik snap nog niet helemaal waarom de UTP het zoveel slechter doet dan dat simpele snoertje. Ligt het inderdaad aan een hogere capaciteit? Of doe ik iets anders verkeerd? En belangrijker: wat zou een goede oplossing zijn?

Alle tips zijn welkom!

[Stefannn]

sanderb2001 schreef op zaterdag 30 augustus 2025 @ 20:55:
[...]

Mijn update over het 1-Wire probleem
Ik denk dat ik eindelijk weet waar mijn issues vandaan komen: de kabels. Misschien heb ik de extremen wat opgezocht.
Ik heb de socket, drukknop en RFID-lezer in een apart kastje zitten, met ±20 m kabel ertussen.

Voor de knop en RFID gebruik ik deze Cat6 F/UTP grondkabel:
https://www.elektramat.nl...at-6-grondkabel-per-meter

Voor PP, CP en de lockmotor gebruik ik deze signaalkabel:
https://www.elektramat.nl...-s2-d0-a3-groen-per-meter

Op de werkbank, vóór het trekken van de kabels door de mantelbuis, werkte alles prima.

Maar omdat het gedrag zo vreemd was ben ik eerst gaan uitzoeken hoe een 1-Wire signaal er normaal uitziet. Het blijkt een soort PWM-achtig patroon te zijn waarbij een ‘1’ een korte LOW-puls is (~6 µs) en een ‘0’ een langere. Dat triggerde me om de scoop erbij te pakken.

Eerst heb ik besloten om de boel te resetten en opnieuw te beginnen, met de RFID-lezer direct (kort kabeltje) op de SmartEVSE aangesloten. Toen werkte het ook meteen prima.

Met de PicoScope kon ik de pulsen netjes zien: korte kabel → mooi signaal.

Met 20 m UTP ertussen → de opgaande flank werd te traag. De puls haalt soms de 3,3 V niet binnen het tijdslot → bit wordt niet herkend?

Belangrijk: mijn probe is 1× (dus voegt zelf ook capacitantie toe). Met een 10× probe zou het beeld waarschijnlijk iets beter zijn.

Wat me verbaast:
Met een simpel huishoudsnoer van 10 m werkte het ineens wél.

Die heeft een lagere weerstand (0,8 Ω over 10 m) dan de UTP (2,5 Ω over 20 m), maar mijn gevoel zegt dat vooral de capaciteit van de kabel het verschil maakt.

In theorie: de tijdconstante is τ = R·C. Na 3·τ zit je pas rond 95% van de uiteindelijke spanning.

Bij hoge capaciteit → trage stijgflank → signaal haalt logische “1” niet op tijd.

Ik heb geprobeerd de capaciteit van de UTP te meten met mijn Fluke, maar daar kwam niks bruikbaars uit (te laag voor dat toestel?).

Vraag:
Ik snap nog niet helemaal waarom de UTP het zoveel slechter doet dan dat simpele snoertje. Ligt het inderdaad aan een hogere capaciteit? Of doe ik iets anders verkeerd? En belangrijker: wat zou een goede oplossing zijn?

Alle tips zijn welkom!

Hoi,..
Ik trigger op het woord “1-wire”.
Ik weet helemaal niet hoe dat in de smartEVSE zit maar ik heb mijn home automation wel compleet met 1wire uitgerust.
Het stamt uit 2008 en ik heb toen alle drivers zelf geschreven en ook hardware matig het nodige gedubugged.
Het is geheid oplosbaar maar ik weet niet exact hoe het in de smartEVSE geïmplementeerd is.
Ik maak gebruik van de usb-1wire interface component en daarvan kan je reactietijden instellen.
Geen idee hoe smartevse dat doet.
Wordt er gebruik gemaakt van een aparte 5V? Of parasitaire voeding?
Ik gebruik “vaste 5V voeding” en heb op al mijn 1wire sensoren een simpel RC filter van 100ohm, 10uFop de 5V voeding gezet omdat het “in bedrijf komen van de sensor een dip op de voeding kan geven die de communicatie vernaggelt”. Direct op de sensor.
Ik heb iets van 50 sensoren. Alles aangesloten met simpel utp uit 2008. Lengte tot een meter of 40.

Eventueel in dm kan ik nog wel meer tips geven. Moet ik wel complete schema zien.

[dingo35]

https://github.com/dingo3...schematic/SmartEVSEv3.pdf

[Stefannn]

dingo35 schreef op zondag 31 augustus 2025 @ 08:17:
https://github.com/dingo3...schematic/SmartEVSEv3.pdf

Dank,
Maar.. als ik het goed begrijp heeft @sanderb2001 problemen met de externe rfid lezer via 1wire.
Ik heb zelf geen rfid lezer dus ik weet niet precies hoe dat werkt.
Eerlijk gezegd zie ik de aansluiting daarvan ook niet op het schema (maar dat kan aan mij liggen, ik heb de lezer immers niet dus weet er niet zoveel van).
ik weet wel veel van 1wire (als is dat erg roestig nu).

[dingo35]

https://www.stegen.com/en...tachment&id_attachment=14

[mjvdzwet]

sanderb2001 schreef op zaterdag 30 augustus 2025 @ 20:55:
[...]

Mijn update over het 1-Wire probleem
Ik denk dat ik eindelijk weet waar mijn issues vandaan komen: de kabels. Misschien heb ik de extremen wat opgezocht.
Ik heb de socket, drukknop en RFID-lezer in een apart kastje zitten, met ±20 m kabel ertussen.

Voor de knop en RFID gebruik ik deze Cat6 F/UTP grondkabel:
https://www.elektramat.nl...at-6-grondkabel-per-meter

Voor PP, CP en de lockmotor gebruik ik deze signaalkabel:
https://www.elektramat.nl...-s2-d0-a3-groen-per-meter

Op de werkbank, vóór het trekken van de kabels door de mantelbuis, werkte alles prima.

Maar omdat het gedrag zo vreemd was ben ik eerst gaan uitzoeken hoe een 1-Wire signaal er normaal uitziet. Het blijkt een soort PWM-achtig patroon te zijn waarbij een ‘1’ een korte LOW-puls is (~6 µs) en een ‘0’ een langere. Dat triggerde me om de scoop erbij te pakken.

Eerst heb ik besloten om de boel te resetten en opnieuw te beginnen, met de RFID-lezer direct (kort kabeltje) op de SmartEVSE aangesloten. Toen werkte het ook meteen prima.

Met de PicoScope kon ik de pulsen netjes zien: korte kabel → mooi signaal.

Met 20 m UTP ertussen → de opgaande flank werd te traag. De puls haalt soms de 3,3 V niet binnen het tijdslot → bit wordt niet herkend?

Belangrijk: mijn probe is 1× (dus voegt zelf ook capacitantie toe). Met een 10× probe zou het beeld waarschijnlijk iets beter zijn.

Wat me verbaast:
Met een simpel huishoudsnoer van 10 m werkte het ineens wél.

Die heeft een lagere weerstand (0,8 Ω over 10 m) dan de UTP (2,5 Ω over 20 m), maar mijn gevoel zegt dat vooral de capaciteit van de kabel het verschil maakt.

In theorie: de tijdconstante is τ = R·C. Na 3·τ zit je pas rond 95% van de uiteindelijke spanning.

Bij hoge capaciteit → trage stijgflank → signaal haalt logische “1” niet op tijd.

Ik heb geprobeerd de capaciteit van de UTP te meten met mijn Fluke, maar daar kwam niks bruikbaars uit (te laag voor dat toestel?).

Vraag:
Ik snap nog niet helemaal waarom de UTP het zoveel slechter doet dan dat simpele snoertje. Ligt het inderdaad aan een hogere capaciteit? Of doe ik iets anders verkeerd? En belangrijker: wat zou een goede oplossing zijn?

Alle tips zijn welkom!

Je kan nog kijken of een terminator weerstand helpt.

Daarnaast weet ik niet wat voor signaal er op de andere ader van het twisted pair staat.

[dingo35]

1wire gebruikt géén terminator weerstanden!

[Stefannn]

dingo35 schreef op zondag 31 augustus 2025 @ 08:37:
https://www.stegen.com/en...tachment&id_attachment=14

dank,
@sanderb2001
Er zit dus een 12V als voeding op de rfid lezer. Ik neem aan dat die intern verlaagd wordt.
In ieder geval kan je proberen betreffende voeding wat te stabiliseren door op de rfid lezer tussen 12V en ground 10uF te zetten en de 12V via een 100ohm weerstand aan te sluiten.
Ik heb al mijn ongeveer 50 DS18S20 sensoren op die manier met "local stabilisatie" aangesloten en dat heeft alle storingen opgelost.
Verder is me niet exact duidelijk welke draad voor 1-wire communicatie wordt gebruikt maar ik gok de SW aansluiting (de red en grn zijn immers pure outputs). Op de smartEVSE zit een 10k weerstand R13 als pull-up naar 3.3V. 10k is vrij hoog. Op applicatie schemas van 1wire zie ik 2.2k tot 5k weerstanden.
Dus... je kan proberen R13 te overbruggen met 10k.

zoals @dingo35 zegt: GEEN afsluitweerstand.

[sanderb2001]

Thnx voor de input!
Ik gebruik geen afsluitweerstand o.i.d.
Ik denk dat deze RFID-lezer erbij wordt verkocht: https://drexia.pl/en/stro...rfid-reader-1356-mhz.html
. Op die site staat ook een pdf met het elektrische schema.

Hans had het schema van de SmartEVSE al gedeeld. De RFID wordt inderdaad op sw aangesloten. Zelf ben ik niet helemaal thuis in het aanpassen van de pull-up weerstand. Ik ga kijken of ik het kan verbeteren zonder de SmartEVSE open te maken.

Supercool dat je zo actief meedenkt!

[dingo35]

Pak eens wat andere aders, bijv. SW en GND op andere twisted pairs, dan zal de capaciteit vermoedelijk een stuk minder zijn.

[mjvdzwet]

dingo35 schreef op zondag 31 augustus 2025 @ 10:17:
1wire gebruikt géén terminator weerstanden!

Dat weet ik, maar het kan soms helpen om het signaal de juiste kant op te trekken, dus meet eennpull up of down.

De twisted pair kan ook het probleem zijn.

[mjvdzwet]

sanderb2001 schreef op zaterdag 30 augustus 2025 @ 20:55:
[...]

Mijn update over het 1-Wire probleem
Ik denk dat ik eindelijk weet waar mijn issues vandaan komen: de kabels. Misschien heb ik de extremen wat opgezocht.
Ik heb de socket, drukknop en RFID-lezer in een apart kastje zitten, met ±20 m kabel ertussen.

Voor de knop en RFID gebruik ik deze Cat6 F/UTP grondkabel:
https://www.elektramat.nl...at-6-grondkabel-per-meter

Voor PP, CP en de lockmotor gebruik ik deze signaalkabel:
https://www.elektramat.nl...-s2-d0-a3-groen-per-meter

Op de werkbank, vóór het trekken van de kabels door de mantelbuis, werkte alles prima.

Maar omdat het gedrag zo vreemd was ben ik eerst gaan uitzoeken hoe een 1-Wire signaal er normaal uitziet. Het blijkt een soort PWM-achtig patroon te zijn waarbij een ‘1’ een korte LOW-puls is (~6 µs) en een ‘0’ een langere. Dat triggerde me om de scoop erbij te pakken.

Eerst heb ik besloten om de boel te resetten en opnieuw te beginnen, met de RFID-lezer direct (kort kabeltje) op de SmartEVSE aangesloten. Toen werkte het ook meteen prima.

Met de PicoScope kon ik de pulsen netjes zien: korte kabel → mooi signaal.

Met 20 m UTP ertussen → de opgaande flank werd te traag. De puls haalt soms de 3,3 V niet binnen het tijdslot → bit wordt niet herkend?

Belangrijk: mijn probe is 1× (dus voegt zelf ook capacitantie toe). Met een 10× probe zou het beeld waarschijnlijk iets beter zijn.

Wat me verbaast:
Met een simpel huishoudsnoer van 10 m werkte het ineens wél.

Die heeft een lagere weerstand (0,8 Ω over 10 m) dan de UTP (2,5 Ω over 20 m), maar mijn gevoel zegt dat vooral de capaciteit van de kabel het verschil maakt.

In theorie: de tijdconstante is τ = R·C. Na 3·τ zit je pas rond 95% van de uiteindelijke spanning.

Bij hoge capaciteit → trage stijgflank → signaal haalt logische “1” niet op tijd.

Ik heb geprobeerd de capaciteit van de UTP te meten met mijn Fluke, maar daar kwam niks bruikbaars uit (te laag voor dat toestel?).

Vraag:
Ik snap nog niet helemaal waarom de UTP het zoveel slechter doet dan dat simpele snoertje. Ligt het inderdaad aan een hogere capaciteit? Of doe ik iets anders verkeerd? En belangrijker: wat zou een goede oplossing zijn?

Alle tips zijn welkom!

Misschien heb je hier nog iets aan:

https://www.analog.com/en...-line-1wire-networks.html

[Crxtreem]

Ik heb gisteren 2 accespoints van Unifi gewisseld (Unifi inwall-HD vs Inwall U6) en wil nu dat de SmartEVSE naar de AP die in mijn garage hangt verbinding maakt.
Maar hij blijft voor mijn AP kiezen die eerst in mijn garage hing en nu op de 1e verdieping in huis.

Als ik de SmartEVSE lock op mijn garage AP verdwijnt de SmartEVSE en komt niet meer online.
Ook uit/aan zetten heeft geen resultaat.
Kan ik dit in de Smartevse ook forceren dat hij op een ander AP verbind?

Dit is het enigste apparaat wat zo koppig is.

[martijn_van_eck]

Crxtreem schreef op maandag 1 september 2025 @ 10:43:
Ik heb gisteren 2 accespoints van Unifi gewisseld (Unifi inwall-HD vs Inwall U6) en wil nu dat de SmartEVSE naar de AP die in mijn garage hangt verbinding maakt.
Maar hij blijft voor mijn AP kiezen die eerst in mijn garage hing en nu op de 1e verdieping in huis.

Als ik de SmartEVSE lock op mijn garage AP verdwijnt de SmartEVSE en komt niet meer online.
Ook uit/aan zetten heeft geen resultaat.
Kan ik dit in de Smartevse ook forceren dat hij op een ander AP verbind?

Dit is het enigste apparaat wat zo koppig is.

Je kan in de Unifi app de gebruiker (SmartEVSE) locken op een access point. Volgens mij moet je hiermee gaan spelen.

[Stefannn]

sanderb2001 schreef op zondag 31 augustus 2025 @ 20:16:
Thnx voor de input!
Ik gebruik geen afsluitweerstand o.i.d.
Ik denk dat deze RFID-lezer erbij wordt verkocht: https://drexia.pl/en/stro...rfid-reader-1356-mhz.html
. Op die site staat ook een pdf met het elektrische schema.

Hans had het schema van de SmartEVSE al gedeeld. De RFID wordt inderdaad op sw aangesloten. Zelf ben ik niet helemaal thuis in het aanpassen van de pull-up weerstand. Ik ga kijken of ik het kan verbeteren zonder de SmartEVSE open te maken.

Supercool dat je zo actief meedenkt!

Als je de smartEVSE niet wil openmaken moet het ook met een extern circuit lukken. Mijn suggestie in plaatje hieronder dat je dus op de externe aanslutingungen voor gnd, 12v en sw aan sluit.
Het enige verschil met een parallelweerstand aan R13 is dat je aan de andere kant van de serieweerstand R15 van 100ohm zit. Dat moet geen enkel probleem zijn. Dat is een chipbeveiliging cq piekstroom onderdrukker.
Je kan dit circuit op de terminals van de smartEVSe proberen maar je kan het ook aan de kant van de rfid lezer proberen.
Het is trouwens niet alleen de capaciteit van de kabel, ook de inductie daarvan die je parten speelt.

Yep @mjvdzwet betreffend document heb ik in 2008 grijs gelezen. In de voorbeeld schema’s gebruiken ze daar trouwens een pull-up van 1k. Kortom.. dat onderstreept dat de 10k in de smartEVSE aan de hoge kant is.

[timovd]

martijn_van_eck schreef op maandag 1 september 2025 @ 12:54:
[...]


Je kan in de Unifi app de gebruiker (SmartEVSE) locken op een access point. Volgens mij moet je hiermee gaan spelen.

huh?

Crxtreem schreef op maandag 1 september 2025 @ 10:43:
...
Als ik de SmartEVSE lock op mijn garage AP verdwijnt de SmartEVSE en komt niet meer online.
...

@Crxtreem Andere frequentie (2,4Ghz band) geprobeerd?

[dingo35]

@martijn_van_eck Ik ben voor de wifi verbinding afhankelijk van de ESP32 libraries, dus heel veel kan ik daar niet aan doen.

Sinds v3.9.0 werken we weer met een "eigen" (=native library) AP bij het configureren van de Wifi, dus je zou kunnen proberen na de lock op je garage AP opnieuw een wifi-setup via je LCD scherm te doen; dan zoekt hij opnieuw contact en neem ik aan dat de "foute" unify AP niet antwoordt...

[Beer070]

dingo35 schreef op maandag 1 september 2025 @ 13:48:
@martijn_van_eck Ik ben voor de wifi verbinding afhankelijk van de ESP32 libraries, dus heel veel kan ik daar niet aan doen.

Sinds v3.9.0 werken we weer met een "eigen" (=native library) AP bij het configureren van de Wifi, dus je zou kunnen proberen na de lock op je garage AP opnieuw een wifi-setup via je LCD scherm te doen; dan zoekt hij opnieuw contact en neem ik aan dat de "foute" unify AP niet antwoordt...

Zou kunnen dat de ESP32 libraries een lock doen op het mac adres van de AP, en niet op het ssid. Dan zou het opnieuw registreren idd werken.
Hiermee heb je dus geen fallback naar andere AP’s.
Mijn iRobot vertoont met ubiquiti vergelijkbaar gedrag. Op 2.4ghz komt ie echter een heel stuk het huis door, maar niet erg stabiel. Meting vorig jaar zag 178 andere 2.4ghz stations in de buurt

[Crxtreem]

dingo35 schreef op maandag 1 september 2025 @ 13:48:
@martijn_van_eck Ik ben voor de wifi verbinding afhankelijk van de ESP32 libraries, dus heel veel kan ik daar niet aan doen.

Sinds v3.9.0 werken we weer met een "eigen" (=native library) AP bij het configureren van de Wifi, dus je zou kunnen proberen na de lock op je garage AP opnieuw een wifi-setup via je LCD scherm te doen; dan zoekt hij opnieuw contact en neem ik aan dat de "foute" unify AP niet antwoordt...

Heb eerst een AP lock aangezet en daarna de Wifi-setup en nu pakt hij de juiste AP.
Werkt wel een stuk soepeler de nieuwe Wifi-setup dan de oude methode.

[Hmmbob]

Beer070 schreef op maandag 1 september 2025 @ 19:57:
[...]

Zou kunnen dat de ESP32 libraries een lock doen op het mac adres van de AP, en niet op het ssid. Dan zou het opnieuw registreren idd werken.
Hiermee heb je dus geen fallback naar andere AP’s.
Mijn iRobot vertoont met ubiquiti vergelijkbaar gedrag. Op 2.4ghz komt ie echter een heel stuk het huis door, maar niet erg stabiel. Meting vorig jaar zag 178 andere 2.4ghz stations in de buurt

Zou zomaar kunnen - een van mijn airco controllers blijft ook hangen op een volstrekt onlogisch AP

[databeestje]

Instellingen voor Custom EV meter Kowsi KWS-306L meter.

Byte Order HBF & HWF
Data Int32
Input Reg 4
Vol reg 14
vol div 100
Cur Reg 17
Cur div 1000
Pow Reg 23
Pow div 10
Ene reg 54
Ene div 100

[Hansie_P]

Robert-Jan schreef op donderdag 14 augustus 2025 @ 14:32:
[...]


Nee, er wordt exact gezocht naar een Homewizard meter met de naam "p1meter".

Ik ben benieuwd hoe dit regelen via de p1 meter van homewizard werkt als je ook batterijen van homewizard hebt. Die kunnen namelijk ook enkel met zonnestroom worden opgeladen en reageren dus ook op negatieve meterstanden. Schakelt de smart EVSE pas in als er minimaal 6A wordt teruggeleverd, dus de batterijen gaan altijd voor? En hoe wordt er omgegaan met schommelingen op de p1 meter (kleine wolkjes voor de zon bijvoorbeeld)? Je wilt niet dat de lader heel de tijd schakelt tussen uit en aan.

[TorpedoX_88]

Blackraven schreef op donderdag 28 augustus 2025 @ 10:26:
[...]

Van de communicatie, want zo te zien aan je P1 meter werkt je lader wel continu.

Heb dit inmiddels gecheckt en de bedrading van zowel de stroom als de communicatie zit goed, maar de meter meet geen spanning op fase 1 en soms wel en soms geen spanning op fase 3. Ik neig daarom een beetje naar een defecte meter, iemand dit eerder meegemaakt bij een Eastron SDM72D-M V2?

[mjvdzwet]

Hansie_P schreef op woensdag 3 september 2025 @ 16:32:
[...]


Ik ben benieuwd hoe dit regelen via de p1 meter van homewizard werkt als je ook batterijen van homewizard hebt. Die kunnen namelijk ook enkel met zonnestroom worden opgeladen en reageren dus ook op negatieve meterstanden. Schakelt de smart EVSE pas in als er minimaal 6A wordt teruggeleverd, dus de batterijen gaan altijd voor? En hoe wordt er omgegaan met schommelingen op de p1 meter (kleine wolkjes voor de zon bijvoorbeeld)? Je wilt niet dat de lader heel de tijd schakelt tussen uit en aan.

Dit gaat niet lekker samen. Althans niet zonder extra sturing.
Ik heb zelf een Marstek batterij en gebruik eigen domotica software om het te regelen. Als ik de auto niet direct nodig heb dan mag de batterij tot 85% laden, daarna mag de auto. Zodra de auto laad gaat de batterij in standby.
Zo verdeel ik mijn zonnestroom. Het slaat met dubbele laad/ontlaad verliezen nergens op om de auto uit de batterij te laden.

[Blackraven]

TorpedoX_88 schreef op woensdag 3 september 2025 @ 22:18:
[...]

Heb dit inmiddels gecheckt en de bedrading van zowel de stroom als de communicatie zit goed, maar de meter meet geen spanning op fase 1 en soms wel en soms geen spanning op fase 3. Ik neig daarom een beetje naar een defecte meter, iemand dit eerder meegemaakt bij een Eastron SDM72D-M V2?

Zelf heb ik zowel een 630 als een 72D, maar beide werken prima.
Blijft een stukje techniek natuurlijk, kan altijd stuk. Klinkt inderdaad als een defecte meter als je maar een gedeelte van de metingen binnen krijgt.

[dj_dysaster]

Ik ben mijn ABL eMH1 aan het ombouwen met een SmartEVSE. De bestaande leds, contactor, dc current detector en laadsocket met locking actuator worden hergebruikt. Met die laatste heb ik een probleempje.

De actuator is een Kiekert Secucharge. Dit lijkt een clone te zijn van een "Phoenix contact locking motor". De draadkleuren zijn het zelfde (4 stuks), het ding lijkt erop en als ik de 4 draden doormeet lijkt dit te matchen met de pinout van de Phoenix motor; Blauw/Rood en Blauw/Bruin zijn de motorspoel, Blauw/Geel en Blauw/Groen zijn een schakelaar om de stand van de actuator terug te koppelen.

De SmartEVSE is geconfigureerd met "Config = Socket" en "Lock = Motor".

Nu zie ik het volgende gedrag;
Stroom op de laadpaal; de locking motor vergrendeld direct.
Stroom van de laadpaal af; de locking motor laat direct los.
Stroom weer op de laadpaal; locking motor vergrendeld weer.
Via de webUI op de "cable lock" knop klikken; er gebeurd niks (behavle het vinkje op de knop die aan en uit gaat als ik klik).

Nu heb ik de debug firmware (3.9.2) geflashed en met telnet verbonden. Daar had ik een bericht verwacht als; "Locking Actuator" en "Unlocking Actuator", maar die zie ik niet bij het klikken op de knop in de webUI.

De actuator lijkt dus wel bestuurd te kunnen worden door de EVSE, maar doet dat niet bij klikken op de knop. Of werkt deze knop alleen als er een auto is aangesloten? Op dit moment ligt alles nog op de testbench en heb er nog geen auto aan gehangen.

[Hermarcel]

@dj_dysaster Heb je de datasheets van beide actuators al vergeleken?

[dj_dysaster]

Kriekert geeft helaas geen datasheet vrij. Echter het doormeten van de motorspoel en vergrendelingsschakelaar doet er op lijken dat het ding vergelijkbaar is met de Phoenix.

Ik ben vooral benieuwd naar het softwarematige gedrag dat de EVSE zou moeten geven. Ik heb een beetje in de source code zitten graven en ik krijg bijna het idee dat de "Cable Lock" knop in de UI iets zegt over het algemene vergrendelgedrag van de actuator. En dus niet, zoals ik dacht, vergrendeld en ontgrendeld met een druk op dat knopje.

De interrupt routine die de actuator bestuurd wil namelijk alleen vergrendelen als de system state geen A is. En alleen ontgrendelen als de state wel A is. Nou is in mijn geval de state altijd A omdat er geen EV aan de kabel hangt.

kan iemand mijn vermoeden rond de "cable lock" knop bevestigen?

[Grondgebonden]

dj_dysaster schreef op vrijdag 5 september 2025 @ 11:28:
Kriekert geeft helaas geen datasheet vrij. Echter het doormeten van de motorspoel en vergrendelingsschakelaar doet er op lijken dat het ding vergelijkbaar is met de Phoenix.

Ik ben vooral benieuwd naar het softwarematige gedrag dat de EVSE zou moeten geven. Ik heb een beetje in de source code zitten graven en ik krijg bijna het idee dat de "Cable Lock" knop in de UI iets zegt over het algemene vergrendelgedrag van de actuator. En dus niet, zoals ik dacht, vergrendeld en ontgrendeld met een druk op dat knopje.

De interrupt routine die de actuator bestuurd wil namelijk alleen vergrendelen als de system state geen A is. En alleen ontgrendelen als de state wel A is. Nou is in mijn geval de state altijd A omdat er geen EV aan de kabel hangt.

kan iemand mijn vermoeden rond de "cable lock" knop bevestigen?

Hoi dj_dysaster,

Je hebt de juiste conclusie getrokken uit de source code. Het gedrag staat ook beschreven in de documentatie.

Ik heb eerder een feature request aangemaakt op github om de Cable Lock optie ook te laten werken in STATE_A (als laden nog niet geactiveerd is). Daar heb ik helaas nog geen reactie op gehad. Lijkt mij persoonlijk een logische verbetering.