Initial commit — KC868-A2 contrôleur solaire ESP32
Fonctionnalités : - Lecture RS485 Modbus Epever Tracer 4210N (115200 bps, FC03/FC04/FC16) - Moteur de règles JSON (LittleFS) — commande automatique des relais - Interface web mobile-first (dashboard, règles, config, historique, EPEVER, debug) - WiFi AP+STA simultanés avec reconnexion automatique et portail captif - mDNS configurable (pv.local par défaut) - Configuration registres EPEVER depuis l'UI (18 registres holding) - Historique basse/haute résolution avec graphes canvas - VPN WireGuard optionnel (désactivé par défaut, config via UI) - OTA firmware + filesystem via ElegantOTA - Deep sleep / économie d'énergie Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,352 @@
|
||||
# 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.
|
||||
|
||||
Reference in New Issue
Block a user