Looks interesting!


#22

A change like that will be fine. I use PHP’s strtotime function and it can easily handle this format. It is better to be parsing any single format rather than 3 though! :grinning:


#23

I’ve had better examples, but just haven’t saved them. I’ll keep an eye out for more.


#24

Ok great. Thanks again for reporting the issue. I’m adding some tests to better catch CSV specific formatting problems to avoid this getting to our production systems in the future.

Currently JSON is primarily used for integration testing, however CSV is heavily used, more so than I initially thought but users so before the beta stage ends for the API, there will be more work on CSV on the way.

Just as a heads up, we are aware of the naming inconsistency of row headers like cloud_opacity vs Azimuth. There will be a fix to change this to match each other. There will probably be an email to recent CSV endpoint users with a few weeks warning as I known it will be a breaking change for some users. This won’t be for a while yet though.


#25

You can get a better idea of the longer term optimism of Solcast forecasts by looking at the latest forecast which shows forecast generation for 2 hours out, around the 3pm time mark period, (each tick mark represents 3 hours and 3pm is the next one) has now dropped to around about what the weatherzone data has been telling me for much longer.

Solcast:
timeline_icons


#26

What data/components from weatherzone are you using to forecast PV?


#27

From their 48 hour forecast page for a given location, I use cloud cover for obvious reasons, rain chance to give a rough indication of how dense the cloud cover is, and temperature to alter panel output expectations due to temperature coefficient. This data is in 3 hour intervals, which is not ideal, but once weighted and interpolated to 5 minute intervals it is proving to be a reasonable estimate of generation behaviour over the next 24 hours.


#28

Interesting approach! If you’re able, it would be great to see some of the data to compare on an interesting/cloudy day. Being able to reproduce what you are seeing would enable us to dig further into it.


#29

Regarding this data change, I’ve removed the problematic +0000 entries at the start. The UTC midnight times are still not ideal but a change to fix these will be coming down in the near future. If you write your code in way to check if UTC midnight is missing hours info (even just a length check would work), when the fix comes through, nothing on the client side will change.

Eg, this

2017-10-06

Will become

2017-10-06T00:00:00Z

#30

My code has been checking to see what the 11th character is. If is a comma then it 00:00:00 Z. Otherwise I just take the next 8 characters, ignore the rest and tack on a Z for the strtotime function. As previously mentioned, its a kludge that has worked well and will still work when you make the fixes you have mentioned, so all is good.