OpenEVSE + PV divert + Fronius Smart Meter + zero-feed-in

Hello all.

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?

Thank you.

I know nothing about OpenEVSE, and the same about Fronius Primo, however the principle of using the two together is outlined here: Using Multiple Diverters — OpenEnergyMonitor 0.0.1 documentation, which might help a little.


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.

Hi Glyn.

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

Enedis is the power grid operator in most of France (was ERDF): ENEDIS (ex-ERDF), Power Grid Operator in France

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.

Well, I tried and it doesn’t work.

I started with fast charging at 32A, wait a bit, then switched to Eco mode.
OpenEVSE and SmartMeter did not “sync”, as you can see.

Robert, you’re right it’s “other” :sunglasses:

Here’s the current setup:

CT-Grid is used to get the “Divert Excess Generation” as per the documentation, positive when importing, negative when exporting (OpenEVSE / EmonEVSE Setup Guide — OpenEnergyMonitor 0.0.1 documentation).

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.

Try setting the OpenEVSE to divert based on ‘production’ rather than ‘export’:

Unfortunately, it seems the Primo is not able to give this information, I went through the API and could not find it.

I’ll open a support case by Fronius to be sure about this.

I’ll keep on doing tests (the one Glyn suggested and tricking OpenEVSE by manipulating MQTT data).

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.

It seems to work (the OpenWB talks with the inverter using modbus): openWB Fronius WR + Smart Meter - openWB Forum

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

% curl ""
   "Body" : {
      "Data" : {
         "Inverters" : {
            "1" : {
               "DT" : 102,
               "E_Day" : 14847,
               "E_Total" : 4566270,
               "E_Year" : 4566273.5,
               "P" : 409
         "Site" : {
            "E_Day" : 14847,
            "E_Total" : 4566270,
            "E_Year" : 4566273.5,
            "Meter_Location" : "grid",
            "Mode" : "meter",
            "P_Akku" : null,
            "P_Grid" : -14.77,
            "P_Load" : -394.23000000000002,
            "P_PV" : 409,
            "rel_Autonomy" : 100,
            "rel_SelfConsumption" : 96.388753056234719
         "Version" : "12"
   "Head" : {
      "RequestArguments" : {},
      "Status" : {
         "Code" : 0,
         "Reason" : "",
         "UserMessage" : ""
      "Timestamp" : "2023-06-24T18:19:11+02:00"

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

1 Like

I was thinking of this.

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. :grin:

There is, but it’s not a low cost solution.

The answer is one of these:

Price tage varies wildy. Anywhere from 279 to 600 USD depending on where it’s purchased.

I remembered reading about it in this thread:

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.

If I have to go this way, I might do it with a WittBoy.

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

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.