Which Free Weather Forecast API are people using?

[Rob]

I'm looking for a forecasting service which will give me day ahead data so I can make some decisions around whether to charge my batteries overnight or wait for the sunshine to do it during the day.

Thanks

[Colin]

Not sure I'd trust a weather forecast app that much.  The paid-for ones I've tried don't give very reliable forecasts. Free is very unlikely to.  Unless someone has found one?

[DanF]

I use VisualCrossing via Weather4Lox.  See:

https://wiki.loxberry.de/plugins/weather4loxone/start

https://www.visualcrossing.com/

[Scott F]

I am using the free api from Open Weather although i am using it more for current weather rather than forecasting. You can make up to 60 api calls per hour for free which is fine for my needs as it makes a single call each minute and then outputs data from the stored xml file.

https://openweathermap.org

[Tico]

The best option I've found is Solcast -

https://solcast.com/

It is better than a forecast, insofar is as it's a specific solar production forecast for your rooftop system. If you have a Loxberry (https://wiki.loxberry.de/), there's a specific Solcast plugin that makes integration with the Miniserver very simple.

Alternatively, polling the API via Virtual HTTP inputs can be used. There's then a bit of logic needed on the Loxone end.

[Rob]

Thanks for the suggestions, I'll take a look at all of those.

Cheers

[Techdoctor]

I use openweathermap.  Here is a link on the automated home website where I wrote a tutorial. If you scroll down to the end you can download a PDF of it. This gives you the basics. I also did a next day forecast as well.

[Simon Still]

That looks useful - I'd like to know when it's hot/clear sky to automate a skylight and blinds.  Looks like would work.

Can you make your icon's available?

Also, you say "There are quite a lot of sky codes, but I have only used the most common ones. So an id value of 804 as in our example above gives Overcast".  Doesn't this mean the API will regularly be sending a sky code that you've not coded?  What happens then? 

[Scott F]

I have not put all of the symbols in yet but you can easily download a free .png template from the likes of here https://toppng.com/show_download/173579/msn-weather-icons you just cut out each of the symbols in a 96x96 pixel format in paint or any other picture editor of your choice and save them as individual items then import them as custom symbols into your table.
I also did full tables for wind direction and weather statuses with pretty much every code in there so i do not get any errors. A pretty tedious job as the tables functionality is not great at all or at least not when i created them so it takes even longer than you expect. To my knowledge the virtual status only changes its output if it receives a relevant input that you have listed so if you do not have one of the status codes then it should just leave it showing as the last known value from the table i think but am not 100% sure, i will test and let you know.

[Scott F]

When testing what happens if you have a status code that is not in the table then it seems to leave the description blank and will revert the icon to whatever the default icon is that you chose in the user interface properties of the status block.

[Simon Still]

there's no way of sharing the actual tables without sending your entire config file is there?  

On Saturday, 4 November 2023 at 13:03:42 UTC Scott F wrote:

[Scott F]

I can create a sample config file, just copy the specific blocks into a blank page and send that with all other information removed. Let me know if the attached works for you, you should be able to copy paste the 2 blocks from the sample, unfortunately i cant provide the full virtual input setup config as that has my private API key in it but you can easily set it up as per the guide that Techdoctor provided.

[Scott F]

Here is a slightly more in depth version for you as well I rewrote the virtual input part and put markers where you would put in your own data and included the main blocks i am using. At the moment i am tracking the weather history to look at the suitability for wind and solar install which is why i am using the blocks the way i have it but it should give you a good idea of how it is done.

[Rob]

Been playing around a bit with openweathermap, visual crossing and solcast.

Openweather and visual crossing have loads of detailed info and pretty comprehensive although I couldn't see any solar radiation info in the free version of openweather.

At the moment my main focus is to try and achive a reasonable forecast of tomorrow's solar generation so that I can then have Loxone decide whether to charge my batteries overnight on cheap rate or just wait for the sun to do it.

I like the fact solcast will allow me to specify the details of both my PV arrays and it will then return a solar energy generation prediction based on the weather forecast. Quite neat although you need to do seperate api calls for each PV array and then aggregate them together to get total predicted solar generation.

For the moment think I'm going to use solcast and see how accurate it's solar generation predictions are over the next few months.

As and when I need other data, it's probable I will use one of the other services too as they have much higher limits on daily api calls than solcast.

[Tico]

If you use a Virtual Output combined with a Scheduler, you can better bias the Solcast API calls to when they're effective. ie. every 1 hour for the free 10 calls; 7am to 3pm. By that stage, hopefully the charging management is a done deal (and reserve one API call immediately before the cheap electricity rate).

'Save HTTP Reply' is necessary in the Virtual Output, combined with a Virtual Input polling the saved file. Alternatively, you can use a PicoC block to retrieve the saved file. This link refers (use Google Translate, but revert to German if copying PicoC code....Translate can sometimes screw with the code.) -

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/392954-virtueller-eingang-mittels-http-request-steuern?p=409235#post409235

Solcast is very effective at doing intra-day forecasting and will perceive a frontal system with reduced solar production. I sum the forecast periods remaining for the day and compare that with how much energy is required to fill the battery. If the 'Production Forecast kWh' approaches the 'Charging Remaining kWh' (with a buffer), all priorities are set to filling the battery. In the absence of this signal, charging rate is set to fill the battery by sunset (minus a buffer).

 

This reduces thermal stress on the battery and maximises the available AC production for other loads (EV charging etc.)

[Rob]

Thanks Tico

That's an excellent way of managing the solcast api calls to stay within the free call limits. I hadn't realised you could do api calls this way and was intending to spread the calls out over 24hrs with set polling intervals.

Would you be happy to share your config on how you aggregate the solcast forecasts as that sounds like an exact match for what I'm trying to achive with my battery management too.

Cheers

Rob

[Tico]

Hi Rob,

I have outsourced the main Solcast logic to a Loxberry. Notwithstanding, here's a short version of the logic I had on the Miniserver before doing so. It achieves the same thing as the Loxberry.

The Virtual Inputs (Period 1, Period 2, Period 3 etc.) continue through to Period 48. Command Recognition is very long by the time you get to Period 48. You just need to add an addtional \i"pv_estimate"\i to the preceeding Virtual Input.

Each period is 30 minutes, making the addition of all 48 inputs a rolling 24 hour 'look-ahead'.

I simply used 4-way Adder blocks to group each 4 x Virtual Inputs. Then add those 4-way Adders to the other Adders etc. in a big sidewise tree. 

[Rob]

That's great, thanks for the info, really useful.

[Tico]

edit. And I think you will need to divide the end result by 2 to get the total 24 hour kWh sum.