v4.3.5

[autoSteve]

What's Changed

• Fix API key change detection on 429 when using multi-key by @autoSteve
• Fix key validation corner case that could prevent start by @autoSteve
• Add update failure count attributes to last polled sensor by @autoSteve
• Allow get sites when failed every 30 minutes in 429 storm by @autoSteve
• Stricter type checking by @autoSteve

Full Changelog: v4.3.4...v4.3.5

---

The fixes

API key change detection was broken for those using more than one API key. This is now resolved, and the synthetic test scenarios have been bolstered to prevent a similar issue being missed.

The corner case fixed was not hitting a random 429/Too busy on initial configuration, but hitting this on startup.

---

The addition

More attributes have been added for the entity sensor.solcast_pv_forecast_api_last_polled, with the number of forecast update failures for today and last seven days added.

---

The 429 storm change

Should a change be made to the Solcast configuration, like changing the API key occur at precicely the same time that a 429/Too busy storm commences, then the prior behaviour of the integration would be to not repeatedly attempt to load sites data from Solcast. The reasoning was that doing so could actually make the 429 storm worse. It would not recover without human intervention.

It now will eventually recover, depending on when the key was changed.

If the key was changed at solcast.com.au during a 429 storm, then it would be impossible to update to the new key in the integration, because the new key would not be able to be verified on configuration change. The storm would need to pass, and human intervention would still be required.

Changing the key at Solcast and the integration might hit a moment where the key is validated, but the very next start hits a 429, and this is where this change comes in.

(A 429 storm is generally caused by undisciplined user code that generates an unreasonable amount of traffic for the Solcast API, often millions of hits per day either intentionally or (usually) unintentionally. The 429/Too busy responses are a defence mechanism employed by the API. This spoils things for all hobbyists, and denies access to the service. Our code definitely does not do this, and yet we need to cope with this occasionally happening.)

---

Stricter type checking

Developer stuff.

Python does not enforce type checking, and this can lead to inadvertant problems. Type checking this code when using PyLance in strict mode is now more effective at detecting issues before they might occur.

[autoSteve]

Discussion #300 for the win. A nice even number.

I hope it's an #enjoythesilence number for everyone. 😘

[autoSteve]

I love 3,500+ downloads without incident...

[autoSteve]

~7,900 downloads without issue logged.

The new attributes for API failure count on the sensor entity solcast_pv_forecast_api_last_polled for 24-hour and 7-day in my prod instance indicate zero for me. This means happy days for all (in Oz time zone, at least), but I had hoped weirdly, that some API goings on would have occurred, as I have this rigged to pop up a dashboard card when failures have occurred for the present day so that I can be alerted to the fact. Yeah, call me weirdo disappointed.

Thanks @billy-solcast and your entire crew for the silence, and also thanks to anyone else not running this integration not spoiling it for everone.

These attributes are a farly "binary" affair at present, and the 7-day stat is quite useless if I might say so myself, even though I coded it. Sooo...

What could possibly make these attributes better to improve situational awareness? Sure, they could help analysing a diagnostic dump when an issue is raised, but not much else for a user.

Date-time of last failure? Whether that past failure has now been invalidated by a success? (That failure count can not currently be quatifiably correlated to current success/failure state.)

I'm all ears, and still thinking about this API state transparancy aspect; I'm thinking about an "all good?" binary sensor state out of the box, possibly with attributes. I know that new sensors are to be avoided because sensor bloat, but this might be worth the addition.

Current sensor attributes is kind-of okay, but I reckon it could be better.

Thoughts?

[gcoan]

I don't know that an "all good" sensor is really meaningful. For brand new users all good can be inferred by a forecast being populated, and for those users they're unlikely to use a binary sensor to code anything up as they are brand new users.

For existing users, what is the definition of 'all good'. As you have repeatedly said, its just a forecast, so having a more recent refresh of the forecast is useful but not essential. Without any forecast updates you still have 7 days of future forecast although obviously with diminishing accuracy.
We already have 'last polled' sensor.solcast_pv_forecast_api_last_polled which is only updated when a poll is successful so if you wanted to do some alerting based on that not being updated for a period of time, its a pretty straight forward automation trigger. Bit harder if you have forecast updates only in the solar day, but not impossible.

I would say if anything extend that sensor with attributes of date/time of last poll regardless of whether successful or not, and maybe error/OK status of last poll, and that would give those power users that want it some more information without further sensor bloat

[autoSteve]

Good suggestion, Geoff. #301.