La consigne de repos absorbe les a-coups de la plaque

Valeurs negatives au point de raccordement, contacteur ferme. La mesure separe
deux phenomenes que rien ne reliait.

Le premier est bien la plaque qui cycle : sur la fenetre de midi, 9 % des
echantillons negatifs, minimum -477 W, mediane -146. Le regulateur ne rattrape
pas un delestage brutal d un kilowatt avec une consigne de repos a 200 W. Elle
passe a 700 : la courbe monte de 500 W et le minimum devient +23 W. Le surcout
va dans le bon sens, cette consigne ne s appliquant que contacteur ferme sans
session reseau — c est-a-dire apres une coupure sur SOC bas ou une fermeture
par la regle de protection, deux cas ou l on veut justement que le reseau
contribue davantage.

Le second, -2819 W pendant deux minutes, n a rien a voir : le debranchement du
vehicule a supprime 2,2 kW d un coup alors que la batterie a 93 % n absorbait
rien et que le MPPT produisait 4 kW. Aucune consigne n absorbe cela. Ce qui l
evite est le correctif du matin sur la regle de protection : la demande sur le
parc valait 741 W, le contacteur n aurait pas ete ferme, et sans reseau il n y
a rien ou injecter.

Golden 80/80, trois attendus mis a jour avec la mesure en commentaire.

Et docker n est pas dans le PATH d une session SSH sur DSM : les commandes de
deploiement appellent desormais /usr/local/bin/docker.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

deploy/historisation/README.md

@@ -1,5 +1,13 @@
 # Mémoire de mesures EVCS
 
+> ⚠️ **Sur le Synology, `docker` n'est PAS dans le `PATH` d'une session SSH.**
+> Il vit dans `/usr/local/bin/docker`, et DSM ne le met dans le chemin que pour
+> les sessions interactives de l'interface. Toute commande lancee a distance
+> doit donc l'appeler par son chemin complet, sinon elle echoue sur
+> `sudo: docker: command not found` — constate le 06/09/2026.
+> Depuis un terminal DSM ouvert a la main, `docker compose ...` suffit.
+
+
 Deux bases sur **10.10.10.22**, décidées le 04/09/2026 : on met les deux en
 service et on décide à l'usage s'il faut garder les deux.
 
@@ -24,8 +32,8 @@ libres.
 ```sh
 cd /volume2/projects/EVCS/EVCS/deploy/historisation
 bash preparer-env.sh      # génère .env avec des secrets aléatoires
-docker compose up -d
-docker compose logs -f
+/usr/local/bin/docker compose up -d
+/usr/local/bin/docker compose logs -f
 ```
 
 ### D'où viennent les secrets
@@ -49,9 +57,9 @@ d'attendre les anciens.
 Vérifications :
 
 ```sh
-docker compose exec postgres psql -U evcs -d evcs -c '\dt'
+/usr/local/bin/docker compose exec postgres psql -U evcs -d evcs -c '\dt'
 curl -s http://10.10.10.22:8086/health
-docker compose logs historisation --tail 5
+/usr/local/bin/docker compose logs historisation --tail 5
 ```
 
 ### Ports : 5433, et pas 5432
@@ -129,7 +137,7 @@ se corrige d'elle-même.
 besoin d'un `INSERT` sur cette seule table :
 
 ```sh
-sudo docker compose exec -T postgres psql -U evcs -d evcs -c \
+sudo /usr/local/bin/docker compose exec -T postgres psql -U evcs -d evcs -c \
 "GRANT INSERT ON evenement TO evcs_lecture;
  GRANT USAGE, SELECT ON SEQUENCE evenement_id_seq TO evcs_lecture;"
 ```
@@ -197,8 +205,8 @@ bien meilleure.
 ```bash
 cd /volume2/projects/EVCS/EVCS/deploy/historisation
 bash preparer-grafana.sh          # génère le mot de passe admin, l'affiche une fois
-sudo docker compose up -d grafana
-sudo docker compose logs -f grafana
+sudo /usr/local/bin/docker compose up -d grafana
+sudo /usr/local/bin/docker compose logs -f grafana
 ```
 
 ⚠️ **`sudo` est obligatoire sur DSM** : l'utilisateur ordinaire n'a pas accès
@@ -296,8 +304,8 @@ s'est vu qu'au journal du conteneur.
 **Et après tout déploiement du service :**
 
 ```bash
-sudo docker compose restart historisation
-sudo docker compose logs --since 2m historisation
+sudo /usr/local/bin/docker compose restart historisation
+sudo /usr/local/bin/docker compose logs --since 2m historisation
 ```
 
 ⚠️ **`--since`, pas `--tail`.** Le service ne journalise que lorsqu'il a écrit