v4.3.3

[autoSteve]

What's changed?

• Add sites to exclude from totals and Energy dashboard by @autoSteve
• Add Portuguese translation by @ViPeR5000 (thanks!)
• New Jinja template examples documentation by @autoSteve
• Clean up orphaned hard limit diagnostic sensors by @autoSteve
• Avoid init crash HA restart calling rooftop_sites repeatedly by @autoSteve
• Fix diagnostic sensor values for multi-api key hard limit by @autoSteve
• Fix remove orphaned cache where API key contains non-alphanumeric characters by @autoSteve
• Fix solcast-dampening.json granular dampening formatting to be semi-indented by @autoSteve

---

New: Exclude sites

Do you have a holiday house with Solar, as well as a main residence? Check out the new sites to exclude, in CONFIGURE which enables multiple (distant) Solcast accounts to co-exist in one HA instance with Energy dashboard and sensors being the main residence rooftop sites with one or more remotes excluded.

For the excluded remote sites, the ability to visualise with Apex charts and create template sensors for them from sensor attributes is then possible. Neat. It's advanced stuff, but now do-able.

See the README.md and shiny new TEMPLATES.md for details and some example Jinja.

We've all got @Ndrinta to thank for being the spark for this new feature, and I'm sure he'll help out in a discussion should anyone get stuck.

---

The fixes

• The diagnostic sensor values for hard limit set when there is more than one API key were all reading the hard limit set for the first site, despite the hard limit actually being applied correctly. Fixed.
• Clean up an orphaned cache? What-evs. Fixed.
• Format the solcast-dampening.json file as intended? It worked before. Fixed.
• The clean-up of orphaned diagnostic sensors was only pointed out by one person, and only occurs when transitioning from one API key to multiple or from multiple to single, and doesn't break anything. Fixed.

These are quite mundane for this release, and the issues fixed didn't interfere with expected integration core function. This is great because it tells us that we're on top of the code. Synthetic testing has helped heaps in eliminating almost all unexpected code behaviour. When changes are made the PyTest code when run virtually assures that there are no regressions or new issues created, because every single line of code is exercised with expected result compared with current results. We love it. 🎉

---

Ты говоришь по-русски?

Speak Russian? We don't yet. But our translations continue to grow... DE, EN, ES, FR, IT, PL, PT, SK, UR. This is great!

It does add a maintenance burden that BJ and Steve are not equipped to deal with properly, though. So if any translated existing or new thing gives you an eye twitch then do please submit a PR with better phrasing for the context, or if you don't know how to do that then create an issue for it.

Or if you're willing to vet existing translated things before any release and suggest improvements, then do let us know!

Full Changelog: v4.3.2...v4.3.3

[autoSteve]

I should point out that there is a wee benign problem with v4.3.3.

A "critical" logged error message, which is definitely not critical, and definitely benign, and almost no one will notice but some have.

Sometimes when I develop code I include some logged messages at "critical" level that I want to stand out like a sore thumb in logs. This is for easy identification in bright red. Sadly one of these remained on startup after release for v4.3.3.

Sorry.

Ignore it...

It should almost always report "False" in the log for everyone, which just means that the integration is not considered "presumed dead". Which is good. This is good. When I was testing presumption of integration death it was my friend. Now it is a potential benign foe.

[autoSteve]

I'll take the first definition...

[gcoan]

Slightly off topic but I saw a YouTube video just now on Sun Forecast Plus HACS integration https://youtu.be/sOLolzIY2SI so put in a plug for Solcast and this integration in the comments

[gcoan]

I'm a guest.

You can't claim that, you're a collaborator

No escape from this one ...

[autoSteve]

Or is this just for 'core' HA integrations rather than HACS?

I didn't address this. My apologies, Geoff.

The rating system is officially for core integrations. It's a really good idea as it provides incentive for developers to step up their game in terms of quality delivered for users.

When BJ took on ownership of this integration the quality of the code was honestly terrible. It is no surprise to me that Oziee fielded so many Github issues, and eventually cracked it because he thought everyone "an idiot".

How many issues do we now see get raised here? Not many after countless hours with an eye on code quality, so the proof is in the pudding.

So yeah, just for core, but really good guidance for custom components delivered using HACS.

[tabascoz]

i'd honestly say i had 0, really no issues whatsoever since the takeover. +1 this should earn a quality badge in HA despite not core integration, but you all have my gold quality badge as a "happy user"!

[BJReplay]

i'd honestly say i had 0, really no issues whatsoever since the takeover. +1 this should earn a quality badge in HA despite not core integration, but you all have my gold quality badge as a "happy user"!

Thanks!

I am pretty sure that I didn't know that you had a slightly later fork than the one I started from way back then, at first, but later was pointed to yours as a source of some of the missing commits - so thanks for capturing those changes so we could understand them in the cold hard light of hindsight!

[tabascoz]

Yw, I'm willing to contribute more but still pretty involved in another task now for at least some months.