# 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 :

```json
{
  "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 :

```cpp
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.