Tesla BLE: add caching

[andig]

@wimaha would that work? Wasn't sure if HTTP cache headers are already supported. If not, this will force caching and reduce number of requests.

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider making the cache duration configurable via a parameter (similar to timeout) instead of hardcoding 1s in each query so different deployments can tune caching without editing the template.
• Since the same uri and endpoints=charge_state are repeated for each query, you might want to factor this out into a shared template/partial or YAML anchor to reduce duplication and the chance of inconsistencies in future changes.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider making the `cache` duration configurable via a parameter (similar to `timeout`) instead of hardcoding `1s` in each query so different deployments can tune caching without editing the template.
- Since the same `uri` and `endpoints=charge_state` are repeated for each query, you might want to factor this out into a shared template/partial or YAML anchor to reduce duplication and the chance of inconsistencies in future changes.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[wimaha]

Hi, we have in-memory caching for VehicleData responses (per-endpoint, per-VIN, configurable via vehicleDataCacheTime, default 30 seconds), which reduces BLE connections. So we should not have a problem with multiple request in a short period.
But if this reduces http requests it may be a good change.

We currently don't have HTTP cache headers set for VehicleData responses.

[andig]

Thank you, then this PR should reduce number of requests. If your internal caching sends headers in future we can drop this again.