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

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.

## 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.