How to remove waves when Fronius Inverter is clipping?

I made an overlay with from this day:

The ripples are not there in this view (but maybe they smoothing the graph)
On a sunny day like this the panels get to hot and I don’t reach the maximum, on this day the maximum was 13.5 kW. On cloudy days (like the 30/05/2022) pvoutput wrotes a peak on 1:00PM of 15.264kW, while the inverter log shows a maximum of 15.146kW. solarweb shows at 1:00PM on this day 15.17kW

Hmm. My mistake. I only see the ripples when my inverter is running at its maximum output i.e. 5kW whereas in your situation there is significant ripple much of the time and most importantly when your inverter is running at less than its maximum.

If the ripple is ‘real’ it could represent some sort of response by your inverter to your local grid. If you take a closer look at the AC output data using SolarWeb is there anything odd showing with respect to GRID voltage & GRID frequency? Does your grid operator impose any sort of output limiting?


IMHO the ripples are a) calculation error on pvoutput or b) the inverter sends other data to solarweb as in the push services…

I copied some values from both services - maybe solarweb uses an average value

Time     pvoutput (kW)  solarweb (kW)
12:00:00   13.056         12.97
12:05:00   12.924         13.05
12:10:00   13.164         13.08
12:15:00   12.912         13.04
12:20:00   13.2           13.12
12:25:00   13.08          13.21
12:30:00   13.296         13.21
12:35:00   13.176         13.31
12:40:00   13.416         13.33
12:45:00   13.26          13.39
12:50:00   13.416         13.32
12:55:00   13.152         13.29
13:00:00   13.476         13.39
13:05:00   13.26          13.39
13:10:00   13.44          13.35
13:15:00   13.176         13.31
13:20:00   13.44          13.35
13:25:00   13.212         13.34
13:30:00   13.44          13.35
13:35:00   13.164         13.3
13:40:00   13.356         13.27
13:45:00   13.116         13.25
13:50:00   13.356         13.26
13:55:00   13.092         13.23
14:00:00   13.272         13.19

No, no output limiting (except the 15 kW…) And CosPhi is always 1. In the extended output of solarweb I can see reactive power (only some watts), AC voltage and AC current, but seems all normal

The ripples are only visible when the output power does not change much. On a cloudy day I can’t see it, too.

What PVO push string(s) are you using in your Fronius? Can you post them sans API key? Are you using the optional LOG push?

Plotting the data that you supplied it certainly looks like some sort of smoothing. Hopefully someone else on this forum with more knowledge than me would care to comment. I imagine that there are a few in that category!

Also. What version(s) of the firmware are running in your Fronius Symo and its Datamanager card?

SolarAPI v1 - CurrentData - Inverter (5 min)

SolarAPI v1 - Logdata - Data (1 h)

Datamanager card
Circuit board version: 2.4E
Software version: 3.21.4-1

Fronius Symo 15.0-3-M
Software version:: fro33151.upd
Control unit RECERBO: V0.3.27.2
Power stage set SYMO _PS: V1.9.5.1
Filter PC board SYMO _FIL: V1.0.0.1
Country setups: V0.0.116.10

@grannos, I have already explained above (4 years ago) where the ripple comes from.

Hi @bulletmark thanks for the reminder. I wasn’t aware though that @bobosch was using a LOG push until his immediate previous post.

Hi @bobosch. If you take a look at @bulletmark’s post to you will see that the ripple appears to be caused by the LOG push. Can you disable the LOG push ( for a day or two ) to see if this removes the ripple?


Actually, the problem occurs whenever PVOutput calculates power based on the difference of the TOTAL_ENERGY value (for the reason I describe in that link). The is true for processing of the LOG push but I think there is also a mode where it is also true for the normal push, depending on how you configure your push.

I will take a look at the diagram before the full hour (before the log data is pushed).

My tries with the push service showed me that the Logdata push just overwrites the power from the Currentdata push. When this is a known issue, then the Logdata push should only fill values from a missed Currentdata push…

I just setup my own data logger, I will collect some data and take a look at the values send by the inverter on my own.

There are 3 useful values in CurrentData and LogData:
PAC: The actual power output
DAY_ENERGY: counter reading of the energy meter
EnergyReal_WAC_Sum_Produced: In the LogData the amount of produced energy in 5 minutes

PAC is a momentary value, so not the best choice.
DAY_ENERGY: Fronius writes in their documentation, that the value “May be imprecise”

WAC_Sum seems to be the best for this purpose, but also have these ripples

Maybe the inaccurate energy counter is also used in the WAC_Sum value. To verify the output energy I already have measured the real produced energy with an electric meter, but its resolution is only 0,1 kWh, on this the ripples are not visible. I will swap this with a newer one…

I suggest to add two flags to froniuspost.jsp with LogData:

  1. A flag not to use the WAC_Sum value (disable the override of the CurrentData), as the PAC is smoother
  2. A flag to smooth the WAC_Sum value. I haven’t found the solarweb way. In my spreadsheet analysis “=(H3/2+H4+H5/2)/2” does smooth the line nice

Fronius does an artificial quality reduction to make their own service look better :frowning:

I decoded it only partially, but I think they remove 1% of the power at the timestamps with *0 minutes and add 1% at the timestamps with *5 minutes …

My measurement with an electric meter “EM” is still a little bit ripply because I get only a resolution of 10 Wh

So I update my suggestion:
2. Add a flag to do experimental decode the WAC_Sum value
Who could I contact to add this in froniuspost.jsp ?

@bobosch please reply to the personal message I sent you here 2 weeks ago.

PVOutput calculates the power from each EnergyReal_WAC_Sum_Produced data point provided by the LOG push.

Note that these values in Wh are decimal values, currently the calculation rounds the value to an integer, e.g. at 12:00 in the sample data -

EnergyReal_WAC_Sum_Produced = 1048.62

Power = 1049 * 12 = 12588

This matches the “pvoutput” column in the spreadsheet.

One change is to retain the decimals, and the calculation becomes 1048.62 * 12 = 12583.44 but will we still get these “ripples” as shown by dark red lines in the sample graph.

It seems Fronius solarweb does not use EnergyReal_WAC_Sum_Produced provided via LOG push which external parties rely on.

Please send the sample spreadsheet below with solarweb values to

A simple moving average (SMA-20mins) solution yields the following graph -

Original raw values calculated from Fronius energy -

Results with average power overlay, which is power calculated from energy

BB, I have explained this issue years ago. The ripple comes from the generation data (i.e. the inverter push), not the consumption data (i.e. the meter push). For the generation data, I suspect you are reading the TOTAL_ENERGY value but this is updated by the inverter at a slower rate, about every 10 secs, instead of the 2 secs which the DAY_ENERGY value is updated (from my personal measurements). These periods are asynchronous to the 5 min push period so we see a small “sampling/aliasing” ripple beat in the generation graph as the 10 sec sample time drifts wrt to the 5 mins (even with the 2 sec asynchronous sample we see a small ripple but it is much smaller). So you have to use DAY_ENERGY from the inverter/generation push data. Now for those people who have a feed-in meter then you have to subtract generation from consumption and thus the generation sample ripple is introduced into their consumption graph as well. People who have consumption wired meters (which is less common, at least in Australia) don’t get this ripple in their consumption graph. I know this because an early version of my own PVOutput pusher software exhibited the same small ripples on the generation graph until I identified the cause and fixed it.

BTW, as I have said here before, whether a users meter is wired feed-in or consumption is indicated in the meter push data (Meter_Location_Current) so PVOutput should use this, and not require the user to configure it as a push option because user’s get it wrong.

I created a proxy which I have been using since 2018. It corrects this error (and other small PVOutput errors which I will not go into here). Actually, after I did this in 2018 my graphs on PVOutput and Solarweb were essentially exactly the same except for one very slight difference which I determined to be a bug in Solarweb. I corresponded with Fronius engineers for a few months in email (doing various tests and showing them the data) and they eventually agreed and fixed their bug so now the graphs are same. The daily generation and consumption kWh totals are exactly the same and the power values are the same or differ in a few watts here and there only because the Fronius push data is sampled at a slightly different time to the data Fronius send to Solarweb.

The LogData push now has the option to disable the power calculation or use the simple moving average method.


Unfortunately there was a bug reported in DAY_ENERGY which would hang in the middle of the day. PVOutput originally used this until many sites reported this issue.

This is why DAY_ENERGY is disabled by default and calculated from PAC.

BB, I am very aware of that bug. It occurred in some firmware versions before fro28500 (for Symo and Primo) and before fro29390 (for Galvo). An inverter running earlier versions may appear to work fine until generation energy hits 3.277kWh in a day and then it stops counting up. From then and for the rest of the day the computed generation power drops to zero (obviously). Those versions are now ancient so there would be few users still running older versions. Those versions and all versions since do not have this problem.