[upstream-doc] easee_cloud: Easee ongoing session API changed (d0d51ad5)

[github-actions]

The upstream document easee_cloud is watched against has changed.

• Driver: easee_cloud — drivers/lua/easee_cloud.lua, manifests/easee_cloud.yaml
• Document: Easee ongoing session API
• URL: https://developer.easee.com/reference/chargers_getongoingsessiondetails
• Kind: api_docs
• URL stability: stable
• Previous SHA-256: e6b86d7322dfd23c202e73da97fbae22631f766ba411d74be143d242e265f0e4
• New SHA-256: d0d51ad58c580f05cb00d213a42c468494f3c962796ec9a995e947ea72457ac0
• Detected: 2026-09-14T06:49:17+00:00

Review

• Read the new document and note what changed (registers renumbered,
  parameters added, scaling corrected).
• Cross-check against the registers/parameters easee_cloud reads.
• If the driver is affected, open a fix and bump its version;
  otherwise close this issue.

Detection is a raw-byte hash: the file's bytes moved. That can be a
genuine content change or just rebuild churn in the PDF metadata —
this issue is a prompt to look, not proof the registers changed.

[frahlg]

Reviewed the live content of https://developer.easee.com/reference/chargers_getongoingsessiondetails against what drivers/lua/easee_cloud.lua actually reads.

The driver calls this endpoint (GET /chargers/{serial}/sessions/ongoing) from current_session_id() (lines ~386-392) purely to confirm that the session identity implied by observation 223 (Id/Start) is still the currently-open session before restoring validated_session_id. It reads exactly two fields from the response:

• ongoing.sessionId — compared with tonumber(...) ~= id
• ongoing.sessionStart — normalized via normalized_session_start() and compared against the observation-223-derived start time

Both fields are present in the current documented response (sessionId: integer, nullable; sessionStart: date-time, nullable) with the same names and types the driver assumes. No other fields of the response (session energy, pricing, duration, OCMF data, etc.) are consumed by this driver, so changes to those parts of the schema — if any — don't affect it. The rate limit the driver enforces (10 requests/hour, see session_lookups_ms) also still matches the documented limit ("max 10 requests per 60 minutes").

For context: this exact code path (session-identity confirmation via this endpoint) was reworked and merged just hours before this hash change was detected — PR #116 (merged 2026-09-14T03:51 UTC, this issue opened 2026-09-14T06:49 UTC, "retain session identity across pauses and preserve source times") — so the matching logic reflects the live API as of this week, not a stale assumption.

No discrepancy found between what the driver expects and what the document currently states. Closing as not-planned.

---

Generated by Claude Code