And @BJReplay, it’s even more messed up than just potentially two folders. The Oziee integration of old and yours both have the Home Assistant manifest.json “domain” of solcast_solar, which should identify them as the same thing. The domain must be unique, and must not change.
This is why installing both at the same time should not be possible. We check for a repeat install and block it. So did Oziee.
Having both folders would be possible if the names were different , but based on my testing the folder used to initially install the integration from wins., but the manifest domain name would need to match the folder name.
The only way a folder other than solcast_solar could exist is if a manual custom component install outside of HACS was done to a folder named something different. And the only way that they could co-exist as installed integrations would be if the manifest.json had an altered domain name (and the folder name matched that domain).
Purely speculation in this case. We have no further info to go on.
New HA user here. I´m trying to use this card but it doesn´t show the forecast, although the integration is working properly and giving data. I have no idea how to solve this issue. This is what I get:
Yes, in Developer Tools are translated as well. This is the first thing I checked. Not sure why entities are being translated, it’s the first time it happens to me.
It seems that data generator is not producing valid results although the entities are available and the attributes are also correct.
Today I got quite strange values - with negative values for forecast.
I had some downtime this night, but nevertheless the values do not have any useful meaning for the upcoming days.
@webwude hit a bug in v4.4.0 where missed generation / bumps in generation due to dodgy input data skewed automated dampening.
That should be sorted now in v4.4.1.
A follow-up issue was seen in v4.4.1 where the mitigation for “jumps” in generation was found flawed for Enphase Envoy generation entities, so v4.4.1 was short-lived.
v4.4.2 replaces that, and I look forward to much silent enjoyment by all.
That said, if there are any anomalies then feel free to call them out. Auto-dampening is a very new feature, and it does depend on things outside of the Solcast sphere, so there will be an escalation of things hitting the fan.
i keep getting the error:
API key looks like a site ID
when i want to setup the integration
I use this ID: 59c2-b97e-xxxx-xxxx
I dont know how to resolve it, any clues?
Solved by using the correct api page.
The documentation seems to expect the site ids, but it doenst.
Maube an idea to update that piece of documentation
Timezone or similar was my first thought too. I have looked at the solcast web site and don’t see anything timezone related. The only location info is lat/Lon which correctly defines my location. It is definitely solcast related as the realtime production graph is correct from my observations. I will keep looking.
looking at the Integration docs here it mentions to “Note the importance of getting your Solcast site configuration correct. Use the “Site is facing” hint to ensure the azimuth is signed correctly, as if this is incorrect then forecasts will appear shifted, possibly by up to an hour during the day.”
At a glance this would appear to be the exactly situation you are describing with your pic in original post…have you had a double-check of this?
@Gav_in I have done my best to get this correct from day 1. My roof faces a little to the east of south and using various solar mapping sites I have measured the azimuth as 160deg for the SolCast integration.
AI Claude suggested adding…
homeassistant:
time_zone: Europe/London
to configuration.yaml which I have done but it didn’t seem to make any difference. AI Claude also said “Of course you could just fudge the graph by adding a 1hr offset in the data generator”. I applied the ‘fudge’ and this is the result on another blue sky day…