I have 9.6 kWp setup with a Fronius Primo 8.2.
The Primo is “managed” by its Smart Meter (because I’m not allowed to feed-in, thank you Enedis/France).
This does work well, the Primo “produces” what the house needs and doesn"t feed-in.
Now I’ve added an OpenEVSE to charge my car and I would like to use the PV divert feature (eco mode).
But the OpenEVSE eco mode and the Fronius Smart meter kind of fight against each over.
The Smart Meter tells the Primo not to over-produce so the eco mode can’t do its job because it doesn’t see anything to divert.
Does anyone have the same issue and/or maybe a way to fix it?
The Primo is the solar inverter, not a diverted load.
I’m not sure I’m in the same case than two different diverted loads (OpenEVSE and something else like a boiler) and the need to decides which gets the most power.
The solar inverter (Primo) is operated by its smart meter (that stands between the grid and all the loads, home/EV).
If there’s no power use (in the house/EV), the smart meter tells the solar inverter to stop producing (to have zero feed in to the grid).
When it does this (zero feed in), the OpenEVSE sees there’s not power to divert.
So doesn’t charge the EV (in eco mode)…
I think I need a way to ask the Primo how much it would produce if zero feed in was not active, then calculate the power I can divert and then link the OpenEVSE eco-mode to this calculated value: Primo possible production - current load (home) = power that can be diverted.
So it would force OpenEVSE to divert power even if its CT doesn’t see it as available.
Unfortunately, I cannot find such data in the Primo (yet).
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.
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).
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.
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.
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.