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.
