docs(prepa): le relevé du 28 dépasse trois affirmations — dont le blocage sessionEnergy
Relevé Integrations.GetThings sur .75, borne appairée et sous tension.
· §2.1 — la classe publie currentL1/L2/L3 (5,86 / 5,94 / 6,02 A), plus powerL1/L2/L3 :
le renommage et l'unité Ampère sont déployés
· §6.4 — phaseCount vaut 3 sur la Trydan, le réglage est posé
· §2.2 — sessionEnergy EST exposée : 4,229 kWh
Mais la levée du §2.2 n'est pas acquise, et c'est le point à ne pas lire trop vite :
sessionEnergy vaut EXACTEMENT chargeEnergy (4,229419231414795 des deux côtés), ce qui est
précisément ce qu'on attend d'une session sans interruption. L'égalité ne distingue pas une
grandeur construite d'un alias du registre 0x0BC4, dont le retrait par evcc reste la raison
du refus initial.
Le test qui tranche est nommé dans le document : une remise à zéro de chargeEnergy — elle
survient à l'ARRÊT de la charge, pas au débranchement (mesuré le 28 au matin : 0,3456 kWh
→ 0, 119 s avant que le câble ne bouge) — avec un sessionEnergy qui, lui, continue. Tant
qu'elle n'est pas observée, C1 de LM-1009 reste entière et l'app n'affiche aucun
avancement. C'est elle qu'il faut guetter dans le relevé de la campagne, pas la présence du
champ.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQbZKrWqsMFP1Lh2jjjd9f
This commit is contained in:
parent
b3e39a5a2a
commit
985b4ac4f6
@ -10,6 +10,31 @@ borne au mur. Le banc tourne `1.15.2+etm24`.
|
||||
> arm64, posé, et la ThingClass `trydan` se charge avec `phaseCount` (§2.1 corrigé). Le blocage
|
||||
> §2.2 est un refus assumé, pas une tâche. Il ne reste que le câblage et l'appairage — §6.
|
||||
|
||||
> ## ⚠️ CORRECTION DU 28, APRÈS-MIDI — ce document a été dépassé par le déploiement du matin
|
||||
>
|
||||
> Relevé `Integrations.GetThings` sur `.75`, borne appairée et sous tension. **Trois
|
||||
> affirmations de ce document ne sont plus vraies**, et deux d'entre elles décrivaient des
|
||||
> blocages qui n'en sont plus :
|
||||
>
|
||||
> | Ce que le document dit | Ce que la borne publie le 28 |
|
||||
> |---|---|
|
||||
> | §2.1 — la classe déclare `powerL1/L2/L3` | **`currentL1/L2/L3`** — 5,86 / 5,94 / 6,02 A. Le renommage (unité Ampère) est **déployé** ; les anciens noms ont disparu |
|
||||
> | §6.4 — poser `phaseCount = 3` reste à faire | **fait** : l'état vaut **3** sur la Trydan |
|
||||
> | §2.2 — `sessionEnergy` n'est **délibérément pas** exposée | **elle l'est** : `sessionEnergy = 4,229 kWh` |
|
||||
>
|
||||
> **Mais la levée du §2.2 n'est PAS acquise, et c'est le point à ne pas lire trop vite.** Au
|
||||
> moment du relevé, `sessionEnergy` valait **exactement** `chargeEnergy` — 4,229419231414795
|
||||
> des deux côtés. C'est précisément ce qu'on attend d'une session **sans interruption** :
|
||||
> l'égalité ne distingue pas une grandeur construite d'un simple alias du registre
|
||||
> `0x0BC4 ChargeEnergy`, dont le retrait par evcc reste la raison du refus initial.
|
||||
>
|
||||
> **Le test qui tranche est nommé** : une remise à zéro de `chargeEnergy` — elle survient à
|
||||
> l'**arrêt de la charge**, pas au débranchement, mesurée le 28 au matin (0,3456 kWh → 0,
|
||||
> 119 s avant que le câble ne bouge) — **avec un `sessionEnergy` qui, lui, continue**. Tant
|
||||
> qu'elle n'est pas observée, la condition **C1 de LM-1009 reste entière** et l'app
|
||||
> n'affiche **aucun avancement de charge**. La campagne en cours devrait la produire :
|
||||
> c'est elle qu'il faut guetter dans le relevé, pas la présence du champ.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ce qui n'est pas encore sur la box
|
||||
@ -36,6 +61,10 @@ beta validée. Ne pas promettre tant que non testé sur borne réelle. »** Dema
|
||||
|
||||
La ThingClass `trydan` déclare `connected`, `pluggedIn`, `charging`, `power`,
|
||||
`maxChargingCurrent`, `currentPower`, `powerL1/L2/L3` et une série d'états de diagnostic.
|
||||
|
||||
> **Périmé le 28 :** ce sont désormais `currentL1/L2/L3`, en **ampères**, nom et unité
|
||||
> corrigés côté plugin — les anciens `powerL1/L2/L3` étaient des ampères mal nommés, et
|
||||
> aucun écran ne doit porter de conversion héritée de ce temps-là.
|
||||
**Elle ne déclare pas `phaseCount`.** Et il n'existe **aucun registre de phases** dans la carte
|
||||
Modbus V2C (0x0BC2–0x0BD5, 0x177A–0x1783) : le nombre de phases n'est pas lisible sur la borne.
|
||||
|
||||
@ -76,6 +105,12 @@ l'appairage** — c'est l'étape 5 du §6, et c'est le seul geste qui reste sur
|
||||
|
||||
### 2.2 `sessionEnergy` n'est délibérément PAS exposée — et c'est LM-1009 qui en dépend
|
||||
|
||||
> **⚠️ PÉRIMÉ LE 28 SUR LE FAIT, PAS SUR LE FOND.** La borne publie `sessionEnergy`
|
||||
> (4,229 kWh) depuis le déploiement du matin. Mais elle publie **la même valeur** que
|
||||
> `chargeEnergy`, ce qui ne prouve pas que la première survive là où la seconde est remise à
|
||||
> zéro — voir le bandeau de tête. Tout ce qui suit reste donc à lire comme la **raison** du
|
||||
> refus, et comme la validation qui reste à faire.
|
||||
|
||||
Le registre existe : `0x0BC4 ChargeEnergy`, kWh de la session. Mais le brief du plugin l'interdit
|
||||
explicitement : *« NE PAS exposer en `sessionEnergy` »*, et la liste des interdits porte
|
||||
« Exposer `sessionEnergy` depuis ChargeEnergy sans validation matérielle ».
|
||||
@ -151,6 +186,7 @@ lui-même** `batteryLevel`. Le pourcentage affiché demain sera une intégration
|
||||
| **`minPowerW` sans véhicule branché** | **OUI** | depuis `+etm24` la borne est *hors arbitrage* — vérifier qu'elle n'apparaît pas dans `loads[]` et que le journal le dit |
|
||||
| **`EV_GRID_START`** | **PEUT-ÊTRE** | il faut que le budget tombe dans `[plancher × 0,5 ; plancher[`. À **guetter**, pas à fabriquer |
|
||||
| **`sessionEnergy` sur matériel réel** | **ATTENDU RETIRÉ** *(Patrick, la veille)* — le refus V2C est documenté, pas un oubli | remplacé par deux choses, §2.2 : **ré-examiner** `ChargeEnergy` borne et référence en main, et **exercer C1 de LM-1009 sur ce cas réel** plutôt que sur un cas fabriqué |
|
||||
| **`sessionEnergy` survit-elle à une interruption ?** *(ajouté le 28)* | **OUI, et c'est LE point** | le champ existe désormais mais vaut `chargeEnergy` ; il faut **observer une remise à zéro de `chargeEnergy` pendant que `sessionEnergy` continue**. Sans cette observation, rien n'est acquis et l'app n'affiche aucun avancement |
|
||||
|
||||
---
|
||||
|
||||
@ -166,7 +202,8 @@ lui-même** `batteryLevel`. Le pourcentage affiché demain sera une intégration
|
||||
C'est le geste qui distingue un problème réseau d'un problème logiciel — la Terra AC a
|
||||
coûté une session faute de l'avoir fait.
|
||||
3. [ ] Appairer la Trydan, vérifier `connected: true` et un `currentPower` qui bouge.
|
||||
4. [ ] **Poser `phaseCount` = 3** dans les réglages du Thing. Le défaut est 1 ; sans ce geste,
|
||||
4. [x] ~~**Poser `phaseCount` = 3** dans les réglages du Thing.~~ **Fait** — vérifié le 28 :
|
||||
l'état `phaseCount` de la Trydan vaut **3**. Le défaut est 1 ; sans ce geste,
|
||||
le plancher publié sera de 1 380 W au lieu de 4 140. **C'est le seul point où l'oubli
|
||||
est silencieux** — à vérifier par le `minPowerW` publié en télémétrie, pas de mémoire.
|
||||
5. [ ] Créer la voiture `genericCar` avec les quatre réglages du §3 — dont `capacity` réelle et
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user