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: dear axel, after doing a full search on my envirnment, i found that your issue does occur also with v308 BUT it is not persistent -> it appeared "only twice in 18" executions can you please forward the additional information as requested above I expect that you can modify your patch such that at occurence of the issue you can generate the additional information kr wim
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: dear axel, after doing a full search on my envirnment, i found that your issue does occur also with v308 BUT it is not persistent -> it appeared "only twice in 18" executions can you please forward the additional information as requested above I expect that you can modify your patch such that at occurence of the issue you can generate the additional information kr wim
