Repository navigation
Conversation
Signed-off-by: Segran <goran@andersson-stehag.se>
…ix/easee-observation-order Signed-off-by: Segran <goran@andersson-stehag.se> Conflicts: CHANGELOG.md
|
@frahlg Could you please update #172 ( I merged current The remaining CI failure is DCO: it reports missing CI run: https://github.com/srcfl/device-drivers/actions/runs/39050615490 |
* fix(easee_cloud): start a 6 A order at 7 A (1.3.7) Signed-off-by: Lödkolven <lodkolven@users.noreply.github.com> * fix(easee_cloud): boost only with a read static limit (Codex review) Signed-off-by: Lödkolven <lodkolven@users.noreply.github.com> * docs(changelog): wrap easee_cloud 1.3.7 Signed-off-by: Lödkolven <lodkolven@users.noreply.github.com> * fix(easee_cloud): boost only when Core's cap allows 7 A The 7 A start for a 6 A order now needs Core's cap_amps_per_phase (srcfl/ftw#1809) to allow 7 A, besides max_amps_per_phase and the charger's static limit. max_amps_per_phase is the fuse rating, not the room left: on a phase with room for 6.4 A the car drew 7 A, Core cut to 0 W, and the next start boosted again. A Core that sends no cap gets no boost. Review findings on srcfl#190: - P1: every 6 A order during a boost checks the gate again; one that no longer fits writes 6 A at once and ends the boost. - P2: the 90 s window ends in driver_command too, and driver_poll ends it before reading observations, so a failed read cannot keep 7 A. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com> --------- Signed-off-by: Lödkolven <lodkolven@users.noreply.github.com> Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com> Co-authored-by: Lödkolven <lodkolven@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Findings L1 and L2 from the review of srcfl#190. L1: before the first poll last_op_mode is nil, so a reloaded driver offered 7 A to a car that may already charge at 6 A. A boost now needs a poll that saw the charger not charging. L2: a pause or the stand-down cleared the boost but left 7 A in last_amps_set, so the phaseMode re-assert on the next poll wrote 7 A without the cap or the 90 s window. Clearing a running boost now sets last_amps_set to what the charger should hold: the 6 A order after a pause, 0 A after the stand-down. A pause keeps 6 A, not 0 A, because Core's contactor cycle sends ev_resume after ev_pause with no new order between. Harness cases 15-17 fail on 1.3.7 and pass here. Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Segran <goran@andersson-stehag.se>
…d version Signed-off-by: Segran <goran@andersson-stehag.se>
Signed-off-by: Segran <goran@andersson-stehag.se>
An older Easee cloud TotalPower observation can replace a newer one because the previous get_observations accepts replies without checking power source order. A synthetic 10.242 kW → older 0 W sequence reproduces this. This is verified driver behaviour, not proof that cloud reordering caused every incident in srcfl/ftw#1674.
While connected, reject backward power source times, conflicting values at the same physical instant, and missing/malformed power timestamps. Compare RFC3339 instants across offsets and fractional precision. Identical valid change-only values remain confirmable; newer measured zero is accepted. An explicit disconnect resets session ordering. Rejected replies emit no fresh power and use the existing poll-error path.
The observation-ordering fix changes no charging commands, phase policy, limits, retry settings or Core safety logic. It does not synchronize Easee with the site meter or repair historical records.
Integration and scope
Head: a7b6a3d. Integrates #172 at aa0ee46 and current main at 219c462, preserving existing commits. Remains stacked on #172 because its load-balancer reporting changes are still required; retarget to main after that dependency merges.
The main integration preserves the published 1.3.8 start-boost implementation and its reload, pause, default-mode, cap and timeout safeguards. Start-boost helpers and command/default-mode code were compared with main and match exactly. This PR does not introduce or modify that command policy. Observation ordering is separate from the 6 A delay; the combined implementation has not been accepted on hardware.
Candidate version is 1.3.9, above published 1.3.8. Catalog hashes and sizes are regenerated. The diff against the still-older #172 base also includes the main integration, including start-boost code and its tests; those are inherited upstream work.
Validation on the integrated tree
Relevance to Core v0.155.1-beta.1
The official Core tag pins device-drivers at 5cc7bb1 in drivers/BUNDLED_SOURCE.json. That source contains Easee 1.3.6 and lacks the accepted_power_key/power_time_key ordering checks. The release therefore does not supersede this fix. A separately installed local driver must be checked by source/hash; Core's version alone does not identify the active driver.
Remaining acceptance
Keep draft pending review and hardware validation of the combined candidate, including normal charging, stop/reconnect, 6 A start with/without sufficient cap, step-down to 6 A and bounded timeout. No candidate installed on production hardware in this work, and no channel signed or published. After merge, advance FTW's bundled-driver pin so the fix also reaches offline gateways.
Vendor API: https://developer.easee.com/reference/getobservations and https://developer.easee.com/docs/charger-observation-ids. The endpoint returns last reported observations, not a synchronized site energy balance.