RENAULT-forum

Ik ga over een tijdje een nieuwe lader bouwen op basis van OpenEVSE. De P20 gaat er uit. Doel is, naast gewoon een nette lader aan huis te hebben, alle "wellicht" en "zou moeten" in alle rust te kunnen uittesten. Ik ga het systeem dus ook zo bouwen dat ik er echt gemakkelijk nieuwe firmware in kan laden zonder bijvoorbeeld de kap te hoeven verwijderen.

Wat mij betreft zetten we dat voort in Zoë en Zon, want we zijn hier aardig afgedwaald van de RWE box.

Ik zou zelf nooit direct in de code zoiets opnemen. OpenEVSE is een echte laadoplossing en het lijkt mij griezelig daar extra functionaliteit anders dan puur laden aan toe te voegen. Één reden is dat het PWM signaal op de CP pin helemaal in software wordt samengesteld en dus erg timing afhankelijk is.

Wat ik bedoel te zeggen is: Prima modificatie om tegen OpenEVSE te kunnen zeggen "maximeer de stroom nu op 7.2A", maar niet zo'n goed idee om in OpenEVSE in te bakken "als de PV meer oplevert dan 10A, schakel dan het laden in op 12A". Mijn mening dan uiteraard. Dat soort van logica hoort m.i. meer in een energie management systeem, die ook kijkt naar het actuele gebruik ik de rest van de woning, eventuele opwekking in andere bronnen, later wellicht opslag, etc.

Als je bedoelt: hoe moet dat signaal bij OpenEVSE komen: dat is simpel. De processor heeft een seriële interface (PD0 en PD1, volgens mij op de officiële printplaat al naar een header gewired). Die kun je, tegenwoordig meestal via een USB converter, aansluiten op een PC en zo communiceren.

@Fivari: correct. Dat is dezelfde sleep mode welke je nu al wel extern kunt aansturen met RAPI.

Edit: ik lees in de code dat bij een sleep eerst de auto wordt geinstrueerd te stoppen met laden (via de CP), en dat drie seconden later het relais wordt geopend.

Het lijkt me een toevoeging die vrij eenvoudig te maken is. We gaan wel even "de diepte in", maar het belangrijkste is dat de aansturingscommando's onder geen beding de capaciteit van de de voeding te boven gaan. Je hoeft geen rekening te houden met de capaciteit van de kabel naar de auto, dat regelt de auto zelf, maar je moet er natuurlijk wel voor zorgen dat als bijvoorbeeld de aansluitgroep 16A is, een besturingscommando voor 32A niet tot een "plof" leidt. Anders gezegd, de nu in OpenEVSE handmatig of default ingestelde stroomsterkte moet altijd als absoluut maximum worden gehanteerd.

Edit: Met de command line interface (i.p.v. RAPI) kun je wel de maximale stroom ingeven middels het set amp commando. Dat is echter meteen het absolute maximum, alsof je de instelling met de knop doet. Een overbelasting zit dan in een klein hoekje.

Nou, ja en nee. Met RAPI kun je wel Enable (FE) en Disable (FD) uitvoeren, maar geen dynamische wijziging. Pruts. Dat wordt toch nog knutselen tegen die tijd. Aan- en uitzetten kan ik nu al (met een relaiscontact) en dat is me voor straks echt te grof.

Ah, losse stroomspoel! Top. Niks gezegd over groepen.

Hmmm, ik dacht dat het al in de RAPI module zat. Als ik lieg, lieg ik onbedoeld, ik zal het nog even nazoeken, moet wel kloppen wat ik beweer

OpenEVSE kan wel degelijk aangestuurd worden. Op de seriele poort kun je òf een soort command prompt zetten, òf een echt protocol waarmee de boel bestuurbaar is. Blijft natuurlijk dat er "iets" moet zijn wat die informatie ophoest. Als je denkt in termen van compleet energie management, dan is dat super, je centrale besturing kan dan tegen de lader vertellen wat er moet gebeuren.

Het aardige van die RWE box is dat hij zelfstandig de solar opbrengst meet, gewoon met een eigen tussenmeter, kortom, geen enkel integratiewerk nodig. Heeft overigens nog vast wel een haak en een oog, want in Nederland is het verplicht dat elke PV zwaarder dan ik meen 600 Watt op een eigen groep moet worden aangesloten, lees, niet samen mag op de laadgroep.

Op dit moment zie je eigenlijk bosjes van dit soort "deel" oplossingen. Componenten (zoals OpenEVSE), gesloten "boxen" (zoals deze RWE, die probeert netafname te verkleinen, de nieuwe lolo die je op een slimme meter kan aansluiten en dan load balancing doet met de rest van het huis, etc).

Ik hobby zelf heel rustig aan met een wat geintegreerder benadering, vooral omdat ik verwacht dat vanaf 2020 teruglevering erg ongunstig gaat worden.

Maar blijven opletten he? 3 x 16A is leuk, maar bij een standaard aansluiting heb je dan nog 9A over per fase. Goed oppassen met de oven zal ik maar zeggen. Nog een reden dat ik "zeur" over regelbaar. Tenzij je je huisaansluiting wilt verzwaren natuurlijk, maar in dat geval zou ik me in termen van kosten niet meer opwinden over een paar procent beter rendement. Met het vastrecht kun je een heleboel kWhtjes kopen

@michel04: Arduino IDE 1.6.1 (op Ubuntu), OpenEVSE 3.2.2. Geeft bij mij (vooralsnog) alleen een compilatiefout op prog_mem. Wellicht

"prog_uchar and such have been depricated in avr-libc. If you have the newer avr-libc you'll see these errors."

Met de IDE 1.0.5 krijg ik geen errors.

Als je andere versies of andere problemen hebt, PM gerust, dan wil ik best even "meeprutsen"

Fijn dat het werkt!

Groot voordeel van de openEVSE is dat de laadstroom dynamisch bestuurbaar is, mits je de juiste softwaremodules meelaadt. En dat kan altijd, ook achteraf. Ga ik op termijn ook doen.

Ziet er serieus uit. Als ik het goed zie is de automaat (F1) en voeding voor de controller (T1) naar boven verplaatst en verzwaard, zit er linksboven een meter-module (A1), en een spannend relais (K2). Werkt het zo dat als de PV meer dan X levert, de laadbox wordt geactiveerd? Prima methode om ongunstige teruglevering te voorkomen: in Duitsland is het verschil tussen nemen en geven van energie EUR 0.10 per kWh!

Semi-off topic: het zal vast wat slimmer werken dan ik hierboven bedenk, want het nadeel is dan dat je in de nacht niet goedkoop en rustig kunt laden. Overigens is dat dan weer de hele ratio waarom ik met de CAN bus van de Zoe aan het spelen ga, want dan kan ik iets doen als: Laadt 's-nachts op tot x% (seizoensafhankelijk), en hou de rest als reserve voor als de zon flink schijnt.