Sauvegarde de serveur écologiquement soutenable (à froid)

Pour les besoins de mes activités pro et associatives, j’ai besoin de faire de la sauvegarde quotidienne de serveur. Les serveurs c’est déjà plutôt énergivore en électricité/climatisation (quoi que pas tant que ça si on s’auto-héberge – pas de climatisation par exemple). Je cherche à faire diminuer le coup énergétique tant que je peux, et les sauvegardes ne sont pas en reste.

Je suis donc parti sur une solution :

  • Froide : c’est-à-dire qui ne serait allumée qu’au besoin (au moment de la sauvegarde) et pas allumée 24h/24 comme à l’habitude dans un datacenter.
  • Faible consommation : Puisque composée d’un Raspberry Pi et d’un disque dur 2,5° = consommation ~3Wh
  • Auto-hébergée : ça veut dire « à la maison », ça évite les climatiseurs des datacenters (vitaux quand la concentration de serveurs est forte) et on garde le contrôle sur les données/le matériel.

En solution logiciel, j’utilise Dirvish, qui est une surcouche à Rsync, qui permet (en gros) de faire des sauvegardes « full » tous les jours en ne copiant que les différences. En gros il ne télécharge et enregistre que les fichiers différents de la veille et utilise l’adresse INODE sur le disque des fichiers qui n’ont pas changé. De cette façon, toute l’arborescence est complète tous les jours mais elle ne prend pas plus d’espace disque que la différence (un peu magique quand on ne connait pas le fonctionnement d’un partitionnement sous linux). De cette façon, ma sauvegarde quotidienne prend ~1h pour sauvegarder ~150Go sur 4 serveurs.

Le matériel utilisé

J’utilise donc pour mes sauvegardes à froid :

  • Un Raspberry Pi (4 ici mais pas vraiment d’importance – quoi que avec un Zero j’ai essayé c’est pas terrible en perf…)
  • Un disque dur 2,5° mécanique (ça serait encore plus économe en électricité avec un SSD) dans un boîtier USB 3.0

Consommation totale : 3Wh constaté au Wattmètre

Comparatif consommation

Pour comparaison (discutable j’en conviens) dans mon cas avec la solution choisie et une VM ou un serveur que j’aurais pu louer dans un datacenter :

RaspberryPi + DisqueDatacenter
Temps d’allumageLe temps de la sauvegarde (ici ~1h mais variable)24h/24h
Consommation électrique (W)38 à 170 (1)
Consommation journalière (Wh/j)3192 à 4080

(1) Consommation serveur nuancée entre une VM (8W) et un serveur physique dédié (170W) – chiffres de l’ADM (source). C’est tout relatif, ça dépend des cas, c’est une hypothèse de travail. Je n’ai pas non plus considéré les équipements actifs pour simplifier (chez moi juste une box, dans un datacenter beaucoup de switch/routeurs : même s’ils sont mutualisés, ça a un coût énergétique).

Avec cette méthode de sauvegarde à froid, dans mon cas, on est entre 64 et 1360 fois moins énergivore que dans le cas d’une sauvegarde ‘classique » en datacenter.

L’allumage automatique peut se faire de différente façon :

  • BIOS : certain bios permette un « réveil » à heure fixe mais ce n’est pas le cas du Raspberry Pi
  • WakeOnLan (fait par le serveur a sauvegarde par exemple)
  • Une prise programmable avec l’heure
  • PvMonit (dans mon cas) logiciel avec lequel je gère le surplus de mon énergie solaire

Dans tous les cas, le Raspberry Pi s’éteint de lui même après la sauvegarde (shutdown -h now dans le script à la fin de la sauvegarde).

Il y a quand même des désavantages à faire la sauvegarde « à la maison » :

  • Débit montant limité : dans le cas ou il faut remonter le serveur en entier (toute la sauvegarde) ça peut prendre un certain temps car le débit montant d’une box est souvent faible
    • Ce cas est très très rare
    • Ce défaut n’est plus si on est en situation auto-hébergée : on va brancher notre disque dur avec la sauvegarde directement sur le serveur à reconstruire
  • Restaurer à distance peut être problématique : si on est pas sur site et qu’on a besoin d’accéder aux sauvegardes, ça peut être problématique
    • Tout dépend de la conception pour l’allumage automatique. Dans mon cas, je peux allumer à distance au besoin avec PvMonit.

Après quelques tests de débits/écritures, voici ce que je constate sur ce « nas » de sauvegarde :

root@nas(ro):/mnt/nas# curl -4 -o ./test100M http://bouygues.testdebit.info/100M.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  7145k      0  0:00:13  0:00:13 --:--:-- 7509k

En comparaison avec mon ordinateur :

david@monordinateurportable:/tmp$ curl -4 -o ./test100M http://bouygues.testdebit.info/100M.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  8424k      0  0:00:11  0:00:11 --:--:-- 8689k

A ~100k de différence ça me semble pas significatif voir même plutôt bon ! (surpris même que ce soit si bon…)

Plus gros, plus redondant

Pour ceux qui ont de plus gros besoins en capacité / redondance de disque, il y a des HAT pour Raspberry Pi où il est possible de connecter plusieurs disques :

Héberger un WordPress : sécurité, optimisation, économie d’énergie

WordPress occupe une part très importante dans l’usage des CMS à l’heure ou j’écris ce billet (62%). Voilà ce qui peut l’expliquer à mon sens :

  • Simple d’utilisation côté utilisateur
  • Plutôt simple côté développeur
  • Un nombre incalculable de thèmes et de plugins sont à disposition (communauté conséquente).

Mais il a aussi les défaut de ses qualités :

  • Côté utilisation de ressources énergétiques (serveur), WordPress est une catastrophe… Surtout dès qu’on lui ajoute des plugins (qui n’en ajoute pas ?).
  • Côté sécurité, il est très attaqué (car très utilisé). Le sport préféré des hackers, c’est le brute force…

Je vais tâcher de balayer ici mes trucs pour transformer un wordpress énergivore en wordpress sobre et sécurisé 🙂

Transformer en site statique (parfait pour les sites vitrines)

Un site « statique » c’est quoi ? C’est un site ou le code est uniquement exécuté sur le client et le serveur ne fait rien d’autre que « servir la page ». Alors qu’un site dynamique par opposition (sous wordpress pour l’exemple) va générer des pages « à la volée » et donc utiliser des ressources sur le serveur.

Mon parti-pris, c’est de convertir le wordpress « visible pour les visiteurs » en site statique « html ». L’utilisateur continue d’utiliser / d’alimenter son site via l’interface (bien faite et connue) wordpress, mais le visiteur lui ce qu’il voit c’est un site « html », sans aucun code dynamique (php ici) exécuté. De cette façon :

  • Le site est inattaquable par les hackers/spameurs, il n’y a plus de code dynamique, donc plus de moyen de corrompre le site / le serveur
  • L’affichage pour le visiteur est beaucoup plus rapide.
  • Le serveur consomme beaucoup moins de ressources (moins d’électricité, plus petit serveur…).
  • Les utilisateurs qui connaissent déjà wordpress ne sont pas bouleversés / impactés par cette optimisation.

Pour cela j’utilise un plugin wordpress qui s’appelle wp2static. Voici la structure du répertoire « web » qui est la racine du site :

  • /wp/ : site wordpress avec le plugin wp2static. Adresse utilisée par l’administrateur du site pour faire ces modifications
  • /static/ : le site statique généré par le plugin
  • /.htaccess : contient les redirections pour que le visiteur ne voit pas de différence

Dans le wordpress installé dans /wp/ rendez -vous dans wp2statics et configuré :

  • Where will you host the optimized version of your site? : Subdirectory
  • Destination URL : http://votresite.fr/
  • Target Directory : /var/www/votreiste.fr/web/static/

Puis dans l’onglet Crawling indiqué :

  • Exclude certain URLs :
    • /wp/
    • /wp-content/uploads/
    • /wp-admin/

Quand c’est fait, vous pouvez cliquer sur Start Static Export.

Ajouter dans votre configuration apache ou dans un .htaccess à la racine du site :

RewriteEngine on
# Pas de ré-écriture pour le contenu uploadé (images, 
RewriteRule ^/wp-content/uploads/(.*)$          /wp/wp-content/uploads//$1 [L]
# Rediriger toutes les requêtes vers /static sauf quand l'accès est souhaité sur le site wordpress original (/wp)
RewriteCond %{REQUEST_URI} !^/wp/ 
RewriteRule ^(.*)$          /static/$1 [L]

Inconvénient majeur de ce type de « transformation » en site full static

  • A chaque modification l’utilisateur doit penser à re-générer le site statique
  • Le contenu dynamique (formulaire de contact / commentaire) est impossible :
    • Pour les commentaires, c’est possible avec des commentaires chargés en Javascript, typiquement HashOver Next (alternative auto-hébergable à DISQUS). J’ai fait un script de migration WordPress > HashOver : wp2hashover
    • Pour les commentaires, il est possible d’utiliser des formulaires en iframe ou formulaire javascript/ajax

Transformer en (presque) site statique (W3 Total Cache)

La solution wp2static n’était pas complètement satisfaisante et j’ai continué mes recherches. En testant le plugin W3 Total Cache, je me suis aperçu qu’il faisait exactement ce que je cherchais à faire et même plus !

Après paramétrage, j’ai trouvé ceci dans le fichier .htaccess :

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
[...]
    RewriteCond %{REQUEST_METHOD} !=POST
[...]
    RewriteCond "%{DOCUMENT_ROOT}/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" -f
    RewriteRule .* "/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" [L]
</IfModule>

Pour résumer, ce que font les règles c’est :

  • Si la page HTML static a été générée (le fichier existe) dans /var/www/decroissant-au-beurre.com/web/wp-content/cache/page_enhanced/decroissant-au-beurre.com/services/_index_ssl.html (pour l’appel à https://decroissant-au-beurre.com/services/ alors on l’appelle directement (pas d’exécution de code PHP… ) SINON on appelle la page « normale » dans wordpress et celui-ci génère la page de cache /static pour le prochain visiteur
  • Dès qu’il y a une requête POST, le cache n’est pas appelé. Donc tous les formulaires restent compatibles avec le cache et seules les pages de résultats ne seront pas tirées du cache.

Ca veut dire qu’a performance égale avec la solution précédente, ce plugin fait mieux car il gomme les défauts précédents et permet de continuer d’utiliser des formulaires/les commentaires.

C’est parfait ! Le cache peut aussi être stocké via memcache et non sur disque (ce qui rend l’accès / l’affichage encore plus rapide (d’autres technologies possibles : APC / Xcache…)

Les fonctionnalités supplémentaires :

Minifier : diminuer trafic réseau

W3 Total Cache propose une fonctionnalité de Minification

minifier signifie réduire la taille du code. C’est un processus très utilisé en programmation web pour réduire la taille d’un programme à télécharger depuis un serveur et ainsi réduire l’encombrement du réseau. Cela peut aussi être considéré comme une forme d’offuscation du code.

Pour cela on supprime tous les commentaires et les espaces qui ne gêneront pas le bon fonctionnement de l’application. On remplace aussi le nom des variables interne à l’application pour les réduire à un seul ou deux caractères. Il est aussi possible d’utiliser certaines écritures compactes propres aux langages (couleur en hexadécimal, raccourcis…)

https://fr.wikipedia.org/wiki/Minification

Si on analyse le code après avoir activé la Minification on observe :

<!DOCTYPE html><html lang=fr-FR><head><script>window.w3tc_lazyload=1,window.lazyLoadOptions={elements_selector:".lazy",callback_loaded:function(t){var e;try{e=new CustomEvent([...]

Alors qu’un site non-minifié donne plutôt :

<!DOCTYPE html>
<html lang="fr-FR">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    
<link rel="stylesheet" id="extend-builder-css-css" href="assets/static/css/theme.css" type="text/css" media="all">
<style id="extend-builder-css-inline-css" type="text/css">
/* page css */
/* part css : theme */

.h-y-container > *:not(:last-child), .h-x-

Vous pouvez minifier tout ou partie du code (HTML/ CSS / Javascript…). Certains plugins peuvent ne plus fonctionner à cause de la minification. Il est donc important de tester votre site après avoir activé ces options.

Lazy Loading : Afficher les images au besoin

Si vous avez un site très long, il est possible que des images soient présentes en bas de page. Il est pertinent de ne charger ces pages qu’au besoin (que si vous allez jusqu’en bas de la page). Et bien la fonction Lazy Loading permet cela.

Cette fonctionnalité permet aussi un gain non négligeable de bande passante.

Mise en cache navigateur

Vous pouvez améliorer les entêtes navigateurs en spécifiant à celui-ci des dates d’expiration de fichier. De cette façon il ne va pas retourner charger la/les pages sur le serveur en cas de nouvelles visites.

Mesures performance

Voilà un stress test (envoi de requêtes massives) du même site avec ou sans génération en site statique (fait avec W3 total cache ici) :

On constate que c’est 20 fois plus rapide à l’affichage et que c’est plutôt constant. Est-ce que c’est 20 fois moins énergivore ? ça c’est difficile à mesurer mais c’est forcément moins…

Voici ci-après le poids de chargement d’une même page sans optimisation et avec Lazy Loading + Minification

  • Sans optimisation : 21,5Mo
  • Avec Minification et Lazy : 3,9Mo

Soit 5,5 fois moins lourd…

Sécurité

Le minimum pour sécuriser un wordpress c’est :

  • Faire les mises à jour (de nombreux plugins existent pour automatiser cela)
  • Ne pas utiliser « admin » en nom d’utilisateur admin
  • Avoir des mots de passe forts
  • Bloquer les tentatives de brutes forces :

WordPress se fait pas mal attaquer du fait qu’il soit populaire. La principale attaque (hors SPAM sur les commentaires) est faite par brute-force sur la page wp-login.php et xmlrpc. J’ai consacré un article dédié pour intégrer les logs de WordPress dans Fail2ban, et ainsi pouvoir bloquer les tentatives au niveau firewall : WordPress & fail2ban : stopper la brute-force « POST /wp-login.php » (uniquement possible sur un hébergement dédié). C’est particulièrement efficace comme vous pouvez le voir sur ce graphique :

Graphique fail2ban sur 1 semaine

Gestion serveur mutualisé

Si vous gérez un serveur mutualisé, vous pouvez déployer le plugin de cache et faire les mise à jour de tous les wordpress installé sur votre serveur avec wp-cli-isp (taillé pour les serveurs sous ISPconfig, mais c’est adaptable)

Diminuer son impact numérique : comment envoyer des pièces jointes

Petit tuto vidéo pour vous expliquer comment envoyer des pièces jointes en limitant votre impact sur l’environnement. Il s’agit d’un service (open source) d’envoi de fichier avec expiration

Le service tourne avec un logiciel libre en PHP (sans base de donnée) que c’est « moi qui l’a fait » : file2link mais il y a beaucoup d’autres alternatives :

PvMonit 3.0 : Cloud + Programmation surplus d’énergie par Blockly

La version 3.0 de PvMonit vient de sortir ! Au programme service de Cloud et gestion simplifié de la programmation des relais pour gérer le surplus d’énergie via Blobkly.

PvMonit c’est un logiciel libre de monitoring de système électrique solaire autonome qui est capable de gérer le surplus d’énergie solaire. Pour en savoir plus c’est par ici

Un petit tour vidéo des nouvelles fonctionnalités :

Démonstration de l’interface blockly dans PvMonit c’est par ici.

Pour souscrire au service Cloud c’est par ici.

Programmer les ordres (surplus électrique)

La doc écrite est ici : https://framagit.org/kepon/PvMonit/-/blob/master/domo/relay.script.d/README.md et la doc vidéo c’est juste en dessous :

Installation / mise à jour

Pour l’installation de PvMonit le tuto se trouve dans le INSTALL.md du projet : https://framagit.org/kepon/PvMonit/-/blob/master/INSTALL.md

Pour les mises à jours, reportez vous au UPGRADE.md : https://framagit.org/kepon/PvMonit/-/blob/master/UPGRADE.md

Si vous n’avez pas les compétences (ou pour soutenir le projet) je propose le service d’installation sur mesure « clef en main » ou le téléchargement d’une image pour la carte SD prêt à l’emploi.

Vous pouvez soutenir le projet par ici.

PvMonit – Boîtier impression 3D

Un utilisateur de PvMonit (logiciel libre de monitoring photovoltaïque autonome et de gestion du surplus solaire) ayant pour alias Akoirium, à contribué à PvMonit en proposant des boîtier imprimable en 3D. Voilà ce que ça donne avant et après :

Pour le TM1638 (circuit de gauche)

Le circuit TM1638 est utilisé pour la gestion de la domotique (optimisation surplus solaire), il existait déjà des modèles de boîtier, Akoirium s’en ai donc inspiré :

  • https://www.thingiverse.com/thing:3578683
  • Un autre modèle : https://www.thingiverse.com/thing:2794902

Voici les fichiers sources sous licence GPL

Pour l’Adafruit 16×2 Character LCD

Pour l’adafruit 16×2, utilisé pour lire les informations de l’installation solaire, Là Akoirium c’est aussi inspiré de projet existant sur thingiverse. C’est pas parfait (il faut gratouillé un peu quand certaine soudures sont trop épaisses), mais c’est franchement pas mal. De mon côté il m’avait envoyé les boutons mais je les ai perdu donc j’ai coupé des visses de 2×20 pour faire les boutons n’ayant pas d’imprimante 3D, ça fait le taf 🙂

Voici les fichiers sources sous licence GPL

Merci encore à Akoirium pour cette contribution !

PvMonit v2.0 + Domotique : Gestion surplus électrique solaire en autonomie

Ou comment utiliser le surplus d’une installation solaire autonome

Dans le cas d’une installation solaire autonome (non raccordée au réseau EDF), une fois que les batteries sont rechargées (ce qui se produit aux alentours de 11h-12h pour moi 80% du temps), il y a de l’énergie potentielle de perdue. Plus précisément, si je n’utilise pas cette énergie au moment où il y a du soleil (de la production), cette énergie n’est pas utilisée. On peut augmenter le stockage mais c’est infini, coûteux en argent et en ressource environnementale. Voilà un graphique pour illustrer ce propos :

Courbe production solaire estivale en situation d’autonomie électrique avec des panneaux photovoltaïques

Du coup, il m’a semblé pertinent de réfléchir à un moyen d’automatiser certaines tâches qui me permettent d’utiliser ce surplus d’électricité quand il est là. Actuellement, je le fais de façon tout à fait manuelle : quand les batteries sont pleines et qu’il y a du soleil, je lance une machine à laver, je lance la pompe de relevage de la phyto, je recharge mes batteries d’outils portatifs…. Cette automatisation va aussi me permettre d’aller plus loin & d’envisager d’installer un petit chauffe-eau électrique de camion (~10L) ou autres…

Grâce à PvMonit, j’avais déjà une remontée d’informations sur l’état de l’installation solaire, des batteries, de la production qui m’arrivait sur un Raspberry PI. Il ne me restait plus qu’à « piloter des prises électriques » en fonction de l’état de l’installation solaire et des conditions que je donne au programme.

Soutenir / Commander

Si vous voulez soutenir le projet ou que vous n’avez pas suffisamment de compétences pour faire tout ça, je peux tout vous préparer à la maison, il n’y aura plus qu’à brancher… C’est à prix libre et c’est sur mesure selon vos compétences/besoins, on en parle ? : https://david.mercereau.info/pvmonit/#shop

Le projet, en vidéo

Le projet, en image

Voilà de quoi est composé le tout :

  • Le raspberry pi (zéro ça suffit) sur lequel est installé PvMonit (expliqué ici) : compter entre 110 et 200€ de matériel
  • Carte module 8 relais 8,99€
  • TM1638 Afficheur 8 chiffres 7 segments, 8 LEDs, 8 boutons (option) 5,49€

Si vous n’aimez pas les vidéos je vous mets des z’images :

Installation

Pour l’installation, vous pouvez vous reporter au dépôt du code source PvMonit, dossier « domo » : https://framagit.org/kepon/PvMonit/blob/master/domo/

Si vous avez des questions / bugs, c’est par ici : https://framagit.org/kepon/PvMonit/issues

PvMonit Domotique v1 béta

Note : c’est une version béta car j’ai pas mal de BUG avec le tm1638, du coup je vais changer mon fusil d’épaule pour la version 2, donc cet article c’est « pour la mémoire », « pour la gloire », mais pas pour la vrai vie…

Ou comment utilisé le surplus d’une installation solaire autonome

Dans le cas d’une installation solaire autonome (non raccordé au réseau EDF), une fois que les batteries sont rechargé (ce qui se produit au alentour de 11h-12h pour moi 80% du temps) il y a de l’énergie potentiel de perdu. Plus précisément si je n’utilise pas cette énergie au moment ou il y a du soleil (de la production) cette énergie n’est pas utilisé. On peut augmenter le stockage mais c’est infini, coûteux en argent en ressource environnementale.

Du coup m’a semblé pertinent de réfléchir à un moyen d’automatisé certaine tâche qui me permette d’utilisé ce surplus d’électricité quand il est là. Actuellement je le fait de façon tout à fait manuel : quand les batteries sont pleine et qu’il y a du soleil, je lance une machin à laver, je lance la pompe de relevage de la phyto, je recharge mes batterie d’outil portatif…. Cette automatisation va aussi me permettre d’aller plus loin & d’envisagé d’installé un petit chauffe eau électrique de camion (~10L) ou autres…

Grâce à PvMonit j’avais déjà une remonté d’information sur l’état du système solaire, des batteries, de la production qui m’arrivait sur un Raspbery PI. il ne me restait plus qu’a « piloter des prises électrique » en fonction de l’état du système solaire et de conditions que je donne au programme.

Le cahier des charges c’était :

  • De pouvoir piloter ce que je veux, mon choix c’est donc porté vers un système de contrôle de relais (en gros des interrupteur contrôlé de façon électronique)
  • Que le système consomme très peu. C’est réussi le système consomme ~0,153W (tout les relais d’éteint), 0,4W avec 1 relais d’allumé (hors PvMonit…)
  • Que je puisse passé certain appareil en « marche forcé » ou en « stop forcé »
  • Que le système soit résilient, qu’il puisse encore fonctionné sans l’apport d’information du raspbery pi en cas de panne

Voilà de quoi est composé le tout :

  • Le raspbery pi (zéro ça suffit) sur lequel est installé PvMonit (expliqué ici)
  • Un arduino UNO qui reçois de potentiel ordre du Raspbery PI avec le protocole i2c. (6€)
  • Un afficheur 8 chiffres + 8 leds + 8 boutons (tm1638) nous permet d’interagire avec le système (forcé l’alumage, interdir l’allumage…) (~6€)
  • Une plaque de 8 relais (mais vous pouvez envisagez en avoir autant que vous voulez… ça correspond à mon besoin…) qui allume tel ou tel appareil pour (9€)

ça nous fait un projet à ~25€ (hors PvMonit) si on considère les fils de prototypage, le câble usb pour l’arduino…

Actuellement je m’en sert pour :

  • Allumer ma box et mon téléphone fixe quand les batteries sont presque pleines (quand le régulateur passe en ABS)
    • Éteindre le téléphone après 19h
    • Éteindre la box après 19h SI plus aucun PC n’est allumé (scan réseau IP)
  • Démarrer la pompe de relevage de la phytoépuration quand les batteries sont pleines
  • Recharger mes batteries d’outils électroportatifs quand la pompe de relevage c’est allumé puis c’est éteinte
  • Démarrer un disque dur externe et ma box pour sauvegarder un serveur en ligne si les batteries ne sont pas trop basses

Et dans le futur :

  • Recharger un vélo électrique l’été
  • Démarrer un petit chauffe eau
  • ?

Le champs des possibles :

  • Allumer un groupe électrogène automatiquement par contacteur si les batteries passe sous un certain seuil
  • Remplir un surpresseur
  • Remonter de l’eau d’un puits
  • Lancer une production d’hydrogène ? …
  • …All is possible …

A l’heure actuelle mes relais sont majoritairement connecté sur un bandeau de prise, ça me permet d’être résiliant. En cas de pépin, si ça marche pas/plus, je peux repassé en mode manuel et débrancher/brancher les prises facilement.

Prés-requis :

  • PvMonit installé et fonctionnel
  • Un BMV de chez Victron de connecté sur PvMonit c’est le mieux, sinon un MPPT de chez Victron toujours (seul constructeur supporté par PvMonit à l’heure actuel)
  • En matériel :
  • Compétence : programmation python (a l’heure actuelle aucune interface graphique n’est à disposition pour organiser les ordre au relais, c’est envisagé pour le futur…)

Pour l’installation, rendez-vous sur la page du projet, dossier « domo » : https://github.com/kepon85/PvMonit/tree/master/domo