v4.1.4 pre-release

[autoSteve]

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
• Monitor last updated timestamp for sites-usage.json by @autoSteve
• Extensive code clean-up by @autoSteve

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

Note that I experienced some interesting behaviour with HACS 2.0.0 when upgrading my main rig. I updated information in HACS, yet was not offered an upgrade. When @BJReplay did the same thing it did offer an upgrade. 🤷‍♂️

[autoSteve]

Notifying the usual early-adopting-and-reporting folk. @dtswk, @EddieSpaghettie, @ffm777, @gcoan, @hwb45, @iainfogg, @isorin, @jeffb1974, @kernow, @ladaan, @Markyt77, @Nilogax, @Noodleyman, @ProphetOfDoom, @rholligan, @Unlik and @wimdebruyn.

[autoSteve]

Correct. The same conversion of a converted date occurs for comparison, so no foul.

But it makes my eye twitch.

[BJReplay]

But it makes my eye twitch.

The funny thing is that I noticed it in as much as I saw 14:00 and groked that it wasn't 00:00 and also not 10:00, but didn't apply sufficient thought to it to spot that it was wrong.

[autoSteve]

Actually, it's more than an eye twitch. The timestamp gets compared to the TZ aware utcnow(), so it's super important to fix. PR#152. Simple fix, but we need another day of run-time testing @BJReplay.

For those folks running v4.1.4 this will not cause any issues unless a restart of HA occurs at the wrong time of day, with "wrong" depending on which time zone you are in.

The fix is on https://github.com/BJReplay/ha-solcast-solar/tree/Fix-usage-cache-timestamp, not at autoSteve, BJ. Sorry, for your test setup I should have branched over there.

[BJReplay]

The fix is on https://github.com/BJReplay/ha-solcast-solar/tree/Fix-usage-cache-timestamp, not at autoSteve, BJ. Sorry, for your test setup I should have branched over there.

No problem, I need to brush up on my git command line skilz

[BJReplay]

Sorry, for your test setup I should have branched over there.

git remote origin remove
git remote origin add https://github.com/BJReplay/ha-solcast-solar
git config pull.rebase true
git branch --set-upstream-to=origin/Fix-usage-cache-timestamp

I could have apparently switched branches, rebased, and set upstream all in the one command (setting the origin with options), but that worked and I learned something that I knew I could do, but didn't know well.

At which point the git pull in my script picked up your change :)

[EddieSpaghettie]

Will install now and test

[dtswk]

I was already on Has 2 with beta flag set. So upgrade appeared in HA and went smoothly. Ideally like the clock submit to restart. Nice. Will update through the day, still dark here now.

[autoSteve]

There are some inherent resiliancy improvements in this version too , and not really worth including in "what changed".

Added to "what changed" * Monitor last updated timestamp for sites-usage.json by @autoSteve

If anyone is interested, here's the deets.

The removal of the Solcast API call to get current usage vs. limit opened up the opportunity for corner case issues to arise. These are now avoided.

Normally, at each forecast retrieval an API use counter is incremented, and on next poll is checked against limit. Every day at midnight UTC this counter is reset to zero. This is all goodness if nothing goes wrong, but there were a couple of circumstances where this would not work reliably.

1. Restarting Home Assistant immediately before midnight UTC (or with far less chance of an issue, the integration) would cause the API use counter to not be reset.
2. Situations like @gcoan encountered a while back, where HA was down for some days would also get the use counter out of whack. (A feature to immediately fetch a forecast after revival was built in a few releases ago, and this was broken before this release, despite what the readme still says in known issues. Must fix that.)

What happens now is that each day at midnight UTC a date/time is recorded in the solcast-usage.json. On startup, if this date/time is older than the current UTC 'start of day' date/time, then the integration will reset usage and save the usage cache.

So if a re-start causes midnight UTC to be missed all will now function correctly. And if startup happens after a whole day has been missed due to not having been running the same thing will happen, and also cause an immediate forecast fetch without waiting for the next scheduled automation to fire.

[autoSteve]

This fix does maybe beg the question from some, "What if I restarted Home Assistant just before midnight local time?"

I'm quite certain that the answer is, "Nothing interesting, and nothing bad. Your solcast.json cache gets loaded, splines are calculated, and all sensors get set up."

[wimdebruyn]

4.1.4 in, no problems

…

On Fri, Aug 30, 2024 at 11:19 AM Steve Saunders ***@***.***> wrote: Notifying the usual early-adopting-and-reporting folk. @dtswk <https://github.com/dtswk>, @EddieSpaghettie <https://github.com/EddieSpaghettie>, @ffm777 <https://github.com/ffm777>, @gcoan <https://github.com/gcoan>, @hwb45 <https://github.com/hwb45>, @iainfogg <https://github.com/iainfogg>, @isorin <https://github.com/isorin>, @jeffb1974 <https://github.com/jeffb1974>, @kernow <https://github.com/kernow>, @ladaan <https://github.com/ladaan>, @Markyt77 <https://github.com/Markyt77>, @Nilogax <https://github.com/Nilogax>, @Noodleyman <https://github.com/Noodleyman>, @ProphetOfDoom <https://github.com/ProphetOfDoom>, @rholligan <https://github.com/rholligan>, @Unlik <https://github.com/Unlik> and @wimdebruyn <https://github.com/wimdebruyn>. — Reply to this email directly, view it on GitHub <#150 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASXMRMM7SA2COAGWJNQF34LZUA2JBAVCNFSM6AAAAABNMCLR7KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANBZGY2DMOI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[gcoan]

Thanks @BJReplay for the advice on setting up beta version mode, HACS automatically must have copied this forward for solcast when I upgraded as the setting was on for me, but it was useful for other integrations I use.

But then I didn't get prompted with the latest update despite it being a few days - been away, landing my Microlight on a beach in Scotland

Update information in hacs and was presented with the upgrade 🤷‍♂️.
Installed and all seems well

[gcoan]

Minor observation on 4.1.4, which I first noticed on 4.1.3 but didn't get submitted:

Entity solcast_pv_forecast_today has a state_class attribute value of 'total'

but the entity solcast_pv_forecast_tomorrow and entities _day_3..7 do not have this attribute set:

forecast_next_hour, forecast_next_X_hours, forecast_this_hour and forecast_remaining_today also don't have a state_class set

I assume they should all be state_class total https://developers.home-assistant.io/docs/core/entity/sensor/#available-state-classes

However I notice that forecast_power_now, forecast_power_next_30_minutes and forecast_power_next_hour all have a state_class of 'measurement', question whether these should be 'total' based on the description of state_class and that these are all forecast values not actual measured values.

[typxxi]

same HACS 2.0 behaviour here. No update or upgrade message.

But what I did not know was the availability of HA solcast via HACS.
What should I do now to upgrade to this version without having a HACS installation ?

[BJReplay]

same HACS 2.0 behaviour here. No update or upgrade message.

This is a little confusing. Your first sentence suggests you do have a HACS installation, running at HACS 2.0 level, with no update message. yet you expected one?

But what I did not know was the availability of HA solcast via HACS.

It's not yet available as a default repository in the store, only as a manual repository, but you now (usually) get notified of new versions

What should I do now to upgrade to this version without having a HACS installation ?

Do you mean HACS not installed? Or do you mean you don't have Solcast installed via HACS?

But this suggests that you don't have a HACS installation.

Which is it?

Or do you have two separate HA installs, one with HACS, and one without?

In any case, the readme does have instructions for both scenarios:

• Firstly: Via HACS (as a manual Repository)
• Secondy, manually, without HACS, into HA

Or perhaps I've read far to much into this question, and the question is:

I have a entirely manual installation, installed without HACS. How do I now update?

If so, go back to the readme, and follow the instructions - this will add the integration as a custom repository in HACS. Restart HACS. Then follow the instructions to enable access to pre-releases, and finally redownload the integration from HACS and you'll have updated.

[BJReplay]

Thanks to the 170 people who downloaded this pre-release and reported either no problems or problems - both are good!

If you're still running this version, in HACS, Update Information / Redownload to prompt an update to v.4.1.5 which has several fixes, including an important fix for adding / removing / changing PV arrays in Solcast, as well as several reliability fixes.

Closing this discussion - please continue with any findings after updating to v4.1.5 🙏