Bonjour à tous,
Suite de mon précédent sujet sur le dashboard Énergie avec un Balco 260 :
J'y expliquais notamment que l'intégration officielle ne remonte que des watts, jamais
des kWh, et que la puissance batterie du Balco 260 n'existe tout simplement pas côté
cloud — d'où une estimation par bilan de puissance, avec les approximations que ça
implique.
Le Modbus local règle ces deux problèmes.
Où on en est
L'intégration Modbus locale que je maintiens reconnaît maintenant deux appareils :
le S Meter et le Balco 260. Aucune dépendance au cloud, aucune latence, ça
tourne même sans internet.
Concrètement, par rapport au cloud :
- Compteurs d'énergie cumulée natifs (production PV, import et export réseau,
sortie AC). Plus besoin de helpers Riemann, les kWh sortent directement de
l'appareil - Données batterie réelles : énergie chargée et déchargée en Wh, SoC, SoH,
nombre de cycles. L'estimation dont je parlais dans le tuto précédent devient
inutile en local - Par string PV : puissance, tension et courant de chacune des quatre entrées
séparément — ce qui permet de vérifier qu'un panneau débite réellement, panneau par
panneau - Statuts, avertissements et défauts onduleur, en valeurs énumérées
À ne pas confondre avec l'intégration officielle BLUETTI, qui existe déjà, passe
par le cloud avec un compte BLUETTI et couvre un large catalogue d'appareils. Ce
projet en est indépendant : c'est une démarche communautaire centrée sur le local.
Les deux sont complémentaires et peuvent cohabiter.
La suite : Home Assistant Core
Une PR est ouverte dans Core, construite sur la nouvelle architecture Modbus arrivée
en 2026.9 :
Si elle est acceptée, BLUETTI apparaît dans la liste des intégrations natives — plus
de dépôt tiers, plus de HACS. Elle ne porte que sur le Balco 260 pour l'instant : les
mainteneurs de Core demandent des PR courtes et ciblées, ce qui est parfaitement
compréhensible vu le volume qu'ils traitent. Le S Meter suivra dans une PR séparée,
puis les autres modèles un par un.
Une trouvaille qui peut servir à d'autres
En testant les connexions persistantes, on a changé le backend de notre bibliothèque
client : pymodbus remonte les réponses tronquées comme de simples timeouts, là où
tmodbus les identifie correctement comme ModbusProtocolError. On a passé un bon
moment à déboguer des « timeouts » qui étaient en réalité des trames malformées.
À retenir si vous chassez des appareils Modbus instables.
Où j'en suis honnêtement
Le projet est jeune et il reste des bugs. Le firmware Modbus des appareils a par
ailleurs ses propres instabilités — trames tronquées intermittentes, épuisement du
pool de sockets — que j'ai remontées au constructeur et qu'on contourne côté client
en attendant. C'est utilisable au quotidien, pas encore d'une robustesse
irréprochable.
Si vous avez du matériel BLUETTI
C'est là que j'ai besoin de vous. Étendre la compatibilité ne dépend pas du temps de
développement mais de l'accès au matériel : je possède un Balco 260 et S Meter, et c'est tout.
Activer le Modbus TCP prend deux minutes (serveur web local de l'appareil, login
admin avec le mot de passe de l'app BLUETTI, Settings → Modbus TCP, port 502, puis
bien cliquer sur le bouton d'enregistrement). Une lecture, et vous m'envoyez la
sortie.
Le mieux est d'ouvrir une issue ou une discussion sur le dépôt plutôt que de répondre
ici : c'est suivi, c'est traçable, et ça profite aux suivants.
Et bien sûr, questions et retours bienvenus dans ce fil.
