EVCS/deploy/historisation/README.md

# Mémoire de mesures EVCS

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.

| | rôle | source | résolution |
|---|---|---|---|
| **PostgreSQL** | ce que n8n **calcule** — bilan, décisions, prévisions publiées | workflows n8n | cadence des workflows |
| **InfluxDB** | ce que Home Assistant **observe** — tous les états du périmètre énergie | intégration HA | chaque changement d'état |

Le raisonnement complet et le comparatif : `HANDOFF.md` §42 et suivantes.

## Pourquoi pas sur 10.10.10.17

Cette machine porte déjà Home Assistant, n8n, openclaw et open-webui. Une
mémoire hébergée par la machine dont elle documente les pannes ne survit pas à
celles-ci. Le volume n'est pas l'argument : les deux Synology ont des téraoctets
libres.

## Mise en service

### 1. Les deux bases (à faire sur 10.10.10.22)

```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
```

### D'où viennent les secrets

| secret | origine |
|---|---|
| `HA_TOKEN` | **existe déjà** — repris du `.env` à la racine du dépôt |
| `POSTGRES_PASSWORD` | **créé ici** — la base n'existe pas encore, ce fichier décide de son mot de passe |
| `DOCKER_INFLUXDB_INIT_PASSWORD` | **créé ici**, idem (InfluxDB exige au moins 8 caractères) |
| `DOCKER_INFLUXDB_INIT_ADMIN_TOKEN` | **créé ici** — c'est le jeton que Home Assistant utilisera pour écrire |

Aucun ne s'obtient auprès de quelqu'un, et aucun ne doit être choisi à la main :
personne ne les tape jamais — les conteneurs les lisent dans `.env`, et Home
Assistant lit le jeton dans son propre `secrets.yaml`. Une phrase inventée est
plus courte et plus devinable qu'elle n'en a l'air ; `openssl rand` ne l'est pas.

`preparer-env.sh` refuse d'écraser un `.env` existant : régénérer les mots de
passe d'une base déjà créée la rendrait inaccessible, puisqu'elle continuerait
d'attendre les anciens.

Vérifications :

```sh
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
```

### Ports : 5433, et pas 5432

DSM fait tourner **son propre PostgreSQL sur 5432**, pour ses services internes.
Notre base est donc publiée sur **5433**. Ce port ne sert qu'à l'analyse depuis
un poste de travail :

```sh
psql -h 10.10.10.22 -p 5433 -U evcs -d evcs
```

Les trois conteneurs, eux, se parlent par le réseau interne du compose et par
nom de service (`postgres:5432`) — ni adresse IP en dur, ni dépendance au port
publié. Vérifier ce qui occupe un port avant de conclure :

```sh
sudo ss -lntp | grep -E '5432|5433|8086'
```

Le schéma (`schema.sql`) est appliqué **une seule fois**, à la création de la
base. Pour le faire évoluer ensuite, écrire une migration et la passer à `psql` :
recréer le volume effacerait l'historique, ce qui est précisément ce qu'on
cherche à ne plus faire.

### 2. Brancher Home Assistant sur InfluxDB

⚠️ **Demande un redémarrage de Home Assistant**, pendant lequel le contrôleur
EVCS ne décide plus rien. **Jamais entre 01:24 et 07:24**, ni pendant une charge.
Le bon créneau est le milieu de matinée.

1. mettre le jeton dans `secrets.yaml` sous la clé `influxdb_token` ;
2. coller le bloc de `ha-influxdb.yaml` dans `configuration.yaml` ;
3. `homeassistant.check_config`, puis redémarrer.

### 3. Alimenter PostgreSQL depuis n8n

À faire après l'étape 1 — n8n a besoin que la base existe pour qu'on y crée
l'identifiant de connexion.

## Accès en lecture pour l'analyse

```sh
sudo bash creer-role-lecture.sh
```

Crée le rôle `evcs_lecture` en **lecture seule** et dépose son mot de passe dans
le `.env` à la racine du dépôt. Le mot de passe est généré, jamais choisi, et
**n'est pas affiché** : il va du générateur au fichier, donc rien à recopier et
rien à exposer dans une capture.

Deux raisons de ne pas analyser avec le compte `evcs` : une mémoire dont tout
l'intérêt est de ne pas être réécrite ne se consulte pas avec un compte qui peut
écrire, et un mot de passe rangé dans un fichier lisible ne doit pas être celui
qui gouverne la base.

Le script est rejouable : si le rôle existe déjà et que son mot de passe est
dans le `.env`, il ne fait rien.

## Ce qu'aucune des deux ne fait

Elles ne remontent pas dans le passé. La mémoire commence le jour où on les
branche : c'est un argument pour les mettre en service vite, pas pour les
mettre en service parfaitement.

## Sauvegarde

Les deux bases vivent dans des volumes Docker nommés, donc **hors du dépôt et
hors des sauvegardes Home Assistant**. Une mémoire non sauvegardée est une
mémoire qu'on perdra une fois — voir `HANDOFF.md` §34, qui raconte la même
histoire pour Home Assistant.