Updating my post above… have just noticed a zero power usage reading early this am… well before any solar production. And the usual zero reading at 0005 am
Currently 00:05 will be 0W since it is the first reading of the day, the calculation uses the previous reading to determine the difference. This may need to be enhanced to pickup the last last reading of the previous day.
A 0W reading during the day is the result of export calculated from Fronius to be higher than the inverter push reading at the same time/reading. It is not possible for export to be greater than generation so consumption is calculated as 0W.
Everybody using the Fronius push service has this bug but most haven’t noticed it. I wrote about this and another bug a year ago in my post Cumulative flag and daily energy totals. I use my own pusher to work around these issues.
BB, when you say “This may need to be enhanced” are you suggesting you will fix this?
We’ll fix it for Fronius Push first.
Thanks to both of you for your replies.
Now I vaguely recall reading about the zero reading at 5 past midnight bug - easy to live with.
I suppose the zero readings during the day aren’t a huge issue, given that the end of the day consumption and generation figures look about right. It’s probably only an issue for the more obsessional among us 
But I can’t help asking if there’s some way of getting around the issue. I did have a wild stab at a solution by setting a 5 minute delay in the PVOutput settings… but no luck.
Unfortunately the delay won’t help since the processing is using the Fronius timestamp from the inverter and meter push. The auto=1 setting actually has a built-in delay and also re-calculates consumption even if a net meter push is received before an inverter push.
I don’t quite have my head around the logistics of all of this. But it sounds like I’ll just have to put up with it for now. it’s no big issue, I’m very happy with my Smappee/all of panels outputs.
The bug is not specifically about “5 past midnight”. It occurs on the first push of the day which for “always on” inverters will be at 00:05 but for inverters which are self-powered it occurs sometime in the morning when they fire up and note in that case PVO loses the generation value as well. I agree it is typically only a small error but PVO “leaks” this amount every day forever, So after a month you have lost 30 times that amount from your cumulative totals, etc.
Now I’m confused - I though this ‘zero reading on the first push’ thing was an issue for meters, not inverters. Or is it an issue for inverters that are paired with a Fronius meter?.
I have just a Fronius inverter, no Fronius meter, and the inverter doesn’t have the ‘nodayenergy’ problem so my energy value is coming straight from the DAY_ENERGY value from the inverter.
@willsave, is your inverter reporting over 24 hours? If so then you won’t have any issue because you will never have any generation at midnight to report. If not, then is the first generation energy value reported each day (e.g. around 7am) always zero? Perhaps post a link to your system on PVO.
It is set to sleep overnight, so the first reading is around 7am, and yes it is always 0. But then this morning the first 2 readings were 0 power (and naturally therefore energy), and going back a few days to the 8th the first 5 readings are zero (it was a particularly dismal morning)
See https://pvoutput.org/intraday.jsp?id=64310&sid=57175&dt=20180608
I don’t know how much power the inverter itself requires to wake up and operate, but the initial few zeros are the actual energy values reported in the DAY_ENERGY field.
The push service field I’m using in the Fronius inverter is as simple as it gets - /service/r2/froniuspost.jsp?sid=AAAAA&key=BBBB with no extra modifiers at all.
But again - this thread (I thought) was all about pushing from a meter, not a inverter - and working around issues with registers that permanently increase and don’t reset to zero inside the inverter each day, which DAY_ENERGY (now that bug is fixed) doesn’t have.
FWIW, this is the JSON extracted from the inverter in the first reading at 6:55am this morning. The data direct from the inverter shows PAC (Power) = 0, DAY_ENERGY = 0, so the zeros uploaded into PVO are real, not bugs:
{
“Body” : {
“DAY_ENERGY” : {
“Unit” : “Wh”,
“Values” : {
“1” : 0
}
},
“PAC” : {
“Unit” : “W”,
“Values” : {
“1” : 0
}
},
“TOTAL_ENERGY” : {
“Unit” : “Wh”,
“Values” : {
“1” : 404923
}
},
“YEAR_ENERGY” : {
“Unit” : “Wh”,
“Values” : {
“1” : 404923
}
}
},
“Head” : {
“RequestArguments” : {
“Query” : “Inverter”,
“Scope” : “System”
},
“Status” : {
“Code” : 0,
“Reason” : “”,
“UserMessage” : “”
},
“Timestamp” : “2018-06-13T06:55:01+10:00”
}
}
To be honest I don’t use Fronius push. My pusher sends lifetime energy counts where I know for sure that PVO has this bug. The bug being that PVO uses the first push of the day to bias the day’s counts whereas it should use the counts from the last push of the previous day. So both generation and consumption leak away one 5 min period every day.
If you think about it, your inverter has generated power to boot itself and then send a PVO push at the next 5 min boundary so I think it should definitely be sending a finite generation energy count at that time although I agree with you that from the raw DAY_ENERGY it seems to be 0 from the inverter.
I forgot to comment about this. Note that the generation and consumption power values send by Fronius are a “spot” sample so largely of little value or meaning. E.g. you may turn the microwave oven on for 30 secs at the time the spot value is sampled so the consumption power value sent to PVO is much higher than the average power used over the complete 5 mins. So a “0” value doesn’t necessarily mean no power was generated/consumed over the period. It just means 0 was the value of the spot sample.
Thus the only meaningful power value to send each 5 min period is the AVERAGE power over that 5 mins but because we are sending the energy value that means that the average power can be computed by PVO itself (from the difference between current and preceding energy counts scaled by time) and thus we don’t need to send it(!). So my pusher originally only sent generation and energy counts, plus voltage. However PVO has another bug that it will not display standby values unless you send power values so I actually just compute the average power values from the energy value differences and send them redundantly.
You two are talking/operating at a level way above my understanding. But I’ll just point out that my zero readings occur during the day… multiple times… not just after midnight. And I also get a few power figures that are less than what I know is my baseload (if that’s the term). So, each month, I’m losing a lot more info than 30 x my first reading of the day.
Bankstown bloke has kindly explained why that happens - to my unsophisticated understanding, it’s something like the inverter and the smart meter sending generation and export figures info at slightly different times which might explain why it seems to happen a lot more on days when ther’s intermittent cloud cover. But a warning to any readers who think they can rely on my ideas about this.
Perhaps it does that for meters, where it is looking at a permanently incrementing ‘lifetime’ counter that doesn’t reset. For inverters, running from the DAY_ENERGY field direct from the inverter, it clearly is not doing this - its just recording the value straight from the inverter. Different variables, different JSON collections from meters than from inverters.
To the extent that it is using a bit of power to power the inverter, this energy is lost and not available to the house to use anyway, much like the unknown amount of energy lost in the wires from the roof to the inverter, so I’m happy to accept the 0 baseline as whatever comes out of the inverter after it has used what it needs to power itself.
But to answer the question you edited out - yes, I’ve checked the TOTAL_ENERGY and YEAR_ENERGY counters which don’t reset - and the initial value at the start of the day is always identical to the last count at the end of the day when the unit sleeps, so there really isn’t any lost energy being masked by setting anything to zero in the first push.
Here are the raw values from the inverter in the last push of yesterday, and the first push of this morning. TOTAL_ENERGY and YEAR_ENERGY are identical, indicating the zero value in PAC (instantaneous power) and DAY_ENERGY (accumulated daily energy counter) are real and valid, not a result of any bug.
Yes. But Fronius provides the DAY_ENERGY and other energy counters direct from the device, so the energy recorded for the day is an accurate count, regardless of the timing of the spot power samples, which make for pretty charts but shouldn’t be used for doing any maths on unless theres no other choice. This is actually an issue for many of the Powerwall recordings, where accumulated energy currently being calculated from spot power values, and by the end of the day have incorrectly accumulated +/- 0.5 kWh different from that recorded from the inverter - but the Fronius energy counts (NOT the power counts) are the ‘true’ record in this example.
Yes - if you are getting solar generation power from instantaneous ‘spot’ readings on the inverter, and consumption from spot power readings from the meter, and they are sampling at different times, then the ‘export’ value or ‘net’ value calculated from subtracting these two could easily go negative as times. Better to use energy counters and calculate average power from the energy measures if you can, rather than use spot power samples direct from the devices - but I don’t have a Fronius meter, so can’t help there.
I did a test overnight and also saw that what I said didn’t exactly match what I measured although to be honest I can’t explain what I measured either! You hadn’t replied so I just edited out what I wrote.
Inverter Logdata push which contains average 5-minute power from the inverter is now supported.
This brings us one step closer to getting better results with net meter data.
Next step is to support the Meter Logdata push, will need a volunteer with a Fronius smart meter to push some samples for analysis.
EDIT: @bulletmark has kindly offered to push some meter samples.
Needing another volunteer with a Fronius smart meter currently using auto=1 parameter to push some samples for analysis.
Please email pvoutput@gmail.com details.