fix(easee_cloud): report Easee's load balancing below FTW's order (1.4.1)

CHANGELOG.md

@@ -2,6 +2,48 @@
 
 ## [Unreleased]
 
+### easee_cloud 1.4.1
+
+Report when Easee's own load balancing holds the car below FTW's order. A
+tester's trace (srcfl/ftw#1763, 23 October 2026) showed FTW ordering 15 A
+and the charger reading back 15 A, while Easee's circuit allocation
+(observations 70–72) and the current it signalled to the car (114) fell to
+12, 14 and 13 A. The car took 8.2–8.9 kW instead of 10.4 kW, and FTW said
+"Not following". The driver now reads 70–72 and 114 and emits
+`current_limit_a`, the signalled current, while the car charges, the
+charger reads back FTW's last order (48) and the signalled current is
+more than half an amp below it. A value counts only when it answers that
+order: Easee recorded it at or after the order, or the order has stood
+30 s. It emits `current_limited_by = "load_balancer"` only when the
+allocation is below the order too and no higher than the signalled
+current, and the charger's own static limit does not explain it. A
+three-phase charger uses the lowest allocation of the phases in use (a
+phase with none is not in use); a one-phase charger the highest. When
+Easee lets the car take the order again, the last limit stays for up to
+20 s while the car still draws below the order, since the cloud reports
+the car's new draw a few seconds later.
+ReasonForNoCurrent is not used as a cause: in that trace reason 77 was
+older than the cuts. Labels for reasons 6, 8–11, 25–30 and 77 now match
+Easee's published table (from srcfl/device-drivers#172).
+
+A REST reply is no longer used when its power time goes back from the
+last reply used or gives another power value at the same instant, or,
+while a car is connected, when its power time is missing or unreadable. A
+late cached reply once turned a measured 10.242 kW into 0 W. Times
+compare as instants across UTC offsets and fractional precision. A
+disconnect starts the order again. Such replies one after another for
+30 s mean the time itself is wrong: an older time then starts the order
+again, and unreadable times are used as they come until a readable one
+arrives, so a stamp from the future or an odd format cannot keep the
+driver silent. A gap of more than 30 s between such replies, such as an
+outage, starts the count again, and a held-back reply does not use up one
+of the ten session checks an hour. The check and its tests
+come from Segran in srcfl/device-drivers#183. The stream's own order is
+unchanged.
+
+Not yet seen against a load-balanced Easee with this code. Core reads the
+new fields from srcfl/ftw#1537.
+
 ### easee_cloud 1.4.0
 
 Read Easee's SignalR stream when the host grants a WebSocket. Easee

SUPPORT_STATUS.md

@@ -46,8 +46,8 @@ Catalog source is not proof that a target can install or run a driver.
 | deye | 2.1.1 | blixt-l1 | not_assessed | — | not_recorded | not_assessed |
 | easee | 1.0.4 | ftw-core | not_assessed | — | not_recorded | not_assessed |
 | easee | 1.0.4 | blixt-l1 | not_assessed | — | not_recorded | not_assessed |
-| easee_cloud | 1.4.0 | ftw-core | not_assessed | — | not_recorded | not_assessed |
-| easee_cloud | 1.4.0 | blixt-l1 | not_assessed | — | not_recorded | not_assessed |
+| easee_cloud | 1.4.1 | ftw-core | not_assessed | — | not_recorded | not_assessed |
+| easee_cloud | 1.4.1 | blixt-l1 | not_assessed | — | not_recorded | not_assessed |
 | esphome_dsmr | 1.0.7 | ftw-core | not_assessed | — | not_recorded | not_assessed |
 | esphome_dsmr | 1.0.7 | blixt-l1 | not_assessed | — | not_recorded | not_assessed |
 | etrel | 1.0.3 | ftw-core | not_assessed | — | not_recorded | not_assessed |

devices.yaml

@@ -338,7 +338,7 @@ manufacturers:
         protocols:
           - protocol: http
             driver: "easee_cloud"
-            version: "1.4.0"
+            version: "1.4.1"
             ders: [ev]
             control: true
         firmware_versions: ""

docs/WRITING-A-DRIVER.md

@@ -425,6 +425,17 @@ all modes. They never grant control or replace a safety limit:
   from the dynamic offer in `max_a`. `device_limit_age_s` is time since the
   successful settings read. Failed reads must not reset its age. Core stops
   treating it as a current limit after two minutes.
+- `current_limit_a`: the current per phase the charger lets the car take
+  now, while the car charges and that current is below the host's last
+  order, which the charger reads back. Set it only from a value that
+  answers that order: one the charger reported at or after it took the
+  order, or any once the order has stood long enough for the value to
+  move. Leave it nil otherwise.
+- `current_limited_by`: `"load_balancer"` when the charger's own load
+  balancing sets `current_limit_a`, shown by an allocation that is below
+  the order and explains the limit. Leave it nil when the cause is not
+  shown. An older vendor reason code is not proof of a cause. Core says
+  the car is limited only when its measured power also falls short.
 
 A device reading makes a response measured, nothing more. Core calls it
 confirmed only when an identified, separate site meter shows a matching