Intro
Deux manipulations utiles quand on pousse Venus OS et Node-RED un peu plus loin que l’interface standard : obtenir un accès SSH root sur le Cerbo GX, et faire en sorte que les variables de contexte d’un flow Node-RED survivent à un redémarrage.
Activer l’accès SSH root sur le Cerbo GX
Victron cache volontairement cette option pour éviter les manipulations accidentelles — elle reste néanmoins officiellement supportée.
Étape 1 — Passer en « User and Installer »
Sur le Cerbo (écran tactile ou Remote Console) : Réglages → Général → Access Level, puis choisir User and Installer. Le mot de passe demandé est ZZZ (en majuscules).
Étape 2 — Débloquer le niveau Superuser
Rester positionné sur la ligne Access Level (sans la rouvrir) puis :
- Sur écran tactile / appli mobile : glisser le menu vers le bas et maintenir l’appui 5 secondes
- Sur PC via le Remote Console classique : maintenir la flèche droite du clavier enfoncée (la souris ne fonctionne pas pour ce geste)
Le niveau bascule alors sur Superuser.
Étape 3 — Définir un mot de passe root
Un nouveau menu apparaît : Réglages → Général → Set root password. Choisir un mot de passe d’au moins 6 caractères.
Attention : ce mot de passe est stocké sur le rootfs et sera réinitialisé à chaque mise à jour de firmware — c’est normal, il faudra le redéfinir après une mise à jour Venus OS si l’accès SSH root reste nécessaire.
Étape 4 — Activer SSH on LAN
Toujours dans Réglages → Général, activer l’option SSH on LAN.
Étape 5 — Se connecter
ssh root@<adresse-IP-du-cerbo>
Si la connexion échoue avec Too many authentication failures avant même de demander le mot de passe, c’est que votre client SSH tente automatiquement toutes vos clés existantes. Forcez l’authentification par mot de passe :
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@<adresse-IP>
Rootfs « modifié » après coup
Une fois le mot de passe root défini, le menu Réglages → Firmware affichera l’état du système de fichiers racine comme « Modifié », avec une option Nettoyer. C’est normal : le mot de passe root est stocké sur le rootfs, qui doit rester une image en lecture seule identique à celle fournie par Victron. Le nettoyage restaure le rootfs d’origine (supprimant le mot de passe root et tout paquet tiers éventuellement installé dessus) sans toucher aux réglages ESS, VRM ou réseau, qui vivent sur une partition séparée (/data).
Rendre persistant le contexte d’un flow Node-RED
Par défaut, les variables stockées via context.set() / flow.set() / global.set() dans Node-RED vivent en mémoire uniquement. Un redémarrage du service Node-RED, un redeploy de flow, ou un reboot du Cerbo efface tout. Pour une machine à états qui tourne sur plusieurs heures (par exemple un calcul qui suit un cycle de charge/décharge complet), c’est un problème : le moindre redémarrage entre-temps remet le calcul à zéro sans jamais le laisser aboutir.
Trouver le bon fichier de configuration
Sur Venus OS, Node-RED est lancé par /usr/bin/node-red-venus.sh avec l’option --settings /usr/lib/node_modules/node-red/venus-settings.js. Ce fichier ne doit jamais être édité directement (il sera écrasé à la prochaine mise à jour firmware), mais il inclut en fin de fichier :
...try_require("/data/home/nodered/.node-red/settings-venus.js"),
...try_require("/data/home/nodered/.node-red/settings-user.js"),
settings-user.js est donc le point d’extension officiel pour les réglages personnalisés — il survit aux mises à jour firmware car il vit sur la partition /data.
Piège à éviter : ne pas créer un fichier nommé simplement settings.js dans ~/.node-red/ — le script de démarrage Venus OS le renomme automatiquement en settings.js.old au prochain démarrage (mécanisme prévu pour migrer l’ancien credentialSecret), ce qui neutraliserait silencieusement toute configuration ajoutée là.
Créer settings-user.js
Le fichier n’existe généralement pas encore par défaut :
cat > /data/home/nodered/.node-red/settings-user.js << 'EOF'
module.exports = {
contextStorage: {
default: "memoryOnly",
memoryOnly: { module: "memory" },
file: {
module: "localfilesystem",
config: {
dir: "/data/home/nodered/.node-red/context",
flushInterval: 300
}
}
}
}
EOF
chown nodered:nodered /data/home/nodered/.node-red/settings-user.js
default reste sur memoryOnly — seul le store nommé file est persistant, à utiliser explicitement là où c’est nécessaire. Le flushInterval de 300 secondes limite la fréquence d’écriture sur la flash embarquée du Cerbo (à ménager, ce n’est pas un disque classique).
Utiliser le store persistant dans le code
Dans un nœud function, il suffit d’ajouter le nom du store en second argument :
// Lecture
let st = context.get('st', 'file') || { phase: "ARM" };
// Écriture
context.set('st', st, 'file');
Sans ce second argument, Node-RED utilise le store default (mémoire uniquement).
Redémarrer Node-RED (pas juste Deploy)
C’est le point qui piège le plus souvent : un simple clic sur Deploy dans l’éditeur ne redéploie que le flow, pas le processus Node-RED lui-même. Les changements dans settings-user.js ne sont lus qu’au démarrage du service. Il faut donc redémarrer Node-RED via SSH :
ls -la /service/ | grep node-red
svc -t /service/node-red-venus
(svc -t envoie un signal TERM au service ; le superviseur runit le relance automatiquement.)
Vérifier que ça fonctionne
ls -la /data/home/nodered/.node-red/context/
Ce dossier n’apparaît qu’après le redémarrage complet de Node-RED (pas au premier Deploy). Son contenu ne se remplit qu’après le premier flushInterval écoulé (5 minutes dans l’exemple ci-dessus) suivant une écriture — un dossier vide juste après redémarrage est normal, pas une erreur.
En résumé
- SSH root : Access Level → User and Installer → maintien 5s sur la ligne → Superuser → Set root password → SSH on LAN
- Contexte persistant : jamais
settings.js, toujourssettings-user.js; déclarer un storefile; l’utiliser explicitement (context.get('x', 'file')) ; puis redémarrer le service, pas juste redéployer.
Article rédigé avec l’assistance de Claude AI (Anthropic) à partir de mes données et retours d’expérience.
