[Xitee1]

What

DataProvider.read_data() fetched both /api/v1/var (the full resource tree) and /api/v1/var/status on every call. The resource tree is the largest response the Query API produces and only changes when the myGEKKO configuration itself is changed, so this PR fetches it only on the first read_data() call and caches it afterwards. Every subsequent cycle only requests /api/v1/var/status.

Why

• Halves the number of requests per polling cycle — relevant for the Plus Query API, which enforces rate/burst limits (HTTP 429).
• Avoids repeatedly transferring the biggest payload, which is especially noticeable with the 30s polling interval of the Home Assistant integration.

Notes

• If the initial resources fetch fails (or its JSON is invalid), resources stays None and the next read_data() call retries it, matching the previous behavior.
• A config change on the controller (e.g. renaming/adding items) is picked up again after re-creating the client — same as the Home Assistant integration behaves today, where entities are only created at setup anyway.
• Added a test asserting /api/v1/var is requested once across two read_data() calls while /api/v1/var/status is requested each time.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

No active review issues remain for the resource-tree caching change.

No open issues 🎉

What changed in this PR

Caches the myGEKKO resource tree in DataProvider to reduce polling requests and data transfer while continuing to refresh status on every cycle.

Changes:

• Fetches /api/v1/var only while resources is None, preserving retries after an initial fetch or JSON parsing failure.
• Adds a regression test verifying one resource-tree request and two status requests across two polling calls.

File	Description
tests/​test_pymygekko.py	Tests resource caching and continued status polling.
PyMyGekko/​data_provider.py	Reuses the cached resource tree on subsequent reads.

_{Review effort: Balanced}