repost scaling problem

[GoogleCodeExporter]

in the repost routine the dtotal and etotal today are scaled by 1000 which 
results in an error from pvoutput. both should remain as queried.

Original issue reported on code.google.com by b...@ticm.com on 15 Jan 2011 at 1:58

[GoogleCodeExporter]

Curious can you post some data bits as mine requires it.

Original comment by stephenb...@gmail.com on 15 Jan 2011 at 6:22

• Changed state: Accepted

[GoogleCodeExporter]

Well I went to manually post the url that received a 22 result, but got this..

Forbidden 403: Exceeded 60 requests per hour

Something else to think of.. :) - will wait an hour and try again..

Original comment by b...@ticm.com on 15 Jan 2011 at 7:51

[GoogleCodeExporter]

This is the URL - minus the key that smatool tries to send..
http://pvoutput.org/service/r1/addoutput.jsp?d=20110101&g=5346510.000000&key=xxx
xxxxxxx&sid=822

Original comment by b...@ticm.com on 15 Jan 2011 at 7:53

[GoogleCodeExporter]

ok this the the normal result..
Bad request 400: Generated cannot exceed 250000W [5346510.000000]

Original comment by b...@ticm.com on 15 Jan 2011 at 8:11

[GoogleCodeExporter]

What are the values in mysql?

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 2:00

[GoogleCodeExporter]

PVOutput limits to 60 requests per hour. Error 22 which comes from curl usually 
means over this limit.

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 2:43

[GoogleCodeExporter]

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 2:47

[GoogleCodeExporter]

Ah found out something..

if I do a repost within a day things work fine, but when I do a repost from say 
2011-01-01 00:00:00 to 2011-01-15 23:59:59 then the query generates an entry 
per day and pvoutput seems to expect a daily total, so it automatically scales 
by 1000 at pvoutput's end..

Another thing I noticed - and this is function, not really a bug... when I do a 
-repost and its light, smatool tries to do teh normal update, then does the 
repost - it probably should ignore the bluetooth side (if it has the data in 
teh mysql that is) and just do the repost - just me though :)

Original comment by b...@ticm.com on 16 Jan 2011 at 3:27

[GoogleCodeExporter]

error 22 from curl is just reporting  the 400 error from pvoutput.. - perhaps 
its worth passing this out as eh error? without debug on smatool just silently 
quits.

Original comment by b...@ticm.com on 16 Jan 2011 at 3:28

[GoogleCodeExporter]

sql = SELECT DATE_FORMAT( DateTime, "%Y%m%d" ), ETotalToday FROM DayData WHERE 
DateTime LIKE "%-%-% 23:55:00" ORDER BY DateTime ASC

result =

+-----------------------------------+-------------+
| DATE_FORMAT( DateTime, "%Y%m%d" ) | ETotalToday |
+-----------------------------------+-------------+
| 20110101                          |     5346.51 |
| 20110102                          |     5364.57 |
| 20110103                          |     5377.06 |
| 20110104                          |     5394.63 |
| 20110105                          |     5401.57 |
| 20110106                          |     5420.02 |
| 20110107                          |     5433.01 |
| 20110108                          |     5452.46 |
| 20110109                          |     5471.43 |
| 20110110                          |     5490.47 |
| 20110111                          |     5510.11 |
| 20110112                          |     5529.21 |
| 20110113                          |     5548.14 |
| 20110114                          |     5564.26 |
| 20110115                          |      5583.6 |
+-----------------------------------+-------------+
15 rows in set, 1 warning (0.04 sec)

Original comment by b...@ticm.com on 16 Jan 2011 at 3:37

[GoogleCodeExporter]

I'll change repost so it doesn't do an update. I also think repost should only 
work until the day before (midnight) as the normal update will work for the day 
your in. Comments??

There is still an error in the undocumented update feature. If you run the 
system without any dates AND mysql it will only get data from the last output 
to mysql. If there were gaps in the data (like internet or PVOutput failure) 
there will be no update. You can run the system for any date in the past, the 
inverter will give only the data it has. I use 2000-01-01 00:00:00 as a start 
data.

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 5:33

[GoogleCodeExporter]

Yup I was using repost to try and fill in the gaps between 1/1 and now :)

I found the undocumented no args function and have that as my cronjob task once 
per hour now - so things are working nicely :)

Here is another interesting one - using repost..
got this with the below url

http://pvoutput.org/service/r1/addstatus.jsp?d=20110101&t=04:45&v1=-256055.00000
0&v2=12.000000&key=03xxxxxxxxxxx&sid=822

Bad request 400: Date is too far in the past [20110101]

So it looks like PVOutput doesn't let you go too far back to fill in the holes 
:(

Original comment by b...@ticm.com on 16 Jan 2011 at 10:57

[GoogleCodeExporter]

This is strange - I have been putting data back in as far as november - when I 
had the system installed. I'll send a message to Bankstown_bloke and see if he 
can relax it to 3 months for the sma bluetooth systems.

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 11:16

[GoogleCodeExporter]

I use cron every 10 minutes like 0,10,20,30,40,50 * * * * cd
/usr/local/sma-bluetooth; ./smatool -v --debug > /tmp/sma_output.txt

Original comment by stephenb...@gmail.com on 16 Jan 2011 at 11:20

[GoogleCodeExporter]

Fixed in 10test

Original comment by stephenb...@gmail.com on 11 Feb 2011 at 5:01

• Changed state: Fixed