v4.2.5

What's Changed

New feature

You can now specify hard limit per-API key. Ask the readme for details. (The units have changed from Watts in options to kilowatts, and the existing value is migrated...) Thanks @ChirpyTurnip.

Key issues fixed

Transition to and from daylight time was not being handled correctly, and this has now been corrected.

The total sites tally of kWh expected for a given day was not right when a hard limit was set, which has now been corrected.

If the integration, or Home Assistant, or the whole server itself was restarted just prior to an auto-update then that update would be missed. This is now not the case, as auto-update checks on startup for a missed update and does so if needed.

• Add multi-API key hard limit by @autoSteve
• Proportionally limit site breakdowns by @autoSteve
• Calculate daily site tally correctly based on hard limit by @autoSteve
• Immediate application of dampening to future forecasts by @autoSteve
• Fix daylight time transition issues by @autoSteve
• Fix system health output exception by @autoSteve
• Logging improvements for info situational awareness by @autoSteve
• Auto-update tolerate restart right before scheduled fetch by @autoSteve
• Update Polish translation, with thanks to @erepeo

Full Changelog: v4.2.4...v4.2.5

v4.2.4

What's Changed

In an attempt to avoid 429/busy status the user agent included in calls to Solcast has changed. This may only temporarily improve things, and we will work with Solcast to hopefully solve this.

Many thanks to @gcoan for bringing the readme in line with Home Assistant changing the name of a service call to be an action.

• Add user-agent header to API calls by @autoSteve
• Refer to action instead of service call by @gcoan

Full Changelog: v4.2.3...v4.2.4

v4.2.3

What's Changed

If you missed upgrading to v4.2.0 then you missed a lot of additions in past release notes, including bringing back auto-update. Check out the readme.

• Fix an issue that causes changing Solcast accounts to fail by @autoSteve
• Fix an issue with multi-API key where API usage reset was not handled correctly by @autoSteve
• Fix an issue with enabled detailed site breakdown for hourly attributes by @autoSteve
• Code clean-up and some refactoring by @autoSteve
• v4.2.1 had a major, but one-line issue. Release pulled.
• v4.2.2 had a major, but one-line issue. Release pulled.

Full Changelog: v4.2.0...v4.2.3

v4.2.0

Feature-completeness and code quality is the focus of this release.

What's Changed

TL>DR:

• Automated forecast updates that do not require an automation by @autoSteve and @BJReplay
• Granular dampening to dampen per half hour period and by site by @autoSteve and @isorin
• Dampening applied at forecast fetch and not to forecast history @autoSteve and @isorin
• Retrieve un-dampened forecast values using service call by @autoSteve (thanks @Nilogax)
• Get presently set dampening factors using service call by @autoSteve (thanks @Nilogax)
• Migration of un-dampened forecast to un-dampened cache on startup by @autoSteve
• Add site breakdown option for detailed forecasts by @autoSteve
• Add hard limit configuration to options by @autoSteve
• Suppress integration reload when many configuration options are changed by @autoSteve
• Translations of service call error responses by @autoSteve

Automated forecast updates

All users of this integration will have Home Assistant automation(s) set up to fetch forecast updates at desirable times of day. And that's great for the power users, who want an update just after midnight, then another strategic update pre-dawn, and then spread other updates up to API limit throughout the day (or not...).

If you don't need to do anything special, then head into the integration configure options and turn on 'Auto-update'. Disable or delete your automation. You can specify whether you want automated updates over twenty-four hours, or from sunrise to sunset. More in the readme.

Granular dampening

The only option to set dampening previously was at per-hour increments, and not the half hour forecast periods that Solcast provide to hobbyists. You can specify a total of 48 dampening values now, corresponding to one for every half-hourly forecast period, and do this per-site if needed. See the readme for more on this.

Dampening at forecast fetch

Previously, dampening was applied to all forecasts, both up-coming and all history, but those dampened values were not saved to retain historical differences in dampening that had changed over time.

The history of dampened forecasts is now preserved, and only newly fetched forecasts have dampening adjusted.

At 'day one' there will be no dampening applied to your history, but this will build over time.

Retrieve un-dampened forecast values

Because history is now dampened as-at the dampening values set at the time, automations might need un-dampened data to calculate future dampening based on consistent past differences in generation performance versus recent history. The 'get forecasts' service call is extended to allow this by specifying undampened: true.

At upgrade, the past fourteen days of undampened history will be saved, allowing this extended call to be used immediately.

Get currently set dampening values

To avoid an automation needing to keep track of dampening set, the current dampening values can be retrieved with a new service call.

Full spread of attributes breakdown by site

Absolutely all sensor attributes may now be broken down by site, including the detailed half-hourly and hourly forecasts.

All attributes sent to Home Assistant may be configured in configure options. Turn them on or off to reduce clutter.

Hard limit

Hard limit is now in the configure options dialogue. Don't know what it does? Ask the readme. You probably don't need it.

Suppression of integration re-load on options change

Previously, should any configure option be changed then the integration would simply re-load. Now if the integration does not need to then it will not fully re-load.

Full Changelog: v4.1.7...v4.2.0
Changes since v4.1.9: v4.1.9...v4.2.0

v4.1.9

Pre-release.

What's Changed

TL>DR:

• Granular dampening to dampen per half hour period by @autoSteve and @isorin
• Dampening applied at forecast fetch and not to forecast history @autoSteve and @isorin
• Retrieve un-dampened forecast values using service call by @autoSteve (thanks @Nilogax)
• Get presently set dampening factors using service call by @autoSteve (thanks @Nilogax)
• Migration of un-dampened forecast to un-dampened cache on startup by @autoSteve

Granular dampening

The only option to set dampening previously was at per-hour increments, and not the half hour forecast periods that Solcast provide to hobbyists. This can now not be a thing, because you can specify a total of 48 dampening values, corresponding to one for every half-hourly forecast period.

Plus, you can now dampen per Solcast site if desired, either hourly or at half-hourly resolution.

Implementation is by way of two methods. Either calling the set dampening service call, or by creating and maintaining a file of dampening factors. (More in the updated readme.)

Dampening at forecast fetch

Previously, dampening when seen was applied to all forecasts, but not saved in a cache for history. It was for display purposes only. Yes, the 730 days of history, today and the up-coming seven days were calculated and shown as dampened with the current values. Yuck. This is no more.

The history of dampened forecasts is now preserved, and only newly fetched forecasts have dampening adjusted for that refreshed data.

At 'day one' there will be no dampening applied to your history, but this will build over time. A nice segue into...

Retrieve un-dampened forecast values

Because history is now dampened as-at the dampening values set at the time, automations might actually need undampened data to calculate future dampening based on past performance. So the 'get forecasts' service call is extended to allow this by specifying undampened: true.

At upgrade, the past fourteen days of undampened history will be saved, allowing this modified call to be used immediately. Undampened forecasts get saved to a different cache than the dampened forecasts, and are kept at fourteen days of history. Additionally at upgrade, current 'today' and beyond forecasts will be dampened and saved to the dampened history cache, allowing a seamless display transition to this new mode of applying dampening.

Get currently set dampening values

To avoid an automation needing to keep track of dampening set, the current dampening values can be retrieved with a new service call.

Some bug fixes

There have also been some v4.1.8 corner-case bugs fixed that nobody noticed or reported.

Full Changelog: v4.1.8...v4.1.9

v4.1.8

Pre-release. Quite a bit of existing code has been modfied, and new code has been added. Feature-completeless and code quality is the focus.

What's Changed

TL>DR:

• Automated forecast updates that do not require an automation by @autoSteve and @BJReplay
• Add per-site dampening by @autoSteve
• Add site breakdown option for detailed forecasts by @autoSteve
• Add hard limit configuration to options by @autoSteve
• Suppress integration reload when many configuration options are changed by @autoSteve

Automated forecast updates

All users of this integration will have Home Assistant automation(s) set up to fetch forecast updates at desirable times of day. And that's great for the power users, who want an update just after midnight, then another strategic update pre-dawn, and then spread other updates up to API limit throughout the day (or not...).

The reason that all users have to create an automation now is because our forebears removed automatic updating when Solcast dropped their API limit maximum for hobbyist users to just ten per day.

It got too hard I guess.

It is not too hard. And it is done.

If you don't need to do anything special, then head into the integration config options and turn on 'Auto-update'. Disable or delete your automation. You can specify whether you want automation over twenty-four hours, or from sunrise to sunset. Too easy.

"But hang on! I want an automation to get one update just after midnight for PredBat, then I wouldn't mind taking advantage of this new auto-update thing. Can I?" Absolutely. Supposing you have two sites, and an API limit of 10, then set the limit in the integration config options to 8, turn on auto-update, then have your post-midnight automation do its thing (with a twist).

The twist is that there is now a new service call that must be used instead. This is force_update_forecasts, which basically ignores all configured limits. So change your midnight call to use this service. (As an aside, when auto-update is enabled the service call update_forecasts is ignored, and logged as such, so it must be changed.)

Full spread of attributes breakdown by site

Absolutely all sensor attributes may now be broken down by site, including the detailed half-hourly and hourly forecasts.

For why? I dunno. They're there for the taking, and for you to decide what you want to do with the data. How about build an Apex chart representation of each site forecast? Or build an automated per-site dampening automation? Your install, your things. (And tell us if you can't do what you want because the data is missing. We may have missed exposing something.)

All attributes sent to Home Assistant may be configured in config options. You choose the clutter. Turn them on or off.

The big attributes, like per-site detailed forecasts are not sent to recorder, so your Home Assistant database size will not suffer even with everything turned on.

Per-site dampening

Do you need to dampen just one site output in the forecast calculation? You can now. Check out the extended service call for set_dampening.

It is now possible to add an optional site variable to the call with the ID of the Solcast site, which will disable overall dampening and switch to per-site. Don't want per-site any more? Set the total dampening either in config options, or use the service call without specifying a site and it will reset to the total dampening settings.

Hard limit

Most of you don't know what this is. But it has been a thing, only configurable by service call. It is now in the config options dialogue. Don't know what it does? Ask the readme. You probably don't need it, but for those that do they will appreciate this.

Suppression of integration re-load on options change

Previously, should any config option be changed then the integration would simply re-load, because whatever. It does not now.

It is judicious.

It's a small thing, but we like it.

Basically, if the integration does not need to, then it will not re-load. Are selected sensor attributes changed? Fine. Just update the sensors and move on. Has dampening been adjusted? Fine, re-calculate forecast, splines, and then update the sensors. Change to auto-update forecasts? Re-load.

Legacy improvements

(Nerd alert 🚨) Some Home Assistant timers seemed to not be culled at times on re-load. This was usually an annoyance and waste of system resources. However, with auto-update of forecasts now implemented this has become super-important to avoid.

So it is avoided.

All coroutines that may be pending/running/waiting/hung at shutdown are now gracefully cancelled.

Full Changelog: v4.1.7...v4.1.8

Release Discussion
#176

v4.1.7

What's Changed

• Bug fix: Issues with site breakdown for sites added at a later date by @autoSteve
• Bug fix: Issues with site breakdown for splined sensors by @autoSteve

Full Changelog: v4.1.6...v4.1.7

v4.1.6

What's Changed

A change occurred in HA 2024.9.0 that caused an issue in the configure initial dialogue for this integration. So it's fixed, but it's even better. Now most everything is on a single dialogue, with only manual dampening factors a separate configuration.

• Simplify configure dialogue by @autoSteve

Prior beta changes in v4.1.4 and v4.1.5:

• Update Polish translation by @home409ca
• Rename integration in HACS to Solcast PV Forecast by @BJReplay
• Reduce aiofiles version requirement to >=23.2.0 by @autoSteve
• Configuration dialog improvements by @autoSteve
• Misc translation updates by @autoSteve
• Refactor moment and remaining spline build by @autoSteve
• Prevent negative forecast for X hour sensor by @autoSteve
• Suppress spline bounce for reducing spline by @autoSteve
• More careful serialisation of solcast.json by @autoSteve
• Monitor last updated timestamp for sites-usage.json by @autoSteve
• Extensive code clean-up by @autoSteve
• Bug: Timestamp stored in usage cache was wrong by @autoSteve
• Bug: Adding API key reset usage for first key by @autoSteve
• Bug: Missing iterator in new sites check by @autoSteve
• Work around a possible HA scheduling bug by @autoSteve
• Code style alignment to HA style guidelines by @autoSteve

Full Changelog: v4.1.3...v4.1.6

v4.1.5

What's Changed

A bug fixed based on feedback from the previous pre-release (thank you!), plus a couple more we found.

• Bug: Missing iterator in new sites check by @autoSteve
• Bug: Timestamp stored in usage cache was wrong by @autoSteve
• Bug: Adding API key reset usage for first key by @autoSteve
• Work aound a possible HA scheduling bug by @autoSteve
• Code style alignment to HA style guidelines by @autoSteve

Full Changelog: v4.1.4...v4.1.5

v4.1.4

What's Changed

Feedback from v4.1.3 was welcomed, and incorporated. So keep it coming!

A lot of code has been touched in this release, so this is a pre-release. Many changes were to ensure code consistency, adherence to Python standards, and to ensure a clean run through Python lint. Extensive testing has been performed.

• Update Polish translation by @home409ca
• Rename integration in HACS to Solcast PV Forecast by @BJReplay
• Reduce aiofiles version requirement to >=23.2.0 by @autoSteve
• Configuration dialog improvements by @autoSteve
• Misc translation updates by @autoSteve
• Refactor moment and remaining spline build by @autoSteve
• Prevent negative forecast for X hour sensor by @autoSteve
• Suppress spline bounce for reducing spline by @autoSteve
• More careful serialisation of solcast.json by @autoSteve
• Extensive code clean-up by #autoSteve

Full Changelog: v4.1.3...v4.1.4