Zelfbouw Laadpaal ervaringen

[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.

[dj_dysaster]

Dank voor je reactie! Dan ga ik voor nu even aannemen dat mn opbouw wel werkt. Ik ga wachten tot mn nieuwe wagen er is, om het dan eens in zn geheel te testen.

[benthouse]

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?

Ergens een brakke verbinding? Vond zelf de kooiklemmen die er in zitten niet de beste……

[databeestje]

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?

Ik heb hier een SDM72D-M 2e hands van MP, en hier zijn alle registers opgeschoven als ik deze via de rs485 gateway benader. Heel apart. Dus energie zit in 341 ipv 343. Dit levert voor de spanning dus ook de merkwaardige situatie op dat ik wel l2 en l3 zie (matcht met de andere meters) maar l1 onbereikbaar is geworden.

code:

modbus -s 21 192.168.11.72:502 -B mixed i@1/f i@3/f i@5/f
Parsed 0 registers definitions from 1 files
1: 233.96485900878906
3: 228.5128173828125
5: 7.349109796151503e-41

Het kan ook zijn dat de rs485 ethernet gateway niet goed is. Koop geen EBYTE NE2-D14PE of vergelijkbaar uit de serie. De interface is ouderwets brak engels met hier en daar chinees er doorheen. Het wachtwoord kan je instellen, maar niet langer dan 5 karakters (wat dus net zo lang is als admin). Het leek een handige combi, een rs485 ethernet gateway met PoE, dus geen extra losse voeding nodig. Software updates niet te vinden, wel een config tool.

Er is een Elfin EE11 onderweg ter vervanging.

[dingo35]

Weet je zeker dat het juiste aantal bytes per register gehanteerd wordt door de gateway? Je kunt alle parameters (high/low bytes, float/int, exponent) in de source code van SmartEVSE vinden....

[databeestje]

dingo35 schreef op zaterdag 6 september 2025 @ 08:34:
Weet je zeker dat het juiste aantal bytes per register gehanteerd wordt door de gateway? Je kunt alle parameters (high/low bytes, float/int, exponent) in de source code van SmartEVSE vinden....

Dat is dus de vraag, maar dit is een meter in de meterkast. Niet SmartEVSE gerelateerd.
Meer om mensen te waarschuwen dat deze gateway sub-optimaal is.

Ik haakte in op de request van Torpedo omdat hij vreemde values ziet voor spanning 1,2,3 en ik dus iets vergelijkbaars zie. Maar ik geloof niet dat hij een gateway gebruikt.

Ik heb de juiste settings voor de Kowsi hier gepost en in jouw DM, die werken nu zoals het hoort en SmartEVSE is er happy mee. Geen rare waarden meer gezien, ik snap nu waarom deze de draad kwijt was bij laden met meer dan 6553.5 Watt

[Crxtreem]

Volgens mij vind onze Corsa-e het niet tof dat ik load balancing doe.

Als de auto aan het laden is en bijvoorbeeld de vaatwasser staat aan dan kan het zijn dat de stroomwaarde te hoog wordt en de stroom voor de SmartEVSE onder de 6 komt.
Auto schakelt dan uit en gaat niet meer verder.
Ik krijg dan ook de statussen “Charging Stopped” - “Connected to EV” - “Activate”- “Connected to EV” via MQTT.

Activate krijg ik normaal niet te zien.

Bij mijn Tesla heb ik dit probleem niet dus zal waarschijnlijk aan de auto kant niet lekker gaan.

[databeestje]

Crxtreem schreef op zaterdag 6 september 2025 @ 10:19:
Volgens mij vind onze Corsa-e het niet tof dat ik load balancing doe.

Als de auto aan het laden is en bijvoorbeeld de vaatwasser staat aan dan kan het zijn dat de stroomwaarde te hoog wordt en de stroom voor de SmartEVSE onder de 6 komt.
Auto schakelt dan uit en gaat niet meer verder.
Ik krijg dan ook de statussen “Charging Stopped” - “Connected to EV” - “Activate”- “Connected to EV” via MQTT.

Activate krijg ik normaal niet te zien.

Bij mijn Tesla heb ik dit probleem niet dus zal waarschijnlijk aan de auto kant niet lekker gaan.

Dit heb ik nog niet gezien met onze 208 uit 2021, die gaat wel verder. Ik zal het eens in de gaten houden. Deze blijft ook rustig de gehele avond standby en schakelt rond 23.00 naar Smart en gaat dan vrolijk verder.

[BarryH]

Crxtreem schreef op zaterdag 6 september 2025 @ 10:19:
Volgens mij vind onze Corsa-e het niet tof dat ik load balancing doe.

Als de auto aan het laden is en bijvoorbeeld de vaatwasser staat aan dan kan het zijn dat de stroomwaarde te hoog wordt en de stroom voor de SmartEVSE onder de 6 komt.
Auto schakelt dan uit en gaat niet meer verder.
Ik krijg dan ook de statussen “Charging Stopped” - “Connected to EV” - “Activate”- “Connected to EV” via MQTT.

Activate krijg ik normaal niet te zien.

Bij mijn Tesla heb ik dit probleem niet dus zal waarschijnlijk aan de auto kant niet lekker gaan.

sommige auto's trekken dat aan /uit niet. je kan de vertraging (Std. 5 minuten) langer maken?

[dingo35]

Crxtreem schreef op zaterdag 6 september 2025 @ 10:19:
Volgens mij vind onze Corsa-e het niet tof dat ik load balancing doe.

Als de auto aan het laden is en bijvoorbeeld de vaatwasser staat aan dan kan het zijn dat de stroomwaarde te hoog wordt en de stroom voor de SmartEVSE onder de 6 komt.
Auto schakelt dan uit en gaat niet meer verder.
Ik krijg dan ook de statussen “Charging Stopped” - “Connected to EV” - “Activate”- “Connected to EV” via MQTT.

Activate krijg ik normaal niet te zien.

Bij mijn Tesla heb ik dit probleem niet dus zal waarschijnlijk aan de auto kant niet lekker gaan.

De SmartEVSE stopt met laden bij waardes lager dan MinCurrent (default 6A en kan niet lager ingesteld worden); ook bij je Tesla.

MAAR als er weer genoeg stroom is hervat de SmartEVSE de laadsessie. Kan zijn dat de Corsa-e zich niet aan de laadstandaarden houdt, de Tesla doet dat wel!

[ Voor 8% gewijzigd door dingo35 op 06-09-2025 13:47 ]

[tukker999]

Hoe doe je dat dan met mqtt?
Normaal gesproken schakel je niet aan/uit , maar geef je een mqtt commando aan de SmartEVSE, die past de weerstand aan, waarop de OBC in de auto naar een nieuwe stand schakelt.

Van aan/uit schaken van de stroom worden OBC's niet blij.

[databeestje]

@dingo35 Hoi, ik had net de auto aangesloten in modus Solar en deze is de sessie begonnen in Solar 3P terwijl deze expliciet op Solar C2 Off staat. In de statistieken zie ik ook enkel dat deze op 1.2kW laad. Inmiddels is het donker, staat deze nog in Solar maar blijft deze laden met 1.2kW in de modus Solar 3P.

Ik heb de Raw Data opgeslagen lokaal. Versie 3.9.2

[Driehoek]

databeestje schreef op zaterdag 6 september 2025 @ 20:33:
@dingo35 Hoi, ik had net de auto aangesloten in modus Solar en deze is de sessie begonnen in Solar 3P terwijl deze expliciet op Solar C2 Off staat. In de statistieken zie ik ook enkel dat deze op 1.2kW laad. Inmiddels is het donker, staat deze nog in Solar maar blijft deze laden met 1.2kW in de modus Solar 3P.

Ik heb de Raw Data opgeslagen lokaal. Versie 3.9.2

[Afbeelding]

Ik zie geen timer staan. Als je die niet instelt blijft hij laden. (Geen idee waarom hij 3f laadt met C2 off)

[dingo35]

Zo te zien aan je stroomafname laadt hij wel degelijk op 1 fase, maar toont het display foutief 3P?

[databeestje]

dingo35 schreef op zondag 7 september 2025 @ 06:52:
Zo te zien aan je stroomafname laadt hij wel degelijk op 1 fase, maar toont het display foutief 3P?

Het meest apart is dat aan het begin van de Sessie deze toonde 1P -> 3P met een start timer en daarna Solar 3P toonde. Dit was een nieuw gestarte sessie en mijn solar is niet groot genoeg om uberhaupt bij 3P snelheden te komen.

De C2 Solar Off was de instelling in 3.8.5, en is hier ook zichtbaar.

@Driehoek
Zo te zien is Starttime None en Stoptime None, ik dacht dat dan de defaults van toepassing waren. Deze heb ik nooit bewust ingesteld sinds eerste installatie met 3.6.x
Geen idee waar dit vandaan komt eerlijk gezegd, ook niet op gelet. Misschien met upgrade van 3.8.5 naar 3.9.2 verdwenen?

[lemming_nl]

Sinds een tijdje heb ik een laadpaal met de SmartEVSE hangen. Deze heb ik getest in de normale modus en dat werkt prima. Met de HACS integratie kon ik de data via HA uitlezen. Nu wil ik met solar charging aan de slag, Ik wil de mains data daarvoor via MQTT aanleveren. Ik zag dat de HACS integratie depreciated is dus die is weg en ik ging met goede moed met MQTT aan de slag (0 ervaring daarmee). Lang verhaal kort; het wil nog niet zo vlotten. Waar ik nu ben;
- Mosquitto broker draait en werkt. De SmartEVSE verbind en stuurt data (kan ik zien met MQTT Explorer). Ook HA is verbonden en ziet data (als ik handmatig de data uitlees via de 'Listen to a topic' feature).
- Zoals ik het begrijp zou autodiscovery moeten werken maar er gebeurt niets. Autodiscover staat aan met als topic 'homeassistant'. SmartEVSE publisht naar 'homeassistant/SmartEVSE/7884'. Als ik het goed begrijp moet dit werken? Mis ik iets?
- Vervolgens wil ik P1 data sturen naar de SmartEVSE. Ik heb al gezien dat ik de P1 data moet verwerken om te zorgen dat ik 1 waarde krijg per fasestroom (ipv 1 voor productie en 1 voor consumptie). Daar kom ik denk ik uit met een sensor template maar dan? Wat is de 'nette' manier om te publishen? Is dat met een automation die op een vaste interval loopt? Zoals ik het begrijp dient de SmartEVSE iedere 10s of minder data te krijgen dus puur op een verandering in waarde sturen lijkt mij niet goed. Ik heb in dit topic wel wat scripts gevonden (zoals deze) maar is dat de 'juiste' manier?

[Jfwiet]

Ben toevallig van het weekend ook aan het spelen geweest met HA sinds hele lange tijd. Kreeg het ook niet voor elkaar, totdat ik merkte dat ik in de EVSE een verkeerd IP adres had staan.

Heb via de releases versie 3.9.2 op de EVSE geladen.

Dingen waar ik even goed doorheen moest lezen: Heb je ook een gebruiker aangemaakt? Die moet je op 3 plekken invoeren. 1. In de Mosquitto broker (configuration >> add-ons) in de configuration tab. 2. In de MQTT (onder settings >> devices & services >> MQTT ) en 3. In de UI van de EVSE. Op al die plekken dezelfde gebruiker/pass.

En wat ik las moet je HA opnieuw opstarten en mogelijk ook de EVSE om de verbinding te maken. Daar zocht ik het eerst (totdat ik zag dat ik x.x.x.150 ipv x.x.x.50 als IP adres had ingevoerd in de EVSE).

Toen ik het IP adres juist had staan kreeg ik onder Settings >> Devices & Services >> MQTT keurig netjes onder Mosquitto Broker een SmartEVSE device. Dus niet als een los device, als je dat verwachte. onder het tab devices zie ik keurig de EVSE.

Misschien dat er hiermee een lichtje gaat branden.

[databeestje]

lemming_nl schreef op maandag 8 september 2025 @ 11:38:
- Vervolgens wil ik P1 data sturen naar de SmartEVSE. Ik heb al gezien dat ik de P1 data moet verwerken om te zorgen dat ik 1 waarde krijg per fasestroom (ipv 1 voor productie en 1 voor consumptie). Daar kom ik denk ik uit met een sensor template maar dan? Wat is de 'nette' manier om te publishen? Is dat met een automation die op een vaste interval loopt? Zoals ik het begrijp dient de SmartEVSE iedere 10s of minder data te krijgen dus puur op een verandering in waarde sturen lijkt mij niet goed. Ik heb in dit topic wel wat scripts gevonden (zoals deze) maar is dat de 'juiste' manier?

Nu ook beschikbaar in 3 fase variant. Zo staat deze in mijn automations.yml

code:

- id: '1732101563658'
  alias: Mains Meter Current to SmartEVSE
  description: ''
  triggers:
  - trigger: time_pattern
    seconds: /5
  conditions: []
  actions:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: true
      qos: 0
      retain: false
      topic: SmartEVSE-7603/Set/MainsMeter
      payload: '{% set v1 = states(''sensor.electricity_meter_spanning_fase_l1'')
        | float %}

        {% set l1i = states(''sensor.electricity_meter_energieverbruik_fase_l1'')
        | float * 10000 |float / v1  %}

        {% set l1e = states(''sensor.electricity_meter_energieproductie_fase_l1'')
        | float * 10000 |float / v1 %}

        {% set v2 = states(''sensor.electricity_meter_spanning_fase_l2'') | float
        %}

        {% set l2i = states(''sensor.electricity_meter_energieverbruik_fase_l2'')
        | float * 10000 |float / v2  %}

        {% set l2e = states(''sensor.electricity_meter_energieproductie_fase_l2'')
        | float * 10000 |float / v2 %}

        {% set v3 = states(''sensor.electricity_meter_spanning_fase_l3'') | float
        %}

        {% set l3i = states(''sensor.electricity_meter_energieverbruik_fase_l3'')
        | float * 10000 |float / v3  %}

        {% set l3e = states(''sensor.electricity_meter_energieproductie_fase_l3'')
        | float * 10000 |float / v3 %}

        {{ (l1i - l1e) | round(0) }}{{ ":" }}{{ (l2i - l2e) | round(0) }}{{ ":" }}{{
        (l3i - l3e) | round(0) }}

        '
  mode: single

Zo laad ik inmiddels al een aantal maanden, en sinds 2 weken met bovenstaand.
Je kan deze natuurlijk voorwaardelijk maken op EV Connected, maar dan knippert deze rood.

[ruud76]

Maakt het voor de solar mode uit op welke fases ik de 2e contactor zet? Idealiter zet ik hem op fase 1 en 3, omdat de 2e fase enkel door de smartevse wordt gebruikt (dan zou hij dus in solar mode enkel op fase 2 laden en daarmee nooit kunnen concurreren met andere afnemers in huis). Is daar iets op tegen, ook als de zonnepanelen op fase 1 zitten?

[ Voor 20% gewijzigd door ruud76 op 08-09-2025 18:57 ]

[sandergar]

ruud76 schreef op maandag 8 september 2025 @ 18:54:
Maakt het voor de solar mode uit op welke fases ik de 2e contactor zet? Idealiter zet ik hem op fase 1 en 3, omdat de 2e fase enkel door de smartevse wordt gebruikt (dan zou hij dus in solar mode enkel op fase 2 laden en daarmee nooit kunnen concurreren met andere afnemers in huis). Is daar iets op tegen, ook als de zonnepanelen op fase 1 zitten?

Technisch kan dit maar je creëert een fase onbalans. Mooier is het om je PV en je EV op dezelfde fase te hebben zodat de productie meteen geconsumeerd kan worden. Als salderen in de toekomst verder wordt afgebouwd, kan het gunstig zijn om direct zo veel mogelijk autonoom per fase te verbruiken. Je profiteert dan maximaal van directe eigen consumptie zonder afhankelijk te zijn van de “virtuele saldering” van de slimme meter. Kan je de PV ook niet op fase 2 zetten?

[databeestje]

meeste auto's malen niet om de fase rotatie, als fase 1 van de stekker maar wel prik krijgt. Dus wat dat aan gaat kan je de afgaande draden onder C1 verzetten en C2 de draden voor pin 2 en 3 van de laadstekker schakelen.

[PimDoos]

ruud76 schreef op maandag 8 september 2025 @ 18:54:
Maakt het voor de solar mode uit op welke fases ik de 2e contactor zet? Idealiter zet ik hem op fase 1 en 3, omdat de 2e fase enkel door de smartevse wordt gebruikt (dan zou hij dus in solar mode enkel op fase 2 laden en daarmee nooit kunnen concurreren met andere afnemers in huis). Is daar iets op tegen, ook als de zonnepanelen op fase 1 zitten?

Je EV heeft voor 1-fase laden voor zover ik het begrijp altijd fase 1 (L1) op de connector nodig. Om naar 3-fase te gaan zou ik dus fase 2 en 3 schakelen met contactor C2.
Ik heb dit opgelost met phase rotation (faseverschuiving): L1 van mijn SmartEVSE komt in de meterkast uit op L2.

Dus

Meterkast	SmartEVSE
L1	L3
L2	L1
L3	L2

Wat @sandergar schrijft geldt dan overigens nog steeds.

[lemming_nl]

databeestje schreef op maandag 8 september 2025 @ 16:06:
[...]


Nu ook beschikbaar in 3 fase variant. Zo staat deze in mijn automations.yml
[...]
Zo laad ik inmiddels al een aantal maanden, en sinds 2 weken met bovenstaand.
Je kan deze natuurlijk voorwaardelijk maken op EV Connected, maar dan knippert deze rood.

Hartelijk dank, uit dit stuk ga ik wel komen. Helaas loop ik daar tegen een praktisch probleem; ik heb een DSMR 4.2 meter die geen spanning doorgeeft... De enige 3-fase spanningsmeting gebeurt bij mijn PV omvormer. Op zich beter dan niets (en waarschijnlijk goed genoeg) maar ideaal is het niet.

Ik snap echter nog niet waarom het niet lukt om de SmartEVSE te auto-discoveren. Ziet iemand op onderstaande instellingen van Mosquitto en SmartEVSE een probleem? Ik heb helaas geen 2e MQTT device liggen om te testen. Ik zal eens zoeken of er een of andere testtool is hiervoor.

[databeestje]

lemming_nl schreef op maandag 8 september 2025 @ 20:11:
[...]

Hartelijk dank, uit dit stuk ga ik wel komen. Helaas loop ik daar tegen een praktisch probleem; ik heb een DSMR 4.2 meter die geen spanning doorgeeft... De enige 3-fase spanningsmeting gebeurt bij mijn PV omvormer. Op zich beter dan niets (en waarschijnlijk goed genoeg) maar ideaal is het niet.


Ik snap echter nog niet waarom het niet lukt om de SmartEVSE te auto-discoveren. Ziet iemand op onderstaande instellingen van Mosquitto en SmartEVSE een probleem? Ik heb helaas geen 2e MQTT device liggen om te testen. Ik zal eens zoeken of er een of andere testtool is hiervoor.

In plaats van de spanning gewoon 230 neerzetten, dat is dichtbij genoeg en de SmartEVSE interpoleert en laat de laadstroom langzaam oplopen tot evenwicht of Max Import.

Ik gebruik regelmatig MQTT Explorer, handig.

[ Voor 21% gewijzigd door databeestje op 08-09-2025 20:25 ]

[ruud76]

@sandergar @databeestje @PimDoos dank voor jullie snelle reactie! De panelen moeten hier nog geïnstalleerd worden dus ik laat mijn gedachten er over gaan - kan ik het de installateur daarna laten maken zoals ik het hebben wil 😀

In elk geval goed om te weten dat de auto doorgaans spanning op fase 1 verwacht, ik de faseverschuiving in stand moet laten (dus geen fases omwisselen maar allemaal doorschuiven als dat wenselijk is). En mee eens dat het in de toekomst wel eens wenselijk kan zijn de eigen opgewekte stroom te gebruiken en niets alsnog via het net te balanceren over fases.

[ Voor 31% gewijzigd door ruud76 op 08-09-2025 20:51 ]

[adjego]

lemming_nl schreef op maandag 8 september 2025 @ 20:11:
[...]

Hartelijk dank, uit dit stuk ga ik wel komen. Helaas loop ik daar tegen een praktisch probleem; ik heb een DSMR 4.2 meter die geen spanning doorgeeft... De enige 3-fase spanningsmeting gebeurt bij mijn PV omvormer. Op zich beter dan niets (en waarschijnlijk goed genoeg) maar ideaal is het niet.

Ik snap echter nog niet waarom het niet lukt om de SmartEVSE te auto-discoveren. Ziet iemand op onderstaande instellingen van Mosquitto en SmartEVSE een probleem? Ik heb helaas geen 2e MQTT device liggen om te testen. Ik zal eens zoeken of er een of andere testtool is hiervoor.

[Afbeelding]

[Afbeelding]

Mijn topic prefix bevat alleen maar "SmartEVSE" en verder niks. Ook geen "homeassistant" of iets.

[lemming_nl]

Bedankt, dat hielp. Met alleen 'SmartEVSE' als topic prefix in de SmartEVSE vindt HA hem. Ik snap niet waarom dat werkt met de auto discovery prefix op 'homeassistant' in HA maar dat zal wel een of andere quirck zijn. Publishen van de P1 data naar de SmartEVSE werkt nu ook dus ik kan weer verder spelen

[RonJ]

Waar komt toch iedere keer dat fabeltje vandaan dat je straks niet meer zou mogen "salderen"/verrekenen over de fases? Het enige dat er door een DSMR naar buiten richting netbeheerder gestuurd wordt zijn de totale tellerstanden.

[Blackraven]

RonJ schreef op dinsdag 9 september 2025 @ 08:21:
Waar komt toch iedere keer dat fabeltje vandaan dat je straks niet meer zou mogen "salderen"/verrekenen over de fases? Het enige dat er door een DSMR naar buiten richting netbeheerder gestuurd wordt zijn de totale tellerstanden.

Ik heb het alleen zo uitgelegd dat ik met een 25A aansluiting toch tot 32A kan laden op 1 fase met >7A van de zonnepanelen op dezelfde fase, niet vanwege salderen.

[databeestje]

RonJ schreef op dinsdag 9 september 2025 @ 08:21:
Waar komt toch iedere keer dat fabeltje vandaan dat je straks niet meer zou mogen "salderen"/verrekenen over de fases? Het enige dat er door een DSMR naar buiten richting netbeheerder gestuurd wordt zijn de totale tellerstanden.

Het ziet er soms raar uit, in de P1 data zie je namelijk tegelijkertijd productie en verbruik voor vermogen als dir op verschillende fases is, maar de kWh telwerken doen de netto som. Misschien is dat het.

[databeestje]

databeestje schreef op woensdag 3 september 2025 @ 15:15:
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

Ene reg 52 is totaal som energie.
Het bleek dat 54, 56 en 58 per fase was. Dit is het correcte totaal energie. Ik kwam er vandaag pas achter na een laad sessie van mijn vrouw waarvan er verschil was tussen de EV meting P1 data als "ongetraceerd verbruik"

[Thepawn]

Naar mijn mening moeten mensen met een 1-fase omvormer hun auto op dezelfde fase aansluiten: het doel is om de spanning te verlagen. Als extra voordeel kun je indien nodig met 32A laden.

[databeestje]

Thepawn schreef op woensdag 10 september 2025 @ 16:26:
Naar mijn mening moeten mensen met een 1-fase omvormer hun auto op dezelfde fase aansluiten: het doel is om de spanning te verlagen. Als extra voordeel kun je indien nodig met 32A laden.

Nu ik 3 fasen heb zie ik dat nummer 3 het handigst is, die is overdag een volle 10 volt lager.
Met de SmartEVSE heb ik ingesteld dat deze 4A van het net mag importeren, dat drukt de spanning aanzienlijk, ik had last van uitvallende omvormers thuis.

[Sosabowski]

Ik zie dat de RFID reader ook wordt aangesloten op de SW poort bij een SMART-EVSE. Betekent dat hiermee alle switch opties komen te vervallen? Idealiter zou ik met SW willen blijven schakelen tussen smart en solar.

[RonJ]

Sosabowski schreef op donderdag 11 september 2025 @ 13:37:
Ik zie dat de RFID reader ook wordt aangesloten op de SW poort bij een SMART-EVSE. Betekent dat hiermee alle switch opties komen te vervallen? Idealiter zou ik met SW willen blijven schakelen tussen smart en solar.

Nee, die werken gewoon tegelijkertijd/samen als je eea parallel aansluit. Heb hier ook de RFID reader en stegen led-switch in gebruik en dat werkt perfect.

[TorpedoX_88]

benthouse schreef op vrijdag 5 september 2025 @ 20:48:
[...]
Ergens een brakke verbinding? Vond zelf de kooiklemmen die er in zitten niet de beste……

Heb alles nagedraaid en de EV lader die erachter zit laad ook nog 'gewoon' op 2 fasen zonder gekke dingen zover ik kan zien, zou ik nog meer dingen kunnen checken hieraan gerelateerd?

databeestje schreef op zaterdag 6 september 2025 @ 09:48:
[...]
Ik haakte in op de request van Torpedo omdat hij vreemde values ziet voor spanning 1,2,3 en ik dus iets vergelijkbaars zie. Maar ik geloof niet dat hij een gateway gebruikt.

Ik lees de meter wel uit via de SmartEVSE maar de meter zelf geeft al foute waardes, dus het probleem lijkt de meter te zijn.

[databeestje]

TorpedoX_88 schreef op donderdag 11 september 2025 @ 19:42:
[...]

Heb alles nagedraaid en de EV lader die erachter zit laad ook nog 'gewoon' op 2 fasen zonder gekke dingen zover ik kan zien, zou ik nog meer dingen kunnen checken hieraan gerelateerd?


[...]

Ik lees de meter wel uit via de SmartEVSE maar de meter zelf geeft al foute waardes, dus het probleem lijkt de meter te zijn.

Probeer anders eens Custom EV meter en stel deze in met de settings uit met de waarden uit de datasheet.
https://docs.vekto.nl/med...72dm-user-manual-v1.5.pdf

Voor een Eastron zou het Float32 moeten zijn, maar je kan even testen met andere instellingen en wat er dan in het dashboard wordt getoond. Let wel dat de kans groot is dat de SmartEVSE de sessies afbreekt bij o.a. negatieve of hele grote waarden. Maar je kan kortstondig zien wat het is.

Zo heb ik dat ook met de KWS gedaan om de instellingen te vinden. Ik was op het fout spoor met type INT16, want dan klopt spanning, maarja, zodra vermogen over de 6553 Watt ging liep de INT16 over en was het einde sessie. Zodoende erachter gekomen dat het INT32 was en alle registers 1 lager beginnen.

De linux modbus tool is wel een zegen, ik heb een Wifi RS485 gateway aan deze lus zitten, dus kan spieken in wat de EV meter ziet.

[jossie67]

Ik ben nu al wat langer dit forum aan het volgen.
in mijn laadpaal heb ik een SmartEVSE zitten met versie v3.9.2

Het lukt mij niet om de data van de slimmelezer over te zetten naar de SmartEVSE
De SmartEVSE is connected aan mijn mqtt server en ik zie via ook berichten via een MQTT explorer in HA binnen komen.


Eerst heb ik geprobeerd om direct van de slimmelezer de data naar de SmartEVSE te sturen maar helaas zonder resultaat ,

Dus nu maar een automation gemaakt die iedere 5 sec de data door stuurt. Ik ben maar begonnen met de stroom

code:

alias: Slimmelezer to SmartEVS 
description: ""
triggers:
  - trigger: time_pattern
    seconds: "5"
conditions: []
actions:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: true
      qos: 0
      retain: false
      topic: SmartEVSE/Set/MainsMeter
      payload: |-
        {{
          ((states('sensor.current_phase_1')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }} 
mode: single

[/code]

Maar ik kijk op mijn SmartEVSE zie ik niks verschijnen, ik doe vast iets fout maar wat zie ik maar niet

[ Voor 5% gewijzigd door jossie67 op 12-09-2025 15:52 ]

[Hmmbob]

jossie67 schreef op vrijdag 12 september 2025 @ 15:49:
Ik ben nu al wat langer dit forum aan het volgen.
in mijn laadpaal heb ik een SmartEVSE zitten met versie v3.9.2

Het lukt mij niet om de data van de slimmelezer over te zetten naar de SmartEVSE
De SmartEVSE is connected aan mijn mqtt server en ik zie via ook berichten via een MQTT explorer in HA binnen komen.
[Afbeelding]

Eerst heb ik geprobeerd om direct van de slimmelezer de data naar de SmartEVSE te sturen maar helaas zonder resultaat ,

Dus nu maar een automation gemaakt die iedere 5 sec de data door stuurt. Ik ben maar begonnen met de stroom

code:

alias: Slimmelezer to SmartEVS 
description: ""
triggers:
  - trigger: time_pattern
    seconds: "5"
conditions: []
actions:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: true
      qos: 0
      retain: false
      topic: SmartEVSE/Set/MainsMeter
      payload: |-
        {{
          ((states('sensor.current_phase_1')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }} 
mode: single

[[Afbeelding]/code]

Maar ik kijk op mijn SmartEVSE zie ik niks verschijnen, ik doe vast iets fout maar wat zie ik maar niet

Je moet op de SmartEVSE nog even instellen dat de MAINSMET via de API komt. Dat doe je via het scherm, er is geen makkelijke klik-optie in de webinterface (je kan in de webinterface wel het scherm bedienen, dat werkt ook)

Enne, de SmartEVSE verwacht stroomsterktes per 0.1A. Dus 10A moet je doorsturen als 100, 6A als 60, 25A als 250. Als er stroom teruggeleverd wordt, moet je de waardes negatief doorsturen.

edit: Ik heb mijn slimmelezer ESPHome config hier staan, misschien kan je er iets mee: https://github.com/hmmbob...b/master/slimmelezer.yaml

[ Voor 6% gewijzigd door Hmmbob op 12-09-2025 16:06 ]

[jossie67]

Hmmbob schreef op vrijdag 12 september 2025 @ 16:00:
[...]

Je moet op de SmartEVSE nog even instellen dat de MAINSMET via de API komt. Dat doe je via het scherm, er is geen makkelijke klik-optie in de webinterface (je kan in de webinterface wel het scherm bedienen, dat werkt ook)

Enne, de SmartEVSE verwacht stroomsterktes per 0.1A. Dus 10A moet je doorsturen als 100, 6A als 60, 25A als 250. Als er stroom teruggeleverd wordt, moet je de waardes negatief doorsturen.

edit: Ik heb mijn slimmelezer ESPHome config hier staan, misschien kan je er iets mee: https://github.com/hmmbob...b/master/slimmelezer.yaml

Thanks uit eindelijk gedaan via de slimmelezer geregeld

code:

  - interval: 10sec
    then:
      - http_request.post:
          request_headers:
            Content-Length: 0
          url: !lambda |-
            std::string url;
            float l1 = id(template_current_l1).state;
            float l2 = id(template_current_l2).state;
            float l3 = id(template_current_l3).state;

            url.append("http://xxx.xxx.xxx.xxx/currents?L1=");
            url.append(to_string(l1*10));
            url.append("&L2=");
            url.append(to_string(l2*10));
            url.append("&L3=");
            url.append(to_string(l3*10));
            return url.c_str();

Nu nog even uitzoeken hoe ik via HA de mode naar
OFF, PAUSE, NORMAAL, SOLAR, SMART
kan veranderen

[databeestje]

jossie67 schreef op zaterdag 13 september 2025 @ 15:05:

Nu nog even uitzoeken hoe ik via HA de mode naar
OFF, PAUSE, NORMAAL, SOLAR, SMART
kan veranderen

Dat zit toch gewoon in de widget van SmartEVSE, dat is een dropdown waar je de modus selecteert. Kan je gewoon toevoegen op jouw dashboard.

code:

type: entities
entities:
  - entity: sensor.smartevse_9999_state
  - entity: sensor.smartevse_9999_evenergycharged
  - entity: select.smartevse_9999_mode
  - entity: sensor.smartevse_9999_error
title: SmartEVSE

[Hmmbob]

jossie67 schreef op zaterdag 13 september 2025 @ 15:05:
Nu nog even uitzoeken hoe ik via HA de mode naar
OFF, PAUSE, NORMAAL, SOLAR, SMART
kan veranderen

Je had hem via MQTT verbonden toch? Dan detecteert Home Assistant hem vanzelf. Die mode kun je instellen met select.smartevse_****_mode waarbij die **** bij jou wat anders zullen zijn.

[ Voor 46% gewijzigd door Hmmbob op 13-09-2025 16:44 ]

[Thepawn]

@dingo35 Misschien een domme vraag, maar zou het mogelijk zijn om de contactors aan te laten staan ​​tijdens het pauzeren van het laden in de zonne-energiemodus? Op dit moment heb ik de stoptimer voor de zonne-energie ingesteld op 5 minuten en de C2-contactor op "solar off". Als er wat wolken voorbijtrekken, hoor ik de contactors opengaan als het laden stopt, en vervolgens weer sluiten om het laden te hervatten zodra er stroom beschikbaar is. Kan smartEVSE de auto via het CP-signaal vertellen om 0A te laden en de contactors aan laten staan? Bedankt!

[dingo35]

Nee dat is niet conform de laadprotocollen, dus dat moet je niet willen.

[RonJ]

Een beetje contactor kan makkelijk 100.000 schakelingen aan (zo niet nog veel meer), dus ik zou me daar niet meteen heel druk om maken.

[adjego]

jossie67 schreef op vrijdag 12 september 2025 @ 15:49:
Ik ben nu al wat langer dit forum aan het volgen.
in mijn laadpaal heb ik een SmartEVSE zitten met versie v3.9.2

Het lukt mij niet om de data van de slimmelezer over te zetten naar de SmartEVSE
De SmartEVSE is connected aan mijn mqtt server en ik zie via ook berichten via een MQTT explorer in HA binnen komen.
[Afbeelding]

Eerst heb ik geprobeerd om direct van de slimmelezer de data naar de SmartEVSE te sturen maar helaas zonder resultaat ,

Dus nu maar een automation gemaakt die iedere 5 sec de data door stuurt. Ik ben maar begonnen met de stroom

code:

alias: Slimmelezer to SmartEVS 
description: ""
triggers:
  - trigger: time_pattern
    seconds: "5"
conditions: []
actions:
  - action: mqtt.publish
    metadata: {}
    data:
      evaluate_payload: true
      qos: 0
      retain: false
      topic: SmartEVSE/Set/MainsMeter
      payload: |-
        {{
          ((states('sensor.current_phase_1')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }}:{{
          ((states('sensor.current_phase_2')|float(0)))
        }} 
mode: single

[[Afbeelding]/code]

Maar ik kijk op mijn SmartEVSE zie ik niks verschijnen, ik doe vast iets fout maar wat zie ik maar niet

In je plaatje van MQTT explorer zie je zelfs je message binnenkomen, het stukje wat grijs is. En het enige wat je dus moet veranderen is de waardes te vermenigvuldigen met 10, en netjes afronden zonder iets achter de komma, en inderdaad de smartevse op API instellen zodat je de "SMART" optie krijgt.

[Thepawn]

RonJ schreef op zondag 14 september 2025 @ 14:08:
Een beetje contactor kan makkelijk 100.000 schakelingen aan (zo niet nog veel meer), dus ik zou me daar niet meteen heel druk om maken.

Nou, het zijn er twee, en ze maken behoorlijk wat lawaai bij het schakelen. Maar mijn oplossing is om gewoon de stoptimer te verhogen en te blijven opladen op de minimale snelheid zonder te stoppen.

[Hmmbob]

adjego schreef op zondag 14 september 2025 @ 14:57:
[...]


In je plaatje van MQTT explorer zie je zelfs je message binnenkomen, het stukje wat grijs is. En het enige wat je dus moet veranderen is de waardes te vermenigvuldigen met 10, en netjes afronden zonder iets achter de komma, en inderdaad de smartevse op API instellen zodat je de "SMART" optie krijgt.

Je had gemist dat dát antwoord allang gegeven was én het probleem inmiddels opgelost, of wat?

[adjego]

Hmmbob schreef op zondag 14 september 2025 @ 21:39:
[...]

Je had gemist dat dát antwoord allang gegeven was én het probleem inmiddels opgelost, of wat?

Initieel wilde hij het via MQTT en heeft het uiteindelijk via http gedaan. Dat kan naar mijn idee netter. Maar bedankt voor je feedback. Ik snap echt niet waarom ik hier een uitbrander voor krijg....

[ Voor 7% gewijzigd door adjego op 15-09-2025 09:52 ]

[Hmmbob]

Hij schrijft zelf dat hij het eerder rechtstreeks wilde doen, vanaf de slimme lezer naar de SmartEVSE. Wat (imho) ook het beste is, beter om niet HA er tussen te hebben als dat niet nodig is: maakt het onnodig complex en gevoelig(er) voor uitval. Aangezien de slimmelezer uit zichzelf niet MQTT ondersteunt, is de rest api een prima optie.

En geen uitbrander, het was simpelweg dubbelop want al beantwoord en opgelost - dat probeerde ik te zeggen

[ Voor 35% gewijzigd door Hmmbob op 15-09-2025 18:53 ]