I tested it only at run-time, by using the chromium developer tools>Sources>Local Overrides. It seems chromium doesn’t handle the .ts files well, but the compiled java-script isn’t too bad to decode.
For me it was in file 1ff0fc16.js at the part containing the setMinutes(0,0,0), modified from:
r.setHours(0,0,0,0):r.setMinutes(0,0,0);const i=r.getTime();i in s?
To:
r.setHours(0,0,0,0):r.setMinutes(0,0,0);const i=r.getTime()-3.6e6;i in s?
Since Solar tiem became effective (last saturday in Italy) now I have this. Any workaround? It seems the values are wrong by 2 hours
I have an entirely different issue with Solar forecast…it seems to be showing the wrong curves on the energy Dashboard quite often. I have no idea, but it seems to he randomly updating itself and sometimes just showing garbage. I even went and put down 24€ for a year of Premium access, but this did not change anything.
I have 3 different forecasts, and jo matter whether I combine them or show them separately, the displayed forecast is often completely implausible, only to correct itself and then go haywire again …
It is not surprising that things occasionally go wrong, it remains a forecast and especially the weather forecast can cause problems in that calculation. Can you maybe share screenshots of when things go wrong?
Updating the chart continues throughout the day. The API calculates a new forecast every 15 minutes and the energy dashboard is updated at least once an hour.
It doesn’t really look like the forecast is off, more like the data somehow gets corrupted…I will attempt to screenshot the next time there is an obvious error.
This is one of those examples. Yesterday night it showed a forecast of 0.0x for all values, this morning it did one 0 less and the final result was… different. Very different.
Since switching to standard time (in the US), has anyone else noticed the shift is even worse than before? I’ve attached a screenshot for today, but it’s been like this (roughly 3 hrs behind) every day since going from daylight saving time back to standard time. Also, I think right around the time switch, I started seeing this weird upward tail at the end of every forecast as well.
I am seeing the same +1 to the right in the UK too as soon as we moved to winter time. My coord, elevation, roof angle and azimuth are 100%. Measured the roof angle myself, compass for azimuth. I have attempted to look at the api output and the entity value but failed to see the correlation. I did not dig into the code yet to understand it better though
My results match yours with a multi-hour offset
It looks to me like this was reported 5 months ago, and the underlying cause detailed 4 months ago. Is there any progress on moving towards a fix? Or are we doomed to having time shifted forecasts forever? It really looks to me like something is looking at the wrong timezone.
There are three ‘time features’ to the solar forecast / HA integration.
The first point is now agreed, so that for many/most/all of us, the line needs to be shifted left by one hour (and only one hour). The symptoms of this ‘right-shift’ are, a low or zero slope to the start of the dotted line, the peak not matching solar noon, and a hanging right hand end. The hanging end is due to both the shift and the plot not extending by a further hour to get back to zero at/after sunset.
The second point is problematic, since HA appears to do everything internally on UTC, and converts to ‘local time’ based on machine time zone settings as and when required. If one part of the system does not “follow the rules” then time used by code can be out from local time at the point of use. DST changes make this more complicated still. Since much of this (great) development and integration work is done by people living in The Netherlands / Europe, they experience UTC +1 (or UTC +2 in the summer). I live in the UK, so my HA is set to GMT (or BST as our DST in summer) which is equal (but not equivalent) to UTC. When developers and testers are +/- 7 hours out from UTC then it is very apparent when local time is not right. When you are +0 or +1 hour off UTC, then DST or living next to someone in a +/- 1 hour different time zone can (quite rightly) be blamed for a great deal of confusion. For me, UTC to local time is currently +0, so human/code errors in UTC-to-local time zone management do not show up.
There is also the question of forecast.solar time. The site appears to use the geographical location provided (from your HA location settings) to calculate effective local time (not UTC) at that location and to return the required data based on (ISO format) local time. My experience is that sunrise/sunset in the forecast and API always matches my local sunrise/sunset, so it does appear to work correctly, but that is only for myself. USA users with multi-time-zones per country may have a issue where forecast.solar is getting local time wrong. If forecast.solar local time for you is +1 or +2 hours out, then the plot will be +2 or +3 hours out.
The third point is a natural consequence of cloud. The solar forecast is updated at regular intervals, and the base weather forecast likewise, so the graph will change. The upcoming forecast can change quite dramatically as the base weather forecast used is updated. I have seen a great solar PV day turn into nothing, and vice versa. Interestingly the solar forecast will change historically as the day progresses, which can have a big impact on the ‘energy generation today’ figures. It can also lead to these dramatic plunges in the graph that can sometimes be seen either during the middle of the day or at the end of the day.
The orange line is the forecast (which is updated for the entire day every hour). The magenta line is a copy of the forecast for the hour, kept as history of what the forecast was. This graph is generated from direct forecast.solar API calls, so in-day forecast change (and the apparent shift of my actual to the forecast) is not an integration / HA issue.
I believe:
1 is an integration feature - the solution (for now) is to use the forecast.solar API directly yourself, or mentally shift the line one hour left.
2 is a more subtle issue where different components might not be strictly adhering to ISO standard timestamps for UTC and correct local time zone conversion. If everything was UTC, or everything was ‘local’ (whatever that means for you) I am sure everything would be fine! Note that (2) may be cancelling out (1) in some cases, so those that develop this stuff are clearly reluctant to fix (1) and cause a problem elsewhere.
3 is down to ‘weather’ and ‘forecasts’.
The fact that this (free) integration is anywhere near right at anytime is, I think, quite remarkable. My grandmother used to check a bit of seaweed she had hanging up in the garden. If it was wet, she knew it was raining.
The custom integration GitHub - oziee/ha-solcast-solar: Solcast Integration for Home Assistant works great. Switched to it after couldn’t get default integration to sync the time correctly. Only takes a couple minutes to setup. Give it a try
It is a real shame.
I bought expensive hardware and invested a great deal of time and effort into Home Assistant based, mostly, on the then website product information on the integrated solar forecast.
Much as I support the efforts of all involved, it turns out that the integration is inaccurate, and you can’t actually use it for anything.
How can I add this integration ( oziee/ha-solcast-solar: Solcast Integration for Home Assistant (github.com))? I configured HACS, but can’t find this integration there.
You have to add it as a custom repository in HACS. Click 3 dots in top right in HACS, add url in repository,select integration.
Or, like any addon, can always do manually: download code from github, copy “solcast_solar” folder into your /config/custom_components/ folder . restart homeasssistant
I was able to add the integration. I created a site with an API key, but I don’t get any values. When I generate an API URL based on the documentation ( Solcast Data API) I tells me that payment is required and I don’t have an active plan for forecast. Then I read, that only 5 requests at my location are for free, for more you have to pay.
probably better to ask in the solcast thread or post an issue on his github (I’m not the author). The documentation of the integration states: Solcast may take up to 24hrs to apply the 50 API counter from the default 10… give it time to work:).
OK so…I tried Solcast instead of Forecast Solar and seem to be getting far more accurate predictions with that. Unfortunately it doesn’t offer quite the same level of features and I also haven’t looked at the paid tiers yet (I actually bought the 24€ package for Forecast Solar in hopes of getting better results) but the data seems accurate so far.
Will keep watching it.
At least your results are better than mine. I set it up 2 days ago and it’s still showing, “There’s no data to show. It can take up to 2 hours for new data to arrive after you configure your energy dashboard.”
I had that as well. Restarting HA fixed it for me. I hope ot doesn’t get stuck again.
