7a26078e730d3647c2ba4bc70ff043a7d8034118
Le correctif precedent bloque l incident de 19:44, mais un excedent proche de zero est ambigu : c est la signature de la censure ET celle de l equilibre de fin de journee. Le releve du 03/09 contient les deux avec le meme excedent — 18:50 : +14 W, ressource refusee ; 19:41 : +1 W, plus rien a donner. Rejeu du 19:41 : batteryAssistSolarStartOk etait encore vrai. Trois minutes avant l incident, le systeme aurait commis la meme faute. Le plan annoncait de lire evcs_balance_pv_censored. Lecture de CENSORSHIP.js : ce drapeau est un OU de motifs dont l un est exactement le proxy qu on voulait remplacer (socPct >= 90 et batterie sans puits). Et il est reste ON jusqu au calcul de 19:50, soit cinq minutes APRES le demarrage de la charge — ce qui l a fait basculer n est pas la censure mais sun_elevation passant sous 10 degres. Il n aurait pas bloque l incident. Le signal juste, ce sont les chargeurs eux-memes : sept entites sensor.*_mppt_operation_mode, jamais lues par aucun workflow. mppt_active = je suis a mon point de puissance maximale, je donne tout ; voltage_current_limited ou off = je me retiens faute de preneur. Le 03/09 elles ont bascule a 19:20, soit 24 minutes avant pv_censored, sans aucun proxy et a la cadence de la boucle. Contre-verification le 01/09 a 14:22 : les trackers restaient limites PENDANT une charge de 3,4 kW sous 6,9 kW de PV, donc le signal ne s auto-annule pas a midi. Collecte sans aucun entity_id code en dur (selectattr sur mppt et operation_mode), expression testee sur /api/template puis gabarit complet re-rendu : 191 champs, JSON valide, aucun null. Lectures inexploitables ecartees, et repli sur le comportement anterieur quand il n en reste aucune. Garde de DEMARRAGE uniquement, structurellement : la lier au sourceMode ou au maintien ferait que la charge, en donnant un preneur au MPPT, detruirait sa propre condition d autorisation — le bistable de l abondance P6 corrige le 24/08. Golden 64 -> 66. Mutation dans trois directions : garde neutralisee -> 1 echec cible, provocation toujours refusee -> 3 echecs, lecture illisible traitee comme "a fond" -> 1 echec sur le scenario de repli. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Description
gestion de la borne de charge avec HA et N8N
Languages
JavaScript
90.2%
Python
7.3%
Smarty
1.9%
Shell
0.6%