89 lines
6.0 KiB
Markdown
89 lines
6.0 KiB
Markdown
## v2c / trydan — V2C Trydan (e-charger)
|
|
|
|
**Statut : Partiel (proche de Supporté)** — transport, décodage, lecture ET écriture validés
|
|
sur borne réelle. Connexion persistante validée par tcpdump (fin du martèlement).
|
|
RESTE : un seul jalon = régulation de puissance réelle avec VE branché (prévu ce soir).
|
|
Ne pas passer « Supporté » dans la matrice beta tant que ce dernier test n'est pas bouclé.
|
|
|
|
| Champ | Valeur |
|
|
|---|---|
|
|
| Plugin | `powersync-plugin-v2c` (création ETM, pas un fork) |
|
|
| Paquet | `powersync-plugin-v2c` 1.15.0+etm1, dépend de `libnymea-modbus` (via ${shlibs:Depends}) |
|
|
| Interface | `evcharger` |
|
|
| Transport validé | **Modbus TCP** (port 502, unit id 1) |
|
|
| Fallback / discovery | HTTP REST (`/RealTimeData`, `/write/<param>=<val>`) |
|
|
| Borne de test | V2C Trydan, ID `XE47OR`, IP 192.168.1.127 |
|
|
| Firmware testé | **2.4.6** |
|
|
| Date MAJ | 2026-06-13 |
|
|
|
|
### Sources de la carte registres
|
|
- Lib officielle V2C : `github.com/V2Charge/Trydan_Modbus_TCP`.
|
|
- Feuille officielle « V2C - Datamanager Modbus TCP & RTU ».
|
|
- Référence comportementale : evcc `charger/trydan.go` (HTTP) — logique enable/PauseDynamic.
|
|
|
|
### Validé sur borne réelle (192.168.1.127, fw 2.4.6)
|
|
- **Transport Modbus TCP** : 0 timeout en poll espacé. Confirmé :
|
|
- poll 1 valeur / 30 s, 5 min → 0 échec ;
|
|
- poll bloc 20 reg / 30 s, 5 min → 0 échec ;
|
|
- cycle read(6 valeurs)+write / 15 s, 10 min → 0 timeout lecture, 18/18 écritures OK, SlaveError=0.
|
|
- **Décodage float Big/Big** confirmé : MaxIntensity (0x0BD2/3026) lu = 20.0 (brut 0x41A0).
|
|
- **Lecture validée** : ChargeState (0=A,1=B,2=C), ChargePower, MaxIntensity, puissances par phase.
|
|
- **Écriture validée** (FC6 uint16) : Intensity écrite=14 → relue=14 ; écrite=8 → relue=8 (vérif HTTP).
|
|
- **Activation de charge** validée via écriture Modbus (PauseState/Lock).
|
|
- **ChargePower non-nul pendant charge** : observé (reg 0x0BC3 remonte une puissance réelle).
|
|
- **Gestion conflit Dynamic** confirmée (cœur du plugin) :
|
|
- Dynamic=1 → consigne Intensity écrasée par le PID interne.
|
|
- PauseDynamic=1 → la consigne Intensity tient.
|
|
- `Dynamic` peut basculer seul 0→1 → **relecture à chaque poll obligatoire**.
|
|
- Corroboré par evcc issue #28157.
|
|
- **SlaveError** (reg 0x0BC5) décodé, table officielle : 00=OK, 01=Communication, 02=Reading,
|
|
03=Slave, **04=Waiting WiFi**, 05=Waiting communication, 06=Wrong IP, 07=Slave not found,
|
|
08=Wrong Slave, 09=No response, 10=Clamp not connected. Le code 4 vu en saturation = perte WiFi.
|
|
- **Puissances par phase** : L1 (0x0BD9/3033), L2 (0x0BDA/3034), L3 (0x0BDB/3035) — exposées
|
|
en states diag, permettent de détecter le basculement mono/tri autonome de la borne.
|
|
|
|
### RESTE À VALIDER (dernier jalon « VE branché », prévu ce soir)
|
|
- **setChargingCurrent régule la charge réelle** : ChargePower doit suivre la consigne
|
|
(paliers 6→10→16 A). Script de test prêt (retry espacés 15 s, grep "Written").
|
|
- Confirmer le basculement mono/tri visible via Power_L1/L2/L3 sous charge.
|
|
|
|
### CAUSE RACINE RÉSOLUE — saturation borne = bug plugin (pas la borne)
|
|
Diagnostic confirmé par tcpdump le 2026-06-13 : la première version du plugin **ouvrait/fermait
|
|
la socket Modbus TCP à chaque cycle de poll**, avec rafale de 6-7 SYN à chaque ouverture +
|
|
FIN/RST après lecture → saturait l'interface WiFi de l'ESP32 (latence 30 ms → 10-18 s, jusqu'à
|
|
100% timeout, état cumulatif).
|
|
- Preuve : mbpoll avec **connexion persistante** + poll espacé = 0% échec, là où le plugin
|
|
open/close = timeouts en boucle.
|
|
- **FIX (commit 186f195)** : connexion TCP persistante, établie une fois et maintenue ;
|
|
connectDevice() retourne si déjà ConnectedState ; pas de reconnexion sur simple timeout de
|
|
lecture ; reconnexion seulement si la socket tombe réellement, avec backoff.
|
|
- **Validation tcpdump post-fix** : 1 seul SYN au démarrage, puis uniquement échanges Modbus
|
|
(length 12/13), ZÉRO SYN/FIN/RST entre les polls. Borne stable, réagit aux commandes nymea-app.
|
|
|
|
### LIMITATIONS MATÉRIELLES (à documenter pour l'installation client)
|
|
1. **WiFi de l'ESP32 sensible au polling rapide.** Sous sollicitation rapprochée (ping continu
|
|
1/s, ou retry serrés, ou clients concurrents), l'interface WiFi sature de façon cumulative
|
|
(latence jusqu'à 18 s) et réversible (repos/reboot restaure). Lien radio lui-même bon (min ~10 ms).
|
|
**Conséquences install :**
|
|
- Poll espacé (30 s) + timeouts généreux (≥2-3 s), pas de retry agressif → 0% échec validé.
|
|
- **nymead doit être l'UNIQUE maître** de la borne. Déconnecter le cloud V2C et fermer l'app
|
|
V2C en installation HEMS (sinon clients concurrents = re-saturation).
|
|
- Le moteur energy-etm passe par nymead, jamais en direct sur la borne (jamais 2 maîtres).
|
|
- Problème reproduit indépendamment : Home Assistant (issue #124295), evcc.
|
|
2. **RS485 non exploitable comme transport HEMS sur ce modèle.** Le port RS485 (RJ45, pin 4=B-,
|
|
pin 5=A+) est réservé par V2C au rôle « Modbus Feeder / lecture compteur PV » (mode maître).
|
|
Aucune réponse esclave obtenue sur bus partagé (IDs 1/2/3 @ 9600 et 19200, 100% timeout).
|
|
Le mode « commande à distance » passe par TCP. **→ Étape 2 (RTU) du plugin non applicable
|
|
à cette borne.** Le RS485 reste pertinent pour d'autres bornes du catalogue.
|
|
|
|
### Notes plugin
|
|
- **Clamp courant** : lire **MaxIntensity de la borne** (= 20 ici), PAS une constante 32 en dur.
|
|
[À VÉRIFIER que le fix est appliqué dans la version courante]
|
|
- Lectures : transactions individuelles de 2 registres, float Big/Big, **pas de block read**
|
|
(chevauchement registres confirmé : un bloc retourne des paires mal alignées).
|
|
- Logique enable : `chargingEnabled = (PauseState==0 ET Lock==0)`, écritures en miroir.
|
|
- **NE PAS écrire** MaxIntensity (reg 0x1782/6018) = plafond physique installation.
|
|
- Connexion : **persistante** (ne jamais open/close par poll — cf. cause racine ci-dessus).
|
|
- `sessionEnergy` (ChargeEnergy 0x0BC4) : NE PAS exposer tant que monotonie/reset non vérifiés
|
|
(cf. evcc issue #28047, ChargeRater retiré pour fiabilité firmware).
|