I’ve set up extended data for a Tesla PW2, using the PVOutput java logger on a Windows PC.
Have set all extended variables v7 to v12 as ‘uncumulate’, as per Addstatus service - Add cumulative flag for extended data
It seemed to be working OK, but then I noticed that the quantity logged to v7 seemed to have random samples where the initial baseline value in the first sample was NOT subtracted from the later sample, giving large spikes at random through the day and throwing off the graph axes.
See the ‘Grid Import’ column as v7 in https://pvoutput.org/intraday.jsp?id=64310&sid=60217&dt=20181006&gs=0&m=0 (system ‘WillisAveBilling’)
Clicking the line for ‘Grid Import’ v7 off shows the data graphed to v8-v12 is behaving beautifully.
To check if it was the PW2 sending dud data, or something with the cumulative processing in the PVO website after upload, I switched the variables being inserted into v7 in pvoutput.ini on the Windows logger, without changing anything in the PVO website system config, not even the variable labels for graphing.
Up to 9th september, v7 = site.energy_imported, v8 = site.energy_exported.
From 9th september to tonight, I switched - v7 = site.energy**_exported**, v8 = site.energy_imported.
From 8th October 12:25am , I switched a different register - v7 = solar.energy_exported, v8 = site.energy_imported, v10 = site.energy_exported.
All these switches were done in pvoutput.ini, without changing anything (including graph labels) in the PVO system config on the website.
The logs in pvoutput.log show the values being uploaded to the PVO website are all perfectly as expected, including seeing the columns switch position after the service was restarted.
The data is being uploaded correctly, but its always v7 (label ‘Grid Import’) every day with the spikes, regardless of which values were being uploaded into v7.
Another thing I noticed - for the first column which is v7, the most recent sample in the table seems to retain the full value as uploaded, and then a few minutes later is reset back to a delta value. All other columns v8-v12 display immediately as the corrected-after-baseline uncumulated value. I think the spikes are random times when the baseline subtraction doesn’t happen at all.
@bankstownbloke, seems to me theres something not quite right with the baseline subtraction to implement ‘uncumulate’ mode, that is only affecting v7 and not v8-v12. Perhaps an uninitialised variable going into a loop scanning v7-v12, that is set at the end of the loop prior to processing v8?
Hope this helps track it down. Watch the column labelled ‘Grid Import’ in https://pvoutput.org/intraday.jsp?id=64310&sid=60217 to monitor it.