etm-powersync-plugins-modbus/v2c/PORTING_STATUS.md

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).