Mmm that sounds awkward, I guess if you manually switch on the EVSE and set it at a low current level the solar PV will keep producing.
I can see the issue will be triggering eco-mode to start charging since there will never be any export. Once running EcoMode should work fine depending on the response time of the ‘Primo’ system.
It’s surprising and a bit crazy you are not allowed to export anything, usually systems that like to limit the export to a low level. I can’t see who a couple of kW would cause the grid any issues. It’s frustrating that clean energy generation is being curtailed like this.
It kinda worked a bit yesterday: eco-mode and smart-meter found some kind of way to play together but only up to 1.6 kW (OpenEVSE was properly setup to charge up to 32A) while the “Primo” could have produce up to 5 kW and I could have diverted up to 4.5 kW to OpenEVSE.
You’re right about the “response time”: it’s all about the sync of the Primo smart meter and OpenEVSE, to get them “read” the power at the same time (and/or in the correct order).
I’ve setup the OpenEVSE yesterday, I’ll do more tests in the following days.
Like starting in forced-mode and leave it this way for 10 minutes then switch to eco-mode (this should do the trick). Not ideal (because I have to manually change the setup after 10 minutes) but at least it would divert all that can be diverted.
About the feed-in limitation: I’m waiting for my new contract with the new energy supplier (with virtual battery).
Until then, I’m not allowed to feed-in anything (spoiler: I was able to send up to 9 kW until a couple of weeks ago, before Enedis installed the connected meter that can “see” feed-in).
Once I have the new contract, I’ll be able to feed-in up to 6 kVA, not more (this is Enedis’ law, you cannot feed in more than 6 kVA when single-phased).
It is almost exactly the same situation: you have two closed-loop control systems that have become cross-linked: The generation is being controlled by the meter with the aim of achieving zero export in the face of varying consumption (and ability to generate), and the openEVSE (eco mode) is trying to control consumption based on varying nett surplus/import.
Your big problem, which I think you’ve alluded to, is delay in the response of the control loop. Any delay almost invariably leads to instability, as in:
I suspect it’s the case that the openEVSE in eco mode needs only to know the generated power - or maybe a little less to allow for house consumption, and this should allow the openEVSE to take most of the generated power until it is satisfied, and at the same time fool the meter into commanding the PV to ramp up to supply the demand.
Without knowing what is measured where and where the various connections are in relation to the measurement points, it’s hard to know how to make this completely automatic, which is surely the objective.
I also measure what is coming out of the inverter (CT-PV), what is coming int/out of the house (including PV, CT-House) and I have another CT for the EV chargers (was here before I setup OpenEVSE).
What you need is communication between the openEVSE and the Primo: the EVSE asks what surplus might be available, the Primo replies (or the Primo just supplies the information anyway) and the EVSE adjusts to that, with the Primo continually monitoring and either adjusting the generation or what it tells the EVSE to take to maintain a balance. When the EVSE is satisfied, the Primo can carry on as normal.
I can’t see it happening unless Fronius are prepared to collaborate.
In the absence of this, I think the answer will be to bias the openEVSE so that it sees a null balance as a small export. It will then drive the EV load upwards in an attempt to balance, whereupon the Primo should ramp up generation until it runs out of capacity and the EV should hold at this. When the EV hits full, it should shut down and the Primo should follow by reducing the generation. If generation falls due to a cloud, import will increase and the EV should ramp down to follow it.
Sadly, this will always require a small import while the EVSE is in operation.
Is “W/m2” from Listing 17 (page 23) helpful? I also noticed the DC voltage and current are available. Maybe it’s worth recording and plotting those values to see if there’s useful information in there.
Nothing really new today.
I’ve upgraded the WiFi firmware to last version (and new look), I’ll be able to do some tests tomorrow.
I found out that Fronius sells it’s own charger (expensive) that is able to communication the inverter (over WiFi) and do some PV-divert charging while using the SmartMeter at the same time (zero feed in).
I also found a document from Fronius that says at least another chargers is able to do the same : the openWB series2.
I tried the URL from the forum post but I can’t see any “production before zero-feed-in”.
“P” and “P_PV” show the power going out of the internet while there’s a zero-feed-in request (it should be >2000 without the zero-feed-in).
@Robert.Wall I did have a look at your suggestion. This value is not available on my inverter (and would need an additional sensor card on a compatible inverter).
I wonder is there any way to measure the solar radiation, and then extrapolate that out to what the expected solar production is, have it at the same slope and azimuth as your solar.
So you could use that as a realtime “measure” of what solar is out there.
Possibly running the openevse at an import of 100w or so. Unfortunately getting it started will be the difficult bit.
Or try to trick OpenEVSE so each 10 minutes, so it tries to add 1A to the current load, until the value it sees at the “CT-Grid” goes positive. Then work this way for 30 minutes, then add 1A… And so on.
But it is complicated.
As far as I’ve understood yet (I’m very rusty in german) OpenWB seems to work a different way: the inverter is not managed by its smartmeter to define the grid-feed-in value.
OpenWB seems to reads the smart meter and the inverter to get PV power and house usage, then talks back to the EV charger (tells it which power it can use) and inverter (limit the PV production to reach the feed-in goal, based on previous PV production and house usage and EV charger usage).
But I’m not sure it does work that way.
I was going to suggest this too - but you got there first. It would be “open loop”, so never totally accurate, but with some adjustment and maybe careful shading of the sensor to replicate shading of the PV array, it would be sufficiently accurate most of the time - probably more accurate than looking at the sky and guessing what solar generation would be.
I had in mind a DIY solution, probably based on an Arduino (or emonTx4’s analogue input) and little more than a small solar cell and load resistor. I’d expect to have to create a look-up table in software to get the output numbers to reasonably match the inverter’s output prior to limiting being applied.
Hello
Interesting topic.
The maximum pv power is trackded by your inverter mppt, but when it limits the output for zero feeding it is no more the case. So it is impossible to know the pv possible yield.
What you can do is implementing an algorythm based on the smart meter grid consumption.
If null increase charging current, if not decrease. I would use a decrease value greater than the increase in order to react fast when you buy the electricity.
And for stability this control loop shall be slower than the one of your inverter, I would say 10 seconds.
I am not familiar with openEVSE so do not know how to implement it.
Good luck
Christophe
To my (perhaps simplistic) thinking, a PV module is in essence a current source, the current available being principally some function of the radiant energy falling upon it (but with some other variables to confuse things). So by knowing the cell voltage and then applying a momentary short-circuit, the MPPT tracker should be able to give a reasonable estimate of the power available. Whether it does this is a different question.
In the case in question, I think it’s obvious the current drawn will be determined by the power demanded to maintain the overall energy balance, with only the upper limit being set by the MPPT controller.
Simplistic view but true. But you can not compute the mppt point from the actual current and cell voltage. It is a max power point tracking not computing
I have one of my inverters do grid limiting, And I looked back a few days at the voltage (DC) graph.
10 panels in a string, Recom 390w, Voc of 49v, Max power voltage of 40.8
Whenever the export limit kicks in, the Mppt is pushed off its “maximum power point” from a string voltage of 408ish to 490ish volts, Possibly that could be something that you could work up from and keep increasing the amount of power the openevse draws.
Since yesterday, my new supplier contract is activated and the new grid limit is 6 KVA.
I setup my Fronius accordingly this morning and the PV-divert feature seems to work (more or less, I have another issue with the i3, I’ll open another thread).
