par Anne-Laure DELPECH | 14 Juil 2016 | Archives
Je veux disposer d’un disque dur accessible en permanence dans la maison. Mais je ne souhaite pas le connecter à un PC à cause de la consommation d’énergie d’un tel appareil. Je vais donc le connecter à un Raspberry Pi qui pourra rester allumer en permanence et mettre les fichiers à disposition.
31/08/2022 : Je viens de mettre en service un Raspberry Pi 3B et le contenu de cet article est toujours d’actualité. J’ai juste apporté quelques précisions.
Préparer le Raspberry Pi
J’ai utilisé un Raspberry Pi 3B, avec un dongle wifi Edimax EW-7811Un.
J’ai installé l’OS Raspberry Lite en 64 bits (version de fin août 2022) selon la méthode décrite dans Mise en service d’un Raspberry Pi.
Mettre le Pi à jour
Exécuter
apt update
apt upgrade
Connecter un disque dur ou une clé USB
J’ai connecté une clé USB de 32 Go.
Un disque dur doit avoir une alimentation externe. Le Pi ne pourra pas lui fournir assez d’énergie. Le disque est donc connecté d’une part à une source d’énergie, d’autre part à un port USB du Raspberry Pi pour l’échange de données.
On peut connecter le disque au Pi sans manipulations préalables. Mais ensuite il faut faire des réglages pour accéder au disque et le partager avec d’autres équipements du réseau local.
Pour ce qui suit, je me suis inspirée principalement des articles suivants :
identifier le type de disque dur
Pour savoir quel type de disque dur on a, on tape :
blkid
Le Pi nous répond avec la liste des unités de stockage qu’il a identifié. Pour moi, il y a les 3 partitions de la carte SD du Pi et le disque dur IOMEGA_HDD que je viens de connecter :
J’apprends ainsi que le disque est monté comme sda1 et qu’il est de type NTFS (le système de fichiers).
Comme le disque utilise le système NTFS, j’installe les drivers correspondants sur le Pi :
apt-get install ntfs-3g
Monter le disque de manière permanente
Si je décide de connecter un autre disque dur, ou une clé USB, le disque Iomega pourrait devenir sda2 et je ne saurai plus comment y accéder. Il faut donc lui donner une « adresse » permanente.
On crée un répertoire sur lequel on va monter le disque dur :
mkdir /media/iomega
Evidemment on peut appeler le répertoire comme on veut, la seule contrainte est que ce soit un sous-répertoire de /media .
Il faut pouvoir donner l’accès à ce répertoire. Dans mon cas, c’est à l’utilisateur al que je veut donner l’accès. Pour savoir quel est l’identifiant de l’utilisateur (-u ) al et du groupe (-g )correspondant, je tape :
id -u al
id -g al
La réponse est 1001 pour les deux. Je sais donc que ‘group id’ est 1001 et ‘user id’ est 1001. Pour donner la propriété d’un répertoire au fichier, on définit d’abord l’utilisateur, ensuite le groupe ([utilisateur]:[groupe] ) :
chown 1001:1001 /media/iomega
Pour monter le disque dur de manière permanente sur /media/iomega :
mount -t ntfs-3g -o uid=1001,gid=1001 /dev/sda1 /media/iomega
Si le disque était en FAT32, j’aurais utilisé -t vfat à la place de -t ntfs-3g .
02/01/2018 : En entrant cette commande j’ai eu une erreur « Mount is denied because the NTFS volume is already exclusively opened.« . J’ai simplement déconnecté le disque avec la commande umount /dev/sda1 puis exécuté de nouveau la commande précédente.
A partir de maintenant, si je veux déconnecter le disque dur, j’utilise la commande :
umount /media/iomega
Dans /etc/fstab , j’ajoute la ligne suivante :
/dev/sda1 /media/iomega ntfs nofail,uid=1001,gid=1001 0 0
Noter la règle nofail , qui permet d’éviter que le Pi ne bloque au démarrage si le disque dur n’est pas connecté ou pas prêt. On vérifie que tout va bien avec mount –a . S’il n’y a pas d’erreur, pas de souci.
Enfin, j’ajuste les paramètres de démarrage du Pi pour laisser le temps au disque dur de démarrer et d’être monté.
On édite /boot/cmdline.txt et on ajoute rootdelay=5 à la fin de l’unique ligne qu’il contient :
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=5
Je redémarre le Raspberry Pi et je vérifie que tout va bien en allant regarder le contenu de /media/iomega.
A ce stade, je fais une copie de la carte SD.
Accès au disque par Filezilla
A ce stade je peux transférer des fichiers dans la clé USB en utilisant Filezilla pour un accès FTP.
Partager le disque dur avec Samba
Pour cette phase, j’ai suivi les instructions de ces deux sites :
Samba a été installé lors de la mise en service du Pi. Il ne reste plus qu’à le configurer pour partager le disque dur externe. Il vaut mieux créer une copie du fichier de configuration avant de le modifier :
cp /etc/samba/smb.conf /etc/samba/smb.old
On édite ensuite /etc/samba/smb.conf et on y ajoute tout à la fin :
[MUSIC]
comment = Musique AL
path = /media/iomega
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no
browseable = yes
public = yes
Je ne suis pas très sûre des raisons d’être de la plupart des lignes. Mais valid users définit que tous les utilisateurs du groupe users auront droit d’accès.
On redémarre samba pour utiliser les nouveaux paramètres :
service smbd restart
Accéder au disque de l’extérieur
Avec certaines versions de Windows, je peux maintenant voir le disque Iomega dans l’explorateur de fichiers, sous « réseau ». Avec d’autres versions (Windows 10 en particulier), il faudra que je crée une « connexion réseau ». Mais dans tous les cas Windows me demandera un nom d’utilisateur et un mot de passe…
créer un nom d’utilisateur Samba
Sur le Pi, j’ajoute un utilisateur ‘alwindows’ qui fera partie du groupe users, que j’ai précédemment défini comme pouvant accéder au disque (dans smb.conf).
useradd alwindows -m -G users
Je crée un mot de passe samba pour cet utilisateur. Le Pi me demande de l’entrer deux fois :
smbpasswd -a alwindows
Je redémarre samba.
service smbd restart
Sous Windows 10, créer un lecteur réseau
Dans l’ordinateur Windows si je vois le disque dur sous « Réseau », je clique dessus et je met cet utilisateur et le mot de passe.
Sous Windows 10 (et dans d’autres cas si mes souvenirs sont bons), il faut créer un lecteur réseau.
Dans l’explorateur de fichier, cliquer à droite sur « Ce PC » et choisir « connecter un lecteur réseau » :
Indiquer la localisation du lecteur : \\NomDuPi\NomDuDisqueDansSamba :
Entrer le nom d’utilisateur Samba et le mot de passe précédemment défini :
J’ai maintenant accès au disque dur géré par le Raspberry Pi sous « Ce PC »
Et voilà. Les fichiers de ce disque sont accessibles 24h sur 24 sans laisser un ordinateur énergivore en fonctionnement !
par Anne-Laure DELPECH | 5 Juil 2016 | Archives
J’ai un Raspberry Pi réglé en tant que serveur web et qui gère motion, un programme pour configurer et diffuser des flux vidéos. L’un de ces flux vidéos provient d’une vieille tablette android, dont la caméra avant a été transformée en caméra IP (article ici). Ce que je veux maintenant c’est que la tablette, qui sera fixée au mur dans un couloir, affiche en permanence le contenu d’une page web qui montre entre autres les flux vidéos capturés. J’ai donc créé une application android pour la tablette, avec App Inventor.
Je considère ici que le lecteur connaît le fonctionnement d’App Inventor. Si ce n’est pas le cas, cette page en anglais donne les bases.
Document et fichiers de l’application mis à jour le 19/7/2016 pour permettre à l’utilisateur de définir l’url à afficher. Voir paragraphe « la version 3 ».
L’application avec App Inventor
Pour afficher une page web avec une application App Inventor, on a deux solutions possibles :
- avec un « web viewer » ;
- avec « activity starter », qui démarre alors le navigateur web de l’appareil ;
Et il faut interdire l’écran d’économie d’énergie
Comme la tablette sera constamment branchée, je préfère qu’elle soit toujours visible plutôt que d’avoir à la « tapoter » à chaque fois.
J’ai donc adopté l’astuce issue de cette source, pour garder l’écran allumé en permanence. Une horloge déclenche toutes les x secondes (TimerInterval) une notification d’alerte. Comme l’alerte a été réglé pour que sa couleur de fond et son texte soient transparents, on ne voit pas qu’elle apparaît et elle empêche l’écran de s’éteindre. C’est la partie when Clock1.Timer des blocs qui suivent.
Solution 1 avec webviewer
En mode « designer » :
- screen1 est en sizing « fixed », ScreenOrientation en « sensor » ;
- Dans les « non visible components », on trouve trois composants :
- webviewer, qui visualise une page web ;
- notifier1 réglé avec BackgroundColor et TextColor sur « none » ;
- clock1 avec TimerAlwaysFires et TimerEnabled cochés, TimerInterval sur 5000 (ce sont des millisecondes en principe, donc ici 5 secondes)
En mode « blocks » :
Voici le fichier en .aia utilisable sur MIT App Inventor (à renommer en .aia au lieu de .zip) : raspberry_pi_dashboard_webviewer
Et voici l’affichage qui en résulte (malgré les règles de style responsive…), en mode portrait puis paysage :
Solution 2 avec « Activity Starter »
En mode « designer » :
- screen1 est en sizing « fixed », ScreenOrientation en « sensor » et contient un « label » et un bouton ;
- Dans les « non visible components », on trouve trois composants :
- activityStarter, dont la propriété action est « android.intent.action.VIEW » et la propriété DataUri est « http://192.168.1.30/ » ;
- notifier1 réglé avec BackgroundColor et TextColor sur « none » ;
- clock1 avec TimerAlwaysFires et TimerEnabled cochés, TimerInterval sur 5000 (ce sont des millisecondes en principe, donc ici 5 secondes)
En mode « blocks » :
Voici le fichier en .aia utilisable sur MIT App Inventor (à renommer en .aia au lieu de .zip) : raspberry_pi_dashboard_activity_starter
Et voici l’affichage qui en résulte. On voit que c’est nettement mieux adapté car les caractéristiques responsive de ma page sont correctement respectées :
La version 3
Je me suis rendu compte que ce n’était pas très pratique : si l’adresse du tableau de bord change, je suis obligée d’aller changer un bloc dans appinventor puis de reconstruire l’application avant de l’installer sur la tablette destinataire. J’ai donc réalisé une version 3, dans laquelle l’utilisateur décide lui-même quelle sera l’adresse de la page à ouvrir.
J’ai mis l’adresse actuelle de mon tableau de bord par défaut (192.168.1.103) mais l’utilisateur peut maintenant en changer sans difficulté. On peut même taper ‘google.com’ et accéder ainsi à la page http://google.com.
L’interface utilisateur (photo à droite) est très simple : lorsqu’on ouvre l’application, on voit écrit une suggestion d’adresse, qui est aussi l’adresse par défaut. L’utilisateur tape ce qu’il veut et clique sur le bouton « voir le dashboard ». L’application vérifie que cette adresse est valide (dans la photo c’est en cours) puis ouvre l’adresse dans un navigateur. Tant que l’application est active, l’écran ne se met jamais en veille.
Par contre, si on se trompe d’adresse locale, il n’y a pas d’erreur de type 404 qui est renvoyée et l’application cherche éternellement. L’utilisateur peut cependant indiquer une nouvelle adresse dans le champs prévu et relancer avec le bouton « voir le dashboard ». C’est irritant mais pas bloquant…
Pour mettre au point le système de vérification, je me suis inspirée de Check Internet Connection In App Inventor.
L’interface de cette application avec appinventor2 (mode designer)
Le composant « notifier » est réglé sur fond transparent et texte transparent pour être invisible.
Les blocs de programmation avec appinventor 2 (mode blocks)
Les fichiers résultat
la version .aia utilisable sur MIT App Inventor (à renommer en .aia au lieu de .zip) : raspberry_pi_dashboard_V3 (zip / aia)
Fichier Version 3 : Application android (apk)
Et maintenant
J’ai appris que seule la solution 2, avec « activity starter » permet de visualiser correctement une page web dans une application android, en respectant les règles de style.
Voici un fichier zip qui contient la page index.php servie par le Raspberry Pi, la feuille de style associée : index-Pi (zip)
Et voici l’application (apk) téléchargeable sur une tablette (mais attention elle ne fonctionnera que pour lire une page index.html ou index.php située à l’adresse 192.168.1.30) : Application android (apk)
Ma vieille tablette samsung est maintenant transformée en caméra IP (cf cet autre article) et affiche en permanence une page web qui contient le flux vidéo de la tablette elle même (mais servie par un raspberry Pi) et d’une autre caméra. C’est chouette, non ?
par Anne-Laure DELPECH | 4 Juil 2016 | Archives
Cet article a été créé le 4 juillet 2016 et mis à jour périodiquement. La dernière version date du 22 avril 2020.
Les distributions Jessie (ou Jessie Lite) du Raspberry Pi sont réglées par défaut en DHCP avec connexion par cable ethernet. Il peut être utile de créer une connexion wifi ou d’imposer une adresse IP fixe. Voyons comment faire ces réglages.
Note du 22/04/2020 : Document mis à jour pour la version Buster de Raspbian et un Pi 3 (équipé de wifi directement sur le Pi, sans dongle)
Régler la connexion ethernet en IP fixe
Selon « Comment configurer une adresse IP statique sur Raspbian Stretch«
ls /sys/class/net/ m’indique :
eth0 lo wlan0
ifconfig m’indique que seule la connexion eth0 dispose d’une adresse IP. Dans mon cas la connexion wifi (wlan0) n’est pas activée.
Editer /etc/dhcpcd.conf .
Copier les lignes suivantes tout à la fin du fichier :
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
Ensuite modifier ce qui a été collé comme suit :
# IP statique AL :
interface eth0
static ip_address=192.168.1.102/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1 8.8.8.8
Ou static routers et static domain name servers contient l’adresse du routeur local (ou de la box) et static ip address contient l’adresse IP que l’on souhaite attribuer à notre Pi.
Redémarrer le Pi.
Sur mon routeur, je vois que le Pi a maintenant l’adresse 198.168.1.102.
Régler le wifi (Raspberry Pi 3 sous Stretch)
Voir « Setting wifi up via the command line« .
Il faut indiquer un mot de passe crypté. Par exemple si notre réseau a les caractéristiques suivantes (visibles en éditant wpa_supplicant.conf) dans le répertoire /etc/wpa_supplicant/ :
network={
ssid="mon-reseau2"
psk="password2"
id_str="home 1"
priority=2
}
Dans la ligne de commande, on tape wpa_passphrase mon-reseau2 password2.
On obtient en retour :
network={
ssid="mon-reseau2"
#psk="password2"
psk=261066f1ec7164401fbae41235107dc66eaad93ed991abcf
}
Il nous suffit de copier le mot de passe encodé à la place du mot de passe en clair.
Archives (pour mémoire)
Tout ce qui suit était valable en novembre 2016. Je le conserve pour mémoire.
Connecter un dongle wifi
A ce stade, le Pi est connecté à notre réseau local par un cable ethernet. il dispose aussi d’un dongle Wifi de bonne qualité (genre Edimax EW-7811Un ou le dongle « officiel » vendu depuis peu pour le Raspberry Pi). C’est important d’avoir déjà le dongle wifi pour que wicd-curses l’identifie dès son installation.
Attention aux versions de Raspbian ...
Pour connaître votre version de Linux, taper uname -a en ligne de commande.
J’ai eu beaucoup de difficultés car j’ai installé le wifi en IP fixe sur un premier Raspberry B+ en utilisant la méthode avec wicd-curses décrite plus bas.
Quelques semaines plus tard, j’ai voulu réitérer sur un deuxième Raspberry Pi B+, avec le même dongle wifi. Et ça n’a pas fonctionné. J’y ai passé des heures sans jamais trouver avant de me résoudre à utiliser une autre méthode, sans wicd-curses.
Cet article présente donc deux méthodes :
- méthode 1, sans wicd-curses : elle fonctionne avec une version plus récente de Jessie (Linux 4.4.14+ #896 Sat Jul 2 14:16:46 BST 2016 armv6l GNU/Linux .
- méthode 2, avec wicd-curses : elle fonctionne avec Linux 4.4.13+ #893 Wed Jun 8 14:34:50 BST 2016 armv6l GNU/Linux, un peu plus ancienne.
Méthode 1 : sans wicd-curses
Le wifi ne fonctionne pas au départ sur le Pi. J’ai fini par me rendre compte qu’il fonctionnait, mais avec une adresse IPv6… La solution a été d’identifier le problème puis d’obliger le wifi à prendre une adresse IPv4.
La commande ifconfig wlan0 produit entre autres la ligne inet6 addr: fe80::52c6:c538:7c8:640c/64 . C’est une adresse IPv6…
Pour comparer, on peut taper ifconfig eth0 , qui nous donne les mêmes informations pour la liaison ethernet. La même ligne devient inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0 , qui est bien une adresse en IPv4…
Faire fonctionner le wifi en IPv4
La solution (qui m’a paru être un miracle après plusieurs heures de recherches et d’essais infructueux) vient de cette page.
Il suffit de créer le fichier local.conf (droits 644) dans le répertoire /etc/sysctl.d , de l’éditer et d’y placer la ligne net.ipv6.conf.all.disable_ipv6=1 (sans ; à la fin).
On redémarre le Pi et voilà, wlan0 a une adresse en IPv4 si je lui donne les coordonnées de mon réseau wifi.
Pour donner les coordonnées du réseau wifi, il suffit de suivre les instructions de cette page, sur le site officiel du Raspberry Pi : éditer /etc/wpa_supplicant/wpa_supplicant.conf et y ajouter les informations du réseau
network={
ssid="monReseau"
psk="MonMotdePasse"
}
Mon Pi est maintenant accessible en wifi (lorsque j’enlève le cable ethernet).
Attribuer une IP fixe sans Wicd-curses
Fonctionne correctement avec Jessie #896 auquel j’ai fait la manip qui précède.
Editer /etc/dhcpcd.conf et ajouter tout à la fin :
interface wlan0
static ip_address=192.168.1.102/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1 8.8.8.8
Noter que j’ai placé 8.8.8.8 dans domain_name_servers, au côté de l’adresse de mon routeur. Ca permet de connecter le Pi à des sites externes sans connaître leur adresse ip. Ainsi ping google.com se connecte bien à google.
Dernière chose à faire : vérifier que le dongle wifi ne va pas s’éteindre pour économiser l’énergie ! Pour celà, utiliser la commande iwconfig . On voit ainsi tous les paramètres du wifi :
- Power Management:off signifie que la clé wifi ne s’éteindra pas lorsqu’elle n’est pas utilisée. Ouf, pas besoin de régler autrement !
interdire au wifi de s’éteindre
Bien que Power Management ait semblé correctement réglé, le wifi se déconnectait et ne se remettait en service qu’en redémarrant le Pi ou en y connectant un cable ethernet.
J’ai trouvé la solution ici. Il faut configurer le driver de la clé (un dongle Edimax EW-7811Un 802.11b/g/n, mais ça semble être une méthode utilisable pour d’autres dongles).
Créer un fichier /etc/modprobe.d/8192cu.conf et y placer les deux lignes suivantes :
# Disable power management
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Cette ligne interdit toute gestion de l’énergie par le dongle et interdit aussi la suspension automatique du wifi.
Redémarrer le Pi. Le problème disparaît.
Méthode 2 : avec wicd-curses
Ne fonctionne pas avec les versions de Jessie postérieures à #893 (pour savoir quelle version on a, taper uname -a en ligne de commande)
Pourquoi wicd-curses ?
C’est une solution reconnue pour éviter les déconnexions du wifi. En effet, avec wicd-curses il est simple de régler le wifi pour qu’il se reconnecte automatiquement si nécessaire, y compris après un redémarrage.
Installer wicd-curses
La bonne façon de faire pour régler une connexion wifi, c’est d’installer wicd-curses (la source en anglais est ici) ET enlever dhcpcd5 (source, en anglais). On ne doit pas éditer de fichier tels que /etc/network/network ou /etc/wpa_supplicant/wpa_supplicant.conf . Tout peut être réalisé en ssh, sans avoir besoin de se connecter à un écran et un clavier – si on dispose d’une connexion ethernet.
Commencer par installer wicd-curses.
apt-get update
apt-get install wicd-cli wicd-curses
Durant l’installation le programme nous demande si l’on veut ajouter un utilisateur au groupe ‘netdev’. On peut ajouter notre utilisateur local (par exemple ‘pi’). Après l’installation on recharge dbus :
service dbus reload
Si une erreur s’affiche, c’est probablement que l’on a déjà installé network-manager. Dans ce cas voir la section correspondante dans ce tutoriel (en anglais).
Démarrer le démon wicd :
service wicd start
Installer rcconf puis le lancer :
apt-get install rcconf
rcconf
Décocher network manager (si il existe), wicd devrait être déjà coché.
Régler le wifi
lsusb permet de vérifier que le dongle wifi est bien détecté.
On démarre le service wicd puis on lance wicd-curses pour configurer le réseau :
service wicd start
wicd-curses start
Pour configurer le réseau wifi, mettre en surbrillance le réseau auquel on veut se connecter et appuyer sur la touche →. Si aucun réseau wifi n’est listé, appuyer sur [SHIFT] R pour scanner le réseau wifi.
wicd-curses configuration réseau
- Use DHCP hostname doit être coché pour que le Pi conserve son nom ;
- descendre vers le bas et cocher ‘Automatically connect to this network‘
- descendre vers le bas et taper la clé de sécurité du réseau wifi
- Appuyer sur[F10] pour sauvegarder. On retourne à la liste des réseaux wifi, avec notre réseau surligné.
- Appuyer sur [shift] + c (C) pour se connecter au réseau.
- Une fois connecté (vérifier le statut en bas à gauche), appuyer sur q pour quitter.
En cas de problème lors de la connexion, aller voir le contenu de /var/log/syslog . Parfois, il suffit de faire les étapes suivantes, redémarrer le Pi et le wifi fonctionne.
On supprime dhcpcd5 :
apt-get remove dhcpcd5
On redémarre le pi (toujours connecté en ethernet, avec le dongle wifi présent) avec reboot .
- Eteindre le Pi avec init 0 . Enlever le cable ethernet. Lorsqu’on redémarre le Pi, il fonctionne en wifi.
- Il est possible qu’un ping au « hostname » ne fonctionne pas tout de suite car windows ne met pas à jour la carte du réseau. il faut alors faire un ping sur l’adresse ip du Pi.
Régler une adresse IP fixe (en wifi ou ethernet)
Pour un réseau wifi (c’est semblable en ethernet), on met en surbrillance sur le réseau que l’on veut paramétrer puis on appuie sur touche →.
- Cocher ‘use static IPs ‘
- entrer l’adresse IP fixe (vérifier qu’elle n’est pas déjà prise dans votre routeur ou votre box) – pour moi 192.168.1.30. On peut utiliser <SHIFT> Inser pour coller ce qu’on aura copié ailleurs.
- Entrer le Masque de sous-réseau (vérifier en tapant ipconfig dans l’invite de commande windows) – pour moi, 255.255.255.0
- Entrer la passerelle (vérifier en tapant ipconfig dans l’invite de commande windows) – pour moi, 192.168.1.1
- Entrer google.com dans search domain et 8.8.8.8 pour DNS1 , 8.8.4.4 dans DNS2 .
- J’ai laissé coché « use DHCP hostname «
- Appuyer sur[F10] pour sauvegarder. On retourne à la liste des réseaux wifi, avec notre réseau surligné.
- vérifier que le réseau est connecté (statut en bas à gauche), appuyer sur q pour quitter.
- On peut vérifier que tout va bien en tapant ping google.com dans la ligne de commande (<CTRL> C pour en sortir).
- Redémarrer le Pi avec init 0 .
Ca fonctionne. Le nautilus a une adresse IP fixe.
Et maintenant ?
J’ai appris que les tutoriels ne sont pas universels… Parfois ce qui fonctionne pour un Pi à une date donnée ne fonctionne pas quelques semaines plus tard, après quelques mises à jour du système d’exploitation.
par Anne-Laure DELPECH | 4 Juil 2016 | Archives
Dans l’article précédent de cette série Caméra de surveillance et Raspberry Pi, j’indiquais que motion crée beaucoup d’images et vidéos qui ne correspondent pas à de véritables mouvements devant la caméra.
motion permet de nombreux réglages. Je l’ai choisi pour ça. En particulier, il semble efficace pour éliminer les mouvements liés au vent.
Pour comprendre les différents réglages, il faut lire attentivement cette aide (en anglais) sur les réglages de la détection de mouvement avec motion.
La situation initiale
Dans /etc/motion/motion.conf , j’ai entre autres les réglages suivants :
# Je ne comprends pas comment ça fonctionne. Valeur par défaut = EedDl
despeckle_filter EedDl
# Ignore les changements soudains de lumière - de 0 (arrêt) à 100%.
lightswitch 0
# Smartmask est un masque auto-apprenant qui va bloquer la détection dans les endroits de l'image où il y a des mouvements fréquents, comme des branches qui bougent à cause du vent. 0 (off) à 10 rapide.
smart_mask_speed 0
# nombre minimum de photos avec du mouvement avant détection : defaut 1 : tous mouvements détectés.
minimum_motion_frames 1
# base pour déclarer un mouvement. C'est le nombre de pixels changés après le filtrage du bruit, le masque et le "despeckle".
threshold 1500
# réglage automatique du threshold - ne fonctionne pas
threshold_tune off
# niveau de "bruit" pour distinguer le bruit de la caméra d'un mouvement
noise_level 32
# si on, ajustement automatique du bruit
noise_tune off
Avec ce réglage, j’obtiens (sur une journée avec du vent) beaucoup trop de faux positifs.
Les faux positifs contiennent du « bruit » la nuit, l’éclairage de la lampe à côté de la caméra, et des mouvements liés au vent :
« bruit » la nuit
Réglages du 1er juillet – soir
J’ai modifié le niveau de lumière qui déclenche un mouvement, le nombre d’images modifiées avant la détection de mouvement, le ‘theshold’ et le niveau de bruit.
despeckle_filter EedDl
lightswitch 25
smart_mask_speed 5
minimum_motion_frames 3
threshold 3000
noise_level 100
noise_tune off
Nota : après chaque réglage de motion.conf, il faut redémarrer le service motion avec :
service motion restart
Le 2 juillet, de 0h à 14h (heure du réglage suivant, il n’y a eu que 24 fichiers créés ( 1 Mo) et 24 fichiers correspondent à un mouvement effectif (ma voiture qui part puis qui revient).
Mais la caméra ne détecte pas une personne qui se déplace à pied.
Réglages du 2 juillet – 11h45
Je n’ai corrigé que le « threshold ».
despeckle_filter EedDl
lightswitch 25
smart_mask_speed 5
minimum_motion_frames 3
threshold 1500
noise_level 100
noise_tune off
Pendant la journée tout va bien : pas de fausse détection (mais le système ne détecte toujours pas une personne à pied) mais la nuit, il y a eu plein de faux positifs. Dès que le jour s’est levé, il n’y a plus de souci.
Réglages du 3 juillet – détecter une personne à pied
Pour détecter une personne à pied, j’ai modifié les paramètres suivants successivement jusqu’à ce que je déclenche une détection de mouvement :
minimum_motion_frames 1
noise_level 32
smart_mask_speed 10
motion : détection d’une personne
Ce n’est qu’au dernier changement que j’ai détecté le mouvement d’une personne.
Ces paramètres détectent aussi bien une voiture qu’une personne (12h20 = OK) :
despeckle_filter EedDl
lightswitch 25
smart_mask_speed 10
minimum_motion_frames 3
threshold 1500
noise_level 32
noise_tune off
Je laisse les paramètres suivants en l’état :
despeckle_filter EedDl
lightswitch 25
smart_mask_speed 10
minimum_motion_frames 3
noise_tune off
et j’étudie l’impact de changements sur threshold ou noise_level :
| Threshold |
Noise_level |
Détecte ? |
| 1500 |
100 |
12h42 ne me détecte pas et fait un faux positif |
| 3000 |
32 |
12h26 ME détecte = OK |
| 3000 |
100 |
12h34 NON, ne me détecte pas |
Les réglages suivants sont donc satisfaisants :
despeckle_filter EedDl
lightswitch 25
smart_mask_speed 10
minimum_motion_frames 3
threshold 3000
noise_level 32
noise_tune off
Maintenant reste à faire un bilan sur environ 24h (depuis 13h le 3 juillet) :
- détection d’une personne : Oui
- détection d’une voiture : oui
- faux positifs : 2 en une nuit.
Je considère donc que ces réglages sont corrects.
Autres notes :
On peut mettre motion en mode deboguage pour voir comment se passe la détection : voir cette page sur le wiki de motion.
par Anne-Laure DELPECH | 3 Juil 2016 | Archives
Mon objectif est maintenant de transformer le Raspberry Pi qui gère les caméras avec motion en un serveur web qui publie une page web contenant les flux vidéos. (suite…)
Commentaires récents