376acb2181
Le piège des accolades n'était pas un détail de chargingModeOf(). C'est la deuxième
occurrence en une semaine d'un motif qui se répétera : deux appels JSON-RPC de la même box,
portant le même objet, n'emploient pas la même convention, et RIEN ne le dit. Écrit comme
tel dans docs/UI_data_contract.md §9, avec renvoi depuis les deux sites de code et depuis
tools/rpc/README.md — là où quelqu'un croise deux réponses brutes.
Les occurrences, leur symptôme :
· GetPowerBalance (currentPowerProduction…) × GetPowerBalanceLogs (production…) →
tout tombe à zéro, l'historique paraît vide sur 7 960 échantillons bien présents
· GetChargingInfos (evChargerId sans accolades) × GetLoadConfig (id avec) →
« mode non lu » sur une borne parfaitement lue, et la note « hors arbitrage » muette
· famille voisine, même silence : currentPower* en W × total* en kWh, facteur 1000
Ce qui en fait un motif et pas trois anecdotes : le symptôme n'est JAMAIS une exception,
c'est une valeur neutre plausible, et un test unitaire qui construit ses deux côtés avec la
même convention passe aussi. D'où les trois gestes écrits au §9 — sonder les deux appels
côte à côte sur les charges utiles brutes, éprouver le rapprochement sur les deux formes
réelles, et se méfier d'un vide qui ne coûte rien à expliquer.
Et le lien avec une règle qu'on suivait déjà sans la relier à ça : une valeur neutre issue
d'un croisement raté est indiscernable d'une vraie absence. « Non lu » laisse une chance de
trouver le bug ; « 0 » l'enterre.
── Campagne V2C arrêtée, et la réserve sessionEnergy avec elle ────────────────
La Trydan non-Pro est en WiFi ESP32 sans repli filaire, lien inexploitable à deux mètres du
point d'accès : 70 % de scrutations avortées, 12 bascules en injoignable en vingt minutes.
Le modèle sort du catalogue ETM ; seule la Trydan Pro (port Ethernet) y reste.
La trace qui lève C1 — chargeEnergy à zéro AVEC un sessionEnergy qui continue — n'a donc
pas été prise et ne viendra pas de cette borne. Les notes restent en place telles quelles,
avec la raison mise à jour : elles seront levées sur une Trydan Pro. Aucun avancement de
charge affiché d'ici là.
164 tests, flutter analyze inchangé à 27 remarques.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQbZKrWqsMFP1Lh2jjjd9f
174 lines
12 KiB
Markdown
174 lines
12 KiB
Markdown
# TODO — ETM PowerSync App
|
||
|
||
## Ouvert au 2026-08-27
|
||
|
||
- [x] ~~🔴 **Bilan JOURNALIER**~~ — **fait le 2026-08-28.** Les quatre tuiles montrent la
|
||
journée, sous un en-tête « Aujourd'hui » qui le dit une fois. Méthode : différence des
|
||
compteurs entre minuit local et maintenant, jamais l'intégration des puissances —
|
||
mesurée contre estimée, 0,8 % d'écart sur `.75`. Le contrôle qui la valide est
|
||
l'identité *production + soutiré == consommation + injecté*, vérifiée exactement sur le
|
||
banc.
|
||
- **Deux bugs d'unité trouvés en chemin** : les compteurs `total*` sont en **kWh** et le
|
||
modèle les nommait `Wh`. L'écran Énergie les divisait donc encore par mille — une
|
||
journée de 78 kWh s'y lisait « 78 Wh » — et la simulation accumulait des Wh.
|
||
- Vérifié sur appareil contre `.75` en lecture seule. Le passage a trouvé quatre libellés
|
||
tronqués qu'aucun des 138 tests unitaires ne pouvait voir.
|
||
|
||
- [ ] ❓ **« ECS d'abord, batterie ensuite » — à porter au moteur.** Demandé le 2026-08-27,
|
||
et **pas exprimable aujourd'hui**. `batteryLevelConsideration` fait l'inverse : il annule
|
||
le budget *sous* le seuil, donc la batterie passe avant. La batterie n'est pas dans le
|
||
waterfall — aucune entrée `GetLoadConfig`, et `enableCharging` / `chargingRate` /
|
||
`enableDischarging` n'apparaissent nulle part dans le plugin ETM. Le levier existe
|
||
pourtant : la classe **SunSpec Storage** de `.75` déclare ces cinq actions. Question :
|
||
*le stockage est-il une charge arbitrable, ou reste-t-il hors du budget ?* Une règle
|
||
`Rules.*` serait un contournement — deux commandeurs sur la batterie, exactement le
|
||
défaut que 3g-2 vient de supprimer sur les bornes.
|
||
|
||
- [ ] **Zones de climatisation — cadrage écrit, banc à préparer.** Voir
|
||
`docs/CADRAGE_zones_clim.md`. Le blocage n'est pas « aucune zone déclarée » : sur les 58
|
||
classes de `.75`, **aucune ne porte `thermostat`, `closablesensor`, `temperaturesensor`
|
||
ni `notifications`** — aucun plugin installé ne sait en créer une. Deux paquets du dépôt
|
||
apt du banc suffisent (`nymea-plugin-generic-heatingcooling`,
|
||
`nymea-plugin-generic-sensors`). Six décisions à prendre avant de coder.
|
||
|
||
- [ ] **`EV_GRID_START` / `PHASE_LIMIT` — éprouvés par test seulement.** Les clés ARB sont
|
||
prêtes, les motifs n'ont **jamais été vus sur machine**. Signaler la première occurrence
|
||
réelle. Ne rien bâtir autour d'ici là.
|
||
|
||
- [ ] ⏳ **`sessionEnergy` est CONSTRUIT par le plugin — mais la trace n'existe pas, et
|
||
n'existera pas sur cette borne.** Le plugin V2C `1.15.2+etm13` (déployé le 2026-08-28 à
|
||
midi) accumule les incréments de `chargeEnergy`, détecte les remises à zéro, et ne repart
|
||
qu'à l'ouverture d'une session : ce n'est **pas** un alias du registre `0x0BC4`.
|
||
**La campagne V2C est arrêtée le 2026-08-28** — la Trydan non-Pro est en WiFi ESP32 sans
|
||
repli filaire, lien inexploitable à deux mètres du point d'accès (70 % de scrutations
|
||
avortées, 12 bascules en injoignable en vingt minutes) ; le modèle sort du catalogue ETM,
|
||
seule la **Trydan Pro** (port Ethernet) y reste. Le cas qui lève la réserve —
|
||
`chargeEnergy` à zéro, `sessionEnergy` qui continue — se verra sur elle. **Aucun
|
||
avancement affiché d'ici là** (LM-1009 §C1), et la note reste en place telle quelle.
|
||
|
||
- [x] ~~Le piège des accolades~~ — **écrit comme MOTIF le 2026-08-28**, pas comme correctif
|
||
local : `docs/UI_data_contract.md` §9, « Deux réponses de la même box, deux conventions ».
|
||
Deux occurrences en une semaine (clés de log sans préfixe `currentPower`, identifiants de
|
||
borne avec/sans accolades), la règle, la façon de le chercher, et un renvoi depuis les
|
||
deux sites de code plus `tools/rpc/README.md` — là où quelqu'un croise deux réponses.
|
||
|
||
- [ ] **Historique des états d'une borne — `sessionEnergy` n'est pas enregistré.**
|
||
`suggestLogging` est écrasé par les préférences persistées de `things.conf` sur un Thing
|
||
déjà appairé, et la V2C n'y a que `connected`, `charging`, `power`. La valeur courante est
|
||
juste — « la nuit relue à 7 h » fonctionne — mais **il n'y aura pas de courbe**. Le
|
||
réglage est côté app : choisir les états enregistrés d'un Thing. À décider si un
|
||
historique de recharge est voulu ; sans lui, l'écran ne peut montrer qu'un instantané.
|
||
|
||
- [x] ~~⏳ `sessionEnergy` existe — mais rien ne prouve qu'il survive à une interruption~~ —
|
||
**répondu le 2026-08-28** par l'origine du champ (entrée ci-dessus). Le relevé qui a posé
|
||
la question est conservé : `Integrations.GetThings` sur `.75`, cet après-midi —
|
||
la V2C publie `sessionEnergy` **et** `chargeEnergy`, tous deux à **4,229 kWh** — égaux,
|
||
ce qui est exactement ce qu'on attend d'une session sans interruption. Le test qui
|
||
tranche est une **remise à zéro observée de `chargeEnergy` avec un `sessionEnergy` qui
|
||
continue**. Tant qu'elle n'est pas vue, LM-1009 §C1 reste entière : **pas d'avancement
|
||
affiché**. À vérifier sur la campagne de mesures en cours.
|
||
- Deux attentes **levées** au même relevé : le renommage `currentL1/L2/L3` (unité
|
||
Ampère) **est déployé** — plus de `powerL1/L2/L3` — et `phaseCount` vaut **3** sur la
|
||
Trydan, le réglage ayant été posé. `PREPA_BANC_20260828.md` (dépôt plugin) est corrigé
|
||
en conséquence : il décrivait l'état de la veille au soir.
|
||
|
||
- [x] ~~**`EVChargingCard` n'est montée par AUCUN écran**~~ — **tranché le 2026-08-28 :
|
||
elle part.** La monter aurait publié de la fiction. Trois des grandeurs qu'elle affiche
|
||
ne sont **jamais lues sur la box** : `chargingMode`, `chargingPower` (3,6 kW) et
|
||
`solarSourcePercent` (82 %) sont des valeurs par défaut de `EnergyData`, et le mode n'est
|
||
écrit qu'en optimiste après une commande — jamais relu par `GetChargingInfos`. Sa feuille
|
||
« Paramètres de charge » proposait en plus un **courant minimum**, qui n'existe dans aucun
|
||
contrat, et son bouton « Enregistrer » ne faisait que `Navigator.pop` : rien n'était écrit.
|
||
|
||
- [x] ~~**La tuile EV des favoris affiche des valeurs par défaut comme des mesures**~~ —
|
||
**fait le 2026-08-28 : rendue muette, pas retirée.** La retirer aurait laissé un trou
|
||
dans une liste que le client a composée lui-même. `EvFavoriteTile`
|
||
(`widgets/ev_favorite_tile.dart`) lit la borne — `pluggedIn`, `charging`, `currentPower`
|
||
du Thing, mode par `GetChargingInfos` + `ChargingInfoChanged` — et **dit** ce qui n'est
|
||
pas publié plutôt que d'afficher zéro. L'écriture du mode **restitue le refus** et les
|
||
cibles tactiles passent de 7–10 px à 44 px. Les trois champs fictifs de `EnergyData`
|
||
(`chargingMode`, `chargingPower`, `solarSourcePercent`) sont **supprimés du modèle** :
|
||
la fiction n'a plus de porte d'entrée.
|
||
|
||
- [ ] **La vue « consommation » du Sankey reste une ESTIMATION — elle le dit désormais.**
|
||
`features/dashboard/widgets/energy_flow_card.dart` : *PAC = 38 % de la maison*,
|
||
*Eau chaude = 18 %*, *Autres = 22 %* sont trois ratios en dur posés à la maquette. Depuis
|
||
le 2026-08-28 les **trois** portent le cercle pointillé (`estimated`) — un seul l'avait —
|
||
et une légende sous le schéma nomme les branches concernées : « seule la voiture est
|
||
mesurée à la borne ». La voiture, elle, lit la mesure réelle (`currentPower`, « non lu »
|
||
sans borne) au lieu des 3,6 kW en dur qu'elle affichait en permanence.
|
||
**Reste le vrai lot** : brancher les trois branches sur `GetLoadTelemetry.measuredW`
|
||
(relevé du jour : chauffe-eau 1500 W, PAC 800 W). C'est une refonte de l'écran d'accueil,
|
||
pas un correctif, et le banc est pris par la campagne V2C.
|
||
Ce qu'une carte de recharge dédiée pourrait dire, si elle revient un jour :
|
||
- le **mode courant**, lu par `NymeaEnergy.GetChargingInfos` et tenu à jour par
|
||
`ChargingInfoChanged` — l'écriture existe déjà et est vérifiée
|
||
(`nymea_service.setChargingInfo`, lecture → patch → réécriture complète) ;
|
||
- la **puissance mesurée** de la borne, prise sur le Thing (`currentPower`) ;
|
||
- l'**échéance** (`targetPercentage` + `endDateTime`) — mais uniquement comme **intention
|
||
saisie**, jamais comme un avancement : LM-1009 §C1. Pas de SOC véhicule (il n'existe
|
||
pas), pas de `chargeEnergy` (remis à zéro à chaque interruption), pas de courant
|
||
minimum (aucun champ), pas de `phaseCount` (la V2C ne le publie pas).
|
||
|
||
- [ ] **Le passage sur appareil doit devenir une habitude, pas un rattrapage.** Il a glissé
|
||
deux fois, et au premier passage il a trouvé deux cibles tactiles hors norme (26 px, 18 px)
|
||
qu'aucun des 129 tests unitaires ne pouvait voir. `integration_test/ui_3g2_on_device_test.dart`
|
||
est le harnais. Rappel MIUI : la confirmation d'installation est redemandée à **chaque**
|
||
fois — faire un `adb install -r -t` préalable, puis lancer le test.
|
||
|
||
## Charges pilotables — ce qui attend la box (2026-08-26)
|
||
|
||
- [x] ~~**`kCodesReserveBatterie`**~~ — **fait le 2026-08-27.** Le motif est publié :
|
||
`BATTERY_RESERVE`, params `socPercent` / `reservePercent` / `withheldW`. Les clés que le
|
||
fichier cherchait (`batteryLevel`, `threshold`) n'avaient **jamais** existé côté plugin —
|
||
le motif sortait donc en repli anglais sur le seul cas qu'aucune mesure ne révèle.
|
||
- [ ] **`minPowerW == null` sans véhicule branché** — couvert en test unitaire
|
||
(`test/ev_runtime_test.dart`), **pas exercé sur appareil** : la borne n'entre pas dans
|
||
`loads[]` avant `3g`. À reprendre quand l'arbitrage prendra la recharge en charge.
|
||
- [ ] **Réserve batterie — portée élargie.** Le jour où le seuil gouverne tout le budget,
|
||
reprendre le texte de `BatteryReserveCard` : il annonce aujourd'hui un futur, il devra
|
||
décrire un présent.
|
||
- [ ] ~~Zones — à ne pas entreprendre~~ — **décision revue le 2026-08-27** : le lot est
|
||
cadré (`docs/CADRAGE_zones_clim.md`), voir l'entrée en tête de ce fichier. `ac_screen.dart`
|
||
reste de la donnée fictive — quatre pièces, huit températures crédibles affichées comme
|
||
des mesures.
|
||
|
||
## En cours / priorité haute
|
||
|
||
- [ ] **TariffProvider — connexion RPC réelle**
|
||
- `load()` appelle encore un `Future.delayed` fictif
|
||
- Brancher sur nymea JSON-RPC pour récupérer les prix live (ENTSO-E, Tibber, etc.)
|
||
|
||
- [ ] **EnergySetupProvider — persistance**
|
||
- Les assignations de rôles (EV, PAC, batterie…) ne survivent pas au redémarrage
|
||
- Sérialiser en SharedPreferences ou JSON local
|
||
|
||
- [ ] **SchedulerProvider — exécution réelle**
|
||
- `forceRecalc()` ne fait rien pour l'instant
|
||
- Brancher sur l'API nymea Energy Scheduler (si disponible)
|
||
|
||
## Screens à implémenter
|
||
|
||
- [ ] **DeveloperScreen** — logs, introspection JSON-RPC, test ping nymea
|
||
- [ ] **AboutScreen** — version app, version nymea, licences
|
||
- [ ] **SystemSettingsScreen** — adresse serveur nymea, port, transport (TCP/WS)
|
||
|
||
## Amélioration UX
|
||
|
||
- [ ] **Timeline** — remplacer la simulation bell-curve par les vraies créneaux du scheduler nymea
|
||
- [ ] **RoleConfigFlow Step 3** — test de connexion sur RPC réel au lieu du délai simulé
|
||
- [ ] **InstallerModeProvider** — persister le hash PIN dans SharedPreferences (actuellement en mémoire)
|
||
- [ ] **AppSettingsProvider** — persister les préférences (thème, densité, écrans actifs) dans SharedPreferences
|
||
|
||
## Intégration nymea live
|
||
|
||
- [ ] Mapping `EmsRole → nymea thingClass` pour les installations réelles
|
||
- [ ] Vérifier les interfaces nymea sur serveur réel (comparer avec `docs/nymea_integrations.md`)
|
||
- [ ] `Energy.GetSchedule` / `Energy.SetSchedule` si l'API le supporte
|
||
|
||
## Technique / dette
|
||
|
||
- [ ] Ajouter des tests unitaires pour `TariffProvider` et `EnergySetupProvider`
|
||
- [ ] Gérer le cas où `NymeaService.thingClasses` est vide en mode live (classes non chargées)
|
||
- [ ] Revoir `_Step1ThingList` : passer en `context.watch` pour réactivité si les things changent
|