Hello,
I recently started using SBFspot, version 3.1.1 on raspberry pi.
I tried to get all archived data from the SMA inverter,
and then upload it to pvoutput.org.
I used the -ad and -ae flags too fetch the archived data
(I used -ad300 and -am300, which are larger than the
'live' data that is present in the inverter -- it gave me
'live' data for a few months;
it gave me per-day totals for all months since the inverter was activated.
Somehow, the very first datapoint for the very first day of the archived data
has an 'interesting' power/energy (V2) value:
I assume it is the amount of energy generated from the moment the SMA inverter was enabled upto that moment in time.
In my case, this is a large number: 110925396
In the csv file it looks as follows:
```
12/07/2015 04:25:00;9243,782;110925,396
12/07/2015 04:30:00;9243,782;0,000
```
When uploading the archived data to pvoutput.org
SBFspot tries to upload this huge value as a value for V2.
Pvoutput.org refuses the upload, because the value is higher than the system size:
```
Bad request 400: Power value [110925396] too high for system size [3825]
```
The following patch kind-of fixes this:
when obtaining the archived data using batch_get_archdaydata we take
the system size into account: the system size is passed as additional
parameter in the call to batch_get_archdaydata.
When it encounters a V2 value that is higher than system size,
it will use 0 instead; when that happens, a LOG line is printed.
This works for me; I only tested this with mysqlite.
Note: I slightly edited the attached diff to remove irrelevant changes;
because of this, line numbers in the patch may be slightly off.
Axel.
PS thanks for SBFspot, it does a nice job! :-)
Comments: Just adding to the thread. I set up my logging on a Windows machine about a week ago. Perfect logging every 5 minutes... until yesterday when this occured as well. As others have done, I went in with DB Browser and fixed the data. I had a look at the log CSV files and can't see any issues with the data in there (unless I'm not looking correctly), so I have a feeling SBF is misinterpreting the data when it's being placed into the SQL DB. Quite happy to provide logs if anyone needs to have a look.
I recently started using SBFspot, version 3.1.1 on raspberry pi.
I tried to get all archived data from the SMA inverter,
and then upload it to pvoutput.org.
I used the -ad and -ae flags too fetch the archived data
(I used -ad300 and -am300, which are larger than the
'live' data that is present in the inverter -- it gave me
'live' data for a few months;
it gave me per-day totals for all months since the inverter was activated.
Somehow, the very first datapoint for the very first day of the archived data
has an 'interesting' power/energy (V2) value:
I assume it is the amount of energy generated from the moment the SMA inverter was enabled upto that moment in time.
In my case, this is a large number: 110925396
In the csv file it looks as follows:
```
12/07/2015 04:25:00;9243,782;110925,396
12/07/2015 04:30:00;9243,782;0,000
```
When uploading the archived data to pvoutput.org
SBFspot tries to upload this huge value as a value for V2.
Pvoutput.org refuses the upload, because the value is higher than the system size:
```
Bad request 400: Power value [110925396] too high for system size [3825]
```
The following patch kind-of fixes this:
when obtaining the archived data using batch_get_archdaydata we take
the system size into account: the system size is passed as additional
parameter in the call to batch_get_archdaydata.
When it encounters a V2 value that is higher than system size,
it will use 0 instead; when that happens, a LOG line is printed.
This works for me; I only tested this with mysqlite.
Note: I slightly edited the attached diff to remove irrelevant changes;
because of this, line numbers in the patch may be slightly off.
Axel.
PS thanks for SBFspot, it does a nice job! :-)
Comments: Just adding to the thread. I set up my logging on a Windows machine about a week ago. Perfect logging every 5 minutes... until yesterday when this occured as well. As others have done, I went in with DB Browser and fixed the data. I had a look at the log CSV files and can't see any issues with the data in there (unless I'm not looking correctly), so I have a feeling SBF is misinterpreting the data when it's being placed into the SQL DB. Quite happy to provide logs if anyone needs to have a look.