Superviser sa consommation électrique : Linky, solaire et Grafana

Suivre sa consommation électrique en temps réel — et sa production solaire si on en a — permet de repérer les postes qui pèsent vraiment sur la facture, bien mieux qu'une estimation annuelle. Voici l'architecture que j'utilise chez moi pour centraliser plusieurs sources de données énergétiques (compteur Linky, onduleur solaire, prises connectées) dans un tableau de bord Grafana unique.

1. Vue d'ensemble de l'architecture

Quatre briques, toutes en Docker Compose sur le même réseau :

• PostgreSQL — base centrale où atterrissent toutes les mesures, quelle que soit leur source.
• n8n — orchestrateur qui collecte les données (Téléinfo Linky via MQTT, API de l'onduleur solaire, prises connectées) et les insère en base, un workflow par source.
• Grafana — visualisation des courbes de consommation/production.
• Une passerelle domotique (ioBroker ou équivalent) — utile quand une source de données ne parle que le protocole propriétaire d'un fabricant (onduleurs solaires notamment, souvent uniquement en API cloud).

2. Schéma de base unique

Plutôt qu'une table par source, une seule table avec une colonne source simplifie grandement les requêtes Grafana :

CREATE TABLE energie_mesures (
  id SERIAL PRIMARY KEY,
  ts TIMESTAMPTZ NOT NULL DEFAULT now(),
  source TEXT NOT NULL, -- 'linky', 'solaire_prod', 'prise_x', ...
  puissance_w NUMERIC,
  tension_v NUMERIC,
  courant_a NUMERIC,
  energie_kwh NUMERIC
);

3. Collecte Linky via Téléinfo/MQTT

Un module Téléinfo (type Tasmota) lit le port série du compteur Linky et publie les trames en MQTT. n8n s'abonne au topic MQTT, transforme la trame JSON et insère dans energie_mesures avec source = 'linky'.

4. Production solaire

Beaucoup d'onduleurs solaires grand public (Hoymiles, Enphase...) ne fonctionnent qu'avec le cloud du fabricant, sans API locale documentée. La solution la plus fiable reste de passer par un adaptateur communautaire (un plugin ioBroker dédié à la marque, par exemple), puis d'interroger cet adaptateur depuis n8n via son API locale plutôt que le cloud fabricant directement — plus rapide et indépendant d'une panne du service cloud.

5. Variable critique à sauvegarder : la clé de chiffrement n8n

n8n chiffre les identifiants stockés (accès Postgres, API...) avec une clé générée au premier démarrage (N8N_ENCRYPTION_KEY, visible dans son fichier de configuration interne). Si vous migrez ou réinstallez n8n sans réutiliser cette même clé, tous les identifiants enregistrés deviennent illisibles et chaque connexion doit être ressaisie à la main.

6. Dashboard Grafana

Avec une seule table et une colonne source, une requête simple suffit pour comparer consommation et production sur un même graphique :

SELECT
  ts AS "time",
  puissance_w,
  source
FROM energie_mesures
WHERE $__timeFilter(ts)
  AND source IN ('linky', 'solaire_prod')
ORDER BY ts

Un panel "Time series" avec cette requête, groupé par la colonne source, donne immédiatement une courbe consommation vs production superposée.

Vue d'ensemble utile pour la suite : une fois la donnée centralisée dans Postgres, elle peut aussi alimenter Home Assistant (capteurs manuels ou intégration SQL) pour déclencher des automatisations — par exemple lancer le lave-linge quand la production solaire dépasse un certain seuil.

Conclusion

Ce genre d'architecture demande un peu de mise en place au départ (une source de données = un workflow), mais une fois le socle Postgres + n8n + Grafana en place, ajouter une nouvelle source de données (nouvelle prise connectée, nouveau compteur) ne prend que quelques minutes.