Étude de cas
LinkyStat
Pipeline data · Séries temporelles · Long terme
GitHubCapturer, stocker et visualiser la consommation électrique à partir du compteur Linky.
Compteur Linky, compteur « connecté ». Tu m'intéresses. Connecté comment, au juste ?
La spécification TIC Enedis, d'accord... et une petite clé USB sur hallard.me pour lire la trame série, et là je suis dans mon monde.
J'arrive à lire la téléinformation (TIC). Une trame brute, un checksum à valider. J'ai mes premières données.
On stocke tout ça dans une base, un Grafana au-dessus, et on accumule. Pas un gadget temps réel : une mémoire longue, exploitable sur des années.
Script Python vers MySQL/Grafana. Un schéma relationnel simple : pas d'explosion de cardinalité, pas de rétention complexe (temps réel complet sur 2 jours, historique horaire sur 7 ans), des requêtes encore lisibles des années après.
7 ans de données stockées dans un seul fichier dump de 1 Mo. Sauvegarde et restauration simples et rapides, automatisées via GitHub Actions.
En production continue depuis le premier jour. CI/CD via GitHub Actions. Historique ininterrompu, la simplicité et la légèreté ont permis une très bonne fiabilité.
Une vue Grafana qui répond aux questions posées dès le départ : des vues court, moyen et long terme, quelques tendances. La valeur s'est accumulée avec le temps.
Après les premières années d'observation à près de 8000 kWh/an, j'ai ciblé le chauffage électrique en premier : meilleure utilisation de la programmation journalière par pièces, optimisation des plages horaires.
La consommation a baissé à 6000 kWh/an.
La veille des appareils ("J'éteins tout à la maison et je regarde ce qui reste.").
J'ai identifié près de 300 W de veille permanente, soit ~2500 kWh/an.
J'ai réduit cette consommation à 120 W, soit ~1000 kWh/an.
La consommation a baissé à ~4500 kWh/an.
"Combien me coûterait ma consommation chez un autre fournisseur ?"
J'ai voulu afficher les prix en direct et imaginer un comparateur de prix. Mais pas d'API chez les fournisseurs : ce sont souvent des PDF qui contiennent leurs grilles tarifaires, qui évoluent souvent et sans préavis.
J'ai testé de télécharger et parser ces PDF automatiquement. Les tableaux étaient trop irréguliers : le parsing cassait à chaque révision de tarif. Trop de travail récurrent.
J'ai fini par fixer les prix en dur. Simple et robuste mais inexact dès qu'un tarif bouge. Un compromis assumé : je préfère une consommation juste, le prix est secondaire.
Je voyais ma consommation totale descendre grâce aux améliorations chauffage et veille, mais quid de la consommation appareil par appareil ? Il fallait aller plus loin et mesurer individuellement.
Quelques prises connectées pour commencer, une clé TIC sur le Linky, et un Home Assistant ont rendu le projet Linkystat obsolète : dès lors que les capteurs de puissance par appareil sont branchés, Home Assistant agrège tout nativement. Plus besoin de collecter les trames, de les parser, de les stocker dans une base pour les visualiser dans un Grafana. Home Assistant fait tout ça mieux, avec une communauté active et un écosystème riche.
On ne perd rien : les 7 ans de données Linkystat ont été migrées et sont visualisables sans rupture dans le tableau de bord dédié à l'énergie de Home Assistant. Le code Linkystat reste sur GitHub. L'instance Grafana/MySQL est éteinte : inutile de maintenir une infrastructure séparée quand une autre fait le même travail en mieux.
Passer à Home Assistant →Références
-
[01]
Spécification Téléinfo Client (TIC), Enedis
La spécification officielle du protocole série émis par le Linky : trames, champs, checksums. Sans elle, impossible de décoder le signal.
-
[02]
hallard.me, Charles-Henri Hallard
Mon fournisseur de clé USB PiTInfo / LibTeleinfo. C'est ici que j'ai acheté le matériel et trouvé la communauté qui lit la trame TIC en France. Un des rares endroits où l'électronique et le logiciel se rejoignent sur ce sujet.