EVCS/docs/CHANTIER_BILAN_ENERGETIQUE.md

Chantier — Bilan énergétique partagé

Journal de bord du chantier ouvert le 24/08/2026. Documentation définitive à écrire à la fin ; ce fichier ne sert qu'à ne rien perdre en route.

Pourquoi ce chantier

Constat du propriétaire, 24/08/2026 : « nous avons essayé de résoudre un défaut de stratégie par une suite de solutions tactiques ». Trois oscillateurs identifiés le même jour (règle de coupure EDF « Fix G », override d'abondance P6 qui détruisait sa propre condition d'autorisation, inversion des planchers de démarrage et de maintien) — tous de la même nature : des seuils empilés par couches successives, chacun défendable isolément, dont personne ne vérifiait la cohérence d'ensemble. Chaque correctif créait l'oscillateur suivant.

Toute valeur fixe est traitée comme une erreur de conception, pas comme un réglage à affiner.

Décisions actées

Sujet	Décision
Profil horaire	Recalculé une fois par jour, publié dans des helpers. Pas de recalcul dans la boucle 30 s.
Prudence	Percentile 20, appliqué une seule fois sur le bilan net (PV − conso par heure et par jour), jamais séparément sur chaque terme — sinon on cumule deux pessimismes et le déficit passe à 109 % de la batterie, système inutilisable.
SOC	Lissé pour les décisions de pilotage, valeur instantanée conservée pour les planchers de sécurité.
Consommation	Mesurée, jamais supposée. Filtrage contextuel. Mesure non biaisée.
Production PV	Jamais la mesure brute. Sans injection, PV_mesurée = min(ressource, conso + absorption batterie) : observation censurée dès que la batterie est pleine. Estimateur = prévision, recalée uniquement sur les heures non censurées.
Rétention historique	recorder.purge_keep_days = 90 (appliqué le 24/08, redémarrage HA fait). Les statistiques long terme étaient déjà sans limite.
Conseiller IA	Les faits restent arithmétiques et déterministes ; l'advisor traite les hypothèses (facteur de confiance sur la prévision, lecture des états et alarmes, explication). Montée en pouvoir en trois paliers, sur un score de prédiction vérifié contre la mesure.

Sorties attendues du bilan

Heure de croisement PV/conso · énergie à couvrir d'ici là · niveau de batterie requis (remplace grid_soc_off fixe) · marge disponible pour le véhicule · drapeau « production actuellement bridée » · drapeau de santé des mesures.

Objectif ajouté le 24/08 : dimensionner le stockage. Le propriétaire vise l'autonomie et veut savoir combien de batteries ajouter. La ressource gaspillée par la censure est précisément l'énergie qu'un stockage supplémentaire capterait : le bilan doit donc produire, en plus, une estimation de l'énergie perdue par manque de puits et le gain attendu par kWh de batterie ajouté. Cela impose une simulation multi-jours sur la ressource décensurée — c'est l'étape 3 qui la rend possible.

Constat mesuré sur 27 jours (28/07 → 24/08)

Grandeur	Moyenne / jour
Production PV (censurée, donc minorée)	38,7 kWh
Consommation totale	43,1 kWh (dont véhicule 10,0)
Décharge batterie	11,5 kWh (p90 14,3 · max 16,1 sur 17,5 utiles)
Import réseau	7,83 kWh — un seul jour sur 27 à zéro

La batterie se vide presque intégralement chaque jour : c'est elle le facteur limitant, pas la puissance des onduleurs.

Parc batterie réel (précisé le 24/08)

8 Pylontech US2000C en deux packs de 4 avec un hub, le premier pack ayant deux ans de plus que le second. Un module est en panne et isolé : le système tourne actuellement sur 7, et un huitième commence à faiblir. Le vieux pack a vécu avant la climatisation du garage. Mélanger des packs d'âges différents est déconseillé — contrainte de budget, pas choix technique.

Conséquence directe sur le code : batteryUsableCapacityKwh: 17.5 est codé en dur dans INPUT_PARSE.js et utilisé trois fois dans WINDOWS_SOURCEV2.js (tampon de prévision, SOC projeté en fin de journée, cible du matin). Avec 7 modules dont un fatigué, la capacité réelle est plutôt de l'ordre de 14-15 kWh : le contrôleur surestime sa réserve d'environ 15 à 20 %. Aucun capteur de capacité ou de santé batterie n'existe côté HA — à publier depuis le BMS pour que cette valeur cesse d'être une constante.

Énergie perdue faute de puits — et pourquoi le recalage de la prévision échoue

Première estimation, avec un facteur de recalage global : 23,9 kWh/jour, 38 % de la ressource. Chiffre faux. Le facteur global valait 1,22 mais il est dominé par les heures de 8-9 h, où le recalage ressort à 4 voire 7 : la prévision sous-estime massivement la rampe du matin. Or ces heures sont sur-représentées parmi les heures exploitables, puisque la batterie y est toujours vide.

Le problème est structurel : la censure est corrélée au beau temps. Les heures exploitables de l'après-midi ne le sont que les jours médiocres — d'où un recalage qui tombe à 0,24 l'après-midi, avec 1 à 5 échantillons. Les données manquantes ne le sont pas au hasard, donc aucun facteur de recalage appris sur cet échantillon n'est transportable. Cela invalide le plan initial de l'étape 3.

Estimation retenue à la place, borne basse : pour chaque heure censurée, potentiel = min(prévision brute, enveloppe horaire réellement démontrée). Ne suppose aucun recalage et ne dépasse jamais ce que l'installation a déjà produit à cette heure-là.

Perte par manque de puits (borne basse)
Moyenne	11,8 kWh/jour (23 % de la ressource)
Médiane · p80 · max	10,8 · 19,5 · 25,6 kWh
Jours sans perte	2 sur 27

Le résultat qui tranche la question du dimensionnement : on jette plus (11,8) qu'on n'importe (7,83). L'énergie existe déjà, il manque le réservoir et la capacité à l'encaisser. Un ajout d'environ +8 kWh utiles est donc à la fois nécessaire (côté demande) et remplissable (côté ressource). Réserve : chiffres d'août ; l'historique de prévision remonte au 2 mars et permettra de refaire le calcul en saison basse.

Avancement

• Étape 1 — détection de la censure (24/08). src/energy-balance/ : snapshot HA de 26 champs incluant les signaux jamais lus (états MPPT, état VE.Bus, alarme de surcharge, ESS BatteryLife, état du bus DC, statut natif de la borne, prévision horaire) et nœud CENSORSHIP.js qui qualifie chaque échantillon. Suite tests/energy-balance/ : 10 scénarios, dont un snapshot réel du 24/08 14:29 correctement classé censuré. Mesure sur l'historique : 48 % des heures de jour sont censurées, 77 à 96 % à partir de 13 h.

• Étape 2 — profil de consommation mesuré (24/08). src/energy-balance/CONSUMPTION_PROFILE.js : compteurs d'énergie cumulés → deltas horaires → distribution par heure de la journée → percentiles. Validé sur 28 jours réels (639 heures, aucun compteur remis à zéro) : consommation typique 31,9 kWh/jour hors véhicule, 42,8 kWh au p80. Le profil tient dans un helper input_text (119 caractères sur 255). Vérification préalable de la méthode : seulement 7,8 % des heures de déficit sont censurées — censure et déficit sont physiquement presque exclusifs (une heure censurée est une heure où la batterie n'avait plus de place, donc une heure de surplus). La grandeur qui pilote la décision EDF est donc mesurée sur des données propres.

• Étape 3 — estimateur de ressource PV (24/08). src/energy-balance/RESOURCE_ESTIMATE.js. Deux approches essayées et écartées, documentées dans l'en-tête du nœud :

  1. Recalage de la prévision — impossible, la censure est corrélée au beau temps (facteur 4,29 à 9 h sur 27 échantillons, 0,48 à 15 h sur 3).
  2. Forme issue de la géométrie solaire — un plan unique ajusté sur les heures propres converge sur « plein est, 20° » et prédit 2,0 % de la journée à 18 h contre 5,8 % mesurés. Le champ a plusieurs orientations (trois trackers) qu'un plan unique ne représente pas.

  Retenu : forme = enveloppe horaire démontrée (comportement réel du champ, orientations multiples comprises, sans modèle) × magnitude = prévision Forecast.Solar (météo, insensible à l'état de notre batterie). Le nœud publie un indice de confiance par heure : l'enveloppe de l'après-midi étant elle-même censurée, elle est signalée « minorée » au lieu d'être présentée comme fiable. Sans enveloppe fournie, le nœud se déclare inutilisable plutôt que d'inventer une forme. Suite portée à 17 scénarios.

• DÉFAUT TROUVÉ — orientation Forecast.Solar mal déclarée. Forme prévue contre forme mesurée, en part de la journée : matin 07-11 h 15,1 % prévus contre 39,3 % réels ; après-midi 14-18 h 52,1 % prévus contre 35,2 %. La prévision attend une journée orientée l'après-midi, l'installation produit le matin. Les totaux journaliers restent à peu près justes, mais la répartition intra-journalière est inutilisable — ce qui dégrade toutes les décisions fondées sur la prévision (EVCS, chauffe-eau, conseiller IA). À corriger dans la configuration de l'intégration (azimut et inclinaison par plan), puis refaire la comparaison.

• Étape 4 — le bilan (24/08). src/energy-balance/BALANCE.js. Ne pilote rien : publie les faits qui remplacent les seuils fixes — heure de croisement, énergie à couvrir, SOC requis (remplaçant de grid_soc_off), énergie réseau strictement nécessaire, surplus disponible pour le véhicule, indice de confiance. Sans une de ses entrées, il se déclare inutilisable et les contrôleurs gardent leurs règles.

  Deux niveaux de prudence, et c'est un choix de conception, pas un détail. Le premier jet n'utilisait que le profil prudent (p80) et exigeait 48 % de SOC pour franchir la matinée du 24/08 — alors que le seuil fixe de 30 % aurait été moins coûteux. Un bilan plus gourmand que le seuil bête qu'il remplace n'a aucun intérêt. Corrigé : la décision réseau, réévaluée à chaque cycle et réversible, utilise le profil typique (p50) ; le profil prudent (p80) sert à la planification qui engage plusieurs heures (cible de nuit, dimensionnement du stockage). Se tromper par optimisme ne coûte qu'un démarrage réseau une heure plus tard, le plancher dur protégeant la batterie ; se tromper par excès de prudence coûte un import réseau immédiat et réel.

  Vérifié aussi : la marge de sécurité de 10 % que j'avais ajoutée était une constante arbitraire de plus, et un double comptage. Mesure du 24/08 : p80(somme des heures) égale somme(p80 par heure) sur toutes les fenêtres testées — les heures de consommation sont fortement corrélées. La prudence est donc entièrement portée par le percentile, qui est mesuré. Marge supprimée.

  Rejeu de la matinée du 24/08 (scénario figé) — SOC réel 21 %, capacité 15 kWh, production horaire réellement mesurée :

  Croisement PV/consommation	08 h
  Énergie à couvrir	0,82 kWh (calcul manuel sur les mesures : 0,80)
  SOC requis (décision)	27,5 % au lieu du seuil fixe de 30 %
  Réseau nécessaire	oui, 0,97 kWh — une session, puis terminé
  SOC requis (planification, p80)	38,1 %
  Déficit calculé sur forme fiable	oui

  Suite portée à 21 scénarios.

• Étape 5 — publication en mode ombre (24/08). Workflow n8n EVCS Energy Balance V1 (QoSfPeyGq35orF1K), actif, cycle 5 min. Périmètre d'écriture garanti par test de mutation : l'injection d'un turn_on sur switch.edf_general_ok_switch fait rougir la suite. Kill-switch input_boolean.evcs_balance_enabled.

• Étape 5b — recalcul quotidien des profils (24/08). Workflow EVCS Energy Profiles Daily V1 (N6UaB4ZozsbRPrFb), actif, 03:30. Lit /api/history/period et republie les quatre CSV. ⚠️ Piège trouvé : sans end_time, l'API ne renvoie qu'UNE journée, en silence. Mes trois premières mesures « sur 3 jours » n'en couvraient qu'une. Refus explicite d'écraser les profils si l'historique ne couvre pas les 24 h. Validation croisée : profils calculés depuis l'API REST (états bruts, 11 jours) contre profils calculés depuis les statistiques long terme (28 jours) → 0,20 kWh/h d'écart absolu moyen, deux chemins de données totalement indépendants.

• Étape 5c — prochaine fenêtre de déficit (24/08). Le bilan ne répondait qu'à « combien jusqu'à ce que le solaire prenne le relais » : à 15 h la réponse est zéro, exacte mais inutile, car le déficit qui approche est celui de la nuit. Ajout de la prochaine traversée déficitaire — heure de début, énergie, SOC à atteindre avant. Ce SOC n'est volontairement pas écrêté à 100 % : au-delà, même une batterie pleine ne passe pas, et l'écart est publié comme storage_shortfall_kwh. C'est le chiffre du dimensionnement du stockage.

• Étape 6 — tableau de bord (24/08). Dashboard YAML dédié bilan-energetique (icône balance, barre latérale), copie versionnée dans dashboards/bilan_energetique.yaml du dépôt. Vue Bilan : la comparaison seuil calculé / seuil fixe / SOC réel avec son commentaire automatique, la décision immédiate, la prochaine traversée déficitaire, une alerte conditionnelle quand le stockage est insuffisant, l'état de bridage de la production, et deux graphiques d'historique (SOC contre seuils, bridage contre réseau EDF). Vue Profils & réglages : le tableau horaire des quatre profils avec le taux de censure par heure, la capacité batterie (modifiable), le kill-switch. Déclaré dans configuration.yaml (sauvegarde dans SAVE_CONFIG/), redémarrage HA effectué, aucune erreur au journal.

Modèle solaire local : tentative abandonnée (25/08)

Objectif : produire la forme horaire à partir de la géométrie et des quatre orientations réelles, pour éviter un abonnement Forecast.Solar. Abandonné, pour trois raisons qui se cumulent.

Découverte utile au passage : les entrées MPPT sont mesurées séparément et la correspondance est établie — sensor.airtria_mppt1_yield_today = les 10 PV sud-est (pic à 11 h), sensor.v1_yield_today = les 3 PV du suiveur (pic à 9 h), tracker_solar_1/2/3 du RS 450/200 = les trois strings sud (pics 13-14 h), tracker_solar_4 = le string ouest (longue traîne jusqu'à 19 h). Chaque plan peut donc être confronté à sa propre mesure — c'est ce qui a permis de trancher.

1. Seules 4 heures de la journée sont exploitables. Taux de censure : 08 h 0 %, 09 h 0 %, 10 h 4 %, 11 h 4 %, puis 12 h 59 %, 13 h 77 %, 14 h 81 %. Ajuster une forme journalière sur quatre heures propres n'est pas sérieux.
2. L'enveloppe n'est pas une courbe de journée valide. C'est le maximum horaire pris indépendamment sur des jours différents : le pic de 8 h vient d'un jour, celui de 11 h d'un autre. Le résultat est plus plat que n'importe quelle journée réelle. Comparer un modèle de journée à cette référence n'a pas de sens. (Limitation qui vaut aussi, au second ordre, pour l'usage de l'enveloppe comme forme dans RESOURCE_ESTIMATE — atténuée par le fait qu'elle y est renormalisée sur la prévision du jour.)
3. Le modèle a besoin de paramètres non ajustables sur ces données. Un modèle direct seul prédit zéro production le matin sur le plan ouest, alors que la mesure donne 14 % à 9 h : il manquait le rayonnement diffus. Ajouté, sa fraction part en butée de l'intervalle de recherche sans jamais converger — le modèle reste trop piqué sur midi par rapport à la mesure, et ce pour les quatre plans à la fois.

Conséquence : l'abonnement Forecast.Solar Professional (souscrit le 24/08, 70 €/an, 14 jours d'essai) est le bon choix, et pour une raison que je n'avais pas identifiée en le déconseillant. Avec la clé d'API, n8n interrogera directement api.forecast.solar et obtiendra la courbe horaire complète (watt_hours_period) pour les trois plans — ce que l'intégration HA n'expose pas, même abonnée, puisqu'elle ne publie que quatre capteurs résumés.

Cette courbe remplacera à la fois la forme (enveloppe) et la magnitude (capteurs) dans RESOURCE_ESTIMATE, ce qui simplifiera le nœud au lieu de le compliquer. Les plans à déclarer : sud-est 135°/40°/4030 W (suiveur fusionné, 930 W), sud 180°/35°/9300 W, ouest 270°/45°/2790 W.

Validation des trois plans (25/08) — et correction d'un chiffre que j'ai trop cité

Configuration appliquée : trois plans (sud-est+suiveur 135°/40°/4030 W, sud 180°/35°/9300 W, ouest 270°/45°/2790 W), inverter_size 8000 → 11000, clé d'API Professional en place. La prévision du jour passe de 30,2 à 43,5 kWh. Aucune erreur au journal.

⚠️ L'API doit être appelée avec sa propre convention d'azimut : 0 = sud, −90 = est, +90 = ouest, soit azimut_API = azimut_HA − 180. Et les plans multiples s'écrivent en triplets successifs dans le chemin (/dec1/az1/kwp1/dec2/az2/kwp2/...), pas en listes séparées par des virgules — celles-ci renvoient une erreur 422.

Résultat du test. Forme ciel clair contre enveloppe mesurée : matin 07-11 h 21,4 % contre 39,3 % mesurés (c'était 15,1 % avant correction) ; après-midi 14-18 h 50,6 % contre 35,2 %. L'écart absolu moyen tombe de ~4,5 à 2,53 points. Amélioration nette, mais l'écart ne se referme pas.

Et c'est ma référence qui est en cause. Confrontation plan par plan, chacun contre son propre MPPT, sur les 4 heures à censure ≤ 4 % : le modèle ciel clair de Forecast.Solar sous-estime 8 h et surestime 11 h — exactement le même biais, et de même ampleur, que mon modèle géométrique local. Deux modèles indépendants s'accordent entre eux et divergent de l'enveloppe : le plus probable est que l'enveloppe ait tort.

Mécanisme : l'enveloppe est un maximum horaire pris sur des jours différents. Le rapport max/moyenne est plus grand le matin que le midi (une matinée claire et une matinée de brume diffèrent bien plus que deux midis), donc l'enveloppe surpondère structurellement le matin.

Correction assumée : le « 39,3 % du matin mesurés » que j'ai cité toute la journée comme preuve du défaut de configuration était lui-même gonflé. Le défaut était réel — un seul plan plein sud, 15 kWp, plafonné à 8 kW — mais j'en ai surestimé l'ampleur en le mesurant contre une référence biaisée.

Conséquence appliquée le 25/08 : RESOURCE_ESTIMATE lit désormais la courbe horaire de l'API, publiée par le workflow EVCS Solar Forecast V1 (07P8I349ugna9FH4, 15 min). Elle apporte forme et magnitude d'un seul tenant, sur 6 jours, avec les trois plans réels, sans aucune censure — le nœud s'en trouve simplifié : plus de répartition au prorata, plus de renormalisation.

L'enveloppe est rétrogradée en repli : elle sert encore si la courbe est absente ou vieille de plus d'une heure, et le champ mode dit laquelle des deux a servi (courbe_horaire_api ou repli_enveloppe). Elle garde par ailleurs un rôle de repère de vraisemblance, sans écrêtage : étant minorée l'après-midi, elle tronquerait à tort une prévision correcte.

25/08/2026 — Première nuit observée, et le défaut qu'elle a révélé

Ce que la nuit a fait

Heure	Événement
01:24	Fenêtre HC : EDF ON, charge du véhicule (P7)
02:42	Fin de charge détectée → night_recovery_done_idle, EDF coupé en 3 s
02:44 → 02:45	Véhicule débranché puis rebranché (93 s)
02:47 → 04:25	Seconde charge, 98 min ; puis EDF coupé
06:22 → 06:49	EDF rallumé, batterie 33 → 35 %, coupé
07:02 → 07:27	EDF rallumé, batterie 33 → 35 %, coupé

Import réseau : 12,30 kWh, dont 11,11 kWh entre 01 h et 04 h pour les véhicules (l'EVCS en a pris 9,57) et 1,19 kWh entre 06 h et 07 h sans aucun véhicule en charge.

Les mécanismes de fin de charge ont fonctionné : détection franche à 02:42, coupure immédiate, et P11 a correctement remis à zéro la mémoire « plein » au rebranchement de 02:45 — le second véhicule a bien été rechargé.

Le quatrième oscillateur

Les deux cycles de 06:22 et 07:02 sont un oscillateur de plus, de la même famille que les trois du 24/08. La cible du matin (batteryMorningTargetPct = 35 %) libère le takeover à SOC > cible et le réarme à SOC ≤ cible − 2. Entre 33 et 35 %, avec une maison qui tire ~0,7 kWh/h et une production encore nulle, la batterie traverse la bande en une vingtaine de minutes : période mesurée ~35 min, deux cycles complets.

Ce n'est pas le seuil grid_soc_off de l'hystérésis (30 %) : à 33 % il n'était pas en cause. C'est la cible du matin de l'EVCS. Et 35 % est une valeur de table (règle « prévision forte → 35 »), pas un besoin calculé — le bilan, une fois corrigé, demandait 31 %.

Le défaut de mesure que cette nuit a mis au jour

Le bilan annonçait à 06 h qu'il fallait 3,37 kWh pour tenir jusqu'au croisement. La consommation réelle sur cette tranche a été de 2,2 kWh, la production de 0,85 : 1,35 kWh. Deux fois et demie trop.

L'erreur ne venait pas du modèle mais de l'attribution horaire. bucketHourly garde la dernière valeur de chaque heure ; le delta entre H−1 et H est donc l'énergie dépensée pendant H. deltaSeries le rangeait sous H−1.

Sur un compteur qui émet en continu, cela décale le profil d'une heure — gênant, pas grave. Mais les compteurs de cette installation sont épars : ac_in_1_to_ac_out ne peuple que 57 heures sur 267, evcs_total 57 sur 264, parce qu'ils n'émettent que lorsqu'ils avancent. Une heure vide veut dire « valeur inchangée », donc zéro énergie : toute l'énergie d'un intervalle à trou a été consommée pendant l'heure finale, celle qui a réveillé le compteur. Rangée sous l'heure initiale, elle atterrissait n'importe où.

Mesuré : consumption_p50[8] = 2,90 kWh/h pour 0,80 réellement consommé. Six échantillons sur douze portaient un delta étalé sur 17 heures — l'import réseau de la nuit suivante, déposé sur la dernière heure de la nuit précédente. Le profil du matin était ainsi gonflé de l'import qu'il servait justement à éviter : le bilan réclamait du réseau parce qu'il avait pris du réseau la veille.

Corrigé : le delta se range sous hours[i]. Profil du matin après correction — 0,7 kWh/h de 01 h à 07 h, 0,8 à 08 h — conforme aux 0,74 kWh/h mesurés ce matin-là. Avec ce profil, le bilan aurait demandé 31 % à 06 h contre 34 % réels : pas de réseau. Sans les 1,19 kWh importés, la batterie serait descendue à ~24 %, au-dessus du plancher dur de 22 % — mais de 2 points seulement.

Troisième correction du même chiffre. L'enveloppe de production subissait le même décalage : la part matinale de la production était donc surestimée une troisième fois, après le plafond inverter_size et après le biais max/moyenne de l'enveloppe. Le pic de l'enveloppe passe de 11 h à 12 h. Aucune conclusion du chantier ne change, mais le chiffre « 39,3 % du matin » doit être considéré comme définitivement abandonné.

Statut degrade

La nuit précédant la mise en service de la courbe horaire, le bilan a publié un SOC requis de 100 % avec un statut ok, faute de croisement trouvé sur l'horizon. Il publie désormais degrade dans ce cas et quand les heures de déficit reposent sur une forme minorée : les chiffres restent visibles, mais plus présentés comme fiables. Un futur câblage ne pourra pas s'y fier par inadvertance.

Ce que la prévision, elle, a très bien fait

Courbe horaire Forecast.Solar contre production mesurée, ce matin :

Heure	Prévu	Mesuré
07 h	0,08 kWh	0,10 kWh
08 h	0,85 kWh	0,75 kWh
09 h	3,07 kWh	2,72 kWh

Les trois plans réels et l'abonnement Professional donnent une ressource utilisable telle quelle. Le côté production du bilan est fiable ; c'était le côté consommation qui mentait.

Suite

Le candidat évident au prochain câblage réel n'est plus l'hystérésis mais la cible SOC du matin : c'est elle qui a coûté 1,19 kWh cette nuit, et le toggle qui permettrait de la piloter existe déjà (input_boolean.evcs_advisor_apply_night_target). À décider après quelques nuits d'observation du seuil calculé contre le seuil de table.

⚠️ Ce toggle porte initial: off dans son package : tout redémarrage de Home Assistant le repositionne à OFF, quelle que soit la valeur choisie par l'utilisateur. C'est voulu pour un câblage réel en période d'essai, mais il faut le savoir — et le retirer le jour où le câblage sera adopté.

Backlog

• Doublon unique_id: victron_vebus_dc_power — déclaré deux fois, avec deux topics différents : configuration.yaml:99 (system/0/Dc/Vebus/Power) et packages/victron_vebus_mqtt.yaml:63 (vebus/276/Dc/0/Power). Vérifié le 24/08 : les deux publient la même grandeur — un système VE.Bus en parallèle n'expose qu'une seule instance D-Bus couvrant les deux onduleurs. Ce n'est donc pas un défaut de données, seulement une ligne ERROR à chaque démarrage et un fichier qui ment sur ce qu'il fait. Supprimer les lignes 62-68 du package, garder celle de configuration.yaml (nom conforme à l'entity_id utilisé par INPUT_PARSE), puis mqtt.reload — pas besoin de redémarrer.
• evcsDedicatedMaxW: 4900 codé en dur dans INPUT_PARSE.js, appliqué dès qu'EDF est absent (plafond ~20 A). Encore une valeur au jugé : à confronter à la réalité du câblage du circuit dédié avant de la garder ou de la remplacer par un helper.
• Alarmes jamais lues : sensor.airtria_mpii_v1_overload_alarm, alarme « High charge current » du Battery Monitor (observée active le 24/08), sensor.gx_device_ess_batterylife_state (peut imposer sa propre limite de décharge à l'insu du contrôleur), sensor.evcs_hq2239dnt7p_status.
• États MPPT jamais lus (sensor.airtria_mppt1_state, sensor.mppt_450_200_hq2449yr9pt_state) — indispensables : ils disent si un échantillon de production est exploitable ou censuré.
• Contrôle de vraisemblance PV + VE.Bus = batterie — vérifié à 95 W près le 24/08 (~9 %). À intégrer comme drapeau de santé permanent : le jour où l'identité diverge, un capteur ment.
• États zombies stop_source_lost / idle_wait_source — noms transitoires peu lisibles dans le journal et le tableau de bord (cf. HANDOFF §24, hors périmètre à l'époque).