v4.4.0

[autoSteve]

What's Changed

Minimum Home Assistant version 2024.11

• Add auto-dampening feature by @autoSteve
• Modified dampening factors are applied from start of current day by @autoSteve
• Fix for translated sensors max attr size exceeded by @autoSteve
• Monitor solcast-dampening.json for create/update/delete by @autoSteve
• Add last_attempt attribute to api_last_polled entity by @autoSteve
• Add allow action site parameter with hyphen or underscore by @autoSteve
• Add test for unusual azimuth by @autoSteve
• Fix Energy dashboard start/end points by @autoSteve
• Attribution attributes only where credit is due by @autoSteve

Full Changelog: v4.3.5...v4.4.0

---

Auto-dampening

This is quite a handy new feature, built based upon the feedback and experience of community members.

A "dampening factor" is simply an adjustment to the forecast to account for the local environment. It can adjust for an annoying tree casting a shadow over solar panels, or a chimney, or simply your own gabled roof casting a shadow in Winter when the sun is low on the horizon reducing expected generation. It is a factor to correct that which Solcast cannot, and needed factors tend to shift with the seasons.

Dampening factors have been a feature of this integration for a while now, but have been very "hands on", or complex to automate.

Auto-dampening is designed to dynamically adjust for localised predictable shading.

An automation to model and set forecast dampening has been one that folks have had varying degrees of success with in the past, depending on skill level and available data, so to have a built-in automated model is a basic win for those that don't want to, or have an okay set up that could be better, or can't because they don't have the skills to set something up.

So now we do it, and you don't need to go there unless you want to. (And you still can, if needed, or you can contribute your experience to make the built-in auto-dampening feature even better.)

Monitor granular dampening file

In previous releases you could modify the contents of config/solcast-dampening.json and the changes would be loaded at the next forecast update. (This was an alternative to using the service action.) This release introduces active monitoring of this file to ensure that any create/update/delete operation is reflected near instantaneously in the forecast values.

Unusual azimuth check

An ignorable repair issue is now raised as a warning where the orientation of a rooftop site doesn't fit a "typical" PV installation scenario (e.g. North-ish facing panels in the northern hemisphere). It does happen, so ignore the "repair" dialogue if this is the case for you. If it is not then you might have an issue with an azimuth setting at Solcast. Check the readme, as Solcast azimuth is 0°=North, unlike Forecast.Solar where azimuth is 0°=South. (If you're migrating from Forecast.Solar then you can not use the same azimuth with the Solcast service.)

Add last_attempt attribute

The current state of forecast update health may now be determined as "healthy" when api_last_polled is greater than or equal to the last_attempt attribute of that entity, or "unhealthy" for the opposite. "Unhealthy" does not mean that dependent automations will break, but rather that out-of-date forecast information is being relied on, and that might be significant and good to know.

Hyphen / underscore for site parameter in service actions

A few releases back, the presentation of Solcast rooftop site resource IDs in attributes was changed to replace hyphens with underscores. This was because Home Assistant and Python nuances. For consistency, service action site parameters will now also accept site resource IDs having hyphens or underscores, and will return IDs in the same format as the request.

Energy dashboard

Depending on time of year, the starting and ending points of a forecast dashed line were not dropping to zero on the Energy dashboard. They do now. Or rather, they will, or will almost (because "almost" is actually more visually pleasing in many circumstances. 😉)

[zhouska]

this seems to be yet another great release, esp. for those of us who have fiddled around with dampening values with various degrees of success. Will install it and report back as the autumn is approaching fast over here in Europe.

[dennisroethig]

Firstly, a massive thanks for this great integration in general and specifically for providing auto dampening. After having spent hours on running my own logic and automations I'm excited for a built-in solution. I will give it a good test run over the next days/weeks.

One thing that came to mind as an idea, reading about the export feature, that might impact others too: I'm with Amber (Australia) as my electricity provider that provides access to wholesale prices. Which means that it's quite common outside of winter to encounter negative feed-in prices. In these times I curtail my PV output to the current load to avoid any exports. In that case PV production might drop to whatever the house load is if the batteries are fully charged. Do you think it would be possible to provide a sensor or some other way to signal your integration that this is happening to exclude this part of the data? I assume it's a similar case to the export limit being hit.

Either way, thanks again and figured I just drop the thoughts here 😊

[BJReplay]

The only way that they could discover that this feature even exists is to read it.

I am fully in agreement - no configuration screens, fully dependent on existence of specific entities, and you have to have read the readme to have set them up.

[gu3stZA]

All fair points - and I didn't even consider the situation where there are no state changes for multiple days.

I also didn't consider that the only way they would even know to create the suppression sensor in the first place is to read the readme... it's not an exposed option.

So your reasonings all make sense!

While I'm waiting for my suppression history to build up past 7 days, let me poke the bear a bit. My innate desire to see lines close to each other on a graph absolutely consumes me, and makes me wonder whether there is any REAL value, other than aesthetic, to split the auto-dampening functionality per site? Do you have a similar level of OCD that would lead you to consider enhancing in this way?

[autoSteve]

I am sooo OCD.

But no.

Integrated automated dampening is a feature that needs to work for up to 17,000 people (at last count), with seemingly 17,000 different implementations. Sure, 17,000 are not using the integral automated dampening, so let's run with, "a lot of people".

My own install features micro-inverters. I have thirty. Can I be arsed assigning each to a given "site" and then totalling their output? (Well, yeah, I have, because OCD, but others would not, nor could work out the serial numbers unless their installer left them the detail.) Some have multiple inverters. Some have one inverter with multiple strings. Some have monolithic inverters alongside micro-inverters. Some have micro-inverters that are so old that the gateway device has died and they can't replace it because it is now no longer a thing.

So no. 😉

There may be value in individual site dampening. Limited, and likely only reducing eye-twitch.

Feel free to copy the theory of operation and roll your own! The component parts, now including est. actuals per-site are there for the building.

We do consider 'pull requests' too... 😂 (With Urdu translations and pytest code.)

[gu3stZA]

😆 I would love to contribute but apart from my year 12 school Java project that was basically a fancy version of hello world, my coding experience is limited to vibe coding scripts with the use of ChatGPT. So I wouldn't want to waste your time having to review anything me and a useless AI can come up with...

[autoSteve]

Yeah, even "GPT-fancy" integrated with VScode, like I pay for boils my piss. 😂 It's like it's trying to do surgery with a machete at times until it "gets" what I am trying to write. And by that stage I've mostly written it. 🤦🏻

That said, it did prevent me writing a bunch of lines tonight.

It mostly auto-completed me once i'd got half way down this lot for you lot while writing pytest code for this 'sleeper' feature. I pressed 'tab' at the suggestion, and moved on with a "nice job, GPT"... (I had to add the "yeahnah". GPT still needs to learn 'my Aussie ways'.)

        sequence: list[dict[str, Any]] = [
            {"hours": 12, "minutes": 14, "seconds": 5, "value": "on"},
            {"hours": 12, "minutes": 18, "seconds": 5, "value": "off"},
            {"hours": 12, "minutes": 22, "seconds": 5, "value": "on"},
            {"hours": 12, "minutes": 48, "seconds": 5, "value": "off"},
            {"hours": 12, "minutes": 49, "seconds": 5, "value": "on"},
            {"hours": 13, "minutes": 14, "seconds": 5, "value": "off"},
            {"hours": 13, "minutes": 14, "seconds": 50, "value": "yeahnah"},
            {"hours": 13, "minutes": 15, "seconds": 5, "value": "on"},
            {"hours": 13, "minutes": 45, "seconds": 5, "value": "off"},
            {"hours": 13, "minutes": 46, "seconds": 5, "value": "on"},
            {"hours": 14, "minutes": 14, "seconds": 5, "value": "off"},
        ]