Catch duplicate API key specified (plus scope creep)

[autoSteve]

Why anyone of sound mind would do this is beyond me. But it does result in exceptions that want heading off at the pass...

[BJReplay]

Most polite. No "WTAF?".

[autoSteve]

🤣🤣🤣

[autoSteve]

Long may the changes in the last two PRs hide dormant. Prepped for next anyways.

[BJReplay]

Long may the changes in the last two PRs hide dormant. Prepped for next anyways.

While I was reviewing and approving your PR, I was sitting in the Palais waiting for...

[autoSteve]

Here's an example for you of how smart Copilot can be.

Scenario: I've copied a unit test function for invalid API limit, and am modifying it to test for invalid hard limit.
Result: The clever bugger has worked out exactly what I am doing and is suggesting absolutely correct lines of code (in grey italic, just press tab...)

[autoSteve]

We now meet (well, far exceed) the minimum requirements for becoming a core component. Unit testing of config_flow.py is must-ride.

I worked out how to shoehorn pytests for a custom into the dev container environment, with minimal alterations required when transitioned as a core component...

In devcontainer.json...

  "mounts": [
    "source=${localEnv:HOME}/Documents/GitHub/ha-solcast-solar/custom_components/solcast_solar,target=${containerWorkspaceFolder}/config/custom_components/solcast_solar,type=bind",
    "source=${localEnv:HOME}/Documents/GitHub/ha-solcast-solar/tests,target=${containerWorkspaceFolder}/tests/components/solcast_solar,type=bind",

from tests/components/solcast_solar run pytest.

(ha-venv) vscode ➜ /workspaces/…/tests/components/solcast_solar $ pytest
Test session starts (platform: linux, Python 3.12.7, pytest 8.3.3, pytest-sugar 1.0.0)
rootdir: /workspaces/homeAssistant-core
configfile: pyproject.toml
plugins: github-actions-annotate-failures-0.2.0, sugar-1.0.0, pytest_freezer-0.4.8, cov-5.0.0, syrupy-4.7.1, picked-0.5.0, timeout-2.3.1, socket-0.7.0, respx-0.21.1, aiohttp-1.0.5, xdist-3.6.1, asyncio-0.24.0, requests-mock-1.12.1, unordered-0.6.1, anyio-4.6.0
asyncio: mode=Mode.AUTO, default_loop_scope=function
collected 7 items                                                                                                                                                                                                                                                                        

 tests/components/solcast_solar/test_config_flow.py ✓✓✓✓✓✓✓                                                                                                                                                                                                                100% ██████████

Results (0.21s):
       7 passed

[BJReplay]

Nice

[BJReplay]

We now meet (well, far exceed) the minimum requirements for becoming a core component. Unit testing of config_flow.py is must-ride.

OK, I'll try to have a look over the weekend.

Very tired, now, so off to bed, but maybe we throw it at the wall and see if it sticks.

Will read up on the process.

[autoSteve]

Sounds like a journey, but I'm betting it's a shorter one than HACS at the mo'...

We got this.

[autoSteve]

I've removed the self-signed certs to stop GitGuardian complaining about them. The sim creates the cert if required on startup.

[autoSteve]

The hard limit validation oopsie would have been caught by the unit test had I also looked for an expected positive outcome going wrong instead of expecting the worst from bad input. I did not. The unit test failed everyone.

It sailed through without a care in the world. It does not now.

[autoSteve]

So I am kind-of guessing re. #227. I am only led by the exception.

The latest commit catches the very first exception regarding 'index' and then bluntly refuses to start the integration with an inferance of a corrupt solcast.json file reported. It might prevent issues raised, but more likely will improve sit. rep. and avoid an exploded log with a bunch of knock-on bad stuff happening.

I thought about doing something fancier, but fancier would have required a LOT more input as to the situation, and a LOT more testing. I am not in the mood for testing. And I have no input. So it is what it is for now.

[BJReplay]

So I am kind-of guessing re. #227.

I am kind-of guessing that some ancient installs - possibly manual, non-HACS, have been upgraded, and they are the cause of the last few issues like this.

[autoSteve]

Kind-of not, I'm tipping.

The log indicated a usage cache load, with a count of two for API used, so must be a relatively recent version. Last reset was within twenty-four hours. This might have been from a prior start attempt, but there are two sites, so if anything API used should be four calls, given history load on fresh start. Unless the second site failed to load...

I got nothin' but conjecture.

2024-12-08 19:54:24.881 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache exists for ******Zr-mpU
2024-12-08 19:54:24.888 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache for ******Zr-mpU last reset 2024-12-08 01:00:00
2024-12-08 19:54:24.888 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Usage loaded
2024-12-08 19:54:24.889 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API counter for ******Zr-mpU is 2/10
2024-12-08 19:54:24.889 DEBUG (MainThread) [custom_components.solcast_solar] UTC times are converted to Europe/Berlin

[BJReplay]

Kind-of not, I'm tipping.

Ahh, I did squint at the log on my phone after I carefully picked up my specs case, left home, and discovered that I had left me specs at home, but didn't spot that.