kc868-a2_solar/consigne_amelioration_epever_config_md.md

amelioration.md

Ajout de la gestion complète de configuration EPEVER dans l'application

Objectif

Ajouter dans l'application une nouvelle section de configuration avancée dédiée au régulateur solaire EPEVER AN4210N.

Cette fonctionnalité doit permettre :

• de lire automatiquement tous les paramètres importants du régulateur via Modbus RS485 ;
• d'afficher ces paramètres dans l'interface web ;
• de modifier certains paramètres depuis l'interface ;
• d'écrire les nouveaux paramètres dans le régulateur EPEVER ;
• de sauvegarder localement la configuration ;
• d'éviter toute écriture dangereuse ou involontaire ;
• de conserver une architecture stable et propre sans casser le fonctionnement actuel.

Cette fonctionnalité doit être conçue pour être robuste, maintenable et extensible.

---

Contexte matériel

Le projet utilise :

• carte KC868-A2 (ESP32)
• régulateur EPEVER AN4210N
• communication RS485 Modbus RTU
• interface web embarquée sur ESP32
• système déjà existant de lecture Modbus

Le projet possède déjà :

• une interface web
• OTA
• gestion des relais
• lecture des données EPEVER
• règles automatiques
• mode économie d'énergie

L'amélioration demandée doit s'intégrer dans cette architecture existante.

---

Nouvelle fonctionnalité à ajouter

Nouvel onglet web :

Créer un nouvel onglet :

• "Configuration EPEVER"

ou

• "Paramètres batterie"

Cet onglet doit permettre :

• lecture des paramètres actuels ;
• affichage des valeurs ;
• modification ;
• écriture vers EPEVER ;
• sauvegarde/restauration ;
• export/import JSON.

---

Fonctionnement attendu

Lecture automatique des paramètres

Au chargement de la page :

• lire automatiquement les registres Modbus de configuration EPEVER ;
• afficher les valeurs dans les champs web ;
• indiquer les erreurs de lecture ;
• ne jamais bloquer l'interface web si une lecture échoue.

La lecture doit être asynchrone et non bloquante.

---

Paramètres à récupérer

Commencer par gérer au minimum :

Paramètres batterie

• type batterie
• capacité batterie (Ah)
• tension nominale

Paramètres charge

• Boost Voltage
• Float Voltage
• Equalize Voltage
• Boost Reconnect Voltage
• Low Voltage Disconnect
• Low Voltage Reconnect
• Under Voltage Warning
• Over Voltage Disconnect
• Charging Limit Voltage

Paramètres timing

• durée boost
• durée equalize

Température

• compensation température

Divers

• activation equalization
• protections

Le code doit être pensé pour pouvoir ajouter facilement d'autres registres plus tard.

---

Interface web

Contraintes UI

L'interface doit rester légère.

Utiliser :

• formulaire simple ;
• sections claires ;
• groupes logiques ;
• unités visibles (V, Ah, min, etc.) ;
• valeurs actuelles visibles ;
• boutons :
  • Lire
  • Écrire
  • Restaurer
  • Exporter
  • Importer

---

Sécurité importante

Très important

Aucune écriture ne doit être envoyée automatiquement.

L'utilisateur doit :

1. modifier les valeurs ;
2. cliquer explicitement sur "Écrire".

Ajouter une confirmation avant écriture.

Exemple :

"Confirmer l'écriture des paramètres vers le régulateur EPEVER ?"

---

Validation des valeurs

Ajouter une validation stricte côté ESP32.

Exemples :

• Float Voltage :

  • min 13.0V
  • max 14.5V

• Boost Voltage :

  • min 13.5V
  • max 15V

• capacité batterie :

  • valeur positive uniquement

Empêcher toute valeur incohérente.

---

Gestion des erreurs

Le système doit être robuste.

Cas à gérer

• câble RS485 débranché ;
• timeout Modbus ;
• CRC invalide ;
• registre inaccessible ;
• écriture refusée ;
• données invalides.

L'interface doit afficher :

• erreur claire ;
• statut de communication ;
• dernière synchronisation ;
• dernière erreur.

---

Sauvegarde locale

Ajouter une sauvegarde locale de configuration.

Objectif

Pouvoir :

• restaurer rapidement les paramètres ;
• sauvegarder avant modification ;
• exporter/importer.

Format conseillé :

• JSON.

Exemple :

{
  "boost_voltage": 14.2,
  "float_voltage": 13.6,
  "battery_capacity": 100
}

---

Architecture logicielle

Important

Ne pas mélanger :

• lecture temps réel ;
• logique métier ;
• écriture configuration ;
• interface web.

Créer une couche dédiée.

Exemple :

• epever_runtime.cpp
• epever_config.cpp
• epever_registers.h
• epever_web.cpp

---

Gestion des registres

Créer une abstraction claire.

Exemple :

struct EpeverRegisterConfig {
    uint16_t register_id;
    const char* name;
    float scale;
    float min_value;
    float max_value;
    bool writable;
};

Objectif :

• simplifier maintenance ;
• éviter duplication ;
• permettre génération automatique UI plus tard.

---

Compatibilité future

Prévoir :

• autres modèles EPEVER ;
• plusieurs batteries ;
• profils batterie ;
• presets ;
• mode expert.

---

Fonctionnalités futures possibles

Le code doit être pensé pour permettre plus tard :

• profils GEL/AGM/Lithium ;
• détection automatique type batterie ;
• historique des changements ;
• rollback ;
• sauvegarde cloud/Home Assistant ;
• synchronisation MQTT ;
• règles automatiques basées sur configuration ;
• assistant de configuration.
• sur la page web des explication pour les parametre permettrons un comprehension pour un novice

---

Contraintes importantes

Le projet ne doit pas être cassé

Avant toute modification :

• analyser l'architecture existante ;
• comprendre les flux actuels ;
• éviter les régressions.

Ne pas réécrire brutalement le système existant.

L'amélioration doit être progressive et propre.

---

Priorité de développement

Ordre conseillé :

1. abstraction registres ;
2. lecture paramètres ;
3. affichage web ;
4. validation ;
5. écriture ;
6. sauvegarde JSON ;
7. import/export ;
8. gestion erreurs avancée.

---

Important

Avant de coder :

• analyser le code actuel ;
• identifier les modules déjà existants ;
• proposer un plan d'intégration ;
• identifier les risques techniques ;
• proposer une architecture propre.

Le but est d'améliorer l'application existante, pas de repartir de zéro.