From ba5a8eb230588d51179c443e9aba10981358a9f7 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sat, 29 Aug 2026 10:38:48 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20le=20premier=20auto-provisionnement=20r?= =?UTF-8?q?=C3=A9el=20=E2=80=94=20trois=20cas=20observ=C3=A9s,=20deux=20tr?= =?UTF-8?q?ouvailles?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Seconde wallbox simulée appairée sur .75 après +etm27. L'entrée n'apparaît pas instantanément : ma première lecture montrait 4 charges, la suivante 5. Puis tout se confirme — rankOrigin "auto", rang 5 (insertion en queue), badge sur elle seule, alerte d'ex æquo muette. Le coût du §10 est constaté, et il est exactement celui annoncé : écho de "auto" par un client → EnergyErrorInvalidParameter, config INCHANGÉE "auto" → "" (ce que fait l'app) → accepté, LA MARQUE EST EFFACÉE "user" sur la seule borne visée → accepté, rang inchangé, seul ce champ change deux renommages voisins ensuite → "user" SURVIT Donc le badge a bien disparu d'une borne que personne n'avait classée, au renommage d'une autre charge — et la fragilité ne touche que "auto". ⚠️ TROUVAILLE 1 — un refus arrive en `status: "success"`, le verdict étant dans params.energyError. Le service de l'app teste bien les deux ; une sonde jetable écrite le jour même, non — elle a annoncé « ACCEPTÉ » sur une écriture que la box venait de rejeter, et c'est le journal de la box qui a rétabli les faits. La raison lisible n'existe que là : « la charge "Simulated wallbox 2" prétend un rankOrigin "auto" que le moteur n'a pas posé ». Côté RPC il ne reste que le code. §10 mis à jour avec la table et ce piège. ⚠️ TROUVAILLE 2 — l'insertion en queue CASSE la contiguïté des domaines : ecs, ev, ev, heating, ev. La note d'ordre entrelacé s'allume donc à juste titre, et prévient que le premier enregistrement regrouperait — remontant au rang 3 une borne que le moteur avait rangée en queue. Ce n'est pas un défaut de LM-1209, c'est son prix dès que la dernière charge n'est pas du même domaine. Trois lectures possibles, portées au brief moteur ; l'app ne change rien tant que ce n'est pas tranché. Et une erreur de ma part, dans une sonde jetable et pas dans l'app : j'ai comparé un id de borne SANS accolades à un id de charge qui en porte — le piège du §9, que j'avais écrit moi-même la veille. Les chemins de l'app normalisent (chargingModeOf) ou comparent l'id à lui-même (adoptRank) ; le script, lui, ne trouvait jamais sa cible. État du banc laissé : libellés restaurés, borne 2 en rankOrigin "user" au rang 5. Le "auto" est consommé — il faudra un nouvel appairage pour revoir le badge. 226 tests inchangés. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01SQbZKrWqsMFP1Lh2jjjd9f --- docs/BRIEF_plugin_depuis_maquettes.md | 31 +++++++++++++++++++++++++++ docs/UI_data_contract.md | 24 +++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md index a71e80b..6015191 100644 --- a/docs/BRIEF_plugin_depuis_maquettes.md +++ b/docs/BRIEF_plugin_depuis_maquettes.md @@ -2,6 +2,37 @@ --- +## 2026-08-29 (suite) — l'insertion en queue casse la contiguïté des domaines + +**Constaté au premier auto-provisionnement réel** (`Simulated wallbox 2`, `.75`, `+etm27`). + +LM-1209 range la borne détectée en queue (`1 + max`), et c'est le bon choix : elle ne passe +plus devant l'ECS que l'installateur a classé exprès. Mais l'ordre obtenu est : + +``` +rang 1 chauffe-eau (ecs) +rang 2 V2C Trydan (ev) +rang 3 Simulated wallbox (ev) +rang 4 PAC banc (heating) +rang 5 Simulated wallbox 2 (ev) ← le domaine `ev` est coupé par `heating` +``` + +Le domaine `ev` est **entrelacé**, et l'app le signale — c'est la note posée le 2026-08-28, +qui prévient que le premier enregistrement **regroupera** et changera donc l'ordre de +service. Concrètement : la borne rangée en queue par le moteur remonterait au rang 3 au +premier geste de l'installateur, sans qu'il l'ait demandé. + +Ce n'est pas un défaut de LM-1209 : c'est le prix de l'insertion en queue dès que la +dernière charge n'est pas du même domaine, ce qui est le cas courant. **Trois lectures +possibles**, et c'est au moteur de trancher : insérer en queue *du domaine* plutôt qu'en +queue de liste ; assumer l'entrelacement et considérer que le regroupement de l'app est +l'erreur ; ou déclarer que l'ordre à plat prime et que l'app ne doit pas regrouper. + +L'app ne changera rien tant que ce n'est pas tranché : elle regroupe pour afficher depuis le +début, et elle prévient avant d'écrire. + +--- + ## 2026-08-29 — `rankOrigin` : un écho inchangé de `"auto"` passe-t-il ? **Une question, et le contournement posé en attendant.** diff --git a/docs/UI_data_contract.md b/docs/UI_data_contract.md index 4a2dd79..9bcf868 100644 --- a/docs/UI_data_contract.md +++ b/docs/UI_data_contract.md @@ -446,6 +446,30 @@ toutes les charges à chaque écriture, et le badge s'éteint sur une borne que classée, au premier renommage d'une autre charge. **Une information qui s'efface au premier geste voisin ne vaut pas d'être publiée.** +### Constaté sur machine le 2026-08-29, et la forme du refus + +Une seconde wallbox simulée appairée après `+etm27` a produit les trois cas d'un coup : +`rankOrigin: "auto"`, rang **5** (insertion en queue), badge sur elle seule. + +| Écriture | Réponse de la box | État après | +|---|---|---| +| renommage d'une AUTRE charge, `"auto"` renvoyé verbatim | `status: "success"` + `energyError: "EnergyErrorInvalidParameter"` | **inchangé** | +| même renommage, `"auto"` → `""` (ce que fait l'app) | `EnergyErrorNoError` | **la marque est effacée** | +| `"user"` sur la seule borne visée | `EnergyErrorNoError` | rang inchangé, seul ce champ change | +| deux renommages voisins ensuite | `EnergyErrorNoError` | **`"user"` survit** | + +Le coût annoncé est donc réel et vérifié : le badge « rang posé par la box » a disparu d'une +borne que personne n'avait classée, au renommage d'une autre charge. La fragilité ne touche +que `"auto"` — `"user"`, lui, traverse les gestes voisins. + +> ⚠️ **Un refus arrive en `status: "success"`.** Le verdict est dans `params.energyError`, +> et un contrôle sur `status` seul le prend pour un succès. Le service de l'app teste bien +> les deux (`setLoadConfig`) — mais une sonde jetable écrite le jour même est tombée dans le +> piège et a annoncé « ACCEPTÉ » sur une écriture que la box venait de rejeter. La raison +> lisible, elle, ne sort **que** dans le journal de la box : *« la charge "Simulated wallbox +> 2" prétend un rankOrigin "auto" que le moteur n'a pas posé »*. Côté RPC, il ne reste que +> `EnergyErrorInvalidParameter`. + ### Ce que ça impose à l'app, aujourd'hui Le nettoyage vit à un **point de sortie unique** (`NymeaService.setLoadConfig`), jamais sur