Pilotage de la Venus A.

Le véritable découverte est celle du mode passif dans la documentation de l'API (révision 2.0 du 6 juin 2026) ou (révision 3.1) .

Toutefois, disons le tout de suite, cette API ne livre pas toutes les méthodes mises en oeuvre par l'application smartphone. Par exemple, on peut régler la DOD (profondeur de décharge) mais pas la lire. On a pas accès au réglage de l'horodatage de la batterie, etc. Elle privilégie uniquement l'accès via des commandes JSON transmises via des datagrammes UDP. Or ce protocole suppose un réseau particulièrement fiable et oblige à envisager des pertes de paquets aussi bien pour les requêtes que pour les réponses. Son seul avantage est sa simplicité de mise en oeuvre, chaque requête ou réponse JSON tenant dans un unique datagramme UDP. Avec Marstek on est loin du niveau d'industrialisation des wattmètres Shelly compatibles avec la plupart des grands standards de supervision (HTTP/REST, Modbus, MQTT, etc.). Si vous devez intégrer votre solution à un système de supervision existant, les Venus Marstek ne sont sans doute pas le meilleur choix.

Une analyse des échanges sur le réseau entre l'application smartphone et la batterie montre que l'application uilise un protocole TCP. Toutefois absolument rien n'est documenté dans ce domaine par Marstek. S'appuyer sur l'analyse réseau est à la fois chronophage et risqué puisque Marstek peut faire évoluer ce protocole à sa convenance.

Le mode "passif".

L'API traite du mode "passif" mais ce dernier n'est documenté nulle part. Sous Linux avec la commande curl, il est facile d'expérimenter pour voir ce qui se passe. En fait, le mode "passif" consiste à demander à la batterie de délivrer une puissance donnée pendant un laps de temps donné. Une fois que ce laps de temps est écoulé, la batterie reste en mode "passif" qui est en quelque sorte un mode d'attente d'une prochaine commande (d'où sans doute le nom de ce mode). En aucun cas, elle ne bascule vers un des 4 autres modes.

L'idée est donc d'utiliser ce mode pour adapter en permanence la puissance délivrée par la batterie à la puissance demandée par le logement. Cette adaptation est faite au moyen d'un logiciel qui exécute une même procédure à intervalle plus ou moins régulier. Cette procédure consiste à demander au wattmètre la puissance fournie au logement et à adapter ensuite la puissance de sortie de la batterie en utilisant le mode passif. Notez que si la puissance excède la capacité de la batterie (Venus A = 1,5 kW maximum), la puissance demandée à la batterie devra être adaptée. Cette adaptation peut aussi tenir compte de son niveau de charge. Avec une telle régulation, le wattmètre n'a aucun besoin d'être compatible avec la Venus A. Le schéma qui suit résume la simplicté de la régulation.

Principe de la réalisation.

Nous utilisons ici l'infrastructure Qt en version 6.11. La communication avec la batterie se fait via UDP (protocole non connecté) tandis que celle avec le wattmètre se fait via HTTP, c'est à dire via TCP (mode connecté). Ces protocoles différents compliquent un peu la conception du régulateur. Nous souhaitons éviter de bloquer le logiciel dans l'attente d'une réponse à une requête (utilisation du mode asynchrone pour économiser le temps processeur). Cela nous amène à faire un large usage des signaux Qt. Le schéma qui suit montre le principe de la régulation :

Ce schéma distingue deux parties. La première consite à vérifier la présence sur le réseau du wattmètre et de la batterie. Si un des deux composants n'est pas joignable, le programme s'achève.

La seconde partie constitue la boucle de régulation. Elle est déclenché par un chronomètre qui émet un signal lorsque le délai fixé est écoulé. Ce chronomètre est réarmé une fois la procédure de régulation effectuée ou en cas de détection d'une erreur qui met fin à cette procédure. Dans tous les cas, ce réarmement relance au bout d'un temps donné la procédure de régulation.

Du point de vue Qt, le schéma qui suit illustre les principaux signaux et leur gestionnaires (slots) lorsque la régulation s'effectue correctement (absence d'erreur) :

Cette architecture logicielle permet de s'adapter aux erreurs réseau susceptibles de se produire. L'intervalle de temps entre chaque commande n'est donc pas garanti mais cela est peu important si la durée demandée à chaque commande du mode passif est relativement faible. De plus en cas de chute du réseau, la batterie se met automatiquement en mode d'attente évitant ainsi de délivrer une puissance inutile (surtout si la dernière demande correspondait à une pointe de puissance).

Si on détecte un délai relativement long entre deux itérations de la procédure de régulation, le régulateur peut éventuellement émettre un courriel vers un administrateur pour l'informer d'une anomalie (l'option actuellement retenue est un message d'erreur dès que le délai dépasse 5 minutes).

Une autre option permet de fixer une série de créneaux horaires au sein desquels s'exerce la régulation. Cela peut être pratique en période de faible ensoleillement pour favoriser la production aux heures pleines ou aux heures de plus fortes consommations.

Le programme réalisé est un programme console Qt 6.11. Il est disponible sous Linux pour les architectures amd64 (Intel) et arm64 (ARM). L'article suivant constitue le guide d'utilisation de ce programme. Il est spécifiquement réalisé pour les périphériques Marstek de type Venus A à D et Venus E mini collaborant avec le wattmètre Shelly Pro 3EM (Gen 2) ou tout autre wattmètre Shelly utilisant la même API HTTP.

Dans notre cas, nous faisons exécuter ce programme par une machine virtuelle Debian d'architecture arm64 exécutée par une freebox Delta dont la mémoire vive a été portée à 8 Gio. Le programme en version 1.0.4 utilise 15 Mio de mémoire vive (qui ne s'augmente pas) et moins de 0,2 % du temps processeur à chaque boucle de régulation. Autrement dit, ses besoins en ressources sont assez faibles ce qui était un des objectifs techniques. La machine virtuelle dispose de 2 processeurs et de 4 Gio de mémoire vive ce qui est amplement suffisant.

Les mesures répercutées sur l'application smartphone montrent que les puissances affichées après activation du cadre "CT" sont assez imprécises et ne reflètent pas vraiment la réalité. Celles affichées sur la page principale ou dans la page des statistiques sont plus fiables mais il faut penser à les actualiser régulièrement.