b298c366d8
Quatrième passe, même logique que la précédente : ce qui demande un calcul revient à Héos, pas à un formulaire. Démarrer assez tard pour arriver à 100 % juste avant la pointe suppose de savoir ce que le soleil va faire — sans prévision ça ne marche pas, et une heure saisie à la main serait un pari présenté comme un réglage. Le gain reste écrit dans la note, parce qu'il justifie que le moteur s'en occupe : pic PV de midi libéré pour l'ECS et la voiture, moins de temps passé à 100 % donc moins de vieillissement calendaire, et aucun kWh sacrifié — la même énergie, stockée plus tard. La frise du point de non-retour n'est PAS supprimée : elle remonte dans l'encart du motif commun, où elle illustre ce que les trois cas partagent au lieu d'illustrer un réglage. C'est même sa vraie place — une prévision n'engage personne, un point de non-retour si. Et l'encart gagne une distinction qui manquait : quels paramètres sont calculés (charge différée → Héos) et lesquels sont saisis (charge réseau, échéance véhicule). Le motif tient dans les deux cas, ce qui renforce l'argument : le moteur porte la forme, Héos ou l'utilisateur la remplit. L'écran de configuration batterie ne garde donc que quatre blocs : le nom, le rang en lecture, la décharge pendant recharge VE, la réserve adaptative, et la charge réseau manuelle. Quatre passes, quatre retraits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016vrTVifar2GN5rtUh89Wkq
etm_powersync_app
A new Flutter project.
Getting Started
This project is a starting point for a Flutter application.
A few resources to get you started if this is your first Flutter project:
For help getting started with Flutter development, view the online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.