v4.6

[autoSteve]

v4.6.0

What's changed?

• Add rooftop site migration between accounts by @autoSteve
• Add api_actuals_used attribute to API Used Total entity by @autoSteve
• Add daily_typical_forecast_updates and api_used_total_combined attributes by @autoSteve
• Add sun elevation adjustment for automated dampening by @autoSteve
• Add per-site compass degree and direction attributes and diagnostics by @autoSteve
• Expanded diagnostic self-test service action by @autoSteve
• Include health check detail in diagnostic download by @autoSteve
• Add undampened total forecast attributes when dampening is enabled by @autoSteve
• Enable return of per-site and un-dampened estimated actuals by @autoSteve
• Expand scope for raised issue when actuals enabled and API limit is too high by @autoSteve
• Compact forecast attribute selection in options dialogue by @autoSteve
• Improve re-config, options and re-auth flow validations by @autoSteve
• Fix enable estimated actuals skips a day (caution: enabling may exhaust API calls available for a day) by @autoSteve
• Fix options flow corner case by @autoSteve
• Remove legacy dampening file location move by @autoSteve
• Code refactoring by @autoSteve
• Add tests to suite to ensure runtime reliability by @autoSteve
• API simulator improvements by @autoSteve

Full Changelog: v4.5.2...v4.6.0

Deets

Dampening compensation for sun elevation

Integrated automated dampening sees an addition of sun elevation compensation to normalise historic generation data based on where the sun is in the sky as at dampening determination.

Rooftop site migration

Pretty cool. Enables movement of existing rooftop site history to a completely new API key/site with the same details. See the readme.

Attributes

Completes some missing things, adding additional visibility and integration with external things.

Improved diagnostics

New detail has been added to diagnostics and health check action.

[autoSteve]

Caution

🚨 Upgrading to v4.6.0+ will change the unique IDs of your Solcast site entity(ies). That alone will not impact anything. If you subsequently downgrade to a prior release and then re-upgrade to v4.6.0 then bad things will occur on startup and all integration sensor entities will become unavailable.

If you hit that, raise an issue and the community will help you fix it if you can't by yourself. But do please try and avoid hitting it.

Note that upgrade/downgrade/upgrade issues are resolved in v4.6.1.

---

So what's the reason for this change, I hear you ask?

The prior state was quite 'fragile', and to support a new feature of site migration to a different API key had to be done.

I'm not sure that downgrade/upgrade can be guarded against and handled cleanly, so please, just don't do it.

It's not the end of the world if you do. What will happen is that duplicated site entities will get created and then the ingration will likely trip over itself during a subsequent upgrade path unless exactly the right duplicate entities are removed prior to the re-upgrade. If that does not happen then the sensor platform will bug out with an exception after upgrage and will not set up any Solcast integration sensor enties.

What will happen in v4.6.1+ is that clean-up of any duplicates will be automatic.

If you're an HA wizz then you'll work it out, but you'd need to notice it occurring.

New entities will get created with an _2 suffix, so you likely will not notice that this has occured in dashboards unless the site entities are on your dashboards, which is unlikely.

• Downgrade will create duplicate site entities
• Continuing to run the older version will leave those duplicates active without intervention
• Recorder history for the affected site sensor will become fragmented
• Subsequent re-upgrade to v4.6.1+ will simply remove the newly created duplicate and continue recorder history for the original entity will break sensors if the duplicates are not cleaned up sensibly

An exception no longer occurs.

The (somewhat confusing) dreaded exception on re-upgrade example:

[autoSteve]

Nope. And please never crawl under any rocks, Geoff. No question is a stupid question.

TL>DR the exception occurs because rename of the unique_id causes a collision...

I've realised I didn't explain myself terribly well. And proof-reading this reply made me go cross-eyed, so... TL>DR for the win.

Entities have a few names. The entity name (duh), an entity_id, a unique_id, a previous unique_id, and more.

If you create an entity of the same name as another one, but with a different unique_id then you will get something with exactly the same name "Example name", but with a different entity_id to the first one like "sensor.example_name_2" (because the entity_id is based on the name).

A unique_id is just that with respect to other entities that share like entity_id for the same domain/platform. Entity names can be identical. Entity IDs get tracked for sanity with the addition of _'number', so like-named entities with different unique_id will cause a "duplicate", and that is expected behaviour.

Further to what I said in that post, the recorder history is tied to the entity_id (i.e. "sensor.example_name_2"). If there is also sensor.example_name then they are different histories. So in this case, when the duplicate gets created with a different unique_id the recorder history will split.

So for this specific case, downgrading from a v4.6.0 upgrade will cause a duplicate for the site entities, because differing unique_id, and that is the beginning of the failure scenario.

A subsequent re-upgrade will be when "bad things" happen should precautions to remove the duplicates have not occurred, because an entity will already exist with the same unique_id and the code changes or renames the unique_id, and then causes the exception because collision with an extant entity with the same unique ID.

It's no biggie. Don't downgrade! 😅

[gcoan]

Thanks Steve, I'm more concerned about the happy path of upgrading to the new release, less so about going backwards with reverting to an older release.

You've said that the Solcast unique_id's (i.e. sensor.solcast_pv_forecast_xxx) are changing.

This to me implies that we will need to change our dashboards, automations, etc to pick up the new names, so could you clarify which are changing and what to? And I assume in changing the unique_id's that any statistics for those entities will be orphaned on the old unique_id's?

Sorry if I am making a meal out of a one liner statement, am trying to get my head around what needs to be done following the new release.

[And I have been under a rock as far as Github is concerned for a month or so, been on two flying tours in Europe so just not had the time. But am back now, hence my questions !]

[autoSteve]

The unique_id is not referenced anywhere by anything other than this code. Should be zero change, @gcoan. entity_id does not change. Here is my 'north-east' entity post unique_id change. Zero difference. The unique_id is never exposed to the UI.

I am considering a patch that could guard against this happening in the code, BTW. It is not worth pushing as a rapid patch because of the slender risk profile of the "issue" being hit. Likely a thing for v4.6.1 should this one-way upgrade/downgrade/upgrade/bang be frequently hit.

It is not an issue, but something that could become one in certain unlikely circumstances.

The patch would go something like:

• Check whether duplicate site entities exist at upgrade.
• If so, remove the "modern" entities, and then proceed with the upgrade of the "legacy" entities.
• Cross-fingers that no one liked the duplicates.

[autoSteve]

Supplemental, which I missed, and stated earlier, @gcoan: Recorder history is tied to the entity_id, and not the unique_id, so zero orphans in this case.

There should be zero change for this unique_id change.

[autoSteve]

A worthwhile discussion, Geoff.

For you, stick to the TL>DR and don't downgrade.

Patch written for v4.6.next.

• If both legacy and upgraded site entities exist for a site (because having downgraded), on upgrade the legacy duplicate is removed first. This is because comprehensive recorder history will have stayed with the upgraded modern entity unique_id with entity_id (unchanged) from the prior upgrade renaming the unique_id. Assumes upgrade actually migrated the modern entities, which if it didn't then this flow is moot.
• The legacy entity is removed where upgraded and lagacy exist. (Legacy will have a *_2 suffix now after downgrade and relatively new recorder history because created later.)
• This all assumes a relatively short-lived upgrade/downgrade/re-upgrade cycle, because the old code cannot maintain the modern "duplicate" entity history, and it's probably best to retain the most comprehensive history, but assumption right there...
• Brace for issue impact, but no exceptions raised, and recent (likely useless) entity history prior to re-upgrade will be gone. 🔥 Likely no one will notice.
• Nobody reviews logs unless they have to, so little of this behaviour flow is logged at present.

I throw this to the floor for comment before add to a patch PR...

• It is pragmatic.
• It will likely not cause issue raising because exceptionless.
• It does result in data loss, which almost no one will care about, which irks me, but is unavoidable without unnatural acts which are HA code-specific, so not going there.
• Forecast history = zero change, only individual site entity history in the recorder, which is unlikely to be cared about.

(Edit: Vindicates original design choice of forecast history not being in recorder...)

[bdii]

When I upgraded to 4.6.0 directly from the previous version, no downgrade and reupgrade involved, the logs show this message.

2026-08-05 05:48:04.341 ERROR
(MainThread) [homeassistant.components.sensor] Error while setting up solcast_solar platform for sensor: Unique id 'solcast_solcast_api_6003-b8e3-7368-f163' is already in use by 'sensor.home’

Solcast did not start, all sensors are unavailable, no generation of additional _2 sensors. Automation which includes Solcast sensors failed overnight.

Presumably downgrading would resolve, but is the very action you warn against!

Not sure how to proceed, will 4.6.next version resolve this variant of the issue?

[BJReplay]

Thanks for reporting, @bdii. @autoSteve will hopefully be able to advise next steps shortly.

Can you please advise what sensor.home is.

At a guess, there has been a guid clash.

[bdii]

Thanks for getting back so quickly, Sensor.home is “Solcast PV Forecast Home” created by the Solcast integration. However it does not appear to have any values associated with it in history, unlike the other sensors that I checked. On the integration page on home assistant It appears under the heading configuration, not sensor or diagnostic. Sent from my iPad On 6 Aug 2026, at 08:06, BJReplay ***@***.***> wrote:  Thanks for reporting, @bdii<https://github.com/bdii>. @autoSteve<https://github.com/autoSteve> will hopefully be able to advise next steps shortly. Can you please advise what sensor.home is. At a guess, there has been a guid clash. — Reply to this email directly, view it on GitHub<#515?email_source=notifications&email_token=AKL6UHMGXWDZN65DTDS5AHD5IOVWTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZDOMJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17912717>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKL6UHL4ZVMOOLUXKDSUSS35IOVWTAVCNFSNUABIKJSXA33TNF2G64TZHM4DAOBYGMZTCMJVHNCGS43DOVZXG2LPNY5TCMBVGM4DQOJSUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AKL6UHPIB3JPAQK6DNJ5T2L5IOVWTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZDOMJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android<https://github.com/notifications/mobile/android/AKL6UHOMHJIPEUIULG6H4Q35IOVWTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZDOMJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[BJReplay]

OK, at a guess, that looks like it is the diagnostic sensor for the total forecast today.

Mine is named sensor.blah, and my site name is named BLAH in the solcast dashboard.

Can you confirm that the resource ID in your solcast dashboard is 6003-b8e3-7368-f163 for your site, and your site name is Home?

I think there five things to try, in increasing levels of risk

1. Firstly, make sure you have a backup of home assistant! No risk at all, and reduces risk of any subsequent step
2. Secondly, if you haven't already, restart home assistant.
3. Thirdly, reload the Solcast Integration - it may (as it is designed to) recover from this.
4. Fourthly, Go Settings, Devices and Services, Entities, and find sensor.home. Turn on the enter selection mode

button at the top of the entity list, so you can select it, then, having selected it, click on the vertical three dots on the right, and select Delete selected. Then try steps three, or steps 2 and three again. 5. Final step would be to remove the Solcast Integration, after backing up the data in the solcast_solar folder under config, restart home assistant, and then add it again. You would lose historical forecasts (and it may screw with automations).

[bdii]

Yes is my Solcast site ID and site is called home on Solcast. HA restart and system reboot followed by Solcast reload tried yesterday had not worked, but option four (delete sensor.home) followed by Solcast reload has worked. Sensor.home is now shown in the diagnostic section and not in the configuration section of the HA Solcast integration page as it was previously. Thanks very much. Sent from my iPad On 6 Aug 2026, at 09:53, BJReplay ***@***.***> wrote:  OK, at a guess, that looks like it is the diagnostic sensor for the total forecast today. Mine is named sensor.blah, and my site name is named BLAH in the solcast dashboard. Can you confirm that the resource ID in your solcast dashboard is 6003-b8e3-7368-f163 for your site, and your site name is Home? I think there five things to try, in increasing levels of risk 1. Firstly, make sure you have a backup of home assistant! No risk at all, and reduces risk of any subsequent step 2. Secondly, if you haven't already, restart home assistant. 3. Thirdly, reload the Solcast Integration - it may (as it is designed to) recover from this. 4. Fourthly, Go Settings, Devices and Services, Entities, and find sensor.home. Turn on the enter selection mode Image: image (view on web)<https://github.com/user-attachments/assets/aecf47c7-2568-46ff-b22c-4db63fae62aa> button at the top of the entity list, so you can select it, then, having selected it, click on the vertical three dots on the right, and select Delete selected. Then try steps three, or steps 2 and three again. Image: image (view on web)<https://github.com/user-attachments/assets/d0ef0f41-59da-4904-9e88-ecebeb195819> 5. Final step would be to remove the Solcast Integration, after backing up the data in the solcast_solar folder under config, restart home assistant, and then add it again. You would lose historical forecasts (and it may screw with automations). — Reply to this email directly, view it on GitHub<#515?email_source=notifications&email_token=AKL6UHOMYFXHSFRUJI5PNML5IPCGDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZTOOJUUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17913794>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKL6UHIXRMUXR75V5SVKYND5IPCGDAVCNFSNUABIKJSXA33TNF2G64TZHM4DAOBYGMZTCMJVHNCGS43DOVZXG2LPNY5TCMBVGM4DQOJSUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AKL6UHN663RF7PLO4B7ELEL5IPCGDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZTOOJUUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android<https://github.com/notifications/mobile/android/AKL6UHM6KLYV7ARFGWPHZBL5IPCGDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGEZTOOJUUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[BJReplay]

Great. It looks like the migration partially failed. I should have asked you to back up logs much earlier in the process to assist in working out why this occurred, but we've got a lot of details already from what you've told us.

[autoSteve]

I am trying to work this out.

I do not think it possible that the upgrade path hoisted itself with its own petard.

A clue that I am hunting is the switch to being a diagnostic sensor, so thanks for pointing that out. How long have you been running, and moving from version to version, @bdii? Since Oziee days I am guessing, pre-v4.0.12. @BJReplay took over at v4.0.23.

In the commit immediately before v4.0.12 (ancient), the RooftopSensor class exists but there is no assignment of _attr_entity_category = EntityCategory.DIAGNOSTIC. It got assigned in the v4.0.12 release by Oziee. That's the only clue I have regarding the switch to being a diagnostic sensor. This bends my head though, because a rooftop site entity actively managed by this integration would have been flipped to being a diagnostic sensor ages ago. An unmanaged "sleeper" registry entity with a coincidentally identical UniqueID that we wanted should have been invisible.

I am tipping this is likely a super-rare scenario, but some background context would help instead of me stabbing in the dim dark recesses of a pre-BJ-managed (and possibly irrelevant) past.

[bdii]

As far as I can recall I may have first started using the Solcast integration as early as March 2020. No idea what version it was then. However, I would have downloaded and installed the latest version available through HACS at that time. Since then I have installed the new versions as they were released. As I am in no way a programmer, just a keen HA user, I have never downloaded beta versions or modified any code in the releases. Sent from my iPad On 6 Aug 2026, at 11:58, Steve Saunders ***@***.***> wrote:  I am trying to work this out. I do not think it possible that the upgrade path hoisted itself with its own petard. A clue that I am hunting is the switch to being a diagnostic sensor, so thanks for pointing that out. How long have you been running, and moving from version to version, @bdii<https://github.com/bdii>? Since Oziee days I am guessing, pre-v4.0.12. @BJReplay<https://github.com/BJReplay> took over at v4.0.23. In the commit immediately before v4.0.12 (ancient), the RooftopSensor class exists but there is no assignment of _attr_entity_category = EntityCategory.DIAGNOSTIC. It got assigned in the v4.0.12 release by Oziee. That's the only clue I have regarding the switch to being a diagnostic sensor. This bends my head though, because a rooftop site entity actively managed by this integration would have been flipped to being a diagnostic sensor ages ago. An unmanaged "sleeper" registry entity with a coincidentally identical UniqueID that we wanted should have been invisible. I am tipping this is likely a super-rare scenario, but some background context would help instead of me stabbing in the dim dark recesses of a pre-

…

-managed (and possibly irrelevant) past. — Reply to this email directly, view it on GitHub<#515?email_source=notifications&email_token=AKL6UHMRCXTYOXXCOKSBKRL5IPQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE2DMMRYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17914628>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKL6UHI6KJNEAPYWF3IEPQT5IPQ53AVCNFSNUABIKJSXA33TNF2G64TZHM4DAOBYGMZTCMJVHNCGS43DOVZXG2LPNY5TCMBVGM4DQOJSUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AKL6UHKIS4ZFJONP6SKWCAD5IPQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE2DMMRYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android<https://github.com/notifications/mobile/android/AKL6UHP7DKEYXPWWFS3AGYL5IPQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE2DMMRYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[autoSteve]

That fits my thinking.

Something was laid down in your entity registry a long time ago by an integration far, far away, which became a time bomb bearing the same domain name of "solcast_solar" waiting for me to make this change in v4.6.0.

Your description of "the Solcast integration" is kind-of accurate. I'd prefer to say you started using "a Solcast integration". Whatever you started with it was not this one, and more like a cousin!

Thanks for the confirmation, @bdii.

[andypnz]

I upgraded from 4.5.2 to 4.6 and all my sensor values became unavailable...

I downgraded back to 4.5.2 and my sensors are all working.....

But now I read about this downgrade - upgrade issue.... what is my best plan?

Thank you!

BTW, my sensors look like this:

[andypnz]

@autoSteve Thank you.... please let me know if you require anything more:

➜ .storage less core.entity_registry
{"aliases":[],"aliases_v2":[null],"area_id":null,"categories":{},"capabilities":null,"config_entry_id":"c95889f1332329daec8efcac80a8563d","config_subentry_id":null,"created_at":"1970-01-01T00:00:00+00:00","device_class":null,"device_id":"93751ad70b4238f623aa9a6b6144f6e4","disabled_by":null,"entity_category":"config","entity_id":"sensor.home","hidden_by":null,"icon":null,"id":"c348c6390fef6b3ec8a757f19751669a","has_entity_name":false,"labels":[],"modified_at":"1970-01-01T00:00:00+00:00","name":null,"object_id_base":"Home","options":{"conversation":{"should_expose":false},"cloud.google_assistant":{"should_expose":false}},"original_device_class":"energy","original_icon":"mdi:home","original_name":"Home","platform":"solcast_solar","suggested_object_id":null,"supported_features":0,"translation_key":null,"unique_id":"solcast_solcast_api_62d6-3299-8a72-75ab","previous_unique_id":null,"unit_of_measurement":"kWh"},

Edited by @BJReplay to mark as json, and re-edited by @autoSteve to form a code line with wrap

I do have two site id's set up with Solcast.... if I search for the second site id, I get: Pattern not found: baae-2e90-ed1d-7645 (press RETURN) - Likely I am only using one in my HA setup.

[BJReplay]

Soz @autoSteve

[autoSteve]

Proposed fix in #517, target v4.6.1.

[BJReplay]

@andypnz your fix is live in the latest release thanks to the work of @autoSteve - and of course your evidence of the underlying problem, as well as the investigations by @proscar87 that helped identify the underlying cause of the problem.

[andypnz]

Works great for me… thank you everyone 🙂

[gcoan]

Adding my observation of 4.6.1 upgrade for feedback and confirmation that this is OK, but can move to a separate github issue if required.

Upgraded from 4.5.2 to 4.6.1

Looking at the new undampened attribute (thanks for adding it), it varies slightly from the one calculated using the template sensor Steve provided earlier

template sensor:

- sensor:
  - name: "Solcast Forecast Today Undampened"
    unique_id: solcast_forecast_today_undampened
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total
    icon: mdi:solar-power
    state: >
      {% set forecast = state_attr('sensor.solcast_pv_forecast_today', 'detailedForecast') %}
      {% if forecast is none or forecast | length == 0 %}
        {{ states('sensor.solcast_pv_forecast_today') }}
      {% else %}
        {% set ns = namespace(total=0.0) %}
        {% for interval in forecast %}
          {% set dampened_kw = interval['pv_estimate'] | float(0) %}
          {% set factor = interval.get('dampening_factor', 1.0) | float(1.0) %}
          {% if factor > 0 %}
            {# Reverse the dampening: undampened = dampened / factor #}
            {% set ns.total = ns.total + (dampened_kw / factor) * 0.5 %}
          {% else %}
            {# Factor is 0 — can't reverse, treat as undampened passthrough #}
            {% set ns.total = ns.total + dampened_kw * 0.5 %}
          {% endif %}
        {% endfor %}
        {{ ns.total | round(3) }}
      {% endif %}
    attributes:
      dampened_today_kwh: >
        {{ states('sensor.solcast_pv_forecast_today') | float(0) | round(3) }}
      dampening_reduction_kwh: >
        {% set undampened = this.state | float(0) %}
        {% set dampened = states('sensor.solcast_pv_forecast_today') | float(0) %}
        {{ (undampened - dampened) | round(3) }}
      dampening_reduction_pct: >
        {% set undampened = this.state | float(0) %}
        {% set dampened = states('sensor.solcast_pv_forecast_today') | float(0) %}
        {% if undampened > 0 %}
          {{ ((undampened - dampened) / undampened * 100) | round(1) }}
        {% else %}
          0.0
        {% endif %}

It seems consistent day to day that its a slightly different

My guess is that this is cumulative rounding errors in the template sensor

As an aside, today's 90-95% solar eclipse is very visible when looking at the solcast site forecast

[BJReplay]

As an aside, today's 90-95% solar eclipse is very visible when looking at the solcast site forecast

I hope that you got/get a chance to view the eclipse!

I first learnt about Solcast by debunking a comment about not being able to predict when the sun would be shining, and that things like eclipses would be impossible for grid operators to deal with - and knowing that

• it wasn't true, and
• there were forecasts out there, and
• eclipses were incredibly forecastable!

When I went looking to debunk I came across Solcast and started using it.

[gcoan]

Today isn't a total eclipse for us (need to be in Spain for that) but it's the biggest eclipse since the last total in 1999. Was very cloudy then whereas today is clear blue skies so 🤞

things like eclipses would be impossible for grid operators to deal with

The national grid operator has already taken action to mitigate the drop in solar generation, and I'm getting paid £1/kWh for exporting in the 2 hours of the eclipse. By comparison my normal export rate is 12p/kWh so it'll be a great income day