I know this sounds weird, but hear me out.
I use the solar prediction and I like the way it shows in the energy dashboard. But I can’t see the graphs from the past. I can see prediction from today and tomorrow. But not from yesterday, day before, last month,…
This could be usefull to see if the prediction is off from the reality.
You’re right: it sound very back to the future like… 
But I understand your goal so If you have the solar prediction and store that in an influx database with Grafana, you can achieve what you want.
Normally you can keep some history in HA as well but it’s not built for that.
I have some info from physical sensors, as well weather predictions, in Grafana and can perfectly look back in those data.
Isn’t that implicit ?
But yes… I too wanted something similar too but for this the data is in the attributes and this is not historised. Timeseries db (@nick4 suggestion)
EDIT: small (?) correction… the data in the attributes are not stored with their datetime, just as attributes so although they contain datetime in-it, HA does not register it against that.
Using open-meteo forecast (in my humble opinion the most precise for my needs) and it is stored in long term (aka lifetime) statistics and shows up nicely in both energy tab and history 
Maybe something wrong that Yours does not add itself to longterm stats?
Best, JR
Not sure what you mean, the LTS are based on state values and solar fc comes often (only) via attributes, like weather forecasts. They are not visible as LTS…kindly share your energy dash setup and a view of (say) 18 Sept incl. the forecast for that date…
Yes, but if I notice that it is off, I can change the parameters to make the prediction more accurate
Yeah, maybe I will look at that way. I have set up influxDB, but not set it up yet. But the reason I suggested it, because it shows the forecast from today
What you could do is to copy the attributes into another sensor, I do this to track tempforecast every day at 6:00 so I can see how ‘off’ the forecast is during the day and compare with rolling forecast.
Copying sensor data is not that complex too
What exactly are you comparing? Unless you utilise all available solar at all times of the day, how would you do this?
Given a ‘solar forecast’ (prediction) it is only right to ask at the end of the day how good that forecast was, when compared to ‘actual generation’ (reality).
If I want to use the forecast for anything other than looking at a line on a graph, then I want to make sure it is ‘good for purpose’. Particularly if I want to know how much cheap electricity I should put into my battery at 02:00 in the morning, still leaving room to store excess solar energy later in the day.
Quick and easy:
The HA forecast.solar integration provides an entity for energy_production_today, and this value can be seen in history for the past 10 days [but not kept in long-term-stats…]. It is easy to pull up one or more ‘forecast-today’ values, along with any ‘total energy today’ generation from an inverter.
I have two integrations, for east and west facing planes. The solar forecast integration also updates every hour during the day, and the forecast can change quite a lot. In simple terms this gives an idea of accuracy by checking to see if the sum of both forecasts adds up to the end of day generation.
Bit more work:
I use Node-RED [but you can do this in HA] and have added a sensor for solar-v-forecast which is calculated from the above figures. This runs at 22:15 every day, pulls state history from HA, and has a stab at averaging out the forecast from the early morning figures. This allows me to plot the overall performance for the past 10 days.
The overall ratio figure tells me that, for yesterday, I got 70% of forecast. In general, I get either 150% or 50%, so forecast accuracy is worth checking.
Do it all yourself:
I use Node-RED to pull down the forecast.solar using the API and manage the data myself. This allows for capturing forecast and actual in more detail. I have a three-day graph to show tomorrow, today with actual, and yesterday as history. All of this has to be run from array data held in Node-RED.
The huge advantage to doing this is I have the data, and in a place where I can work with it and save it to a separate long-term database. This permits back-analysis on my solar system as I have stored hourly data in a separate database.
Ask Solcast:
I have been using Solcast for several months to see if that provides a more accurate forecast (which it does) and I am monitoring the actual/forecast ratio and seeing 90-100% most of the time. One of the great features of Solcast is they provide a back-cast, looking back for two days. I assume that, if you have a vast field of solar panels, it is easier to ask Solcast what you generated yesterday than it is to monitor and process the data ‘in the field’ yourself.
Again, all run in Node-RED, and this is just the backcast for the last two days. The match is very good, both for end of day actual/forecast ratio, but also hour by hour.
Thursday was a nice sunny day (with a few clouds) and the backcast match is good throughout. Friday was overcast with periods of heavy rain. The overall end-of-day match is spot on at 100%, and remarkably the peaks and troughs match both value and time.
Such a good match, backwards, confirms that for myself and my setup, Solcast is a good forecast, and that I have the correct settings.
Hi, my energy dashboard and developer tools entities from open-meteo-solar-forecast:
Interesting… I have forecast.solar and nothing stored in LTS…this may be a solution for the OP then
But you’ll only have that data (reality) if you consume everything that can be produced (generated) — either by directly using it, storing it (batteries) or exporting excess — unless one has irradiation measurements for your location. In other words, only if demand matches or exceeds generation, you can use your PV to provide reality. If OP meant that in hindsight the provider of the forecast also provide their actuals (more like an adjusted forecast), then even that would be off — in the same way a weather forecast will be off, since it’s usually averages across areas.
Used forecast.solar earlier this year and only today erased data from it in LTS (I did not like the outcome ). Looked up and I have LTS for open-meteo forecast from June this year when I switched to it. Maybe something with LTS requirements or recorder exceptions?
Best, JR
I am sooooo curious why/how you have this in LTS and I donot… weird
EDIT: I do exclude things from recorder and the one that comes close is domain ‘sun’ but that should not be the same
Maybe just give open-meteo solar forecast a try- and You can compare the results as they happily coexist- and after finding Your favorite use it in energy calculations?
For Your convinience a link also: https://github.com/rany2/ha-open-meteo-solar-forecast
Best, JR
Edit: saw that You also did it Keep us informed about Your findings please as community feedback is the best thing with open source…
I added it to my dev instance…let’s see tomorrow
My forecast.solar values aren’t going to LTS by default either. The recorder settings doesn’t affect LTS.
You can create a template sensor that uses one of the sun.sun attributes that has that data. I did that so i could plot elevation and azimuth over the year and now i have that data in my Prometheus.
