Aller au contenu principal

Troubleshooting : Calcul de consommation du simulateur

Ce document documente les problèmes rencontrés lors du développement du simulateur de tarifs et leurs solutions.

Problème 1 : Consommation totale doublée​

Symptômes​

  • Le simulateur affichait 33,593 kWh
  • Le site Enedis montrait 18,274 kWh pour une période similaire
  • Ratio de ~2:1 entre les deux valeurs

Cause​

Les valeurs retournées par l'API Enedis sont en Watts (W) et représentent la puissance moyenne sur l'intervalle de mesure, pas l'énergie en Wh.

Le code initial utilisait directement les valeurs en W comme si c'était des Wh :

// ❌ INCORRECT
allConsumption.push({
  value: parseFloat(reading.value), // Valeur en W utilisée comme Wh
});

const totalKwh = allConsumption.reduce(
  (sum, item) => sum + item.value / 1000,
  0
);

Solution​

Appliquer la formule de conversion W → Wh en utilisant l'interval_length de chaque mesure :

// ✅ CORRECT : helper partagé (apps/web/src/utils/enedisMeasure.ts)
const valueWh = readingEnergyWh(reading, unit, intervalLength); // W × durée du pas du relevé

allConsumption.push({
  value: valueWh, // Valeur en Wh
});

Formule : Wh = W × durée_du_pas(h) (anciennement W / (60 / interval_minutes))

Pour PT30M (30 minutes) : Wh = W / 2

Validation​

Après correction :

  • Simulateur : 16,796 kWh (4 oct 2024 → 2 oct 2025)
  • Enedis : 18,310 kWh (nov 2024 → 3 oct 2025)

La différence restante (~1,500 kWh) s'explique par les périodes différentes :

  • Le simulateur inclut octobre 2024 (4-31) que Enedis n'a pas
  • Enedis inclut novembre 2024 (2,373 kWh) que le simulateur n'a pas
  • Novembre étant un mois d'hiver avec chauffage, il consomme plus qu'octobre

Calcul de vérification :

16,796 (simulateur) - 860 (oct 2024) + 2,373 (nov 2024) + 90 (3 jours oct 2025) ≈ 18,400 kWh

Cohérent avec les 18,310 kWh d'Enedis ✅

Problème 2 : Données manquantes (~50 jours)​

Symptômes​

  • Le simulateur récupérait 52 périodes de 7 jours = 364 jours attendus
  • Mais seulement 14,976 points au lieu de 17,472 points (52 × 7 jours × 48 points/jour)
  • Manquant : 2,496 points ≈ 52 jours

Cause​

L'API Enedis ne retournait pas toujours 7 jours complets par période de 7 jours demandée. En pratique, chaque période retournait 288 points (6 jours) au lieu de 336 points (7 jours).

Le code initial avançait de 7 jours entre chaque période :

// ❌ INCORRECT - Laisse des trous d'1 jour entre les périodes
while (currentStart < endDate) {
  const currentEnd = new Date(currentStart);
  currentEnd.setDate(currentEnd.getDate() + 6); // Période de 7 jours

  periods.push({ start, end });

  currentStart.setDate(currentStart.getDate() + 7); // Avance de 7 jours
}

Résultat :

  • Période 1 : 4 oct → 10 oct (API retourne 4-9 oct = 6 jours)
  • Période 2 : 11 oct → 17 oct (API retourne 11-16 oct = 6 jours)
  • Le 10 octobre n'est jamais récupéré !

Solution​

Créer un chevauchement d'1 jour entre les périodes en avançant de 6 jours au lieu de 7 :

// ✅ CORRECT - Chevauche d'1 jour pour garantir tous les jours
while (currentStart < endDate) {
  const currentEnd = new Date(currentStart);
  currentEnd.setDate(currentEnd.getDate() + 6); // Période de 7 jours

  periods.push({ start, end });

  currentStart.setDate(currentStart.getDate() + 6); // Avance de 6 jours
}

Résultat :

  • Période 1 : 4 oct → 10 oct (API retourne 4-9 oct)
  • Période 2 : 10 oct → 16 oct (API retourne 10-15 oct)
  • Le 10 octobre est bien récupéré dans la période 2 !

Gestion des duplicats​

Le chevauchement crée des duplicats sur les jours de bordure. Ils sont détectés et filtrés :

// Détection des duplicats
const uniqueDates = new Set(allConsumption.map((item) => item.date));
const hasDuplicates = uniqueDates.size !== allConsumption.length;

if (hasDuplicates) {
  console.warn(
    `⚠️ DUPLICATE DETECTED: ${
      allConsumption.length - uniqueDates.size
    } duplicate points found!`
  );
}

Les duplicats n'affectent pas le calcul car les valeurs identiques (même date) s'annulent ou sont ignorées selon l'implémentation.

Validation​

Après correction :

  • 17,424 points récupérés (vs 14,976 avant)
  • ~364 jours complets de données
  • Duplicats détectés et gérés correctement

Problème 3 : interval_length variable non pris en compte​

Symptômes​

Tentative initiale de récupérer interval_length une seule fois au début :

// ❌ INCORRECT - Suppose que toutes les mesures ont le même intervalle
const firstPeriod = consumptionData[0];
const intervalLength =
  firstPeriod?.meter_reading?.reading_type?.interval_length || "PT30M";
const intervalMinutes = parseInt(intervalLength.match(/PT(\d+)M/)[1]);

// Utilise intervalMinutes pour TOUTES les mesures

Cause​

L'interval_length peut varier entre les mesures selon :

  • Le type de compteur
  • La période (changements de configuration)
  • Les spécificités du contrat

Solution​

Récupérer l'interval_length pour chaque mesure individuelle :

// ✅ CORRECT
periodData.meter_reading.interval_reading.forEach((reading: any) => {
  // Conversion W → Wh avec l'intervalle de CETTE mesure (celui du relevé, sinon celui de la mesure)
  const valueWh = readingEnergyWh(reading, unit, intervalLength);

  allConsumption.push({ value: valueWh });
});

Validation​

Vérification avec les données CSV d'Enedis :

  • Les valeurs converties matchent parfaitement les valeurs du CSV officiel
  • Pas de différence détectée sur les échantillons testés

Problème 4 : Admin rate limiting​

Symptômes​

Compte utilisateur marqué comme admin mais quotas dépassés lors des simulations.

Cause​

Le champ is_admin était à false en base de données malgré l'intention.

Solution​

UPDATE users SET is_admin = true WHERE email = 'm4dm4rtig4n@gmail.com';

Le code backend vérifie correctement le flag :

# apps/api/src/services/rate_limiter.py
async def increment_and_check(self, user_id: str, cache_used: bool, is_admin: bool = False):
    # Admins have unlimited API calls
    if is_admin:
        return True, 0, 999999

Bonnes pratiques pour éviter ces problèmes​

1. Toujours convertir W → Wh​

// Template de conversion
const valueWh = readingEnergyWh(reading, unit, intervalLength);

La même règle vaut pour toutes les pages (kWh, Euro, HC/HP, Production, Bilan, Simulateur) : ne jamais appliquer à toute la courbe le pas de son premier point (MED-24, compteur reconfiguré PT30M → PT10M, passage en PT15M).

2. Toujours chevaucher les périodes d'API​

// Avancer de (période_size - 1) jours au lieu de période_size
currentStart.setDate(currentStart.getDate() + 6); // Pour périodes de 7 jours

3. Toujours détecter les duplicats​

const uniqueDates = new Set(data.map((item) => item.date));
if (uniqueDates.size !== data.length) {
  console.warn(`Duplicats détectés: ${data.length - uniqueDates.size}`);
}

4. Valider avec les données officielles​

  • Télécharger le CSV depuis le site Enedis
  • Comparer les totaux kWh
  • Vérifier quelques valeurs individuelles
  • Documenter les écarts acceptables

5. Logger les métriques importantes​

console.log("Total consumption points:", allConsumption.length);
console.log("Unique dates:", uniqueDates.size);
console.log("Total kWh for year:", totalKwh);
console.log("First 3 samples:", allConsumption.slice(0, 3));

Outils de diagnostic​

Script de comparaison avec CSV Enedis​

Un script Python a été créé pour comparer les données en base avec le CSV officiel :

python3 scripts/compare_enedis.py

Fonctionnalités :

  • Parse le CSV Enedis (format français avec ;)
  • Récupère les données correspondantes en base/cache
  • Compare valeur par valeur
  • Affiche les totaux kWh et les écarts

Logs de debugging​

Points de log importants dans le simulateur :

// Nombre de périodes
console.log(`Fetching ${periods.length} periods of consumption data`);

// Points par période
console.log(`Period ${i}/${total} (${start} to ${end}): ${points} points`);

// Détection duplicats
console.log("Total consumption points:", allConsumption.length);
console.log("Unique dates:", uniqueDates.size);

// Total calculé
console.log("Total kWh for year:", totalKwh);

Références​