ab66a9ed54
Le demarrage a echoue sur "listen tcp4 0.0.0.0:5432: bind: address already in use". Synology fait tourner son propre PostgreSQL sur le port standard pour ses services internes ; on ne le deloge pas, on se met a cote. Notre base est donc publiee sur 5433, et ce port ne sert qu a l analyse depuis un poste de travail. Corrige au passage une erreur de conception que ce plantage a revelee : j avais repris network_mode bridge du chien de garde, ou il se justifiait parce qu il n a qu un conteneur et doit joindre le GX. Ici il prive les trois services du reseau interne de compose, donc de la resolution par nom — ce qui m avait conduit a coder l adresse 10.10.10.22 en dur dans le service d historisation pour qu il rejoigne une base situee dans le meme compose. Supprime : les conteneurs se parlent desormais par nom de service, sans dependre du port publie ni d une IP. InfluxDB a demarre du premier coup, 8086 etant libre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
107 lines
4.1 KiB
Markdown
107 lines
4.1 KiB
Markdown
# 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.
|
|
|
|
## 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.
|