C’est un peu la succession, l’amélioration de mon service de sauvegarde à froid, ça va maintenant plus loin, c’est plus « user freindly ». Je le propose avec mon activité pro « retzo.net » :
Le stockage à froid qui s’allume uniquement si vous en avez besoin.
Le constat est simple : la majeure partie des données numériques en ligne n’a aucunement besoin d’être accessible à tout instant et pourtant elle occupe une place conséquente sur des serveurs (coût énergétique, environnemental…)
Les données numériques que nous stockons ont un coût énergétique souvent sous-estimé. Les datacenters, où sont hébergés bon nombre de sauvegardes et de services en ligne, représentent environ 1 % de la consommation électrique mondiale (source). Pour des associations ou entreprises éco-responsables engagées dans une démarche de sobriété numérique, il est donc crucial de repenser la façon dont on stocke et sauvegarde les données. Le stockage à froid s’impose comme une solution incontournable pour réduire drastiquement l’empreinte énergétique de vos sauvegardes tout en gardant vos données en sécurité.
🌍 Les serveurs matériels utilisés sont très basses consommations (architecture ARM, disque SSD)
♻️ Les serveurs (hors disque dur) sont issus du ré-emploi
☀️ L’énergie utilisée prioritairement est le solaire
Et exclusivement si vous le souhaitez
🔒 Vos données sont en sécurité, le service étant hors ligne la majorité du temps, la surface d’attaque est bien moindre
Chiffrement de la communication (inclus)
Chiffrement du disque possible
Serveur dédié possible
⏳ L’accès à vos données, l’allumage du serveur est possible via une interface web et/ou des protocoles standard (SFTP, RSYNC (over ssh), WebDAV, BORG) authentification par mot de passe ou par clé
Le stockage à froid consiste à conserver des données (sauvegardes, archives, etc.) sur un support qui n’est alimenté et allumé qu’en cas de besoin. Contrairement à un serveur classique qui tourne en continu 24h/24, un système à froid reste hors tension la majeure partie du temps. Concrètement selon le cas :
Service de sauvegarde : le serveur est démarré uniquement lors des opérations de sauvegarde ou de restauration, puis éteint dès qu’il a fini son travail. On évite ainsi de faire tourner des disques et des serveurs inutilement le reste du temps.
Vous disposez d’une interface pour allumer manuellement celui-ci pour restaurer des données au besoin
Service d’archivage : le serveur est éteint systématiquement et vous l’allumez sur demande via une interface web pour accéder à vos données, en ajouter, en supprimer…
En résumé, le stockage à froid c’est :
Allumé uniquement à la demande : le système de sauvegarde fonctionne seulement au moment nécessaire (sauvegarde programmée, restauration exceptionnelle), le reste du temps il consomme 0 watt.
Matériel sobre en énergie, issu du ré-emploi : il s’appuie sur un mini-ordinateur à très faible consommation (Raspberry Pi) couplé à des disques SSD. Ce type de dispositif consomme environ 3 watts en activité, soit l’équivalent d’une très petite ampoule LED.
Stockage déporté : généralement, le support de sauvegarde se trouve hors du site principal, ce qui protège vos données en cas d’incident (incendie, vol, panne majeure) sur votre infrastructure principale.
Auto-hébergement en France: la solution est hébergée hors datacenter ce qui diminue le coût environnemental infrastructure, climatisation (obligatoire en cas de concentration de serveur) ici les places seront limitées pour éviter d’avoir à recourir à de la climatisation.
Adopter le stockage à froid pour vos sauvegardes permet de réduire la consommation électrique d’un facteur de plus de 100. En effet, la solution de stockage à froid n’utilise qu’environ 3 W lorsqu’elle est allumée (source) – à peine l’énergie d’une seule petite ampoule – là où un serveur de sauvegarde classique consomme souvent 30 W ou plus en continu (source). Sur une journée, cela équivaut à seulement quelques wattheures (Wh) consommés, contre plusieurs centaines de Wh pour une machine fonctionnant 24h/24. On obtient ainsi jusqu’à 100 fois moins d’énergie utilisée (par exemple ~3 Wh/jour contre ~300 Wh/jour dans une configuration classique).
Une infrastructure éco-conçue et sans climatisation
Une autre force du stockage à froid écologique réside dans l’infrastructure matérielle et architecturale qui l’accompagne. Ici, tout est pensé pour minimiser l’impact environnemental :
Matériel basse consommation, issu du ré-emploi : Le cœur du système est un mini-ordinateur de type Raspberry Pi, un appareil de la taille d’une carte de crédit qui consomme seulement quelques watts mais suffit amplement pour gérer des sauvegardes, archiver des données. Ce petit ordinateur, couplé à un disque dur 2,5” économe en énergie, constitue un serveur silencieux et frugal.
Alimentation solaire et autonomie énergétique : Le dispositif peut être alimenté par une installation solaire, cette énergie est utilisée en priorité. Vous pouvez choisir le mode de fonctionnement selon vos critères (énergie solaire prioritaire, exclusivement du solaire…)
Local bioclimatique : Le matériel de sauvegarde est hébergé dans un bâtiment éco-construit en adobe (des briques de terre crue façonnées à partir de terre locale). Ce local a été conçu en auto-construction selon les principes bioclimatiques : il est orienté plein nord pour éviter l’exposition directe au soleil, ce qui le maintient naturellement frais. Les murs en terre crue offrent une excellente inertie thermique, gardant l’intérieur à une température stable. De plus, une ventilation naturelle a été mise en place grâce à des « chapeaux de cheminée » (éoliennes statiques sur le toit) qui créent un tirage d’air frais constant. Résultat : même en été, la température à l’intérieur reste modérée, nul besoin de climatisation artificielle.
Accéder à une interface de démonstration simple
Le mode SFTP distant n’est pas permis ici pour la démonstration, vous avez seulement un accès HTTP et de façon limitée en quota disque.
WakeOnStorage permet d’accéder à distance à des ressources de stockage ou à des petits serveurs domestiques, tout en les maintenant éteints la plupart du temps pour économiser l’énergie, réduire la surface d’attaque
Le principe repose sur deux composants complémentaires :
Interface en ligne (wakeonstorage.retzo.net) — accessible depuis Internet — qui permet à l’utilisateur de visualiser l’état de ses ressources, de les allumer temporairement, et d’y accéder une fois disponibles.
API locale (wakeonstorage-local) — installée sur le réseau local — qui communique avec le matériel (disques USB contrôlé par PPPS, Raspberry Pi allumé par relais…) pour exécuter les ordres.
By mermaid
Lorsqu’un utilisateur demande une ressource, l’interface interroge l’API locale. Si la ressource est déjà allumée, elle devient directement accessible. Si elle est éteinte, l’interface propose de l’allumer pour une durée déterminée (par exemple 2 heures).
L’API locale envoie alors les commandes nécessaires : activation d’un relai pour démarrer un Raspberry Pi, ou alimentation d’un disque dur via un hub USB pilotable (PPPS) Une fois la ressource allumée, l’accès est temporairement autorisé.
Ce fonctionnement en deux niveaux garantit la sécurité, la sobriété énergétique et l’autonomie : aucune ressource n’est inutilement allumée, et tout reste sous le contrôle de l’utilisateur.
J’ai un petit groupe de musique dans lequel je fais de la percussion avec petit set Cajon + accessoires, pour faire une mini batterie transportable à vélo… Nous sommes amateurs ; j’ai rejoint le groupe en cours de route, et ils avaient collectivement acheté la table de mixage et la sono pour les concerts. De mon côté, je me suis dit que j’allais mettre au pot en achetant les lumières.
Un jour, à la déchetterie, j’ai trouvé 2 petits projecteurs LED RVB pilotables par DMX : « Algam Lighting SLIMPAR 710 HEX« . Ils étaient hors d’usage, mais après le passage entre les mains d’un ami magicien de l’électronique, ils ont ressuscités 🙂
La consommation électrique est un point important. Nous avons une petite sono qui consomme ~60W de moyenne, avec des pics à 120W. Il nous arrive de jouer en « autonomie » (dans les bois par exemple) sur ma batterie de vélo 48V, avec un convertisseur 48V-350W de chez Victron. Celle-ci nous permet de tenir ~4h de concert sans problème (on a un set de ~1h alors on est large). Les 2 projecteurs LED consomment ~10W chacun, ce qui fait qu’on devrait pouvoir largement jouer notre concert, même avec les 2 projecteurs, même avec 3 rappels 🙂
Console DMX pour Cajon
Je me suis lancé dans la création d’une commande DMX pour mon Cajon. Afin de pouvoir jouer + commander les lumières par le protocole DMX.
Démonstration vidéo
Préparation lumière sur logiciel
Je suis parti sur le logiciel QLC+, qui est open source, plutôt complet (pour ce que j’ai à faire) et léger. J’ai l’ambition de faire tourner ma mini console sur un Raspberry pi. Dans QLC+, je peux préparer des séquences / ambiances par morceau, et passer d’une ambiance à une autre.
Par exemple, sur la capture ci-après – qui correspond au morceau « Tu veux ou tu veux pas », il y a plusieurs ambiances selon si c’est le moment de l’intro, du refrain, d’un solo…. J’utilise les cadres avec pagination pour « passer au morceau suivant ».
Je vous partage mon fichier qxf, qui permet au logiciel QLC+ de « comprendre » ces projecteurs. Je l’ai créé à partir de l’Éditeur d’appareil QLC+ (qlcplus-fixtureeditor) :
Revenir à l’ambiance lumière précédente (en cas de pépin)
Passer à la page/morceau/séquence suivant
Taper la pulsation (s’il y a des ambiances qui « clignotent », je veux que celles-ci soient en rythme…). 2 tapes à intervalle suffisent à donner la pulsation, il ne reste qu’à la suivre…. A noter que la pulsation peut être détectée via un micro USB sur le Raspberry Pi avec le Audio Trigger dans QLC+. C’est ce que j’ai finalement privilégié…
Rapidement, je me rends compte qu’il me faudra doubler ces 4 commandes :
4 boutons accessibles aux mains (si j’ai les pieds occupés)
Et oui, parce que ça dépend des morceaux… Parfois je fais du cabassa, parfois du cajon…
Voilà le schéma de câblage / branchement sur le Raspberry pi des boutons :
Schéma de câblage / branchement sur le Raspberry
Si vous suivez, vous voyez 3 boutons sur le schéma alors qu’il y en a 4… J’ai changé d’avis en cours de route, et j’ai pas changé mon schéma. Mais vous avez l’idée générale…
Une fois soudé, j’ai tout rangé dans des petites boîtes en chutes de contre plaqué ou autres qui traînaient :
Façade pédaleL’intérieur de la pédale est dédié à l’électroniqueConnexion des boutons d’arcade pour la commande manuelle
Une fois que mes ambiances sont « calées », et que les connexions sont faites, je peux installer un linux (avec interface) sur un Raspberry pi. Désormais, il me faut faire en sorte que les boutons que j’ai connectés sur le GPIO du Raspberry interagissent avec QLC+.
Option 1 : websockets
Option très propre, puisque QLC+ intègre un websockets (moyennant le lancement avec un « -w » de QLC+) qui permet d’interagir avec le logiciel lancé en tâche de fond par script :
import asyncio
import websockets
async def test():
async with websockets.connect('ws://127.0.0.1:9999/qlcplusWS') as websocket:
# Play
await websocket.send("2|PLAY")
response = await websocket.recv()
print(response)
asyncio.get_event_loop().run_until_complete(test())
Seulement, toutes les fonctionnalités des consoles virtuelles ne sont pas implémentées… Par exemple, je ne pouvais pas ajuster le tempo (Widget durée).
Option 2 : simuler un clavier
C’est l’option retenue, je simule l’appui sur une touche de clavier quand un bouton est pressé (signal GPIO d’un bouton poussoir). Je m’explique :
QLC+ peut facilement être piloté par clavier, les raccourcis sont facilement paramétrables. Ainsi, j’ai paramétré plusieurs raccourcis :
d : démarrer le séquenceur du morceau
f : stopper le séquenceur du morceau
q : ambiance suivante
s : ambiance précédente
z : page suivante (morceau suivant)
x : allumer le micro pour détecter le tempo
w : déterminer la durée (taper le tempo)
Ensuite, pour simuler mes touches de clavier en fonction des boutons pressés (GPIO activé), j’ai fait un petit script en python avec la librairie pyautogui qui simule un clavier, voici les dépendances :
#-------------------------------------------------------------------------------
# Bibliothèques
#-------------------------------------------------------------------------------
import RPi.GPIO as GPIO #bibliothèque RPi.GPIO
import time #bibliothèque time
from pyautogui import press, typewrite, hotkey #clavier virtuel
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
# Configuration
#-------------------------------------------------------------------------------
pin1 = 17 #broche utilisé en entrée
pin2 = 18 #broche utilisé en entrée
pin3 = 27 #broche utilisé en entrée
pin4 = 22 #broche utilisé en entrée
pinLed = 23 # Broche de la led
ledUpTime = 500 # Temps d'allumage de la LED
# Temp de rebond :
temps = 100 #valeur attente en msec
#-------------------------------------------------------------------------------
# Préparation
#-------------------------------------------------------------------------------
GPIO.setwarnings(False) #désactive le mode warning
GPIO.setmode(GPIO.BCM) #utilisation des numéros de ports du
#processeur
GPIO.setup(pin1, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(pin2, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(pin3, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(pin4, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(pinLed, GPIO.OUT, initial=GPIO.LOW)
#mise en entrée du port GPIO 22
#et activation résistance soutirage
#au ground
# Passer sur Qlight+ si ce n'est pas le cas
print("alt tab")
hotkey('alt', 'tab')
time.sleep(3)
#-------------------------------------------------------------------------------
# Lancement
#-------------------------------------------------------------------------------
ledup=False
if __name__ == '__main__':
GPIO.output(pinLed, GPIO.HIGH) # Turn on
time.sleep(2)
GPIO.output(pinLed, GPIO.LOW) # Turn off
print("Début du programme") #IHM
print("Sortie par ctrl-c\n") #IHM
try:
while True: #boucle infinie
# Gestion de l'extinciton de la led
if (ledup != False) :
now = time.time()
if (now < ledup+ledUpTime):
GPIO.output(pinLed, GPIO.LOW) # Turn off
ledup = False
# Gestion des boutons
entree1 = GPIO.input(pin1) #lecture entrée
entree2 = GPIO.input(pin2) #lecture entrée
entree3 = GPIO.input(pin3) #lecture entrée
entree4 = GPIO.input(pin4) #lecture entrée
if (entree1 == False): #si touche appuyée
GPIO.output(pinLed, GPIO.HIGH) # Turn on
print("Press f (Stop séquence)")
press('f')
time.sleep(0.5)
print("BP 1 appuyé") #IHM
print("Press z (Page suivant) - N")
press('z')
time.sleep(0.5)
print("Press d (Start séquence)")
press('d')
time.sleep(0.5)
print("Press x (Allumer le micro)")
press('x')
ledup = time.time()
if (entree2 == False): #si touche appuyée
GPIO.output(pinLed, GPIO.HIGH) # Turn on
ledup = time.time()
print("BP 4 appuyé - T") #IHM
print("w (tape)")
press('w')
if (entree3 == False): #si touche appuyée
GPIO.output(pinLed, GPIO.HIGH) # Turn on
ledup = time.time()
print("BP 2 appuyé - P") #IHM
print("Press q (Pas prédent)")
press('q')
time.sleep(0.5)
if (entree4 == False): #si touche appuyée
GPIO.output(pinLed, GPIO.HIGH) # Turn on
ledup = time.time()
print("BP 3 appuyé - S") #IHM
print("s (Pas suivant)")
press('s')
time.sleep(0.5)
time.sleep(temps / 1000) #attente en msec
except KeyboardInterrupt: #sortie boucle par ctrl-c
GPIO.cleanup() #libère toutes les ressources
print("\nFin du programme\n") #IHM
Pour le lancement, au démarrage du Raspberry, je place des fichiers « .desktop » dans le répertoire .config/autostart/ de l’utilisateur « pi » que j’utilise pour lancer l’interface graphique.
Le script qui simule le clavier est lancé avec .config/autostart/button-qlcplus-controle.desktop
Pour le lancement de QLC+, c’est le fichier .config/autostart/qlcplus.desktop :
[Desktop Entry]
Type=Link
Name=Q Light Controller Plus Web
Icon=qlcplus
Exec=qlcplus -f -k -w -o DMX/fichierQLC.qxw
StartupNotify=false
Retour visuel
Même si c’est pas indispensable, pour savoir où on en c’est pratique d’avoir un retour visuel sur la console virtuelle de QLC+. Ce que j’ai fait, c’est que j’ai mis le Raspberry Pi en mode « Hotspot Wifi » (en gros, comme votre box – des tuto plein le web pour faire ça…), et je m’y connecte avec mon téléphone portable. De là, je peux :
Voir la console en mode web (lancer QLC+ avec un « -w »)
Voir l’écran avec VNC (sur un téléphone linux, j’utilise AVNC).
Voilà ce que ça donne :
Le téléphone posé sur le pupitre, pour suivre « là ou j’en suis »Ma console « pour jouer »Console paginée par morceau avec, ici, différentes ambiances pour 1 morceau
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.
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
Le matériel utilisé (Raspberry PI + Disque dur SATA USB3 2,5°)Consommation constatée au Wattmètre : 3W
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 + Disque
Datacenter
Temps d’allumage
Le temps de la sauvegarde (ici ~1h mais variable)
24h/24h
Consommation électrique (W)
3
8 à 170 (1)
Consommation journalière (Wh/j)
3
192 à 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…)
Je ne maintient actuellement plus PvMonit. Je tâche de faire prochainement un article pour vous donner quelques alternative.
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.
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.
Je ne maintient actuellement plus PvMonit. Je tâche de faire prochainement un article pour vous donner quelques alternative.
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
Si vous n’aimez pas les vidéos je vous mets des z’images :
Schéma de câblage complet (PvMonit + domotique)Schéma de câblage hors PvMonitCapture d’écran interface PvMonit avec module domotiqueLa façadeArduino qui récolte les informationsLe câble ve.direct DIYLe tout connecté et fonctionnelEn prod
Je ne maintient actuellement plus PvMonit. Je tâche de faire prochainement un article pour vous donner quelques alternative.
PvMonit est arrivé à une version « mature », une version 1.0. PvMonit est un logiciel sous licence Beerware qui vous permet de monitorer votre installation électrique solaire autonome, plus particulièrement avec les appareils Victron.
Nouvelle version pvmonit dispo ici. Avec une « sur-couche » à PvMonit pour gérer le surplus d’électricité : Déclencher des actions à la demande. Exemple : les batteries sont pleines, on allume une pompe à eau puis la résistance électrique d’un chauffe eau. Ou encore, les batteries sont sous un seuil critique, on coupe tout sauf l’éclairage…. toutes les applications sont possibles !
PvMonit C’est quoi ?
PvMonit, c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (le minimum pour que cela fonctionne est d’avoir un BMV 600, 700 ou 702…), particulièrement adapté pour les installations autonomes (hors réseau). Il permet une vue « en direct » par interface web et un enregistrement de l’historique (avec emoncms, branche d’OpenEnergyMonitor).
PvMonit vue standardPvMonit avec détailsEmoncms Tableau de bord
Mon usage
Je collecte les information de mon système photovoltaïque (température, état des batteries, production solaire, etc…) par une carte électronique (Arduino) qui se trouve dans un local à 35m de mon habitation. Je transporte ces données par un 3 fils dans un câble réseau. Celui-ci est connecté à un mini ordinateur (raspberry pi 0) sur lequel j’ai un écran LCD qui m’affiche l’état du système et j’ai un interface web (démo) ou j’ai plus de détails. Il y a aussi un historique qui est enregistré via emoncms (démo).
Au niveau Matériel
2 versions possibles :
Une version Raspberry PI 3B, si vous avez un point wifi actif (même occasionnellement) et que votre matériel solaire est à porté de wifi. C’est une solution plutôt simple (si on touche un peu sous linux).
Une version Raspberry Pi 0 + Arduino : plus complexe à mettre en œuvre (il faut savoir souder et avoir plus de connaissances), mais beaucoup plus souple et moins chère. Particulièrement adapté si votre installation réseau est loin (max 60m) de votre maison ;
L’usage des câbles ve.direct USB officiel permet de simplifier le montage.
Le hub USB avec les câbles Ve.direct sous la multiLe raspberry tout à gaucheLa pince ampèremétrique USB pour la consommation de l’habitatSchéma de câblage
Arduino + Raspbery Pi 0
L’usage d’un arduino pour collecter les données donne de la souplesse pour pouvoir ajouter des sondes à volonté et permet de parcourir de grande distance jusqu’au Raspberry PI qui récupère les informations. Un schéma de câblage détaillé :
Le schéma de câblage détaillé
Voilà ce que ça donne, c’est plus de boulot, plus de soudure mais plus DIY, plus fun :-p
Le schéma de câblage détailléLes connecteurs MOLEX en cours de connexionLe Shield de l’arduino mega en cours de soudureTest de récupération des données avec Arduino et câble ve.direct DIYLe câble ve.direct DIYSonde de courantLe tout connecté et fonctionnelL’écran LCD dans la maison (le Pi est derrière)
Installation
Il ne faut pas se mentir, ça demande de bonnes connaissances techniques en linux/réseau voir arduino/soudure (si vous choisissiez cette option).
Cet article fait suite à la réalisation de mon installation électrique solaire autonome. Je suis très content de celle-ci, seulement j’ai un grand besoin de maîtrise, et ne pas savoir tout ce qui se passait dans ces petites boîtes bleues me taraudait… Il fallait que je monitor. Coup de chance, les appareils Victron que j’ai installés peuvent se connecter à un ordinateur avec les câbles VE Direct USB.
En bon libriste que je suis, j’ai vite découvert OpenEnergyMonitor project. J’ai failli craquer pour un emonPi – Solar PV mais ça ne correspondait pas complètement à mes contraintes. J’ai donc pris mes petits doigts et j’ai pondu PvMonit.
PvMonit C’est quoi ?
PvMonit c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (USB), particulièrement adapté pour les installations autonomes. Il permet une vue « en direct » et un export de l’historique vers emoncms (une branche d’OpenEnergyMonitor project).
Exemple d’usage de PvMonit (le mien) : je dispose d’un RaspberryPi (mini ordinateur qui ne consomme que ~3W), mes appareils Victron (MPTT, BMV) sont connectés avec des câbles VE.Direct USB. PvMonit est installé sur ce RaspberryPi et me permet :
D’afficher les informations en temps réel sur une page web (local)
Une copie de cette page est faite toutes les heures (si la connexion internet est allumée) et est accessible ici : http://demo.zici.fr/PvMonit/
De collecter les données toutes les X minutes et les expédier vers emoncms quand internet est là (le wifi n’étant pas toujours allumé)
Un ordinateur faible consommation configuré sous Debian ou un dérivé type Ubuntu/Raspbian (j’ai fait un article sur l’installation de mon Raspberry PI) 68€ (d’occasion avec coque, ventilateur, carte SD)
Les câbles Ve.Direct USB connectés à vos appareils 30€ (x3 car 3 appareils à connecter)
En option :
Une sonde de température USB pour contrôler la température du local où vivent les batteries. J’utilise « thermomètre USB TEMPer » qui coûte entre 5 et 20€, (ils en parlent ici)
Une pince ampèremètre USB pour contrôler la consommation de l’habitat. J’utilise la Aviosys 8870 à 27€ quand même, mais il ne semble pas y avoir beaucoup de concurrence pour ce type de produit… (j’en parle ici)
Voici le schéma de mon installation avec le câblage pour PvMonit incorporé :
Et voilà dans la vraie vie :
Le hub USB avec les câbles Ve.direct sous la multi
Le raspberry tout à gauche
La pince ampèremétrique USB pour la consommation de l’habitat
Le logiciel : Installation de PvMonit
Requis
Linux (le tutoriel ci-dessous est prévu pour Debian/Rasbian/Ubuntu like)
PHP (5.6 minimum)
Lighttpd/Apache (ou autre serveur web)
Perl
Python
Installation
PvMonit dispose de deux fonctions dissociées et indépendantes que je vais distinguer :
Interface en temps réel
Export vers emoncms
Il y a bien sûr une base commune :
La base / le socle
Installation de PvMonit via le dépôt git et de ses dépendances :
Vous pouvez maintenant éditer le fichier config.php à votre guise !
Test du script vedirect.py : branchez un appareil Victron avec un Câble Ve.Direct USB et voici un exemple de ce que vous devriez obtenir (Ici un MPTT BlueSolare branché sur le ttyUS0)
$ su - pvmonit -c /opt/PvMonit/getForEmoncms.php
2016-11-02T10:55:30+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBleu
2016-11-02T10:55:30+01:00 - Les données sont formatées comme ceci : V:26180,I:800,VPV:56360,PPV:21,CS:3,ERR:0,H19:3352,H20:5,H21:51,H22:33,H23:167
2016-11-02T10:55:31+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBlanc
2016-11-02T10:55:31+01:00 - Les données sont formatées comme ceci : V:26200,I:600,VPV:53630,PPV:18,CS:3,ERR:0,H19:1267,H20:4,H21:46,H22:17,H23:201
2016-11-02T10:55:31+01:00 - Après correction, la température est de 11.88°C
2016-11-02T10:55:31+01:00 - Tentative 1 de récupération de consommation
2016-11-02T10:55:32+01:00 - Trouvé à la tentative 1 : la La consommation trouvé est 00.1A
2016-11-02T10:55:32+01:00 - La consommation est de 00.1A soit 23W
Test d’envoi des données :
$ su - pvmonit -c /opt/PvMonit/sendToEmoncms.php
2016-11-02T10:56:44+01:00 - Données correctements envoyées : 1, données en erreurs : 0
Mettre les scripts en tâche planifiée
crontab -e -u pvmonit
Ajouter :
+# Script de récupération des données, toutes les 5 minutes
+/5 * * * * /usr/bin/php /opt/PvMonit/getForEmoncms.php >> /tmp/PvMonit.getForEmoncms.log
+# Script d'envoi des données, ici toutes les 1/2 heures
+3,33 * * * * /usr/bin/php /opt/PvMonit/sendToEmoncms.php >> /tmp/PvMonit.sendToEmoncms.log
Je n’explique pas ici comment configurer emoncms, les flux pour obtenir de beaux dashboard, je vous laisse lire la documentation…
J’utilise la sonde thermomètre USB TEMPer, cette sonde fonctionne avec le logiciel temperv14 qui est plutôt simple à installer
apt-get install libusb-dev libusb-1.0-0-dev unzip
cd /opt
wget http://dev-random.net/wp-content/uploads/2013/08/temperv14.zip
#ou un miroir
#wget http://www.generation-linux.fr/public/juin14/temperv14.zip
unzip temperv14.zip
cd temperv14/
make
Test de la sonde :
$ /opt/temperv14/temperv14 -c
18.50
Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :
J’utilise la pince ampèremétrique USB Aviosys 8870 pour mesurer ma consommation électrique.
Le petit script perl (/opt/PvMonit/bin/ampermetre.pl) est très simple pour lire la pince ampèremétrique, qui sera branchée en USB et apparaîtra dans votre système sur le port /dev/ttyACM0
Celui-ci dépend de la librairie serialport :
aptitde install libdevice-serialport-perl
Test : :
$ /opt/PvMonit/bin/ampermetre.pl
00.1A
Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :
En continuant à utiliser le site, vous acceptez l’utilisation des cookies (au chocolat) Plus d’informations
Les cookies sont utilisés à des fin de statistique de visite du blog sur une plateforme indépendante que j'héberge moi même. Les statistiques sot faites avec un logiciel libre. Aucune information n'est redistribué à google ou autre. Je suis seul autorisé à lire ces informations
