Next.jsExpress.jsMongoDBDockerChokidar

Degrés Jours — Automated weather pipeline

ESLC manages heating across 20 sites with fuel contracts billed on monthly DJU data. I replaced several hours of monthly manual work with a fully automated pipeline: a C# script collects MétéoFrance data every day at 1:30 PM, injects it into MongoDB in under 10 seconds, and DJU are calculated and available in real time across all sites.

~3hSaved / month

< 10sFile → portal

0Manual entry error

4 yrsIn production

The problem

Several hours a month, one person, zero automation

ESLC tracks heating across 20 sites via fuel contracts billed on monthly Unified Degree Days (DJU). Before MeteoESLC, this calculation was entirely manual: downloading MétéoFrance reports, copying them into Excel, calculating DJU column by column, emailing the file to each stakeholder, managing concurrent versions (v1, v2, v2_final…). This recurring process took several hours every month — and relied on a single person who knew the spreadsheet.

The real consequence: a delay or error in monthly DJU could distort the fuel billing for all sites. The company's heating budget depended on a fragile Excel spreadsheet, maintained by hand, with no traceability and no centralization.

How it works

From thermometer to energy contract in under 10 seconds

What is a DJU?

A Unified Degree Day (DJU) measures how cold a day is: max(0, 18 − (TN + TX) / 2). When the daily average drops below 18 °C, buildings need heating — each degree below 18 is one DJU. Fuel suppliers use monthly cumulative DJU split into 3 decades (D1/D2/D3) to validate actual consumption and adjust billing.

11:30 PM — SCR-01 queries MétéoFrance API for all 20 stations
2.data files dropped in WATCH_DIR (SRV21 + SRV22)
3Chokidar detects the file in under 5 seconds (SMB polling)
4ingestService parses, idempotent upsert → MongoDB Atlas
5All 4 business views updated — summary email at 1:35 PM

Architecture

Parallel dual-write

The C# script writes in parallel to two completely independent destinations. The ICopitole branch consumes .data files at 1:45 PM for energy management. The web portal branch goes through Chokidar → MongoDB → Next.js for real-time display. A failure on one branch never blocks the other.

Production constraint

The critical window: 10 minutes to fix before ICopitole

ICopitole consumes .data files at exactly 1:45 PM. If a station is in error, the operator has exactly 10 minutes — between the alert email at 1:35 PM and the point of no return at 1:45 PM — to fix and re-run.

1:30 PM

1:35 PM

1:40 PM

Point of no return1:45 PM

2:00 PM

Click a step to see details

Technical decision

usePolling: true — fs.watch doesn't work on SMB

Node.js native fs.watch never fires events on an SMB network share — a Windows kernel limitation, poorly documented. usePolling: true with interval: 5000 is the only reliable option. awaitWriteFinish.stabilityThreshold: 2000 prevents reading a partially written .data file. ignoreInitial: false re-ingests files already present on backend restart — essential on an unstable network.

Technical decision

Idempotent upsert — zero duplicates regardless of retry frequency

ingestService never uses insertOne — always updateOne on the (poste, date) filter with upsert: true. The unique index on (poste, date) enforces this at the database level. A manual re-run, watcher restart, or .data file rewrite never creates a duplicate. The operation is idempotent by design, not by convention.

Technical decision

POST /api/ingest fallback — the watcher is not a SPOF

If Chokidar goes down (SMB outage, Docker restart), the operator injects the file via POST /api/ingest from the admin portal. Same ingestService, same validation, same idempotent upsert. The watcher is not a single point of failure — the system continues in degraded mode without service interruption.

Results

What changed

Before MeteoESLC

Several hours of manual data entry per month
1 to 2 day delay (email + manual validation)
Multiple versions in circulation (v1, v2, v2_final…)
Frequent human data entry errors
1 person = 1 single point of failure

After MeteoESLC

Zero — 100% automated since deployment
Under 10 seconds after the .data file is deposited
Single source of truth — MongoDB Atlas
Zero errors — automatic, controlled parsing
Available to everyone, from any workstation

The application

4 business views, one source of truth

Each view addresses a specific operational need: the dashboard for daily monitoring, the daily report for historical lookup, the weekly trend for temperature patterns, and the monthly DJU report for fuel billing.

/

Dashboard

Last imported day: KPIs (active stations, avg TN/TX, cumulated DJU), frost alerts, bar chart. Daily starting point.

/daily

Daily report

Any past day, filterable by station. TN/TX bar chart and CSV export compatible with Excel (';' separator, UTF-8 BOM).

/weekly

Weekly trend

TN, Average and TX curves over an ISO week for a given station. Only weeks with data are shown.

/monthly

Monthly DJU report

D1/D2/D3 calculation over a full month. CSV export ready for fuel suppliers and energy contract tracking.

Geographic coverage

20 MétéoFrance stations, 20 ESLC sites

For each ESLC site, the nearest active MétéoFrance station with available daily TN/TX data.

BOURG

CEYZERIAT_SAPC

5,8 km

BOURG-ASOTRANS

CEYZERIAT_SAPC

5,6 km

TENDE

TENDE-OBS

1,3 km

DOLOMIEU

FAVERGES

3,6 km

ST-SORLIN

FAVERGES

5,2 km

BOURGOIN

5,4 km

VENISSIEUX

LYON-BRON

5,4 km

AIGUESBLANCHE

LA LECHERE_SAPC

3,4 km

CRUSEILLES

GROISY_SAPC

5,4 km

BARJOLS

VARAGES

5,0 km

PUGET

FREJUS

4,4 km

MONACO

PEILLE

4,4 km

ST-ANDREE

NICE-RIMIEZ

1,3 km

CARROS

CARROS_SAPC

0,2 km

MANDELIEU

CANNES

0,4 km

ST-ETIENNE

SAINT-ETIENNE

6 km

BRIGNOLES

MONTFORT-SUR-ARGENS_SAPC

10,2 km

PASTOR ST-ROMAIN

LYON TETE D'OR

7 km

MARSEILLE MENET

MARSEILLE

3,2 km

THEIZE

LIERGUES_SAPC

4,5 km

MENTON

0,7 km

THONON

EVIAN

4,5 km

≤ 1 km 1 – 5 km> 5 km

For each ESLC site, the nearest active MétéoFrance station with available daily TN/TX data.

Confidential application — restricted access

For confidentiality and legal reasons, I cannot share access to this application. It is deployed in production on ESLC's internal network.

All projects

Degrés Jours — Automated weather pipeline

~3hSaved / month

< 10sFile → portal

0Manual entry error

4 yrsIn production

What changed

Before MeteoESLC

Several hours of manual data entry per month
1 to 2 day delay (email + manual validation)
Multiple versions in circulation (v1, v2, v2_final…)
Frequent human data entry errors
1 person = 1 single point of failure

After MeteoESLC

Zero — 100% automated since deployment
Under 10 seconds after the .data file is deposited
Single source of truth — MongoDB Atlas
Zero errors — automatic, controlled parsing
Available to everyone, from any workstation