I made an overlay with solarweb.com from this day:
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?
G.
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?
https://www.pvoutput.org/help/push_services.html#log-data-push-parameters
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)
/service/r2/froniuspost.jsp?sid=90803&key=xxx
SolarAPI v1 - Logdata - Data (1 h)
/service/r2/froniuspost.jsp?sid=90803&key=xxx&v7=Voltage_DC_String_1&v8=Voltage_DC_String_2&v9=Current_DC_String_1&v10=Current_DC_String_2
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
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 https://forums.whirlpool.net.au/thread/2634198?p=22#r428 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?
Grannos.
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”
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:
Fronius does an artificial quality reduction to make their own service look better 
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 ?
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 pvoutput@gmail.com
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.
See https://forum.pvoutput.org/t/fronius-push-logdata-pac-options/5489
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.
