Si PeaNUT continue de détecter votre onduleur après un redémarrage de ZimaOS, mais que ses paramètres enregistrés disparaissent, le problème vient généralement de la persistance plutôt que de la connectivité avec l’onduleur. Le répertoire de configuration doit être associé à un stockage ZimaOS durable, et le conteneur doit pouvoir écrire dans ce répertoire.
Le fil de discussion du forum de mars 2026 a confirmé une solution pour la version de PeaNUT installée à cette époque : associer un dossier hôte persistant à /app/config. Depuis, la documentation actuelle de PeaNUT en amont a standardisé la configuration persistante sous /config. Les nouvelles installations doivent donc utiliser le chemin actuel plutôt que reprendre aveuglément l’ancien chemin du conteneur.
Ce que la solution du forum a réellement démontré
L’auteur du message original signalait que tous les paramètres de PeaNUT disparaissaient après chaque redémarrage de ZimaOS, alors que Home Assistant continuait de recevoir les données de l’onduleur. Un membre de la communauté a inspecté le paquet et suggéré de modifier l’association de volumes afin qu’un dossier hôte situé dans les données d’application de ZimaOS soit monté sur /app/config. L’auteur a répondu que cela « avait résolu le problème », ce qui en fait une solution vérifiée pour cette version précise du paquet.
Cela ne signifie pas que /app/config est aujourd’hui le chemin cible correct pour toutes les images PeaNUT. Les chemins des conteneurs font partie du contrat de l’image et peuvent changer d’une version à l’autre.
Pour les versions actuelles de PeaNUT, utilisez /config
La documentation Docker actuelle de PeaNUT utilise /config pour les paramètres persistants. L’image actuelle attend également que ce répertoire soit accessible en écriture par l’utilisateur du service, normalement avec l’UID/GID 1000:1000.
Dans ZimaOS, associez un répertoire hôte durable, tel qu’un dossier de données d’application, à /config, puis redémarrez le conteneur et effectuez une modification sans conséquence dans les paramètres. Redémarrez-le encore une fois et vérifiez que la modification est conservée. Le même principe de persistance est expliqué dans le guide de migration des données d’application de ZimaOS.
Vérifiez les autorisations d’écriture avant de modifier à nouveau les chemins
Si l’association est correcte, mais que les paramètres sont toujours réinitialisés, consultez les journaux de PeaNUT pour rechercher des erreurs d’autorisation. Le code en amont actuel signale explicitement lorsque /config n’est pas accessible en écriture. Ne supposez pas que l’ajout de variables d’environnement PUID ou PGID non prises en charge corrigera l’image : les recommandations actuelles en amont consistent plutôt à rendre le répertoire hôte accessible en écriture par l’utilisateur réel du service dans le conteneur.
Le forum de discussion en amont de PeaNUT est utile lorsqu’une image actuelle génère des erreurs spécifiques aux autorisations.
Pourquoi docker exec peut échouer
Le fil de discussion original montrait également que docker exec -it PeaNUT sh échouait, car cette image PeaNUT ne contenait pas de shell. Cela ne prouve pas que le conteneur est défectueux. Les images minimales peuvent volontairement omettre sh ou bash.
Commencez par consulter les journaux du conteneur et l’association de volumes configurée. Pour connaître les principes généraux de la persistance des conteneurs, le guide d’introduction aux applications Docker de ZimaOS explique pourquoi les données montées depuis l’hôte survivent à la recréation et aux redémarrages du conteneur.
En résumé
L’ancienne solution de la communauté fonctionnait bien pour le paquet PeaNUT utilisé en mars 2026, mais les versions actuelles de PeaNUT documentent /config comme répertoire persistant. Utilisez le chemin du conteneur indiqué par l’image installée, rendez le dossier hôte accessible en écriture et vérifiez la persistance après un redémarrage avant de modifier quoi que ce soit d’autre.
