v4.3.5
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.
