·VA

Case study

LinkyStat

Data pipeline · Time-series · Long-term

GitHub

Capture, store and visualise electricity consumption from the Linky meter.

Role
Design & dev
Stack
Python · MySQL · Grafana
Status
Archived
The starting point

A Linky meter, 'connected'. You've got my attention. Connected how, exactly?

The Enedis TIC spec, fine. A little USB key from hallard.me to read the serial frame, and now I'm on home ground: software.

I can read the telemetry (TIC). One raw frame, one checksum to validate. I've got my first data.

Drop it all into a database, Grafana on top, and let it accumulate. Not a real-time gadget: long memory, usable over years.

LinkyStat Grafana dashboard
FIG. 01 LinkyStat dashboard in Grafana: real-time, monthly and yearly history.
What worked
Simple stack

Plain Python script into MySQL/Grafana. A simple relational schema: no cardinality explosion, no complex retention policy (full real-time for 2 days, hourly history for 7 years), queries still readable years later.

Daily backup

7 years of data in a single 1 MB dump. Simple, fast backup and restore, automated via GitHub Actions.

Zero downtime

Continuous production since day one. CI/CD via GitHub Actions. Unbroken history: simplicity and lightness delivered excellent reliability.

Dashboards that answer

A Grafana view that answers the questions I started with: short, medium and long-term views, trends. Value compounded over time.

Consumption drop
Heating schedule

After the first years of observation at close to 8,000 kWh/year, I targeted electric heating first: better use of per-room daily schedules, optimising time slots.

Consumption dropped to 6,000 kWh/year.

Standby appliances

The standby audit: 'I switch everything off at home and watch what's left drawing power'.

I identified close to 300 W of permanent standby, around 2,500 kWh/year.

I brought that down to 120 W, around 1,000 kWh/year.

Consumption dropped to ~4,500 kWh/year.

What broke
Pricing.

'How much would my consumption cost at a different supplier?'

No API from suppliers: rate tables come as PDFs, updated often and without notice.

I tried to download and parse those PDFs automatically. The tables were too irregular: parsing broke on every rate revision. Too much recurring work.

I ended up hard-coding prices. Simple and robust, but wrong the moment a rate moves. A conscious trade-off: I'd rather have accurate kWh than a fake cost.

Results
8300 → 4500 kWh
46% total consumption drop
300 → 120 W
permanent standby identified and cut
7 yrs
in production, no interruption
1 MB
final backup with 7 years of complete history
The next question

I could see total consumption falling. But what was actually using power, appliance by appliance? Impossible to know from a single meter.

A few smart plugs, a TIC interface on the Linky, and Home Assistant made LinkyStat obsolete: once per-appliance power sensors are in place, Home Assistant aggregates everything natively, long-term history included. No need to collect frames, parse them, store them in a database and visualise in Grafana. Home Assistant does all of that, better, with an active community and a rich ecosystem.

Nothing was lost: 7 years of LinkyStat data were migrated and are visible in the Home Assistant energy dashboard without any gap. The LinkyStat code stays on GitHub. The Grafana/MySQL instance is gone: no point running a separate stack when another does the same job better.

Move to Home Assistant →

References

  • [01]
    Teleinfo Client (TIC) Specification, Enedis

    The official spec for the serial protocol emitted by the Linky meter: frames, fields, checksums. Without it, the signal is undecipherable.

  • [02]
    hallard.me, Charles-Henri Hallard

    The maker behind the PiTInfo / LibTeleinfo USB key. Where I bought the hardware and found the community that actually reads TIC frames in France. One of the few places where electronics and software meet on this topic.