Zelfbouw Laadpaal ervaringen

[mukky]

Hmmbob schreef op maandag 12 augustus 2024 @ 17:58:
Groep afschakelen in de meterkast?

Dat was ook mijn eerste gok. Hij springt dan meteen weer naar het default scherm en doet dan verder niets meer

[Hmmbob]

@Sicco92 en @adjego Welke MQTT broker gebruiken jullie?

[Sicco92]

Hmmbob schreef op maandag 12 augustus 2024 @ 20:30:
@Sicco92 en @adjego Welke MQTT broker gebruiken jullie?

Ik gebruik de MQTT broker die meekomt met de Home Assistant add-on, wat Eclipse Mosquitto is blijkbaar.

De logs van de add-on gaan niet zover terug tot mijn laatste 'unavailable', maar ik zal die ook eens in de gaten houden.

[adjego]

Hmmbob schreef op maandag 12 augustus 2024 @ 20:30:
@Sicco92 en @adjego Welke MQTT broker gebruiken jullie?

Ik gebruik mosquitto als service.

[fluppie007]

Ook bovenstaande broker hier.

Iets anders, ik heb nu op een 20-25 Eastron (SDM120/220/230/630/72v2) meters de eerste defecte SDM72v2. Nog geen jaar oud, opeens kon er niet meer geladen worden, communication error, dus dacht simpele reboot klaar. Bleek het schermpje van de Eastron ook niet meer te werken. Dus die tellermodule is kapot. Ook manueel uitlezen van de kWh stand lukt niet meer.
Iemand ook al eens gehad?

[Pietje NL]

Jep, hier paar maanden geleden ook precies hetzelfde, was de mains kWh meter, de ev kWh meter is tot op heden ok.

Beide in dezelfde groepenkast, de Mainz kWh meter zat aan het einde van de modbus kabel.

[ Voor 29% gewijzigd door Pietje NL op 13-08-2024 16:39 ]

[fluppie007]

Garantie proberen te claimen? Hoe oud was de jouwe?

[PeterJones]

Ik heb al 3 SDM72d-m-2 units kapot gehad. Elke keer netjes vervangen door hun customer support.

[Xerox]

Ik wil binnenkort de EVbox HomeLine die hier op de oprit hangt verbouwen naar SmartEVSE, maar heb wat vragen.
Dit is nu de binnenkant:
De voorkant:

1) In de meterkast zit de laadpaal achter aan automaat, dus lijkt mij dat alles eruit kan wat er nu in hangt (m.u.v. een contactor), klopt dit?
2) Er zitten rechtsonder in de binnenkant 2 contactors, maakt het uit welke ik gebruik? Hij gaat gebruik worden voor 1-fase laden, dus volgens mij moet dat niet uitmaken.
3) Ik zou graag de RFID-lezer willen herbebruiken, weet iemand of dat mogelijk is? Deze lijkt achter de blauwe plaat aan de bovenzijde te zitten.
4) Ik heb nu dus alleen de SmartEVSE-controller en een DC/AC Residial current sensor nodig, correct?

[martijn_van_eck]

1. Ik zou de 6A automaat in de paal laten zitten. Deze kan je gebruiken om je SmartEVSE netjes te voeden met dunnere draad.
2. Ik zou de 40A gebruiken. Maakt misschien iets grotere klap met inschakelen, maar is veel robuuster
3. Dit zou je moeten testen, ik durf het namelijk niet te zeggen. En anders zou je altijd nog de standaar RFID lezer aan kunnen schaffen. Ik heb zelf de standaard RFID reader vast gelijmd in mijn laadpaal.
4. Wat heb je nog meer nodig?
* Smart EVSE Sensorbox indien je het vermogen van je hoofdaansluiting wilt limiteren
* Klemmen, Tevens om je de din rail te aarden
* draad (6mm en adereindhulsjes)

Dit is mijn build van een jaar geleden

Xerox schreef op donderdag 15 augustus 2024 @ 20:47:
Ik wil binnenkort de EVbox HomeLine die hier op de oprit hangt verbouwen naar SmartEVSE, maar heb wat vragen.
Dit is nu de binnenkant: [Afbeelding]
De voorkant: [Afbeelding]

1) In de meterkast zit de laadpaal achter aan automaat, dus lijkt mij dat alles eruit kan wat er nu in hangt (m.u.v. een contactor), klopt dit?
2) Er zitten rechtsonder in de binnenkant 2 contactors, maakt het uit welke ik gebruik? Hij gaat gebruik worden voor 1-fase laden, dus volgens mij moet dat niet uitmaken.
3) Ik zou graag de RFID-lezer willen herbebruiken, weet iemand of dat mogelijk is? Deze lijkt achter de blauwe plaat aan de bovenzijde te zitten.
4) Ik heb nu dus alleen de SmartEVSE-controller en een DC/AC Residial current sensor nodig, correct?

[dingo35]

De RFID reader moet een 1wire interface hebben en rom 0 en rom 33 functies ondersteunen. Dat wordt meestal bereikt door een bepaalde chip van Dallas Semiconductor (DS...) te emuleren, het protocol staat ook wel bekend als iButton (soort van marktstandaard).

[nvdbosch]

dingo35 schreef op donderdag 1 augustus 2024 @ 09:05:

• OCPP: Allow using SmartEVSE local RFID storage with OCPP
• remove OCPP from LCD menu since it is configured on the webserver
• platformio.ini: update OCPP commit hashes

Ik wil wat gaan experimenteren met de OCPP funtionaliteit. Ik begrijp alleen niet waar het exact geconfigureerd moet worden. In de release notes wordt verwezen naar de webserver, maar op de UI kan ik geen settings vinden voor de OCPP. Zitten er nog ergens afhankelijkheden om de OCPP settings beschikbaar te krijgen?

[dingo35]

Op dit moment is OCPP alleen beschikbaar als je zelf in staat bent om te compileren; de standaard binaries hebben het nog niet, omdat het echt nog alfa status is.

In september gaan we testen op het OCPP Plugfest, hopelijk krijgen we dan meer inzicht in hoeverre we al compatibel zijn met backoffices...

[Damic]

mukky schreef op maandag 12 augustus 2024 @ 17:23:
Kwam op een camping een VEVOR lader tegen met een print zoals in bijlage. Hij “hangt”, de rechter LED moet een heartbeat laten zien maar brandt solide. Iemand een idee hoe een rest uit te voeren? De handleiding (link) spreekt over een emergency stop die er niet op zit en de knop die er wel op zit heeft geen effect. Scherm gaat wel aan maar reageert nergens op. Tips welkom 🙂[Afbeelding]

Misschien wat laat maar waarom is de batterij eruit? Ik zien trouwens ook een drukknop S201 (rechts boven hoofd chip). Zou de groene connector misschien de noodstop zijn, maar ik zou dan eerder verwachten dat er ergens nu een draadbrug insteekt en anders gaat ie naar de noodstop.

[ Voor 10% gewijzigd door Damic op 16-08-2024 22:01 ]

[nvdbosch]

dingo35 schreef op vrijdag 16 augustus 2024 @ 19:41:
Op dit moment is OCPP alleen beschikbaar als je zelf in staat bent om te compileren; de standaard binaries hebben het nog niet, omdat het echt nog alfa status is.

In september gaan we testen op het OCPP Plugfest, hopelijk krijgen we dan meer inzicht in hoeverre we al compatibel zijn met backoffices...

Net even gecompileerd met OCPP en mijn SmartEVSE-3 werd netjes herkend bij TAP Electric. Ik ben nog in een aanlegfase dus meer kan ik nog niet testen...

[dingo35]

Mooi! Hou er rekening mee dat de huidige RFID reader maar 6 bytes (excl family code en CRC code) leest, en sommige tags 7bytes aan info bevatten; afhankelijk van je NFC tag kan dat een test-sessie laten mislukken...

[nvdbosch]

Dat van die RFID had ik inderdaad al meegekregen. Maar als ik het goed begrijp is er ook een mogelijkheid om een vaste ID te configureren van bijvoorbeeld je eigen laadpas. Heb ik dat goed begrepen?

[dingo35]

Er zijn diverse mogelijkheden om je laadpas te autoriseren, zoals bijv
de lokale RFID lijst, waar je laadpas vermoedelijk al op staat ('Learn'). Maar als je per sé je backoffice je kaart wil laten autoriseren (bijv. omdat die al over een lijst van al je gebruikers' tags beschikt), en jouw tag gebruikt nu net die 7 bytes, dan krijg je hem dus niet geautoriseerd.

[ Voor 13% gewijzigd door dingo35 op 17-08-2024 08:10 ]

[dingo35]

Voor alle SmartEVSE gebruikers, zojuist release v3.6.8 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

This is a bugfix release, where an annoying bug that disturbs modbus traffic is fixed.

Known bugs: spurious malformed MQTT packets are generated, which cause the MQTT broker to disconnect and immediately reconnect. This problem is rarely noticed, it has been there since v3.5.1 .

[robo4u]

Hieke schreef op vrijdag 9 augustus 2024 @ 19:21:

Is het mogelijk om te schakelen bij wisselende zonneopbrengst met 2 stuks Iskra 2 polige 32A contactors van 1 naar 3 fases en terug?

In het aansluitschema staat weer een 4-polige met daarachter een 2-polige contactor..

Gezien de ruimte in de kast zou ik graag 2 stuks 2-polige inzetten..

Wat zijn de ervaringen hierover?

Kerte schreef op zaterdag 10 augustus 2024 @ 16:15:
[...]

Ja dat kan: je kan bepalen hoeveel stroom er wordt geïmporteerd van het net in solar mode (dus waarde=0 voor wat jij wilt).
De tesla kan ermee om om te switchen 1f-3f.. het laden stopt dan even en herneemt dan met de wijzigingen.
Inderdaad jammer dat de AUTO functionaliteit niet werkt , maar kan gesimuleerd worden in HA .

@heike @Kerte
Ja, dat is mogelijk, maar de gewone SmartEVSE versie doet dat niet, zoals je al gelezen hebt.
Er is een fork beschikbaar waarbij de solar mode met volledige automatische omschakeling tussen 1-fase en 3-fase laden van mijn hand. Een release versie 3.6.8+ https://github.com/rob040/SmartEVSE-3/releases/tag/v3.6.8%2B is kortgeleden beschikbaar gekomen na een aantal weken zich bij mij bewezen te hebben. (ook op een Tesla overigens)

De wat omslachtige aansluiting van 4-polige contactor C1 plus 2-polige contactor C2 is nodig omdat er anders een onveilige situatie kan ontstaan wanneer C2 geactiveerd wordt zonder C1, de auto 2 fasen zonder nul aangeboden krijgt, waardoor er feitelijk 400Vac ipv 3x 230Vac naar de on-board chargers (OBC) toe gaat. Het heeft dus niks te maken met warmte o.i.d.
De contactors overdimensioneren is eigenlijk niet nodig, omdat ze altijd stroomloos geschakeld worden. De Tesla OBC bouwd de stroomvraag netjes op en af, en voordat je de stekker mag losgooien, is alles al stroomloos (op 12V CP na).

Wat je ook nog nodig hebt is MainsMeter stroom informatie van je 'slimme' meter. Dat kan een 'slimmelezer' zijn, maar ik gebruik ESP8266 module (wat ouder maar krachtig genoeg) of ESP32 module (soms erg goedkoop) met ESPhome software. zie bijv op https://github.com/rob040/EspHome-SmartEVSE

Overigens, iedere afschakeling / omschakeling leidt (helaas) wel tot een bericht van de Tesla App. Dat valt voor zover ik weet niet te voorkomen, of je moet alle Tesla app berichten blokkeren, wat je dan niet meer waarschuwt voor bijv. openstaande ramen oid.

[astrapowerrr]

Hoi, ik heb al een jaar mijn laadpaal in alle tevredenheid.
Nu krijgt mijn partner over 2 maanden een nieuwe lease auto(elektrisch).
De vraag is hoe ik deze paal ga koppelen met haar laad pas.

Volgens de wagenpark beheerder werken ze met shuttel en eflux.

Ik heb ook geen rfid lezer in de paal maar die is zo bij stegen te koop.

Ik lees termen over ocpp maar heb hier beetje weinig kaas van gegeten.

Kan iemand mij een soort van Jip en Janneke taal uitleggen hoe en wat.
Lees bijv al in bovenstaande dat de rfid ook niet(of wel?) kan werken.

Ik hoop hier nog veel van te kunnen leren.

[mjvdzwet]

robo4u schreef op zondag 18 augustus 2024 @ 22:36:
[...]


[...]


Overigens, iedere afschakeling / omschakeling leidt (helaas) wel tot een bericht van de Tesla App. Dat valt voor zover ik weet niet te voorkomen, of je moet alle Tesla app berichten blokkeren, wat je dan niet meer waarschuwt voor bijv. openstaande ramen oid.

Ik zorg ervoor dat ik de wanted charge van de Tesla naar 50% zet (lager mag niet) voordat er geschakeld wordt of de SolarTimeOut bijna verstreken is.

Dit scheelt een hoop berichtjes.

[Kerte]

robo4u schreef op zondag 18 augustus 2024 @ 22:36:
@heike @Kerte
Ja, dat is mogelijk, maar de gewone SmartEVSE versie doet dat niet, zoals je al gelezen hebt.
Er is een fork beschikbaar waarbij de solar mode met volledige automatische omschakeling tussen 1-fase en 3-fase laden van mijn hand. Een release versie 3.6.8+ https://github.com/rob040/SmartEVSE-3/releases/tag/v3.6.8%2B is kortgeleden beschikbaar gekomen na een aantal weken zich bij mij bewezen te hebben. (ook op een Tesla overigens)

Wat je ook nog nodig hebt is MainsMeter stroom

Wil jouw versie implementeren maar ik zit met volgende situatie:
- mains meter via sensorbox v2 +CT klemmen (de v2 die ik heb werkt niet met de Sagemcom T211 energiemeter)
- geen ev-meter (ik hoor dat de SDM630/72 best vaak stuk gaan...)

Kan jouw firmware in solar schakelen tussen 1F<-->3F enkel gebaseerd op het verbruik doorgegeven via mains meter?

[ Voor 12% gewijzigd door Kerte op 19-08-2024 08:52 ]

[Possible]

Heeft er iemand een waterdichte behuizing welke je aan de muur kan bevestigen? ik wil eigenlijk niet zon grote laadpaal kast aan de muur hebben, maar subtiel iets. Zoals dit:

[adjego]

Possible schreef op maandag 19 augustus 2024 @ 08:55:
Heeft er iemand een waterdichte behuizing welke je aan de muur kan bevestigen? ik wil eigenlijk niet zon grote laadpaal kast aan de muur hebben, maar subtiel iets. Zoals dit:

[Afbeelding]

Hier hebben ze verschillende varianten, ook met een rozet.

https://www.laadkabelfabr...t-wandcontactdoos-type-2/

Ik heb zelf een RVS rozet laten maken, maar ik heb hem in een muur gemaakt, en niet in de gevel van het huis.

adjego in "Zelfbouw Laadpaal ervaringen"

[Possible]

adjego schreef op maandag 19 augustus 2024 @ 09:02:
[...]


Hier hebben ze verschillende varianten, ook met een rozet.

https://www.laadkabelfabr...t-wandcontactdoos-type-2/

Ik heb zelf een RVS rozet laten maken, maar ik heb hem in een muur gemaakt, en niet in de gevel van het huis.

adjego in "Zelfbouw Laadpaal ervaringen"

De SmartEVSE met locker heeft best veel ruimte nodig. Ik wil dan niet dan een groot gat willen boren in de gevel Vandaar de ''externe'' oplossing waardoor ik alleen de kabels door de muur hoef te stoppen. Ik zal eens kijken op de site, thanks!

[ocaj]

Ik heb ook de rozet via laadkabelfabriek. Die kun je niet in combinatie met de vergendeling doen.
In mijn geval heb ik dus simpelweg besloten om de kabel NIET te locken aan de kant van de SmartEVSE. Mijn auto heb ik zo ingesteld dat hij de kabel altijd locked na 15s en dat je de auto van het slot moet halen om de kabel uit de auto te trekken.

Effectief betekent dat dat je kabel niet gejat kan worden. Enige dat in theorie zou kunnen gebeuren is dat een grappenmaker de kabel tijdens het laden uit de muur trekt en je auto dus stopt met laden. Kans daarop is waar wij wonen nagenoeg nihil.
In theorie zou er ook niks stuk moeten gaan als je dat doet omdat de CP-pin korter is en tijdens het er uittrekken van de stekker de auto en/of de smartevse dus direct afschakelt voordat de fase-pinnen verbroken worden. (dat is een test die ik overigens nog nooit gedaan heb....).

[dingo35]

robo4u schreef op zondag 18 augustus 2024 @ 22:36:
Ja, dat is mogelijk, maar de gewone SmartEVSE versie doet dat niet, zoals je al gelezen hebt.
Er is een fork beschikbaar waarbij de solar mode met volledige automatische omschakeling tussen 1-fase en 3-fase laden van mijn hand. Een release versie 3.6.8+ https://github.com/rob040/SmartEVSE-3/releases/tag/v3.6.8%2B is kortgeleden beschikbaar gekomen na een aantal weken zich bij mij bewezen te hebben. (ook op een Tesla overigens)

Is het een idee om je verbeteringen in de community versie mee te nemen?

[vanenkelen]

Possible schreef op maandag 19 augustus 2024 @ 08:55:
Heeft er iemand een waterdichte behuizing welke je aan de muur kan bevestigen? ik wil eigenlijk niet zon grote laadpaal kast aan de muur hebben, maar subtiel iets. Zoals dit:

[Afbeelding]

Heb dezelfde oplossing gebouwd die jij wil met een zo klein mogelijk extern socket en met een locking actuator, zie mijn post van inmiddels al weer een poosje geleden:

Linkje

Ik denk dat je nog kleiner kan dan het kastje dat ik gekozen heb, maar dan wordt het wel heel erg priegelen…

[robo4u]

Kerte schreef op maandag 19 augustus 2024 @ 08:51:
[...]


Wil jouw versie implementeren maar ik zit met volgende situatie:
- mains meter via sensorbox v2 +CT klemmen (de v2 die ik heb werkt niet met de Sagemcom T211 energiemeter)
- geen ev-meter (ik hoor dat de SDM630/72 best vaak stuk gaan...)

Kan jouw firmware in solar schakelen tussen 1F<-->3F enkel gebaseerd op het verbruik doorgegeven via mains meter?

Goede vraag. EVmeter of niet, dat moest ik even checken...
De originele code was daar wel van afhankelijk omdat het de EVmeter gebruikte om te kijken hoeveel fasen er werkelijk gebruikt werden, maar die code was brak en kwam met verkeerde conclusies.
Mijn implementatie is is niet afhankelijk van de EV meter, en dat ga ik vandaag testen door m uit de SmartEVSE config te halen.

Of de sensorbox met CT klemmen goed genoeg werkt weet ik niet; ik heb er wat minder goede berichten over gelezen...
Waarom de Sagemcom T211 (DSMR-5) niet met sensorbox zou werken begrijp ik niet; in HA, en Slimme Lezer wodt die gewoon ondersteund. Ikzelf heb Sagemcom T210 DSMR-5 perfect werkend, niet met sensorbox uiteraard. Wellicht zou je eens bij Stegen kunnen vragen wat er mis zou kunnen zijn.
De DSMR data van P1 poort is altijd te prefereren boven een CT klem meting.

[mukky]

robo4u schreef op maandag 19 augustus 2024 @ 11:53:
[...]
Waarom de Sagemcom T211 (DSMR-5) niet met sensorbox zou werken begrijp ik niet; in HA, en Slimme Lezer wodt die gewoon ondersteund. Ikzelf heb Sagemcom T210 DSMR-5 perfect werkend, niet met sensorbox uiteraard. Wellicht zou je eens bij Stegen kunnen vragen wat er mis zou kunnen zijn.
De DSMR data van P1 poort is altijd te prefereren boven een CT klem meting.

Werkt hier ook gewoon, meestvoorkomende fout is een verkeerde kabel tussen de sensorbox en de slimme meter. Originele kabel gebruikt?

[Possible]

vanenkelen schreef op maandag 19 augustus 2024 @ 11:53:
[...]


Heb dezelfde oplossing gebouwd die jij wil met een zo klein mogelijk extern socket en met een locking actuator, zie mijn post van inmiddels al weer een poosje geleden:

Linkje

Ik denk dat je nog kleiner kan dan het kastje dat ik gekozen heb, maar dan wordt het wel heel erg priegelen…

Heb je een linkje van het kastje? Want het is een screenshot lijkt het Ziet er overigens erg goed uit, zoals ik het ook wil hebben. MOet je nu niet elke keer bukken om de kabel erin te doen? Omdat hij nu redelijk laag zit.

En de kabel invoer, was dat niet mogelijk om een gaatje aan de achterkant te boren van de behuzing en dan rondom sealen zodat je de kabels aan de buitenbuur ook niet zichtbaar hebt.

[ Voor 22% gewijzigd door Possible op 19-08-2024 12:08 ]

[Kerte]

robo4u schreef op maandag 19 augustus 2024 @ 11:53:
[...]
Waarom de Sagemcom T211 (DSMR-5) niet met sensorbox zou werken begrijp ik niet; in HA, en Slimme Lezer wodt die gewoon ondersteund. Ikzelf heb Sagemcom T210 DSMR-5 perfect werkend, niet met sensorbox uiteraard. Wellicht zou je eens bij Stegen kunnen vragen wat er mis zou kunnen zijn.
De DSMR data van P1 poort is altijd te prefereren boven een CT klem meting.

bedankt om dit te willen testen.

• Mijn sensororbox v2 is van maart 2020. Dacht dat er nadien een update van is gekomen
• Als ik die op de P1 aansluit op de Sagemcom krijg ik altijd "error- no data" op de Smart EVSE
• De meting via CT-klemmen is erg accuraat. Op de meter krijg je immers de meting met blindstroom (cos phi correctie) onder current van L1/L2/L3, dus ik weet niet goed of de meter betrouwbaarder is dan met de klemmen
• alternatief is de data te versturen via mijn SlimmeLezer - maar dan ben ik afhankelijk van wifi om te laden.

[AirwinB]

Deze melding ( "error- no data") heb ik ook gehad met een sensorbox v2, nadat er een stroomstoring was geweest. Uiteindelijk heb ik dit kunnen verhelpen door de sensorbox stekker bij de smartevse los te halen, en daarna weer te bevestigen.

[ Voor 4% gewijzigd door AirwinB op 19-08-2024 12:30 ]

[robo4u]

Kerte schreef op maandag 19 augustus 2024 @ 12:10:
[...]

bedankt om dit te willen testen.

• Mijn sensororbox v2 is van maart 2020. Dacht dat er nadien een update van is gekomen
• Als ik die op de P1 aansluit op de Sagemcom krijg ik altijd "error- no data" op de Smart EVSE
• De meting via CT-klemmen is erg accuraat. Op de meter krijg je immers de meting met blindstroom (cos phi correctie) onder current van L1/L2/L3, dus ik weet niet goed of de meter betrouwbaarder is dan met de klemmen
• alternatief is de data te versturen via mijn SlimmeLezer - maar dan ben ik afhankelijk van wifi om te laden.

Real life test draait nu. Maar hopen dat de panelen tot voldoende power komen, want de zon hier in Nbr zit achter een melk witte waas. Mijn PV is slechts 6.7kWp, heb zo'n 5kW nodig om tot 3F omschakeling te gaan. Dat is op een mooie zonnige dag slechts een paar uur per dag.

Als de CT meting voldoende kan aangeven wanneer de fase stromen negatief worden (=teruglevering), is dat al gauw voldoende; een paar procent fout in de stroom waarden is niet erg in deze.

Als je al een slimme meter hebt, kan je daar zien of die netjes rond nul teruglevering regeld.
De regeling is best grof, want de Tesla OBC doet alleen op gehele Amperes regelen, ook al krijgt die informatie per 1/10 A. (op 1F is iedere 1A stap gelijk 230W, maar op 3F is dat dus zo'n 700W stap)

De Slimmelezer draait tegenwoordig ook ESPhome, dus z'n standaard functie kan uitgebreid worden met SmartEVSE stroom informatie. Je bent idd wel afhankelijk van WiFi, ja.

[robo4u]

robo4u schreef op maandag 19 augustus 2024 @ 12:35:
[...]
Real life test draait nu. Maar hopen dat de panelen tot voldoende power komen, want de zon hier in Nbr zit achter een melk witte waas. Mijn PV is slechts 6.7kWp, heb zo'n 5kW nodig om tot 3F omschakeling te gaan. Dat is op een mooie zonnige dag slechts een paar uur per dag.

@Kerte Test is geslaagd en ook weer niet.

Tesla accu is nu vol met zonne-energie, maar wel op 1-fase geladen. De panelen kwamen vandaag slechts tot 4550W, dat is bij mij zo'n 4000W overschot voor de EV. Dus er was te weinig vermogen om tot 3F omschakeling over te gaan.

Maar kijkende in de code, heeft de EV-meter hier geen functie in; die is wel nodig als je load-balancing doet met meerdere EVSE's, o.a. voor het bewaken van de MAX_CIRCUIT stromen.

[vanenkelen]

Possible schreef op maandag 19 augustus 2024 @ 11:58:
[...]


Heb je een linkje van het kastje? Want het is een screenshot lijkt het Ziet er overigens erg goed uit, zoals ik het ook wil hebben. MOet je nu niet elke keer bukken om de kabel erin te doen? Omdat hij nu redelijk laag zit.

En de kabel invoer, was dat niet mogelijk om een gaatje aan de achterkant te boren van de behuzing en dan rondom sealen zodat je de kabels aan de buitenbuur ook niet zichtbaar hebt.

Volgens mij is dit hem:
Linkje

Hoogte is voor ons prima hoor, even wat voorover bukken is geen probleem.

En ja het was nog mooier geweest om de kabels aan de achterkant in het kastje te laten komen, maar dat werd me te veel gepriegel om dan de kabel precies op lengte te strippen, een goede afdichting te realiseren die niet kapot gaat als je een keer het kastje van de muur haalt of onderhoud moet plegen. Dus uiteindelijk was dit voor mij de beste oplossing waarbij ik niet uren aan het priegelen zou zijn om alles aan te sluiten.

[Marijnus]

Ter inspiratie ende vermaak leek het me leuk om even te delen hoe het SmartEVSE gedeelte van mijn Home Assistant dashboard er uit ziet.



Standaard staat de lader op "solar" modus. Mijn auto heeft helaas geen makkelijke manier om de SOC op te halen, dus ik stel handmatig in wat de maximum stroomprijs is. Als de stroomprijs onder de maximum ingestelde waarde komt schakelt "Nu laden" vanzelf in waarmee de modus op "smart" springt en de lader volle bak aan de slag gaat. Op basis van de door de SmartEVSE gerapporteerde laadstroom en hoe lang er geladen is wordt er een schatting gemaakt van hoe veel % de accu bijgeladen is. (Want ik heb ook geen stroommeter in mijn lader zitten)

[Hmmbob]

Marijnus schreef op dinsdag 20 augustus 2024 @ 14:00:
Standaard staat de lader op "solar" modus. Mijn auto heeft helaas geen makkelijke manier om de SOC op te halen, dus ik stel handmatig in wat de maximum stroomprijs is.

Leuk, ziet er grotendeels hetzelfde uit als mijn dahsboard.

Gebruik je EV Smart Charging? Anders wil je daar echt even naar kijken

Ik dacht dat alle auto's waar een stekker in kan (of het nu EV of PHEV is) een app hebben? Kan je daar de SOC niet uithalen? Dat gebruik ik voor mijn Hyundai

[ Voor 5% gewijzigd door Hmmbob op 20-08-2024 14:05 ]

[Marijnus]

Hmmbob schreef op dinsdag 20 augustus 2024 @ 14:03:
[...]
Gebruik je EV Smart Charging? Anders wil je daar echt even naar kijken

Ik dacht dat alle auto's waar een stekker in kan (of het nu EV of PHEV is) een app hebben? Kan je daar de SOC niet uithalen? Dat gebruik ik voor mijn Hyundai

Thanks! Ik ga eens kijken naar EV Smart Charging.

Ik rijd een MG, er is inderdaad een app. Maar tot voor kort was er voor Home Assistant alleen een integratie voor die in een aparte docker draaide en die je via MQTT moest verbinden (te veel gedoe). Maar ik zie nu net dat er iets nieuws bestaat. Ook nog in een vroege fase (Werkt niet icm gebruik van de MG app enzo) maar wellicht binnenkort die eens proberen.

[Hmmbob]

Hmm, gisteren klapte mijn hoofdzekering eruit omdat we tegelijk aan het laden en koken waren. De SmartEVSE stond toch in standje SMART, en in mijn DSMR-reader zie ik dat de slimme lezer ook keurig heeft geregistreerd dat we enkele minuten >35A trokken op L1 (we hebben 25A zekeringen), dus waar dat mis is gegaan en waarom de SmartEVSE niet heeft afgeregeld is mij nog een raadsel. Dat gaat normaal prima

[wiljums]

dingo35 schreef op woensdag 17 april 2024 @ 14:24:
[...]


Eerst moet er een hardware prototype v4 beschikbaar komen; daarna de software upgraden; de upgrade van v1.8.0 naar v3.5.0 kostte 3,5 maand....

Zijn er ontwikkelingen met v4?

[dingo35]

Hmmbob schreef op donderdag 22 augustus 2024 @ 10:29:
Hmm, gisteren klapte mijn hoofdzekering eruit omdat we tegelijk aan het laden en koken waren. De SmartEVSE stond toch in standje SMART, en in mijn DSMR-reader zie ik dat de slimme lezer ook keurig heeft geregistreerd dat we enkele minuten >35A trokken op L1 (we hebben 25A zekeringen), dus waar dat mis is gegaan en waarom de SmartEVSE niet heeft afgeregeld is mij nog een raadsel. Dat gaat normaal prima

Dat kan kloppen, deze week is een bug ontdekt die ervoor zorgt dat MaxMains niet goed bewaakt wordt; de bug is al sinds v3.5.0 aanwezig maar werd gemaskeerd door een andere bug, te weten doordat MaxCircuit bewaakt werd, ook in configuraties waar hij niet geconfigureerd was/zou moeten zijn. De bug is verholpen in de vanochtend uitgebrachte versie v3.6.9, ik had nog geen tijd gehad het hier te melden:

Voor alle SmartEVSE gebruikers, zojuist release v3.6.9 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

Yet another bugfix release; fixed two bugs that disturbed the limiting of charging to MaxMains.

It is highly recommended to upgrade to this release to protect your main fuses!

Known bugs: spurious malformed MQTT packets are generated, which cause the MQTT broker to disconnect and immediately reconnect. This problem is rarely noticed, it has been there since v3.5.1 .

[mukky]

wiljums schreef op donderdag 22 augustus 2024 @ 12:55:
[...]

Zijn er ontwikkelingen met v4?

Daar mogen we niet naar vragen maar ik deel je nieuwsgierigheid

[dingo35]

Nog steeds geen prototype in huis, dus status onveranderd....

[Hmmbob]

dingo35 schreef op donderdag 22 augustus 2024 @ 13:44:
[...]


Dat kan kloppen, deze week is een bug ontdekt die ervoor zorgt dat MaxMains niet goed bewaakt wordt; de bug is al sinds v3.5.0 aanwezig maar werd gemaskeerd door een andere bug, te weten doordat MaxCircuit bewaakt werd, ook in configuraties waar hij niet geconfigureerd was/zou moeten zijn. De bug is verholpen in de vanochtend uitgebrachte versie v3.6.9, ik had nog geen tijd gehad het hier te melden:

Voor alle SmartEVSE gebruikers, zojuist release v3.6.9 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

Yet another bugfix release; fixed two bugs that disturbed the limiting of charging to MaxMains.

It is highly recommended to upgrade to this release to protect your main fuses!

Probleem opgelost, koken tijdens het laden ging nu prima. Gelukkig automaten, dus kan ik zelf weer inschakelen.

Known bugs: spurious malformed MQTT packets are generated, which cause the MQTT broker to disconnect and immediately reconnect. This problem is rarely noticed, it has been there since v3.5.1 .

Vannacht 3x. Deze versie heeft zeker nog de mongoose mqtt client?

[ Voor 9% gewijzigd door Hmmbob op 23-08-2024 09:02 ]

[dingo35]

Ja we proberen het probleem in de mongoose MQTT client te lokaliseren omdat de Arduino Core client veel meer resources gebruikt...

[Possible]

Sikri firmware update is goed gegaan! Echter net als de standaard firmware zie ik alleen deze details:



Zou ik mijn drie fases hier niet moeten zien ? (heb 3x25)

[ Voor 191% gewijzigd door Possible op 24-08-2024 10:31 ]

[Hmmbob]

Hoe stuur je die gegevens naar de SmartEVSE dan?

[Possible]

Hmmbob schreef op zaterdag 24 augustus 2024 @ 11:37:
Hoe stuur je die gegevens naar de SmartEVSE dan?

code:

dsmrtosmartevse: 'curl -X POST "http://192.168.1.xx/currents?L1={{ states("sensor.nettocurrent_l1") | float*10 }}&L2={{ states("sensor.nettocurrent_l2") | float*10 }}&L3={{ states("sensor.nettocurrent_l3") | float*10 }}" -H "accept: application/json" -H "Content-Type: application/json" -d {}'

template:
  - sensor:
      - name: "nettocurrent_l1"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl1 = states('sensor.electricity_meter_power_production_phase_l1') | float(0) %}
          {% set currentl1 = states('sensor.electricity_meter_current_phase_l1') | float(0) %}
          {{ currentl1 * -1 if solarl1 > 0 else currentl1 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l1') | is_number and 
            states('sensor.electricity_meter_current_phase_l1') | is_number }}
  - sensor:
      - name: "nettocurrent_l2"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl2 = states('sensor.electricity_meter_power_production_phase_l2') | float(0) %}
          {% set currentl2 = states('sensor.electricity_meter_current_phase_l2') | float(0) %}
          {{ currentl2 * -1 if solarl2 > 0 else currentl2 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l2') | is_number and 
            states('sensor.electricity_meter_current_phase_l2') | is_number }}
  - sensor:
      - name: "nettocurrent_l3"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl3 = states('sensor.electricity_meter_power_production_phase_l3') | float(0) %}
          {% set currentl3 = states('sensor.electricity_meter_current_phase_l3') | float(0) %}
          {{ currentl3 * -1 if solarl3 > 0 else currentl3 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l3') | is_number and 
            states('sensor.electricity_meter_current_phase_l3') | is_number }}

Ik zie dat de de DSMR addon ze wel laat zien, echter komen ze niet binnen in MQTT / HA.

[rvdgaag]

Possible schreef op zaterdag 24 augustus 2024 @ 12:16:
[...]

code:

dsmrtosmartevse: 'curl -X POST "http://192.168.1.xx/currents?L1={{ states("sensor.nettocurrent_l1") | float*10 }}&L2={{ states("sensor.nettocurrent_l2") | float*10 }}&L3={{ states("sensor.nettocurrent_l3") | float*10 }}" -H "accept: application/json" -H "Content-Type: application/json" -d {}'

template:
  - sensor:
      - name: "nettocurrent_l1"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl1 = states('sensor.electricity_meter_power_production_phase_l1') | float(0) %}
          {% set currentl1 = states('sensor.electricity_meter_current_phase_l1') | float(0) %}
          {{ currentl1 * -1 if solarl1 > 0 else currentl1 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l1') | is_number and 
            states('sensor.electricity_meter_current_phase_l1') | is_number }}
  - sensor:
      - name: "nettocurrent_l2"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl2 = states('sensor.electricity_meter_power_production_phase_l2') | float(0) %}
          {% set currentl2 = states('sensor.electricity_meter_current_phase_l2') | float(0) %}
          {{ currentl2 * -1 if solarl2 > 0 else currentl2 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l2') | is_number and 
            states('sensor.electricity_meter_current_phase_l2') | is_number }}
  - sensor:
      - name: "nettocurrent_l3"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl3 = states('sensor.electricity_meter_power_production_phase_l3') | float(0) %}
          {% set currentl3 = states('sensor.electricity_meter_current_phase_l3') | float(0) %}
          {{ currentl3 * -1 if solarl3 > 0 else currentl3 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l3') | is_number and 
            states('sensor.electricity_meter_current_phase_l3') | is_number }}

Ik zie dat de de DSMR addon ze wel laat zien, echter komen ze niet binnen in MQTT / HA.

Dit is een CURL post naar de SmartEVSE, heeft niets met HA en MQTT te maken, de SmartEVSE gebruikt deze data en laat ze ook zien in de browser mist je op de Smart EVSE aangeeft dat deze een MAINS meter heeft (API versie). En er staat nog een foutje in je CURL opdracht, je IP adres is niet juist en bevat nog .xx dan komt het nooit aan.

[Possible]

rvdgaag schreef op zaterdag 24 augustus 2024 @ 13:41:
[...]


Dit is een CURL post naar de SmartEVSE, heeft niets met HA en MQTT te maken, de SmartEVSE gebruikt deze data en laat ze ook zien in de browser mist je op de Smart EVSE aangeeft dat deze een MAINS meter heeft (API versie). En er staat nog een foutje in je CURL opdracht, je IP adres is niet juist en bevat nog .xx dan komt het nooit aan.

xx heb ik idd weggehaald. Kan ik de CURL post ook testen om te zien of deze werkt? Want ik zie de L1 L2 en L3 van mijn slimme meter niet verschijnen zodat hij smart kan laden.

[rvdgaag]

Possible schreef op zaterdag 24 augustus 2024 @ 14:48:
[...]


xx heb ik idd weggehaald. Kan ik de CURL post ook testen om te zien of deze werkt? Want ik zie de L1 L2 en L3 van mijn slimme meter niet verschijnen zodat hij smart kan laden.

Als hij aankomt en de smartevse weet wat hij er mee moet dan heeft hij de waarden weer in de browser, bij mij wordt zowel de EV meter als de Mains meter naar de EVSE gestuurd. Ik doe dat wel met MQTT overigens.

[Possible]

rvdgaag schreef op zaterdag 24 augustus 2024 @ 14:51:
[...]


Als hij aankomt en de smartevse weet wat hij er mee moet dan heeft hij de waarden weer in de browser, bij mij wordt zowel de EV meter als de Mains meter naar de EVSE gestuurd. Ik doe dat wel met MQTT overigens.


[Afbeelding]

Ik heb een home wizzard KWh meter welke ik later nog ga installeren. Ik heb echter MAINS meter nu op API gezet maar krijg helaas geen waardes binnen. SMARTEVSE geeft dan ook een commication error aan en springt dan weer terug.

Heb jij een voorbeeld MQTT daarvoor?

[rvdgaag]

MQTT is wat complexer.

Maar dit is een yaml van mijn automation die de MQTT waarden post naar de EVSE's (ik heb er 2)

alias: MQTT EV-data upload
description: ""
trigger:
- platform: time_pattern
seconds: /2
condition: []
action:
- data_template:
topic: SmartEVSE1/Set/MainsMeter
payload: |-
{{
((states('sensor.netto_stroom_l1')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.netto_stroom_l2')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.netto_stroom_l3')|float ) * 10 ) | round(0)
}}
action: mqtt.publish
- data_template:
topic: SmartEVSE1/Set/EVMeter
payload: |-
{{
((states('sensor.modbus_current_l1_ev1')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.modbus_current_l2_ev1')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.modbus_current_l3_ev1')|float ) * 10 ) | round(0)
}}:{{
(11000)

}}:{{
((states('sensor.modbus_ev1_active_energy')|float ) * 1000 ) | round(0)
}}
action: mqtt.publish
- data_template:
topic: SmartEVSE2/Set/EVMeter
payload: |-
{{
((states('sensor.modbus_current_l1_ev2')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.modbus_current_l2_ev2')|float ) * 10 ) | round(0)
}}:{{
((states('sensor.modbus_current_l3_ev2')|float ) * 10 ) | round(0)
}}:{{
(11000)
}}:{{
((states('sensor.modbus_ev2_active_energy')|float ) * 1000 ) | round(0)
}}
action: mqtt.publish
mode: restart

[Hmmbob]

Possible schreef op zaterdag 24 augustus 2024 @ 12:16:
[...]

code:

dsmrtosmartevse: 'curl -X POST "http://192.168.1.xx/currents?L1={{ states("sensor.nettocurrent_l1") | float*10 }}&L2={{ states("sensor.nettocurrent_l2") | float*10 }}&L3={{ states("sensor.nettocurrent_l3") | float*10 }}" -H "accept: application/json" -H "Content-Type: application/json" -d {}'

template:
  - sensor:
      - name: "nettocurrent_l1"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl1 = states('sensor.electricity_meter_power_production_phase_l1') | float(0) %}
          {% set currentl1 = states('sensor.electricity_meter_current_phase_l1') | float(0) %}
          {{ currentl1 * -1 if solarl1 > 0 else currentl1 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l1') | is_number and 
            states('sensor.electricity_meter_current_phase_l1') | is_number }}
  - sensor:
      - name: "nettocurrent_l2"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl2 = states('sensor.electricity_meter_power_production_phase_l2') | float(0) %}
          {% set currentl2 = states('sensor.electricity_meter_current_phase_l2') | float(0) %}
          {{ currentl2 * -1 if solarl2 > 0 else currentl2 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l2') | is_number and 
            states('sensor.electricity_meter_current_phase_l2') | is_number }}
  - sensor:
      - name: "nettocurrent_l3"
        unit_of_measurement: A
        device_class: current
        state: >
          {% set solarl3 = states('sensor.electricity_meter_power_production_phase_l3') | float(0) %}
          {% set currentl3 = states('sensor.electricity_meter_current_phase_l3') | float(0) %}
          {{ currentl3 * -1 if solarl3 > 0 else currentl3 }}
        availability: >
          {{ states('sensor.electricity_meter_power_production_phase_l3') | is_number and 
            states('sensor.electricity_meter_current_phase_l3') | is_number }}

Ik zie dat de de DSMR addon ze wel laat zien, echter komen ze niet binnen in MQTT / HA.

Ik weet niet wat je hier probeert te doen, maar dit is geen valid HA config (wat doet die 1e regel ) en ik zie geen automation die daadwerkelijk de waardes ergens heen stuurt.

Maar dit is meer een vraag voor het HA topic dan hier.

Home Assistant: Open source Python3 home automation - deel 5

[Possible]

Hmmbob schreef op zaterdag 24 augustus 2024 @ 15:27:
[...]

Ik weet niet wat je hier probeert te doen, maar dit is geen valid HA config (wat doet die 1e regel ) en ik zie geen automation die daadwerkelijk de waardes ergens heen stuurt.

Maar dit is meer een vraag voor het HA topic dan hier.

Home Assistant: Open source Python3 home automation - deel 5

Die zou de data naar de smartevse moeten sturen zodat hij de drie fases uit zou kunnnen lezen. Dit heeft een jaar gewerkt bij een vriend van mij tot nu.

@rvdgaag Kun je hem eens in YAML code zetten? Dat kijkt wat prettiger

[ Voor 6% gewijzigd door Possible op 24-08-2024 17:21 ]

[rvdgaag]

zo dan ?

[Swerfer]

rvdgaag schreef op zaterdag 24 augustus 2024 @ 17:50:
zo dan ?
[Afbeelding]

Dat is een screenshot.

Zet de code tussen [ code=yaml] en [/code] (spatie achter [ weglaten), dan maakt Tweakers er wat moois van...

[rvdgaag]

Swerfer schreef op zaterdag 24 augustus 2024 @ 21:24:
[...]
Dat is een screenshot.

Zet de code tussen [ code=yaml] en [/code] (spatie achter [ weglaten), dan maakt Tweakers er wat moois van...

Humm, merci weer wat geleerd:

YAML:

 alias: MQTT EV-data upload
description: ""
trigger:
  - platform: time_pattern
    seconds: /2
condition: []
action:
  - data_template:
      topic: SmartEVSE1/Set/MainsMeter
      payload: |-
        {{
          ((states('sensor.netto_stroom_l1')|float  ) * 10 ) | round(0) 
        }}:{{
          ((states('sensor.netto_stroom_l2')|float  ) * 10 ) | round(0) 
        }}:{{ 
          ((states('sensor.netto_stroom_l3')|float  ) * 10 ) | round(0) 
        }}
    action: mqtt.publish
  - data_template:
      topic: SmartEVSE1/Set/EVMeter
      payload: |-
        {{
          ((states('sensor.modbus_current_l1_ev1')|float  ) * 10 ) | round(0) 
        }}:{{
          ((states('sensor.modbus_current_l2_ev1')|float  ) * 10 ) | round(0) 
        }}:{{ 
          ((states('sensor.modbus_current_l3_ev1')|float  ) * 10 ) | round(0) 
        }}:{{
           (11000)
           
        }}:{{
          ((states('sensor.modbus_ev1_active_energy')|float  ) * 1000 ) | round(0) 
        }}
    action: mqtt.publish
  - data_template:
      topic: SmartEVSE2/Set/EVMeter
      payload: |-
        {{
          ((states('sensor.modbus_current_l1_ev2')|float  ) * 10 ) | round(0) 
        }}:{{
          ((states('sensor.modbus_current_l2_ev2')|float  ) * 10 ) | round(0) 
        }}:{{ 
          ((states('sensor.modbus_current_l3_ev2')|float  ) * 10 ) | round(0)
        }}:{{
           (11000) 
        }}:{{
          ((states('sensor.modbus_ev2_active_energy')|float  ) * 1000 ) | round(0) 
        }}
    action: mqtt.publish
mode: restart  \ 

[BarryH]

Net de SmartEVSE ingebouwd in mn oude 1fase 32A laadpaal en een Home assistant green gekocht.

Mijn doel is om Solar charging te gebruiken en dit af te wisselen met Normal charging (25A want aansluiting is 3x25A).
Mijn auto is een Ioniq 28kWh, die kan 1fase 30A laden. Tot nu toe stond de laadpaal altijd op 25A.

De P1 meter wordt in HA ingelezen en getoond
SmartEVSE is zichtbaar (mbv https://github.com/dingo35/ha-SmartEVSEv3)

Nu twijfel ik over de juiste manier om de teruglevering vanuit HA naar de SmartEVSE te sturen
a/ blijkbaar zijn er 2 manieren: REST API of MQTT API (https://github.com/SmartE...ter/docs/configuration.md). Wat is de logische methode voor mij?
b/ Waar kan ik meer uitleg vinden hoe dit in HA te doen. Er staat nu een korte uitleg (https://github.com/SmartE...b/master/docs/REST_API.md), maar voor mij als HA beginner en programmeerskills uit de TurboPascal tijd en MSAccess geprut is dit onvoldoende op dit moment. Daarbij lijkt het te verwijzen naar de configuration.yaml file in github, maar staat er ook dat configuration.yaml is deprecated?

Bedankt

Na wat verder lezen:
1/ https://github.com/SmartE.../p1_dsmr_to_SmartEVSE_API gebruikt
1a/ configuration.yaml code toegevoegd aan de (nog bijna lege) configuration.yaml. En dan het IPadress in de code aangepast
1b/ de automation.yaml copieren werkte niet, dus met "create automation" in settings-automations&scenes de builder gebruikt om iets te maken wat er op leek.

En dit lijkt te werken.

Wel gek dat ik solar mode niet kan selecteren in de HA smartevse koppeling, maar wel in de webinterface van de smartevse (maar goed, dat werkt ook).

Ik twijfel nu nog over de update frequentie van de P1 uitlezing (Standaard 30 seconden? nu op 1 seconde gezet) en de frequentie om de dsmr_to_SmartEVSE te updaten (nu ook op 1 seconde)

[ Voor 32% gewijzigd door BarryH op 26-08-2024 10:39 ]

[THM0]

BarryH schreef op zondag 25 augustus 2024 @ 10:07:
Net de SmartEVSE ingebouwd in mn oude 1fase 32A laadpaal en een Home assistant green gekocht.

Mijn doel is om Solar charging te gebruiken en dit af te wisselen met Normal charging (25A want aansluiting is 3x25A).
Mijn auto is een Ioniq 28kWh, die kan 1fase 30A laden. Tot nu toe stond de laadpaal altijd op 25A.

De P1 meter wordt in HA ingelezen en getoond
SmartEVSE is zichtbaar (mbv https://github.com/dingo35/ha-SmartEVSEv3)

Nu twijfel ik over de juiste manier om de teruglevering vanuit HA naar de SmartEVSE te sturen
a/ blijkbaar zijn er 2 manieren: REST API of MQTT API (https://github.com/SmartE...ter/docs/configuration.md). Wat is de logische methode voor mij?
b/ Waar kan ik meer uitleg vinden hoe dit in HA te doen. Er staat nu een korte uitleg (https://github.com/SmartE...b/master/docs/REST_API.md), maar voor mij als HA beginner en programmeerskills uit de TurboPascal tijd en MSAccess geprut is dit onvoldoende op dit moment.

Bedankt

Niet een antwoord op je vraag maar als je hoofdzekering 25A is, dan moet de paal afgezekerd worden op max 16A (en zo moet je ook de SmartEVSE vervolgens instellen).

[BarryH]

THM0 schreef op zondag 25 augustus 2024 @ 10:16:

Niet een antwoord op je vraag maar als je hoofdzekering 25A is, dan moet de paal afgezekerd worden op max 16A (en zo moet je ook de SmartEVSE vervolgens instellen).

offtopic:
De laadpaal is de enige verbruiker op de fase waar deze aangesloten zit. En de 25A aardlekautomaat gaat er echt eerder uit dan de 25A smeltzekering in het door de netbeheerder afgesloten bakelieten kastje. Gebruik dit al 7 jaar en meer dan 20.000 kWh geladen
Dus: ja, niet volgens de standaard regels. Maar het werkt prima. Zelfs (na installatiefout laadpaal door installateur) kort 30A belast en de smeltzekering bleef heel.

[BarryH]

dingo35 schreef op donderdag 22 augustus 2024 @ 13:44:
[...]


Dat kan kloppen, deze week is een bug ontdekt die ervoor zorgt dat MaxMains niet goed bewaakt wordt; de bug is al sinds v3.5.0 aanwezig maar werd gemaskeerd door een andere bug, te weten doordat MaxCircuit bewaakt werd, ook in configuraties waar hij niet geconfigureerd was/zou moeten zijn. De bug is verholpen in de vanochtend uitgebrachte versie v3.6.9, ik had nog geen tijd gehad het hier te melden:

Voor alle SmartEVSE gebruikers, zojuist release v3.6.9 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

Yet another bugfix release; fixed two bugs that disturbed the limiting of charging to MaxMains.

It is highly recommended to upgrade to this release to protect your main fuses!

Known bugs: spurious malformed MQTT packets are generated, which cause the MQTT broker to disconnect and immediately reconnect. This problem is rarely noticed, it has been there since v3.5.1 .

Bij mij staat maxcircuit nu op 16A, maar dat heb ik niet zelf ingesteld . Met solarcharging zie ik hem er gewoon ook overheen gaan. Weet niet of dit een bug of feature is.....

setup: enkele smartevse v3 met HA aansturing van de P1 data. laad 1fase met max 25A.

[BarryH]

ruubert schreef op vrijdag 9 augustus 2024 @ 20:01:
[...]


Ik heb inmiddels deze sensors zelf ook gebouwd. Nu kan ik de laadstroom/energy mooi volgen in het Energy dashboard zonder een extra meter te moeten kopen. De Charge Current is zo te zien de actuele stroom die naar de EV gaat. Een andere sensor geeft de maximaal toelaatbare stroom aan.

ik heb dit net geprobeerd te gebruiken. Ik dacht dat de code naar configuration.yaml gekopieerd moet worden. Maar dan krijg ik een error.
Wat zie ik over het hoofd? bedankt

[dingo35]

@BarryH In de handleiding staat precies beschreven wanneer MaxCircuit bewaakt wordt.

[Deikke]

Is het mogelijk om zelf het modem gedeelte werkend te krijgen? Ik heb een EV (Ioniq 28kwh) zonder app die de SOC aanlevert en stap binnenkort over op een dynamisch contract. Een beetje prutsen met pi's is geen probleem, maar solderen van onderdelen gaat wat te ver.

Ben nu aan het experimenteren met smart ev charging, maar dat werkt toch niet helemaal lekker zonder SOC. Kan nu eigenlijk alleen maar instellen hoeveel ik erbij wil hebben en daar dan op plannen. Op zich werkt dit met een template sensor die het aantal kwh deelt door 0.28 en dan smart ev charging instellen op bijvoorbeeld 40%, maar ideaal is dit niet.

[Jazsie]

Als alternatief kan je ook naar de WiCAN van MeatPi kijken. Hiermee kan je via de OBD poort SOC etc via Wifi naar Smart EV Charging of ieder ander database oid.

Zou ook graag de "modem" functie willen hebben, denk alleen dat het nog effe gaat duren en zelf maken zou ook kunnen echter is er maar weinig informatie over te vinden.

[dingo35]

In deze thread meer info over je eigen modem aan de praat krijgen:
https://github.com/SmartEVSE/SmartEVSE-3/issues/25

[Possible]

Ook mijn zelfbouw paal is klaar! Gekozen om een externe (opbouw) behuizing te gebruiken zodat ik eventueel in de toekomst alleen de voegen hoef bij te werken.

Foto's:

[mukky]

Possible schreef op donderdag 29 augustus 2024 @ 10:18:
Ook mijn zelfbouw paal is klaar! Gekozen om een externe (opbouw) behuizing te gebruiken zodat ik eventueel in de toekomst alleen de voegen hoef bij te werken.

Foto's:
[Afbeelding]

De uitsparing achter is nogal groot, daar kan ongedierte in gaan kruipen want lekker warm. Ik zou dit nog even dichtmaken (kitrandje is het eenvoudigst). Mooi gemaakt verder

[Possible]

Ja moet ik idd nog even doen. Maar voor nu ben ik al lang blij dat de boel werkt

[ocaj]

Zijn er meer mensen die problemen hebben met Solar-mode? Ik heb van de week mijn SmartEVSE ge-update naar 3.6.9 en nu al 2 dagen achter elkaar dat de auto niet goed laadt op Solar-mode. Hij laadt een paar seconden, stopt dan voor 1 minuut en probeert het dan weer voor een paar seconden. Dat herhaalt zich een aantal keer en dan geeft hij het helemaal op.

In de debug-log zag ik "No power available", vlak voordat hij stopte en dat leek te komen door een modbus-error:

code:

(I) (printStatus)(C0) STATE: C Error: 1 StartCurrent: -5 ChargeDelay: 0 SolarStopTimer: 0 NoCurrent: 0 Imeasured: 5.9 A IsetBalanced: 6.0 A, MainsMeter.Timeout=10, EVMeter.Timeout=64.
(I) (printStatus)(C0) L1: 1.2 A L2: -4.0 A L3: 5.9 A Isum: 3.1 A
(V) (fn_mqtt)(C1) 3 RECEIVED 11:-40:59 <- SmartEVSE/Set/MainsMeter
(MBhandleError)(C1) Error response: E0 - Timeout, address: 09, function: 06, reg: 0001.
(D) (IsCurrentAvailable)(C0) No current available Isum line 918. ActiveEVSE=1, TotalCurrent=6.0A, StartCurrent=5A, Isum=3.0A, ImportCurrent=2A.
(I) (Timer1S)(C0) Waiting for Solar power...
(setState)(C0) 14:21:40 STATE C -> C1
(V) (fn_mqtt)(C1) 3 RECEIVED -54:-41:59 <- SmartEVSE/Set/MainsMeter
(D) (IsCurrentAvailable)(C0) No current available StartCurrent line 910. ActiveEVSE=0, TotalCurrent=0.0A, StartCurrent=5A, Isum=-3.6A, ImportCurrent=2A.
(D) (Timer100ms)(C0) ModbusRequest 4: Request Energy Node 0
(V) (ModbusSend8)(C0) Sent packet address: 0x69, function: 0x04, reg: 0x0048, token:0x69040048, data: 0x0002.
(V) (ModbusDecode)(C1) Received packet (7 bytes) 69 04 04 44 ed 31 89
(V) (ModbusDecode)(C1)  valid Modbus packet: Address 0x69 Function 0x04 Register 0x0048 Response
(D) (Timer100ms)(C0) ModbusRequest 20: Request EVMeter Current Measurement Node 0
(D) (Timer100ms)(C0) ModbusRequest 20: Request EVMeter Current Measurement Node 0
(V) (ModbusSend8)(C0) Sent packet address: 0x69, function: 0x04, reg: 0x0006, token:0x69040006, data: 0x000c.
(V) (ModbusDecode)(C1) Received packet (27 bytes) 69 04 18 3e e8 92 51 3e f4 d6 4c 3e f0 dc 1a 00 00 00 00 00 00 00 00 00 00 00 00
(V) (ModbusDecode)(C1)  valid Modbus packet: Address 0x69 Function 0x04 Register 0x0006 Response
(receiveCurrentMeasurement)(C1) DINGO: Meter=Eastron3P, Power[0]=0.
(receiveCurrentMeasurement)(C1) DINGO: Meter=Eastron3P, Power[1]=0.
(receiveCurrentMeasurement)(C1) DINGO: Meter=Eastron3P, Power[2]=0.
(V) (CalcBalancedCurrent)(C0) Checkpoint 1 Isetbalanced=6.0 A Imeasured=5.9 A MaxCircuit=16 Imeasured_EV=0.4 A, Battery Current = 0.0 A, mode=2.
(V) (CalcBalancedCurrent)(C0) Checkpoint 1 Isetbalanced=6.0 A Imeasured=5.9 A MaxCircuit=16 Imeasured_EV=0.4 A, Battery Current = 0.0 A, mode=2.
(V) (CalcBalancedCurrent)(C0) phaseLastUpdate=1725020502.
(V) (CalcBalancedCurrent)(C0) Checkpoint 2 Isetbalanced=6.0 A, Idifference=15.6, mod=0.
(V) (CalcBalancedCurrent)(C0) Checkpoint 3 Isetbalanced=6.5 A, IsumImport=-5.6, Isum=-3.6, ImportCurrent=2.
(V) (CalcBalancedCurrent)(C0) Checkpoint 4 Isetbalanced=6.5 A.
(D) (CalcBalancedCurrent)(C0) Checkpoint c: Resetting SolarStopTimer, MaxSumMainsTimer, IsetBalanced=6.5A, saveActiveEVSE=0.
(V) (CalcBalancedCurrent)(C0) Checkpoint 5 Isetbalanced=6.5 A.
(I) (printStatus)(C0) STATE: C1 Error: 1 StartCurrent: -5 ChargeDelay: 60 SolarStopTimer: 0 NoCurrent: 0 Imeasured: 5.9 A IsetBalanced: 6.5 A, MainsMeter.Timeout=10, EVMeter.Timeout=64.
(I) (printStatus)(C0) L1: -5.4 A L2: -4.1 A L3: 5.9 A Isum: -3.6 A

Aangezien de changelog van 3.6.7 meldt "Fix Power measurement for modbus meters", dacht ik dat dat misschien iets veranderd heeft wat bij mij juist problemen geeft, dus ben ik terug gegaan naar 3.6.6. Zelfde resultaat.

Nu net weer de 3.6.2 geladen die ik had voor de update naar 3.6.9 en de auto laadt weer lekker als een zonnetje...

settings (3.6.9):

JSON:

{
    "version": "v3.6.9",
    "serialnr": 6734,
    "mode": "SOLAR",
    "mode_id": 2,
    "car_connected": false,
    "wifi": {
        "status": "WL_CONNECTED",
        "ssid": "Wifi",
        "rssi": -46,
        "bssid": "DC:15:C8:99:00:A7"
    },
    "evse": {
        "temp": 30,
        "temp_max": 65,
        "connected": false,
        "access": true,
        "mode": 2,
        "loadbl": 0,
        "pwm": 1024,
        "solar_stop_timer": 0,
        "state": "Ready to Charge",
        "state_id": 0,
        "error": "None",
        "error_id": 0,
        "rfid": "Not Installed"
    },
    "settings": {
        "charge_current": 0,
        "override_current": 0,
        "current_min": 6,
        "current_max": 16,
        "current_main": 25,
        "current_max_circuit": 16,
        "current_max_sum_mains": 75,
        "max_sum_mains_time": 0,
        "solar_max_import": 2,
        "solar_start_current": 5,
        "solar_stop_time": 0,
        "enable_C2": "Always On",
        "mains_meter": "API",
        "starttime": 0,
        "stoptime": 0,
        "repeat": 0
    },
    "mqtt": {
        "host": "mqtt.fritz.box",
        "port": 1883,
        "topic_prefix": "SmartEVSE",
        "username": "",
        "password_set": false,
        "status": "Connected"
    },
    "home_battery": {
        "current": 0,
        "last_update": 0
    },
    "ev_meter": {
        "description": "Eastron3P",
        "address": 105,
        "import_active_power": 0,
        "total_kwh": 1878.199951,
        "charged_kwh": 0,
        "currents": {
            "TOTAL": 0,
            "L1": 0,
            "L2": 0,
            "L3": 0
        },
        "import_active_energy": 1878.199951,
        "export_active_energy": 0
    },
    "mains_meter": {
        "import_active_energy": 0,
        "export_active_energy": 0
    },
    "phase_currents": {
        "TOTAL": 43,
        "L1": 4,
        "L2": 9,
        "L3": 30,
        "last_data_update": 1724350576,
        "original_data": {
            "TOTAL": 43,
            "L1": 4,
            "L2": 9,
            "L3": 30
        }
    },
    "backlight": {
        "timer": 2,
        "status": "ON"
    }
}

@dingo35 Als je wil dat ik op github een issue maak, laat maar weten

[maarten_NL]

dingo35 schreef op donderdag 22 augustus 2024 @ 13:44:
[...]


Dat kan kloppen, deze week is een bug ontdekt die ervoor zorgt dat MaxMains niet goed bewaakt wordt; de bug is al sinds v3.5.0 aanwezig maar werd gemaskeerd door een andere bug, te weten doordat MaxCircuit bewaakt werd, ook in configuraties waar hij niet geconfigureerd was/zou moeten zijn. De bug is verholpen in de vanochtend uitgebrachte versie v3.6.9, ik had nog geen tijd gehad het hier te melden:

Voor alle SmartEVSE gebruikers, zojuist release v3.6.9 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

Yet another bugfix release; fixed two bugs that disturbed the limiting of charging to MaxMains.

It is highly recommended to upgrade to this release to protect your main fuses!

Known bugs: spurious malformed MQTT packets are generated, which cause the MQTT broker to disconnect and immediately reconnect. This problem is rarely noticed, it has been there since v3.5.1 .

Heb je in deze release de regeling ook aangepast?

In het verleden hebben we op git een issue besproken waarbij de regeling heel zenuwachtig gedrag vertoonde. Nu zie ik hetzelfde volgens mij weer terug:



om 15:08:40 piekt de P1 verbruik heel kort op 2400, de EVSE reageert en de EV regelt helemaal terug naar 3x 6A (-5700W op de P1) en begint daarna weer terug op te bouwen.

Als er 2400W boven de 0 wordt verbruikt hoeft de regeling naar mijn idee niet zo aggresief te reageren?

[dingo35]

@ocaj Ja graag op github, dan houden we deze thread schoon en kan ik evt. testversies uploaden; het is vreemd dat er pal 2x achter elkaar een modbusrequest 20 plaatsvindt...

De regeling is niet bewust veranderd, maar het is en blijft een complex stukje code....

[maarten_NL]

dingo35 schreef op vrijdag 30 augustus 2024 @ 17:19:

De regeling is niet bewust veranderd, maar het is en blijft een complex stukje code....

Gebruik je een PID controller lib?

[ocaj]

dingo35 schreef op vrijdag 30 augustus 2024 @ 17:19:
@ocaj Ja graag op github, dan houden we deze thread schoon en kan ik evt. testversies uploaden; het is vreemd dat er pal 2x achter elkaar een modbusrequest 20 plaatsvindt...

Done, ook vreemd dat hij een timeout geeft op modbus-adres 9 gebruikt, dat is toch het broadcast-adres voor load-balancing? Dat gebruik ik niet... Verdere discussie via github:
https://github.com/dingo35/SmartEVSE-3.5/issues/125

[lucas321]

Is de Smart EVSE ook als semi publieke laadpaal oplossing in te zetten? Ik zie nergens dat OCPI of iets dergelijks wordt ondersteund.

Iemand ervaring?

Edit: ik zie dat ik op ocpp had moeten zoeken. Mooi. Maar nog wel steeds benieuwd naar ervaringen.

Mijn case: mijn tuin grenst aan de achterkant aan een openbaar parkeerterrein. De gemeente ambtenaar die ik gesproken heb zegt dat ik geen vergunning hoef aan te vragen mits deze op eigen erf hangt.

[ Voor 49% gewijzigd door lucas321 op 02-09-2024 11:12 ]

[jongerenchaos]

Ik gebruik SMARTEVSE in combinatie met:
- Een EMAT aardlek EBN19-440 https://www.elektramat.nl...40a-30ma-type-b-85002011/
- Een EMAT krachtgroep https://www.elektramat.nl...g-nul-16a-b-kar-85004004/
- Een Eastron SDM72D-M V2 meter
- Een IKA432-40 ISKRA relais

Deze onderdelen heb ik in de bovengenoemde volgorde aangesloten, direct na de hoofdschakelaar. Het probleem is dat ik al drie keer de aardlekschakelaar heb moeten vervangen omdat deze defect raakte. Dit lijkt te gebeuren als de auto direct begint te laden nadat ik een lange rit heb gemaakt. De aardlek schakelt dan alles uit en soms kan ik hem daarna nog inschakelen, maar de testknop werkt dan niet meer. Na een tijdje werkt de aardlekschakelaar helemaal niet meer.

Opmerkelijk is dat ik dit probleem niet heb bij publieke laadpalen. Het lijkt erop dat de huidige aardlekschakelaar niet geschikt is voor mijn situatie.

Wat zou de oorzaak van dit probleem kunnen zijn? Zou het helpen om een aardlekschakelaar met een hogere stroomsterkte te installeren, of is er een andere oplossing?

[mukky]

jongerenchaos schreef op maandag 2 september 2024 @ 12:53:
Ik gebruik SMARTEVSE in combinatie met:
- Een EMAT aardlek EBN19-440 https://www.elektramat.nl...40a-30ma-type-b-85002011/
- Een EMAT krachtgroep https://www.elektramat.nl...g-nul-16a-b-kar-85004004/
- Een Eastron SDM72D-M V2 meter
- Een IKA432-40 ISKRA relais

Deze onderdelen heb ik in de bovengenoemde volgorde aangesloten, direct na de hoofdschakelaar. Het probleem is dat ik al drie keer de aardlekschakelaar heb moeten vervangen omdat deze defect raakte. Dit lijkt te gebeuren als de auto direct begint te laden nadat ik een lange rit heb gemaakt. De aardlek schakelt dan alles uit en soms kan ik hem daarna nog inschakelen, maar de testknop werkt dan niet meer. Na een tijdje werkt de aardlekschakelaar helemaal niet meer.

Opmerkelijk is dat ik dit probleem niet heb bij publieke laadpalen. Het lijkt erop dat de huidige aardlekschakelaar niet geschikt is voor mijn situatie.

Wat zou de oorzaak van dit probleem kunnen zijn? Zou het helpen om een aardlekschakelaar met een hogere stroomsterkte te installeren, of is er een andere oplossing?

Ik zou zo niet kunnen bedenken waarom een aardlek 3x sneuvelt... 40A is al ruimschoots meer dan nodig. Ik zou sowieso voor een aardlekautomaat gaan (dus aardlek en krachtgroep gecombineerd) en dan eens een ander merk. Als je prijsbewust bent kijk dan eens naar deze van Schneider Electric. Ik belast deze zonder problemen op de max stroom van 25 ampere voor uren achter elkaar

[jongerenchaos]

mukky schreef op maandag 2 september 2024 @ 13:13:
[...]

Ik zou zo niet kunnen bedenken waarom een aardlek 3x sneuvelt... 40A is al ruimschoots meer dan nodig. Ik zou sowieso voor een aardlekautomaat gaan (dus aardlek en krachtgroep gecombineerd) en dan eens een ander merk. Als je prijsbewust bent kijk dan eens naar deze van Schneider Electric. Ik belast deze zonder problemen op de max stroom van 25 ampere voor uren achter elkaar

Dat is mij dus ook een raadsel.
Volgens mij kan je die niet gebruiken die je aangeeft want die heeft een lekstroom A karakterstiek (dat moet type B zijn, als je de DC detectie vanuit de EVSE niet gebruikt en dat gebruik ik niet) en mag je met een elektrische auto dan niet gebruiken.

[mukky]

@jongerenchaos Waarom niet de DC detectie van Stegen gebruiken i.c.m de ALA die ik hierboven voorstel? Is nog goedkoper ook

[ Voor 7% gewijzigd door mukky op 02-09-2024 15:43 ]

[rvdgaag]

jongerenchaos schreef op maandag 2 september 2024 @ 12:53:
Ik gebruik SMARTEVSE in combinatie met:
- Een EMAT aardlek EBN19-440 https://www.elektramat.nl...40a-30ma-type-b-85002011/
- Een EMAT krachtgroep https://www.elektramat.nl...g-nul-16a-b-kar-85004004/
- Een Eastron SDM72D-M V2 meter
- Een IKA432-40 ISKRA relais

Den om een aardlekschakelaar met een hogere stroomsterkte te installeren, of is er een andere oplossing?

Vervang die EMAT materialen door een kwaliteitsmerk want dat is echt troep.

[jongerenchaos]

rvdgaag schreef op maandag 2 september 2024 @ 20:20:
[...]


Vervang die EMAT materialen door een kwaliteitsmerk want dat is echt troep.

Mag ik vragen welk merk jij zou kiezen? Ik neem aan dat je geen Chint of Sep bedoelt. Of is dat al een beter merk?

[Possible]

Over die ac / dc detector, hoe kan ik in smartevse zien dat deze werkt ?

[mukky]

Possible schreef op maandag 2 september 2024 @ 22:55:
Over die ac / dc detector, hoe kan ik in smartevse zien dat deze werkt ?

Je kunt met een lampje en een batterij testen of hij gelijkstromen meet en dan afschakelt. Als je m loskoppelt van de SmartEVSE zal deze ook in storing gaan.

[rvdgaag]

jongerenchaos schreef op maandag 2 september 2024 @ 22:17:
[...]


Mag ik vragen welk merk jij zou kiezen? Ik neem aan dat je geen Chint of Sep bedoelt. Of is dat al een beter merk?

Ik neem altijd standaard Hager (=duurste), Siemens, ABB, Schneider kan ook prima.

Chint, SEP, AEG etc blijf ik ver vandaan.

[lucas321]

jongerenchaos schreef op maandag 2 september 2024 @ 22:17:
[...]


Mag ik vragen welk merk jij zou kiezen? Ik neem aan dat je geen Chint of Sep bedoelt. Of is dat al een beter merk?

Nee, dat is ook Chinese meuk.

A merken voor Groepenkast onderdelen (niet compleet)
ABB
Hager
Eaton
Schneider Electric

Vermijd a.u.b. merken zoals EMAT, SEP de kans dat dit ellende geeft is groot, zie bij jou 3 maal bewijs. Ik neem aan dat dit onder garantie is geruild? Deze merken kopen white label reseller troep uit China en plakken er hun eigen naampje op. Je krijgt geen data specs van deze componenten, je weet niet wat je krijgt. Ik snap nog steeds niet hoe ze de benodigde EU keuringen doorstaan.

Op electronica die ervoor is om jouw leven te beschermen, zou ik echt alleen maar A merken pakken. Brand kan dodelijk zijn, elektrocutie kan dodelijk zijn, waarom hier zo’n risico’s nemen voor een paar tientjes?

[ Voor 12% gewijzigd door lucas321 op 03-09-2024 08:35 ]

[lucas321]

mukky schreef op maandag 2 september 2024 @ 13:13:
[...]

Ik zou zo niet kunnen bedenken waarom een aardlek 3x sneuvelt... 40A is al ruimschoots meer dan nodig. Ik zou sowieso voor een aardlekautomaat gaan (dus aardlek en krachtgroep gecombineerd) en dan eens een ander merk. Als je prijsbewust bent kijk dan eens naar deze van Schneider Electric. Ik belast deze zonder problemen op de max stroom van 25 ampere voor uren achter elkaar

Die SE ALA waar jij naar refereert heeft geen DC lekstroom detectie. Dit is een type A.

[cruysen]

mukky schreef op maandag 2 september 2024 @ 13:13:
[...]

Ik zou zo niet kunnen bedenken waarom een aardlek 3x sneuvelt... 40A is al ruimschoots meer dan nodig. Ik zou sowieso voor een aardlekautomaat gaan (dus aardlek en krachtgroep gecombineerd) en dan eens een ander merk. Als je prijsbewust bent kijk dan eens naar deze van Schneider Electric. Ik belast deze zonder problemen op de max stroom van 25 ampere voor uren achter elkaar

Zoals al in de opmerkingen hierboven staat dat dit een type A is. (Alleen AC detectie)
Van Schneider zou je dan dit type moeten hebben: A9Z51440 : Acti9 iID - Aardlekschakelaar - 4P - 40A - 30mA - Type B-EV Deze is speciaal voor een EV. Alleen een heel stukje duurder. (Bij Elektromat €298,27 Incl. BTW)
Edit: De 1 fase variant: A9Z51240 : Acti9 iID - Aardlekschakelaar - 2P - 40A - 30mA - Type B-EV voor €262,76 Incl. BTW bij Elektromat)

[ Voor 14% gewijzigd door cruysen op 03-09-2024 09:09 ]

[mukky]

cruysen schreef op dinsdag 3 september 2024 @ 09:05:
[...]

Zoals al in de opmerkingen hierboven staat dat dit een type A is. (Alleen AC detectie)
Van Schneider zou je dan dit type moeten hebben: A9Z51440 : Acti9 iID - Aardlekschakelaar - 4P - 40A - 30mA - Type B-EV Deze is speciaal voor een EV. Alleen een heel stukje duurder. (Bij Elektromat €298,27 Incl. BTW)
Edit: De 1 fase variant: A9Z51240 : Acti9 iID - Aardlekschakelaar - 2P - 40A - 30mA - Type B-EV voor €262,76 Incl. BTW bij Elektromat)

Lijkt me financieel onzinnig, had daarom al eerder voorgesteld om DC detectie van Stegen te pakken en een ALA van Schneider

[jongerenchaos]

lucas321 schreef op dinsdag 3 september 2024 @ 08:32:
[...]


Nee, dat is ook Chinese meuk.

A merken voor Groepenkast onderdelen (niet compleet)
ABB
Hager
Eaton
Schneider Electric

Vermijd a.u.b. merken zoals EMAT, SEP de kans dat dit ellende geeft is groot, zie bij jou 3 maal bewijs. Ik neem aan dat dit onder garantie is geruild? Deze merken kopen white label reseller troep uit China en plakken er hun eigen naampje op. Je krijgt geen data specs van deze componenten, je weet niet wat je krijgt. Ik snap nog steeds niet hoe ze de benodigde EU keuringen doorstaan.

Op electronica die ervoor is om jouw leven te beschermen, zou ik echt alleen maar A merken pakken. Brand kan dodelijk zijn, elektrocutie kan dodelijk zijn, waarom hier zo’n risico’s nemen voor een paar tientjes?

Dank voor de feedback! Ja deze heeft 10 jaar garantie dus ik blijf hem insturen en krijg elke keer een nieuwe retour. Maar het is erg vervelend om dit continu aan te passen. Ik vind het wel een fijn idee dat de aardlek geen onderdeel uitmaakt van het SmartEVSE circuit, voor de extra veiligheid.

[ Voor 5% gewijzigd door jongerenchaos op 03-09-2024 10:37 ]

[dingo35]

Het risico op een DC lek is minimaal, tenzij je een Chinese EV hebt, of een Renault.

Zover ik weet heeft elk A-merk EV een galvanische scheiding van het laadcircuit, waardoor DC lekken onmogelijk zijn.
Alleen de briljante ingenieurs van Renault hadden indertijd een model dat via de electro-motor laadde (ik meen dat het de Zoë was), zonder galvanische scheiding.

[jongerenchaos]

dingo35 schreef op dinsdag 3 september 2024 @ 10:51:
Het risico op een DC lek is minimaal, tenzij je een Chinese EV hebt, of een Renault.

Zover ik weet heeft elk A-merk EV een galvanische scheiding van het laadcircuit, waardoor DC lekken onmogelijk zijn.
Alleen de briljante ingenieurs van Renault hadden indertijd een model dat via de electro-motor laadde (ik meen dat het de Zoë was), zonder galvanische scheiding.

Het betreft hier een ID4 dus dan zou het geen probleem moeten zijn.

[Jazsie]

Gewoon voor de DC detectie gaan van SmartEVSE zelf met daarbij een A merk (zoals hier boven al meermaals is genoemd) Type A ALS.

Verre goedkoopste oplossing maar ook degelijk (mits je uiteraard voor een A merk ALS gaat).

[THM0]

Jazsie schreef op dinsdag 3 september 2024 @ 15:41:
Gewoon voor de DC detectie gaan van SmartEVSE zelf met daarbij een A merk (zoals hier boven al meermaals is genoemd) Type A ALS.

Verre goedkoopste oplossing maar ook degelijk (mits je uiteraard voor een A merk ALS gaat).

Kleine correctie: in de meterkast moet een aardlekautomaat, niet aardlekschakelaar (of twee aparte componenten voor beide functies maar geen idee waarom iemand dat zou doen).

[ Voor 5% gewijzigd door THM0 op 03-09-2024 16:24 ]

[Jazsie]

Vraagsteller heeft al een krachtgroepautomaat, ging over zijn Chinese ALS die het begeven heeft...

Daarnaast moet het dus zeker geen aardlekautomaat zijn, een losse ALS en automaat zoals je zelf al aangeeft mag ook .

Altijd leuk als iemand effe snel reageert zonder het voorafgaande te lezen...

[ Voor 17% gewijzigd door Jazsie op 03-09-2024 16:43 ]

[THM0]

Jazsie schreef op dinsdag 3 september 2024 @ 16:40:
Vraagsteller heeft al een krachtgroepautomaat, ging over zijn Chinese ALS die het begeven heeft...

Daarnaast moet het dus zeker geen aardlekautomaat zijn, een losse ALS en automaat zoals je zelf al aangeeft mag ook .

Altijd leuk als iemand effe snel reageert zonder het voorafgaande te lezen...

Zoals je het schrijft interpreteer ik het dat je de hele zaak vervangt door een aardlekschakelaar.Mijn punt was dat dat alleen niet voldoende is. En ja, ik had de hele discussie gelezen. Sowieso zou ik die 4 eenheden ruimte vrijhouden als je toch iets moet kopen maar dat terzijde.

[Jazsie]

Ahh oke, je hebt een punt. Uiteraard moet je bij gebruik van een ALS ook een automaat erbij hebben.

Een ALAMAT is in dit geval wel handiger ja.

[Stefannn]

jongerenchaos schreef op dinsdag 3 september 2024 @ 10:30:
[...]


Dank voor de feedback! Ja deze heeft 10 jaar garantie dus ik blijf hem insturen en krijg elke keer een nieuwe retour. Maar het is erg vervelend om dit continu aan te passen. Ik vind het wel een fijn idee dat de aardlek geen onderdeel uitmaakt van het SmartEVSE circuit, voor de extra veiligheid.

Dat is begrijpelijk (dacht ik eerst ook), maar betrekkelijk.
Je vertrouwt nu WEL op een goedkoop merk aardlek. Maar NIET op een fatsoenlijke evse.
Het is een terechte wens om voor veiligheids zaken te vertrouwen op zo simpel mogelijke systemen. Dat is het meest robuust.
Ik zie de smartevse echter als redelijk robust.
Het betreft welliswaar een geprogrammeerde component, maar het is wel een plc. Geen “General purpose computer”. Het gedraagt zich daarom meer als een intelligente component dan als een vrij programmeerbare computer die bijvoorbeeld kan crashen.
Nb.. de overstroom beveiliging gaat ook via de smartevse. Als je de dc beveiliging niet vertrouwt is het raar die wel te vertrouwen,
Daarnaast… zoals anderen ook zeggen… de dc beveiliging is redelijk “ver gezocht”. Voor eigenlijk alle autos behalve de Renault zoe is het eigenlijk irrelevant.

Dus… weet je zeker dat die goedkope ingebouwde dc beveiliging veiliger is als de smartevse oplossing?
Hij lijkt in ieder geval eerder stuk te gaan.
En kwa veiligheid lijkt een smartevse dus best ok.