Pylontech et votre onduleur : CAN, RS485 et port Console expliqués

Votre onduleur parle déjà à la batterie. Alors pourquoi ne voyez-vous rien ?

Tout onduleur hybride pilotant un parc Pylontech entretient une conversation permanente avec le BMS. Il connaît la tension du pack, il connaît le courant, il sait quand arrêter la charge. Et pourtant, dès que vous voulez voir la tension d'une cellule précise, l'état de santé du module 3, ou pourquoi une unité tourne deux degrés au-dessus des autres — il n'y a rien. L'écran de l'onduleur ne l'a pas, l'application de l'installateur ne l'a pas, et la batterie est pourtant là, devant vous.

Ce n'est pas une limite de votre matériel. C'est la différence entre deux conversations totalement distinctes, qui se déroulent sur deux ports totalement distincts — et comprendre laquelle est laquelle, c'est tout l'objet de ce guide.

Quatre prises RJ45, quatre rôles complètement différents

La façade d'un module Pylontech basse tension est couverte de ce qui ressemble à des prises Ethernet. Aucune n'est de l'Ethernet. Elles transportent quatre protocoles sans rapport entre eux, et brancher le mauvais câble sur la mauvaise prise est l'erreur d'installation la plus fréquente que nous voyions.

Ce que transporte vraiment la liaison onduleur — et ce qu'elle laisse de côté

La liaison CAN ou RS485 entre la batterie et l'onduleur existe pour une seule raison : permettre à l'onduleur de charger et décharger le pack en sécurité. C'est une conversation de contrôle, et elle est volontairement étroite. Elle transporte typiquement l'état de charge global du pack, sa tension, le courant total, les limites de courant de charge et de décharge que le BMS autorise à l'instant T, et une poignée de drapeaux d'alarme et de protection.

Remarquez ce que tout cela a en commun : ces données décrivent l'ensemble du parc comme une seule batterie virtuelle. C'est exactement ce dont l'onduleur a besoin. C'est aussi pourquoi ce qui suit n'apparaît jamais sur votre onduleur, aussi bon soit son écran :

• L'état de santé par module — une unité vieillissante dans un parc de six est invisible dans la moyenne.
• Les tensions de cellules individuelles — le tout premier signal d'alerte qui existe, et l'onduleur ne le reçoit jamais.
• Les températures par module — y compris l'écart entre modules, souvent plus parlant que n'importe quelle valeur absolue.
• Le nombre de cycles par module — utile lors d'une discussion de garantie, absent de la liaison de contrôle.
• Quel module précis a déclenché un événement de protection.

Pylontech ne cache rien. Le BMS connaît tout cela. Ce n'est simplement pas ce que le protocole onduleur a été conçu pour véhiculer.

Le port Console : celui que personne n'utilise

Le port Console est une simple liaison série RS-232 à 115200 bauds, et derrière elle se trouve un petit shell texte intégré au firmware du BMS. Vous envoyez une commande courte, il répond par un tableau formaté. pwr renvoie une ligne par adresse du parc. bat 1 renvoie les tensions de cellules de l'unité 1. soh 2, info 3, stat — même principe, adressé module par module.

C'est le port auquel se connecte le logiciel console de Pylontech, et c'est la raison de son existence. Et comme la plupart des installations ne lancent ce logiciel qu'une seule fois — à la mise en service, depuis un ordinateur portable, et plus jamais ensuite — le port Console passe le reste des vingt ans de vie de la batterie à ne rien faire du tout.

C'est aussi, et c'est décisif, une interface physique distincte du CAN et du RS485. L'utiliser n'enlève rien à l'onduleur.

Quelle liaison utilise mon onduleur ?

La quasi-totalité des onduleurs hybrides compatibles Pylontech utilisent le port CAN ; quelques-uns passent par le RS485, et certains acceptent les deux au choix. Ce qui compte ici, c'est la dernière colonne — identique sur chaque ligne.

Prenez la colonne du milieu comme une orientation, pas comme un schéma de câblage : le port exact, le brochage du câble et le réglage de protocole varient selon la version de firmware et le modèle, et le manuel de votre onduleur fait foi. La colonne de droite, elle, ne change jamais : quel que soit le bus pris par votre onduleur, il n'a pas pris le port Console.

Non, cela n'entrera pas en conflit avec votre onduleur

C'est la question qu'on nous pose plus que toute autre, alors voici la réponse directe. Lire le port Console n'interfère pas avec la liaison onduleur, parce que :

• Ce sont des ports différents. Pas un bus partagé, pas un répartiteur, pas un câble en Y — une prise séparée avec sa propre interface sur le BMS.
• L'échange est en lecture seule en pratique. Le shell console répond aux interrogations. Le monitoring demande pwr, bat, soh et lit ce qui revient ; il n'envoie aucun paramètre de charge, aucune trame de commande, rien qui modifie le comportement de la batterie.
• L'onduleur ne le voit jamais. Sa conversation CAN ou RS485 se poursuit exactement comme avant, au même rythme et avec les mêmes données.

Le même raisonnement vaut pour la question de la garantie : le port Console est une interface de diagnostic documentée, et le lire est précisément son usage prévu. Rien n'est modifié, reflashé ou contourné. (Comme toujours, si votre installateur maintient le système sous contrat, cela ne coûte rien de l'en informer.)

Quand les deux vues divergent — et pourquoi c'est normal

Tôt ou tard vous constaterez que l'onduleur affiche 62 % là où la console de la batterie annonce 64 %. Ce n'est presque jamais un défaut. Le chiffre de l'onduleur est son propre chiffre de travail : beaucoup appliquent un comptage coulométrique, un lissage ou une correction propre au constructeur par-dessus ce que remonte le BMS, et certains réservent volontairement une marge à chaque extrémité de la plage.

Le chiffre de la console batterie, lui, est celui du BMS, non filtré. Quand vous diagnostiquez la batterie, c'est celui-là qu'il vous faut. Quand vous cherchez pourquoi l'onduleur a arrêté la charge à 97 %, c'est le chiffre de l'onduleur qui est pertinent. Les deux sont justes — ils répondent à des questions différentes.

Batteries chaînées : l'erreur que presque tout le monde fait

Un point qui piège une bonne part des installations multi-batteries, et qui a sa place ici parce qu'il ressemble à une panne de monitoring alors que c'est un problème de câblage. Que vous lisiez le parc depuis l'onduleur ou depuis le port Console, tout vous parvient à travers le module maître — donc si le chaînage lui-même est faux, seul le maître existe aux yeux de n'importe quel outil.

Le câble de chaînage doit partir du LINK PORT 1 du maître et arriver sur le LINK PORT 0 du premier esclave, puis répéter ce même schéma 1 → 0 tout au long du parc. Câblé à l'envers, le maître ne voit jamais le reste de la pile, et tous les outils que vous braquez dessus — onduleur compris — n'affichent qu'une seule batterie, quel que soit leur nombre. La séquence complète est dans notre guide d'installation.

Lire le port Console sans scotcher un portable au mur

Savoir que le port est libre est une chose ; l'utiliser en continu en est une autre. Une console série est un outil manuel — elle répond quand on l'interroge, depuis une machine physiquement câblée à la batterie, et elle n'a aucune mémoire d'hier. Parfait pour la mise en service, inutile pour remarquer qu'un déséquilibre de cellules grimpe depuis trois semaines.

Transformer ce port en source permanente suppose un petit appareil qui reste branché sur CONSOLE, interroge le shell à intervalle régulier et republie le résultat là où vous regardez vraiment : un tableau de bord local, une entité Home Assistant, un flux Node-RED ou Jeedom, ou un simple point d'accès JSON que votre propre script lit. C'est exactement ce que fait Pylon-Monitor — et une fois les données qui circulent, savoir quels chiffres méritent une alarme devient le vrai sujet. Si vous en êtes encore à évaluer l'approche dans son ensemble, commencez par ce à quoi devrait ressembler un monitoring Pylontech.

Questions fréquentes