Une carte pour savoir QUI limite la charge de la batterie

Le proprietaire demande comment suivre l'effet du relevement du plafond.
Verification faite : la DVCC n'apparait que dans deux tableaux de debug, et
l'ecart entre cellules comme le mode des chargeurs solaires n'apparaissent
NULLE PART — alors que ce sont exactement les trois grandeurs a regarder.

Deux capteurs modeles crees (`batterie_qui_limite.yaml`), parce que le
systeme publiait les ingredients sans jamais la grandeur :

- **Ecart entre cellules** : le BMS donne la plus haute et la plus basse,
  mais c'est leur difference qui dit si le parc est sain. 2 mV aujourd'hui,
  contre 168 mV sur l'ancien module 3 juste avant qu'il fasse effondrer le
  courant de tout le monde. C'est le garde-fou d'un relevement de plafond.
- **Chargeurs qui se retiennent** : six entites publient leur regime et
  aucune n'etait affichee, alors que c'est le seul signal DIRECT de
  ressource refusee — la puissance mesuree etant censuree par construction
  sur une installation sans injection. `off` ne compte pas : la nuit tout
  est `off` sans que rien ne soit refuse.

Carte « Charge de la batterie — qui limite ? » sur le tableau Bilan : le
courant pris face au plafond que NOUS imposons et a celui que le BMS
autorise, idem pour la tension, puis l'ecart entre cellules et les
chargeurs brides. Avec le mode d'emploi de lecture, parce qu'une carte qui
ne dit pas comment l'interpreter se lit de travers.

Nombre de modules et capacite installee du BMS volontairement absents : ils
ne comptent que le groupe maitre (4 modules, 400 Ah pour un parc de neuf).

Le paquet du concierge vehicule entre aussi dans le depot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
This commit is contained in:
Tallagrand Thierry
2026-09-13 21:04:46 +02:00
parent 43bda3df01
commit d64aef24ea
3 changed files with 197 additions and 2 deletions

63
packages/airtria_concierge.yaml Executable file
View File

@@ -0,0 +1,63 @@
# Concierge vehicule — espace de noms de l'agent Airtria (OpenClaw)
#
# Airtria detecte qu'une session de charge s'ouvre alors que l'etiquette du
# vehicule est douteuse, demande par WhatsApp au proprietaire de quelle voiture
# il s'agit, et depose ici la reponse. Le service d'historisation — seul
# proprietaire de la table `session_charge` — la lit et l'applique.
#
# ⚠️ CE PAQUET NE DOIT CONTENIR QUE DES ENTITEES `airtria_*`. C'est la
# frontiere d'ecriture de l'agent. Elle est CONVENTIONNELLE et non
# structurelle : le jeton Home Assistant qu'il porte peut techniquement
# ecrire n'importe quel service. La garantie repose donc entierement sur la
# discipline de son code — un test de portee doit echouer si une ecriture
# sort de la constante, et aucun nom d'entite ne doit etre construit
# dynamiquement.
#
# ⚠️ `max: 255` EXPLICITE. Le defaut de Home Assistant est 100, et un texte
# trop long est rejete EN SILENCE : le 08/09/2026, `evcs_balance_forecast_updated`
# etait declare a 32 et avalait les messages d'erreur de 43 caracteres — quatre
# heures quarante-cinq de panne sans une seule trace. Airtria relit l'etat
# apres chaque ecriture pour detecter un rejet.
#
# Cree le 13/09/2026.
input_boolean:
# Kill-switch cote CONSOMMATEUR. A OFF, le service d'historisation cesse
# d'appliquer les etiquettes, qu'Airtria continue ou non de publier. Meme
# role que `evcs_balance_enabled` et `evcs_advisor_enabled` : tout
# consommateur de ce projet doit pouvoir etre coupe sans toucher a son
# producteur. Pas d'`initial:` — il desactiverait la restauration d'etat et
# forcerait la valeur a chaque demarrage (piege corrige le 06/09).
airtria_concierge_enabled:
name: Airtria - Appliquer les etiquettes de vehicule
icon: mdi:car-info
input_text:
# Une confirmation humaine, en JSON, atomique :
#
# {"sessions":["2026-09-08 19:39:12.334+02","2026-09-09 01:26:04.887+02"],
# "label":"VW","confirmed_at":"2026-09-13T19:40:00+02:00","source":"whatsapp"}
#
# `sessions` est une LISTE et non une clef unique : un branchement couvre
# souvent plusieurs sessions (la cloture a 10 min coupe entre le solaire du
# soir et l'ouverture des heures creuses), et des ecritures successives sur
# un helper unique perdraient une confirmation sur deux — le service ne passe
# que toutes les 60 s et ne verrait que la derniere.
#
# Les horodatages de `sessions` sont les clefs `session_charge.debut`
# VERBATIM, millisecondes comprises. Le service joint sur une fenetre de
# ±1 s ; une valeur arrondie a la minute ne correspondrait a aucune ligne.
#
# `confirmed_at` est l'horodatage de LA VALEUR, pas du run de l'agent. Une
# valeur perimee doit pouvoir etre reconnue comme telle meme si son
# producteur tourne encore — c'est la lecon du cablage de la cible SOC,
# retire le 13/09 parce que sa garde de fraicheur datait le run.
#
# Une auto-correction est une republication avec un `confirmed_at` plus
# recent. Le helper n'est JAMAIS remis a vide : l'invalidation est
# structurelle (une clef de session perimee ne correspond a aucune ligne
# nouvelle), et le vider ouvrirait une fenetre de perte sans rien proteger.
airtria_vehicle_label:
name: Airtria - Etiquette de vehicule confirmee
max: 255
icon: mdi:label-outline