J’ai eu l’occasion d’installer un système de supervision d’un micro-réseau électrique dans une petite ferme d’Andalousie il y a quelques temps. Pour donner un plus de contexte, cette ferme, isolé, n’est pas raccordé au réseau électrique. L’énergie utilisé sur place est produite par des panneaux solaires, alimentant un joli petit système de stockage, maintenant assez vieux, constitué de batteries plombs. L’idée est d’observer le comportement du réseau en extrayant les données d’un onduleur (Axpert VM3) équipé d’un port série permettant de communiquer avec lui via un programme Windowsien stocker sur un CD fourni avec l’onduleur.

Bien évidemment, pour ceux qui me connaissent, nous n’allons absolument pas nous servir du programme Windowsien, mais plutôt d’un outil tournant sur linux nous permettant de faire ensuite ce que bon nous semble facilement sur une petite machine ayant une faible consommation énergétique : un raspberry pi. Avant d’entrer dans le vif du sujet, voici le détail du matériel utilisé :

• un raspberry pi 4 (4GB)
• 12 batterie plomb 2V 900Ah (avec un montage de ce genre)
• un modèle ancien d’un onduleur Axpert VM3 (sans bluetooth ou autre technologie sans fil)
• des panneaux solaires
• un peu (beaucoup) de cable
• un step down 36-9v vers 5v chinois

Il y avait initialement 4 vieux panneaux solaires ayant un peu souffert de leur longue vie, l’un d’eux fonctionnait encore miraculeusement malgré le pcb cassé en deux. Bref, l’objectif de cette supervision est, dans un premier lieu, de faire un état des lieux de l’existant afin de diagnostiquer un éventuel matériel (panneaux solaires et batterie) défaillant.

Au vu du matériel, cela ne me semblait pas forcément trop compliqué, l’onduleur étant équipé d’un port série. J’ai, comme tout le monde, commencé par chercher sur internet et je suis tombé sur le dépôt github docker-voltronic-homeassistant. Comme je n’avais ni besoin ni intention d’utiliser « Home assistant » sur place, j’ai décidé de me passer de Docker & compagnie préférant me servir uniquement du morceau de code qui extrait les données. Il se trouve que l’outil qui parle à l’onduleur, citer par ned-kelly, vient du dépot github skymax-demo décrit dans un article de blog sympa en anglais.

Bon, maintenant il suffit de récupérer les données et de les exploiter alors ! Et bien non, ce serait trop beau, lorsque j’ai essayé de compiler et d’utiliser l’outil de manio, il s’est s’avèré que le programme se plaignait d’une longueur de réponse et d’un code CRC incorrect. En allant chercher dans les sources présentes sur le dépôt docker-voltronic-homeassistant, le binaire compilé avec celles-ci fonctionnait à merveille (enfin plus ou moins). J’ai donc épluché le code pour comprendre ce qui n’allait pas, corriger et proposer mes correctifs au projet initial.

On avance… maintenant que j’ai des données, il faut que je les stocke quelque part de manière à les exploiter. J’ai utilisé Influxdb puisque ce sont des séries de données temporel (timeseries) que je vais ensuite pouvoir afficher facilement avec Grafana qui l’intègre bien. Pour cela j’ai écrit un petit outil en python disponible sur le dépôt influx-writer qui appel le petit programme en C++ préalablement patcher, extrait ses données et envoie le tout à une base de donnée influx. Reste à installer un grafana pour visualiser le tout et le tour est joué !

Voici un aperçu du résultat :

J’aurais bien réécris le petit programme en C++ qui fait plus de chose que ce dont j’ai besoin, mais cela nécessite un peu de temps et surtout de volonté, ce sera donc pour plus tard… Au même titre que les petites améliorations qu’il me reste à apporter à influx-writer.

Une fois qu’on est content, qu’on arrive à extraire des jolis données avec son petit laptop de dev, il faut maintenant mettre en place l’environnement de production : le fameux raspberry pi. On installe une raspbian, on installe influxdb si on veut conserver les données localement, sinon on adapte simplement la configuration d’influx-writer pour qu’il pousse ses données sur un instance distante. On compile ensuite le binaire en C++ sur la machine (et pas sur une archi amd64 puis envoyé au raspberry au risque de mauvaises surprises…), on pose influx-writer accompagné de sa configuration et un joli petit service systemd, on s’assure que l’outil démarre automatiquement à chaque boot. On branche le cable série entre l’onduleur et le port usb du raspberry, on regarde avec dmesg sur quel device il nous expose l’onduleur et on met à jour la configuration d’inverter-poller.

Dans ce cas les données reste sur le raspberry. Comme l’accès internet n’est pas permanent, j’ai écris un petit script qui dump la base de donnée quand le raspberry est connecté au réseau et me pousse les données sur une instance distante.

Dernier détail important, j’ai d’abord branché le raspberry sur le réseau électrique généré par l’onduleur, cependant lorsque l’onduleur a un soucis et qu’il coupe le réseau, le raspberry se retrouve sans énergie et donc dans l’incapacité de récolter les éventuels codes d’erreur qui nous intéressent beaucoup dans ce cas. D’où le step-down dans la liste du matériel (le meilleur pour la fin) ! J’ai branché avec deux petits fils le step-down directement à la batterie, fonctionnant en 24V, qui convertie la tension d’entrée en 5V pour le raspberry. Même si l’onduleur coupe le réseau parce que la batterie est déchargé, le raspberry continue d’être alimenté même avec une tension plus faible puisque la plage de fonctionnement de ce step-down va de 9V à 36V. Ce n’est évidemment pas recommandable pour la batterie de continuer à la décharger mais au vue de sa capacité et de la consommation ridicule du raspberry, je considère que cela ne devrait pas dégrader la batterie de manière significative puisqu’elle sera théoriquement rechargé par les panneaux solaires sous peu. Raspberry pi alimenté par le réducteur de tension (step-down).