etm-powersync-app/TODO.md

TODO — ETM PowerSync App

Ouvert au 2026-08-27

• 🔴 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 — il ne reste que la trace. 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 de validation en cours produit le cas qui lève la réserve — chargeEnergy à zéro, sessionEnergy qui continue. Aucun avancement affiché avant cette trace (LM-1009 §C1).

• 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é.

• ⏳ 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.

• 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.

• 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)

• 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