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: Never mind, got it figured out. Like you said, the vwPvoData view has to be deleted and a new one created with the case statement inserted. DB Browser can do this using the Execute SQL tab. It would be nice if future versions on SBFSpot has the case statement in there with a default of say 1,000,000 watts. That would fix almost all errors since they seem to always be astronomically high values. Thanks, this program is great!
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: Never mind, got it figured out. Like you said, the vwPvoData view has to be deleted and a new one created with the case statement inserted. DB Browser can do this using the Execute SQL tab. It would be nice if future versions on SBFSpot has the case statement in there with a default of say 1,000,000 watts. That would fix almost all errors since they seem to always be astronomically high values. Thanks, this program is great!