[segran2]

An Easee current-setting readback can remain at 15 A while the actual pilot and circuit allocation allow 13 A. Treating the setting as the pilot makes a real charging limit look unexplained. This adds independently confirmed pilot evidence for srcfl/ftw#1874.

Change

• Expose pilot_a, pilot_observed_at, pilot_confirmed_at_ms and dynamic_limit_a separately.
• Refresh an observation's confirmation only when that REST/SignalR observation is accepted. Reading other observations does not refresh it.
• Keep unchanged old source timestamps usable when freshly confirmed, while rejecting missing, expired or future evidence before pilot/allocation values can explain a limit.
• Preserve fix(easee_cloud): report Easee's load balancing below FTW's order (1.4.1) #194's command, ordering, allocation and safety behavior.
• Propose easee_cloud 1.5.0 for the added telemetry; regenerate catalog metadata and add a changelog entry.

Dependency

Stacked on #194 at 34347fb92b08474b52e6240b28e78498110ba580, targeting easee-allocated-limit. This extends that work without rewriting or replacing it. Paired Core extension: srcfl/ftw#1905 (stacked on srcfl/ftw#1537). After driver integration, FTW still needs a separate pin/snapshot update to the merged driver commit; this PR does not publish a signed artifact.

Validation

• Exact PR tree: make test-driver ID=easee_cloud: 44 passed, 15 skipped.
• Exact PR tree: make check: 4,992 passed, 936 skipped; generated metadata and whitespace checks passed.
• Added harness covers separate 13 A pilot / 15 A setting, constant old source timestamp freshly confirmed by REST, missing observations not refreshing the pilot, zero pilot, no invented limit and future timestamps.

On 27 October 2026 the paired logic ran locally on FTW v0.157.2-beta.1+local.2 with an Easee cloud charger and Audi e-tron. The live driver was the same logic with unpublished 1.4.1 metadata; this PR's 1.5.0 is a version/catalog change, not a second hardware-tested binary.

1. With the car allowed to charge: 15 A request, 15 A pilot and approximately 10.46 kW; Following FTW.
2. Natural charger allocation: request/setting 15 A, pilot/allocation 13 A, approximately 8.93 kW. Six consecutive settled samples over about 54 seconds showed Core load_balancer_limit/info, and the actual EV sheet displayed “Limited by the charger’s load balancing” without a red warning.
3. Releasing the temporary hold returned to plan, 0 A pilot and 0 W; no persistent goal or protection limit was changed.

This is one-site evidence. Charger model/firmware identifiers were not captured, and no claim is made about the exact internal allocation algorithm or which household load triggered it. Communication-loss/recovery and release-of-load-balancing transitions were not hardware-tested here; freshness/order regressions are software evidence. Keep draft pending dependency integration, CI and remaining device identification/review. No site configuration, credentials, raw household history or device identifiers are committed.

[miravoss26]

Easee cloud driver 1.5.0: exposes the charger's confirmed pilot current (pilot_a, pilot_observed_at, pilot_confirmed_at_ms) and dynamic_limit_a as separate fields, only when the REST observation was confirmed recently and isn't in the future.

• Correctness, fine: confirmed_current rejects NaN, negatives, >80 A, missing source time, stale confirmation (REST_FRESH_MS) and future source times. When host.unix_ms is missing it skips the future check and emits pilot_confirmed_at_ms = 0, which the FTW side (#1905) treats as not fresh. That's the safe direction.
• Low: observation_confirmed_ms is stamped in note_observation for any wanted id, including values REST re-confirms unchanged. That's intended (the test name in #1905 says so), but it means "confirmed" = "REST returned it again", not "the charger re-sent it". Worth a comment in the code so nobody reads it as a fresh measurement.
• Low: spec/host-api-profile.json gains four fields, so anything validating against the profile needs to pick them up. CI is green, so presumably done.
• Security screen: no secrets, no new hosts or dependencies, no authz changes.

Safe to merge from my read. It pairs with srcfl/ftw#1905, which consumes these fields. Merge order doesn't matter, since old drivers keep the old contract.