La Lanterne Rouge

La Lanterne Rouge

Warning: Geek Inside

Publié le par Nanawel
Publié dans : #raspberry pi | #rpi | #diy | #motion | #vidéo-surveillance | #arm | #linux | #archlinux | #webcam

MISE À JOUR 01/07/2013 : la suite est disponible ici !

 

Ça y est, je suis moi aussi dans le vent comme disent les jeunes, j'ai reçu ma Framboise Pi ! (Raspberry Pi pour les anglophones).

Quoi ? Vous ne savez pas ce qu'est un Raspberry Pi ? Alors petit résumé pour les gens qui ont vécu dans une caverne sans ADSL durant les 12 derniers mois.

Mini-carte à mini-prix

300px-RaspberryPi.jpgLe Raspberry Pi modèle B (le mien) est un ordinateur monocarte équipé d'un processeur ARMv6 (un Broadcom BCM2835 cadencé à 700 MHz) et conçu par la Raspberry Pi Foundation au Royaume-Uni. Il ne pèse que 45g (!) et est équipé du strict minimum au niveau de la connectique :

  • 2 ports USB 2.0,
  • 1 port HDMI (seule sortie vidéo pour moniteur informatique),
  • 1 port RCA Composite (sortie "TV"),
  • 1 sortie audio Jack,
  • et enfin 1 port Ethernet 10/100.

Il est alimenté en 5V par un port micro-USB et possède 512Mo de RAM, ce qui est très confortable pour une machine pareille. On trouve également un port GPIO qui permet de relier la carte à des composants externes ou circuits de toutes sortes et ainsi accroître ses fonctionnalités.

Quand des informations sur le modèle A de cette carte sont sorties fin 2011, j'avoue avoir hésité un peu malgré le faible prix proposé (25$ soit à peine 18€ HT). "Que vais-je en faire ?" m'étais-je demandé. "Est-ce vraiment un investissement judicieux ?", "Et le trou de la couche d'ozone dans tout ça ?", "Est-ce que je prends du pain ce soir ?".

Toutes ces questions se sont bousculées dans ma tête et j'avoue que j'avais alors décidé de seulement suivre de loin les tests des premiers acquéreurs. Il n'existait alors pas de distrib clé-en-main pour profiter pleinement de la mini-machine, et l'unique port USB ainsi que l'absence de port Ethernet sur le modèle A m'ont clairement refroidi. L'absence de réseau est pour moi rédhibitoire sur tout ordinateur digne de ce nom.

Puis le modèle B a été présenté. Plus cher (35$ soit 25€ HT environ), mais aussi plus complet et offrant enfin une connectivité intéressante avec son port Ethernet 10/100, même si toujours équipé à 256 Mo de RAM ce qui était souvent présenté comme juste par les testeurs. Alors un jour de désoeuvrement de juillet, j'ai dégainé ma carte bleue et j'ai passé commande sur le site de RS Components. Ayant étudié l'assembleur ARM à la fac, la perspective de quitter le confort du monde x86 ne m'a pas trop effrayée. Et puis l'ARM apparemment, c'est l'avenir, alors autant prendre de l'avance.

RaspiModelB.jpgComme la carte nue me semblait assez fragile, j'ai pris également un boîtier (transparent) et un adaptateur secteur (fournissant les 5V requis via la prise micro-USB).

Total final : 52,67€ TTC.

Bon, c'est évidement un peu plus cher que prévu, mais cela reste finalement raisonnable pour un petit ordinateur. Je reçois l'e-mail de confirmation, et là petite déception : expédition prévue dans 19 semaines ! Ce qui correspondait au début du mois de décembre... Bah, ça me fera un petit cadeau de Noël (inattendu, car d'ici là j'aurai oublié !).

Got it!

Le temps passe, décembre arrive, et avec lui un e-mail de notification m'informant que mon colis a enfin été expédié. Youpi ! Entre temps j'avais appris que les modèles B expédiés seraient désormais équipés de 512 Mo de RAM au lieu des 256 initiaux, et ce sans modification de prix. Une très agréable surprise !

Je découvre enfin mi-décembre un colis siglé "RS" dans ma boîte aux lettres et ne peut m'empêcher de le déballer un matin avant de partir au boulot. Bien m'en a pris car j'avais oublié que je n'avais pas acheté de carte mémoire dans mon pack (le prix n'étant pas intéressant). J'ai donc profité de ma pause dans la journée pour acheter une carte SD SanDisk de 16 Go catégorie 10 (donc proposant des débits de 10 Mo/s en écriture, ce qui est indispensable quand on l'utilise comme stockage de masse principal).

De retour le soir, j'avais tout le nécessaire pour commencer à utiliser la carte, y compris l'image de l'OS que j'allais "graver" sur la carte SD pour pouvoir booter : Arch Linux ARM bien entendu.

Installation et configuration d'Arch Linux

L"installation" est d'une simplicité enfantine, et pour cause : il s'agit simplement de copier l'image sur la carte SD avec dd (sous Linux).

Évidemment, il faut une machine avec un lecteur de carte utilisable. Dans mon cas c'est mon portable qui a servi, n'ayant pas de lecteur sur mon PC fixe. Le système est alors pré-configuré et prêt à être booté. Arch Linux oblige, c'est systemd qui joue les chefs d'orchestre, ce qui est totalement transparent d'un point de vue utilisateur évidemment.

Au passage, la copie a tourné à 12 Mo/s en moyenne, la catégorie 10 de la carte n'est donc pas usurpée (mais bien sûr, la copie "brute" est peu représentative des performances observée une fois la carte formatée).

J'insère la carte SD dans l'unique port du Raspberry Pi, puis je branche l'alimentation mcro-USB et les LEDs s'animent instantanément. Dix secondes plus tard elles se stabilisent : le système a terminé de booter !

Comme je n'ai pas connecté d'écran (aucun écran DVI de libre, pas d'adaptateur HDMI-DVI de toute façon, et aucune télé chez moi) c'est avec SSH que je dois contrôler ma mini-carte. La connexion est immédiate, l'accès root est ouvert avec le mot de passe — ultra-sécurisé — "root" :)

wikilogo_0_0.png

Je me retrouve alors dans un environnement totalement connu, et la différence d'architecture est entièrement transparente : on est sur un système GNU/Linux, point final. Seul le nom du kernel trahit que nous sommes sur une plateforme ARM :

[root@alarmpi ~]$ uname -a
Linux alarmpi 3.2.27-17-ARCH+ #1 PREEMPT Thu Dec 6 17:29:12 UTC 2012 armv6l GNU/Linux

L'image étant prévue pour tenir sur des cartes mémoires de capacités inférieures à la mienne, le partitionnement est adapté en conséquence : on a une partition /boot de 100 Mo formatée en vfat et une partition / d'environ 2 Go formatée en ext4. Pourquoi avoir choisi ext4 pour une partition destinée à être utilisée sur une carte SD ? Je ne l'explique pas. Mais qu'importe, je ferai avec. De toute façon ce partitionnement n'est pas adapté à ma carte. J'éteins donc mon RPi et rebranche la carte sur mon portable.

Un petit coup de GParted et j'adapte la taille de / : 3 Go devraient être suffisants. Les 11,8 Go restants — inutilisés jusque-là — serviront pour la partition /home que j'en profite pour créer (en ext2 celle-là).

Après quelques dizaines de minutes, GParted m'annonce la fin de la procédure.

Je reboote mon RPi à nouveau et adapte /etc/fstab afin que /home pointe bien sur la nouvelle partition /dev/mmcblk0p3. Un petit

# mount -a

pour appliquer la modification et tout fonctionne comme attendu.

Ah tiens, mais je remarque que seuls 256 Mo de RAM sont disponibles d'après htop. Hum, étrange. Renseignements pris, il suffit de mettre à jour les paquets (et avec lui le firmware) avec un classique

# pacman -Syu

pour qu'au prochain reboot les 512 Mo soient utilisables.

Là c'est bon je peux maintenant passer à la suite : ajout d'un utilisateur non-privilégié (nanawel), installation des utilitaires de base et configuration de tout ça.

La plupart de ces étapes et d'autres encore sont, comme souvent avec Arch Linux, expliquées de manière très concise mais efficace sur le wiki : https://wiki.archlinux.org/index.php/Raspberry_Pi

 

Maintenant se pose la question fatidique, celle évitée soigneusement jusque-là. Car c'est bien joli de tout bien configurer, tout préparer aux petits oignons et d'avoir un ordinateur de plus qui tourne sur son réseau... mais pour faire quoi ?

raspberry-pi_eyes_167x215.pngUne framboise voyeuse

J'avais détaillé il y a maintenant plusieurs mois comment j'avais monté un système simple de vidéo-surveillance au moyen d'une webcam USB (Logitech C510), d'un logiciel sous Windows (Yawcam) et de montages réseaux Samba couplés à du mirroring rsync.

Malgré ses qualités (dont la plus importante : ça "juste marche"), et le fait qu'il fonctionne sans interruption depuis lors, cette installation possède néanmoins un défaut important : elle nécessite en effet un PC sous Windows qui tourne 24/24.

En plus de ça, Yawcam, bien que "plutôt léger", consomme facilement 100 à 150 Mo de RAM ainsi que des ressources de CPU.

Enfin, dans mon cas où le dossier de réception est situé sur Usul (via montage Samba), il est nécessaire que celui-ci soit monté avant de lancer Yawcam, ce qui complique très fortement toute reprise automatique suite à une coupure électrique par exemple.

 

Mon Raspberry Pi configuré pourrait-il me servir à remplacer ce montage un peu bancal et rendre le système de vidéo-surveillance totalement indépendant ?

Une petite recherche sur la Toile et je tombe rapidement sur de nombreux articles présentant comment faire. Je me suis principalement inspiré de celui-ci : http://chris.gg/2012/07/using-a-ps3-eyetoy-with-the-raspberry-pi/ qui décrit pour ce faire comment utiliser Motion. J'ai ensuite largement débordé de ce cadre, d'où cet article.

Ce logiciel (libre) propose tout le nécessaire pour faire du streaming de webcam en temps réel (via HTTP), des snapshots réguliers, de la détection de mouvement entraînant au choix une ou plusieurs captures statiques (images) ou dynamiques (vidéos, grâce à ffmpeg).

Il est également possible de contrôler la webcam si celle-ci est motorisée, et de la programmer pour qu'elle suive les mouvements détectés. Tout cela avec le support des webcams multiples, de MySQL et PostgreSQL... et j'en passe (voir le wiki pour la liste exhaustive des fonctionnalités). Il est simplement difficile de demander mieux !

Ni une ni deux, je me lance dans l'installation et la configuration de Motion, et son intégration à mon système déjà existant (car je vais conserver le dépôt sur mon serveur Usul).

Ah oui, et ma machine s'appellera désormais "comeye" ("oeil com" dans la traduction française des Dune).

Installation de Motion et Samba  

Ici, que du classique :

# pacman -S motion samba

Je ne détaillerai pas la configuration de Samba, le wiki d'Arch Linux (entre autres) est très bien fait pour cela. Il s'agit simplement ici de me permettre d'accéder au répertoire de travail de l'utilisateur UNIX nanawel depuis Windows (mon PC fixe étant encore sous XP).

 

On branche à présent la webcam sur un port USB libre du RPi et on observe les logs du kernel :

Dec 14 19:31:50 localhost kernel: [ 6572.038364] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
Dec 14 19:31:50 localhost kernel: [ 6572.140566] usb 1-1.3: New USB device found, idVendor=046d, idProduct=0840
Dec 14 19:31:50 localhost kernel: [ 6572.140599] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Dec 14 19:31:50 localhost kernel: [ 6572.140619] usb 1-1.3: Product: Camera
Dec 14 19:31:50 localhost kernel: [ 6572.188841] Linux media interface: v0.10
Dec 14 19:31:50 localhost kernel: [ 6572.212764] Linux video capture interface: v2.00
Dec 14 19:31:50 localhost kernel: [ 6572.224080] gspca_main: v2.14.0 registered
Dec 14 19:31:50 localhost kernel: [ 6572.235084] gspca_main: STV06xx-2.14.0 probing 046d:0840
Dec 14 19:31:50 localhost kernel: [ 6572.237442] gspca_stv06xx: HDCS-1000/1100 sensor detected
Dec 14 19:31:50 localhost kernel: [ 6572.508397] input: STV06xx as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/input/input3
Dec 14 19:31:50 localhost kernel: [ 6572.512047] usbcore: registered new interface driver STV06xx

La caméra est bien détectée et semble utilisable directement. Pour s'en assurer, il suffit de lancer motion via la commande suivante (mode interactif) :

$ motion -n

Normalement la trace qui s'affiche sur le terminal devrait terminer avec :

...
[1] Using V4L2
[1] Resizing pre_capture buffer to 1 items
[1] Started stream webcam server in port 8081

Logiquement, on pourrait naviguer vers l'adresse IP du Raspberry Pi, sur le port mentionné et obtenir l'affichage de la webcam. Mais la configuration par défaut n'autorise que les accès depuis localhost. Comme je suis en headless je n'ai pas de navigateur utilisable sur le RPi pour le vérifier, nous verrons donc cela plus tard.

Appuyer sur Ctrl-C pour stopper l'exécution dans le terminal.

comeye_raspberry_pi_1.jpg

  Configuration du daemon de Motion  

  Le daemon de Motion n'est pas activé par défaut. Pour remédier à cela :

# systemctl enable motion

Mais si nous conservons le fonctionnement par défaut, cela signifie qu'il tournera en tant que root. De manière générale c'est une très mauvaise pratique, surtout pour un programme qui va être accessible depuis le réseau (et à terme, d'Internet).

Je vais donc créer un utilisateur dédié motion dont le répertoire de travail servira de dépôt pour les images issues des détections de mouvements : /home/motion.

Je prends même un peu d'avance et crée un groupe homonyme qui permettra de faciliter la gestion des permissions sur les futurs fichiers.

# groupadd motion
# useradd motion -g motion -m -s /bin/false

Le groupe principal de l'utilisateur motion est donc aussi motion. Je crée un dossier /home/motion/detections qui recueillera les détections de mouvement :

# su -s /bin/bash -l motion -c "mkdir /home/motion/detections"

(ici je me sers de su pour créer le dossier; comme l'utilisateur n'a pas de shell associé, je dois le préciser avec "-s")

 

Il s'agit maintenant de dire à systemd de lancer motion (le programme) en tant que motion (l'utilisateur) :

# nano /usr/lib/systemd/system/motion.service
___
[Unit]
Description=Motion daemon
After=local-fs.target remote-fs.target
 
[Service]
User=motion                            # Ajouter cette ligne
ExecStart=/usr/bin/motion
Type=forking
#StandardOutput=null
StandardError=null
 
[Install]
WantedBy=multi-user.target

comeye_raspberry_pi_2.jpg

  Configuration de Motion  

  On passe ensuite à la configuration plus fine de Motion via le fichier /etc/motion/motion.conf (je ne présente que les lignes que j'ai modifiées par rapport aux valeurs par défaut) :

width 640
height 480
threshold 10000
quality 90
ffmpeg_cap_new off
target_dir /home/motion/detections
jpeg_filename %Y-%m-%d_%H-%M-%S-%q
webcam_motion on
webcam_localhost off

Explications :

  • On augmente tout d'abord la résolution de la webcam à 640x480 (au lieu des 320x240 par défaut). J'ai essayé de monter plus haut mais au-dessus de cette valeur Motion perd la connexion avec la webcam, alors que celle-ci le supporte en théorie (il s'agit peut-être d'un problème d'alimentation, les ports USB ne pouvant pas fournir le courant requis par l'équipement). Je n'ai pas poussé plus loin mes investigations.  

MISE À JOUR 23/07/2013 : L'alimentation est effectivement en cause et il suffit de mettre en place le montage expliqué ici pour pouvoir monter à 800x600 (mais pas plus).

  • Suite à l'augmentation de la résolution, on passe la sensibilité à 10000 au lieu de 1500 par défaut. Cela signifie qu'un mouvement sera détecté uniquement à partir du moment où 10000 pixels au moins seront différents entre deux captures consécutives par le logiciel (il y a par défaut 2 captures par secondes, mais c'est paramétrable). Cette valeur a été déterminée de manière empirique et correspond à mon besoin précis.
  • On préfère conserver une qualité de JPEG de 90% (au lieu de 75% par défaut).
  • On désactive la génération de vidéos suite à la détection de mouvement (car la place occupée par celles-ci est trop importante).
  • On précise que les images comportant des détections de mouvement seront placées dans /home/motion/detections
  • Les noms des fichiers seront de la forme "2012-12-14_17-45-23-01.jpg" afin de faciliter leur traitement par tri (http://www.lavrsen.dk/foswiki/bin/view/Motion/AdvancedFilenames)
  • On active la détection de mouvement
  • On autorise l'accès à la page de streaming depuis toutes les interfaces réseau (et non plus seulement localhost)

 

À ce stade, tout est prêt pour faire les premiers tests. On lance donc le daemon motion :

# systemctl start motion

  Et on peut enfin naviguer depuis un poste relié au réseau local sur la page de streaming de l'application : http://[adresse_ip_eth0]:8081/

Attention : le streaming est constitué d'un flot d'images JPEG (type MIME : multipart/x-mixed-replace). Tous les navigateurs ne gèrent pas correctement ce type de contenu, je privilégie donc Firefox ou Chromium pour le visualiser (rien d'original cela dit ^^). 

La détection de mouvement doit désormais enregistrer des images JPEG dans le dossier /home/motion/detections.

 

MISE À JOUR 23/07/2013 : Pour obtenir des images statiques à partir du flux simplement en utilisant Lighttpd et PHP voir ici.

Synchronisation distante

Pour le moment, les images sont uniquement enregistrées en local, sur la carte SD donc. Cela fonctionne bien mais n'assure pas la sécurité des données attendues par un tel système. Il suffit de retirer la carte mémoire pour perdre toute les traces des détections de mouvement.

Je vais donc reprendre mon script de synchronisation déjà utilisé entre Usul et Sihaya, pour l'appliquer entre ComEye et Usul.

Mais pour cela j'aurai besoin de incrond (utilisant inotify), que j'installe très simplement avec :

# pacman -S incrond

et dont j'active le daemon avec :

# systemctl enable incrond

 

La synchronisation impose de préparer la réception des fichiers du côté d'Usul. Il me faudra un utilisateur dédié sur le serveur pour cela (nommé fort logiquement comeye). À présent que nous sommes sur le réseau local, SSH n'est pas indispensable pour encapsuler les données des fichiers transférés comme c'était le cas entre Usul et Sihaya. On peut donc utiliser le protocole rsync d'un bout à l'autre (sans chiffrage), ce qui allègera en plus l'opération.

Sur Usul

Sur le serveur (tournant sous Debian Squeeze, je rappelle), cela signifie donc effectuer les opérations suivantes :

  • Ajout de l'utilisateur "comeye" et du groupe du même nom
# useradd comeye
  • Activation du daemon rsync (désactivé par défaut)
# nano /etc/default/rsync

(passer la variable RSYNC_ENABLE à "true")

  • Préparer le dépôt pour la synchronisation (nommé ici "motdet", entre les crochets)
# nano /etc/rsyncd.conf
___
log file = /var/log/rsync.log
timeout = 300
 
[motdet]
comment = Motion Detections from ComEye
path = /home/comeye/webcam/motion_detection
read only = no
list = yes
uid = comeye
gid = comeye
list = yes
hosts allow = 127.0.0.0/8 192.168.1.0/24

On force ici l'utilisateur (uid) et le groupe (gid) des fichiers qui arriveront par rsync, et on autorise les accès en écriture depuis les adresses du réseau local (192.168.1.X).

  • Démarrer le daemon
# /etc/init.d/rsync start

À présent le daemon rsync écoute sur le port 873 et est prêt à recevoir les fichiers que nous lui présenterons.

Sur ComEye

Le script modifié pour ComEye est le suivant :

Voir contenu sur PasteBin

On remarquera la syntaxe spéciale pour le protocole rsync dans la définition du dossier de destination (forme hôte::dépôt) :

DEST=usul::motdet

  Je le place à la racine du répertoire de travail de Motion : /home/motion/rsync-motdet-now.sh (et si nécessaire j'ajoute les permissions nécessaires à l'exécution par le propriétaire : motion)

J'édite ensuite la table des événements observés par incrond pour l'utilisateur motion :

# incrontab -u motion -e

et j'ajoute simplement la ligne suivante :

/home/motion/detections IN_CLOSE_WRITE /home/motion/rsync-motdet-now.sh $# $%

puis je sauve et je quitte (:wq sous vim)

Note : pour je-ne-sais quelle raison, je ne peux pas éditer la table grâce à la commande incrontab qui échoue avec un "File not found". Il reste possible de passer par un simple

# nano /var/spool/incron/motion

pour l'éditer à la main si cela se produit...

 

Chaque fichier écrit dans le répertoire /home/motion/detections déclenchera automatiquement l'exécution de la command /home/motion/rsync-motdet-now.sh.

Par rapport à la configuration sur Usul (voir article correspondant) j'ai retiré IN_DELETE car je ne souhaite pas que les suppressions de fichiers soient propagées, comme le précise également la ligne :

RSYNC_CMD="rsync -av $ARGS $SRC $DEST"

dans le script de synchronisation (pas de "--delete-after" dans la ligne de commande).

 

La suppression des fichiers sur ComEye sera réglée par un job CRON quotidien (ici à 3h55), indépendant de celui en place sur Usul :

# crontab -u motion -e
___
55 3 * * * find /home/motion/detections/ -type f -mtime +1 -name "*.jpg" -delete   #Delete motion detections older than 1 day

Ce point est crucial car sinon nous allons rapidement nous retrouver avec des dizaines de milliers de fichiers dans le dossier /home/motion/detections qui rempliront la partition, ce qui entraînera à terme des erreurs d'écriture.

Faisons un point...

comeye-usul-sihaya.png

 

Je récapitule le fonctionnement jusqu'ici :

  1. La détection de mouvement entraîne l'enregistrement des photos correspondantes dans le dossier /home/motion/detections sur la carte SD de ComEye (mon Raspberry Pi)
  2. L'écriture de fichiers dans ce dossier déclenche un événement incron qui va exécuter le script /home/motion/rsync-motdet-now.sh
  3. Ce script va synchroniser les fichiers du dossier de ComEye vers le dépôt préparé sur Usul. La synchronisation ne concerne que l'envoi de nouveaux fichiers (les fichiers supprimés sont conservés intacts sur Usul, et les fichiers déjà existants sont ignorés évidemment).
  4. Le dépôt sur Usul est lui-même surveillé par un job incron qui va envoyer les nouveaux fichiers vers Sihaya
  5. Un job CRON quotidien va supprimer les photos datant de plus d'un jour dans le répertoire /home/motion/detections sur ComEye.

 

Ce système offre donc les garanties suivantes :

  • La détection de mouvement est indépendante de toute autre machine que le RPi lui-même.
  • Le RPi boote en une dizaine de secondes, et démarre automatiquement le daemon motion.
  • Les photos issues de la détection de mouvement sont stockées en local sur ComEye PUIS envoyées sur le serveur Usul si celui-ci est est actif, ce qui duplique les données et protège ainsi de leur perte (accidentelle ou autre).
  • En plus de cela, le dépôt sur Usul est le dossier qui est également synchronisé avec Sihaya, mon autre serveur. J'ai donc une duplication supplémentaire sur une machine distante (hors réseau local). À être parano, autant y aller carrément !

Mais comporte ces inconvénients :

  • D'après le script, la synchronisation (ComEye/Usul) ne s'opère à partir d'une écriture de fichier qu'après un lap de temps d'une seconde sans écriture. Si les mouvements sont continus, la synchronisation sera constamment retardée car de nouveaux fichiers seront écrits les uns à la suite des autres sans interruption, ne laissant pas la pause d'une seconde nécessaire pour déclencher la synchronisation. C'est un point que je tâcherai de traiter plus tard.
  • La duplication des fichiers vers Sihaya impose au préalable que ceux-ci aient été copiés sur Usul, et donc que celui-ci soit actif. Il serait préférable que la synchronisation soit effectuée directement de ComEye vers Sihaya, sans utiliser Usul comme intermédiaire.

Et la surveillance dans tout ça ?

Bien que la détection de mouvement soit un point essentiel du système car il évite la présence permanente d'un "opérateur" qui surveillerait l'image, elle n'en demeure pas moins une des multiples fonctionnalités souhaitées (dont certaines sont déjà offertes par Motion). J'apprécie en effet de pouvoir à loisir jeter un oeil à l'image renvoyée par ma webcam régulièrement, et ce de n'importe où grâce à mon smartphone par exemple (Nexus S, sous Android bien sûr).

 

Petite liste des fonctionnalités qu'il me reste ainsi à mettre en place :

Authentification

Pour conserver l'aspect confidentiel de ces données il est indispensable d'en protéger l'accès, par un couple login/mot de passe par exemple. Or, s'il est bien possible d'affecter un couple de ce type à l'interface de contrôle accessible par HTTP (sur le port 8080), rien n'est prévu de base pour faire de même sur la page de streaming de l'image (sur le port 8081).

Chiffrement

Qui dit mot de passe, dit chiffrement nécessaire, car on ne va pas faire circuler un mot de passe en clair sur Internet, c'est évident. Mais là non plus rien n'est prévu par Motion en standard.

Capture JPG

Comme le protocole de streaming proposé par Motion (à base de multipart/x-mixed-replace comme je l'ai mentionné précédemment) est moyennement supporté par les navigateurs, surtout mobiles, et réclame une bande passante importante souvent insuffisante sur les réseaux mobiles, il est intéressant de pouvoir générer une image statique, un instantané issu du flux généré par Motion et qui sera accessible par une URL dédiée.

Accès direct à la dernière détection

De la même manière, il est enfin intéressant de pouvoir accéder rapidement à la dernière capture issue de la détection de mouvement.

 

Les fonctionnalités que je viens de lister ne sont pas offertes par Motion, mais il est possible de les réaliser avec un serveur HTTP et quelques scripts très simples. Je reviendrai donc dans un prochain article sur la configuration à appliquer à Lighttpd (plus léger qu'Apache et largement suffisant dans ce contexte) et sur les scripts PHP à utiliser pour remplir tous ces besoins.

 

MISE À JOUR 01/07/2013 : la suite est disponible ici !

Commenter cet article

installateur videosurveillance 28/07/2017 15:00

Super montage, j'espère que tu y es arrivé à bout avec la mise en place des divers fonctionnalités :) Ce serait aussi sympa de nous montrer la qualité des images et des vidéos qui ont été pris avec.

Nanawel 29/07/2017 18:00

J'y suis arrivé oui ! Il y a eu quelques ratés mais au final tout fonctionne encore aujourd'hui 24/24 sans la moindre maintenance. La qualité des images est relativement faible cependant, mais il faut noter qu'il s'agit d'un RPi et d'une caméra de première génération. Un RPi 3 avec une caméra HD comme il en existe aujourd'hui fournirait certainement des images de bien meilleure qualité. Mais bon, je suis sur de nouveaux projets à présent donc ce système qui "juste marche" me satisfait pleinement.

Neomagic 18/12/2013 11:09

Salut,
super article pour le non fonctionnement de incrontab -e il te faut juste créer un fichier /etc/incron.conf
et cela fonctionne
pour le contenu j'ai utilisé celui ci http://svn.aiken.cz/websvn/filedetails.php?repname=public&path=%2Fincron%2Ftags%2Fincron-0.5.10%2Fincron.conf.example&

Nanawel 18/12/2013 11:31

En fait c'est plus bizarre que ça car suite à une mise à jour quelques temps plus tard, et sans avoir ce fichier /etc/incron.conf je peux maintenant utiliser la commande incrontab.
Je suppose qu'il s'agissait peut-être d'un petit bug dans la version du package que j'ai utilisée à ce moment-là, corrigé par la suite.

Mais merci de ton retour !

matthieu 11/07/2013 14:12

Bonjour,
J'aimerais si votre SD classe 10 est réellement utile ? et si vous avez quelques statistiques au niveau
des débits (écriture, upload, ...).
Merci

Nanawel 01/08/2013 15:26

SI tu parcours rapidement mes autres articles sur ce blog tu réaliseras que je ne suis pas un grand fan de ce genre de services, c'est pourquoi dans ma solution je n'utilise que des ordinateurs que j'héberge moi-même.

Ces images sont des données que je considère comme confidentielles, donc je ne me vois pas les mettre sur un serveur qui ne m'appartiendrait pas, ou dont je ne maîtrise pas les entièrement les droits d'utilisation et de stockage. Donc non, je ne peux te conseiller aucun service.

Hormis ces points, peut-être que Dropbox semble le plus proche de ce que tu cherches. Je pense que la synchronisation est quasi-immédiate, mais n'ayant pas d'expérience avec cet outil je ne saurais en être sûr.

Nabla 01/08/2013 08:16

Bonjour,

Excuse moi de t’embêter pour une question idiote et pas raspberry :p.
Est ce que tu connaitrais un bon espace de stockage sur le web pour stocker les vidéos de la webcam (Après je les supprimes), accessible ftp ?

Je pensais à utiliser free mais il verrouille avec leur client ftp à eux. Concernant les pages perso, les conditions stipulent pas un espace de stockage.
Sinon je pensais à dropbox comme je mets pas des choses sensibles et qu'il crée un répertoire de synchronisation sur le disque mais je connais pas le délai de synchro.

Si tu as une bonne piste à me donner, je prends.

Merci par avance.

Nabla 29/07/2013 07:42

Bonjour,

Pour l'OS, je savais au vu des lectures mais je me demandais s'il existait une solution d'émulation pour .NET.

En tout cas merci, et après mes congés j'essayerai de faire une note de ma méthode.

@+

Nanawel 28/07/2013 23:17

Pour .NET il faut rappeler que j'utilise comme OS Archlinux ARM qui, comme son nom l'indique, est basé sur un noyau Linux. Les applications Windows en général et .NET en particulier ne sont pas prévues pour tourner sur cet OS (bien qu'il existe une mise en oeuvre (Mono - http://fr.wikipedia.org/wiki/Mono_(logiciel) ) qui a pour but à terme de proposer une compatibilité complète dans cet environnement).
Il te faudra donc te renseigner et probablement tester par toi-même car je n'ai pas d'expérience sur ce sujet.

Pour ta question sur l'autonomie je vais avoir du mal à te répondre car d'une part je ne connais ni la consommation moyenne des appareils que tu cites (hormis le RPi), ni la puissance de ton onduleur. D'autre part je ne suis pas un spécialiste et ne pourrais publier mes résultats avec assurance.

Bonne continuation et n'hésite pas à donner les détails de ta solution quand tu l'auras terminée si tu le souhaites (ou même me contacter si tu veux les publier ici).

Nabla 28/07/2013 22:57

Merci pour tes réponses,

Cela me fait plaisir si j'ai pu t'apporter une information avec le homegenie, pour l'instant il est jolie détecte pas tout en z-wave mais pas tester pour le reste car ne m'apportait pas tout ce que je souhaitais.

Concernant le .Net et la runtime C, est ce que j'ai des chances de le faire tourner sur un raspberry pour importer ma solution à base d'homidom ?

L'idée pour l'autonomie étant de mettre sur l'onduleur que le raspberry pi/ un routeur d-link/ une freebox/des enceintes 7.1 altec lansing et la webcam c910. D'après toi à quel grandeur d'autonomie puis je m'attendre 1H/1J/10J. Hormis le défis :) si c'est moins qu'un jour c'est pas intéressant

Sinon au vu des comparatif la c910 semble sans sortir bien en condition sombre. Ca ne vaut pas une caméra ip avec led mais ce dernier je ne suis pas sur que cela fonctionne avec mon réseau domotique.

En tout cas j'ai déjà réussi ma première étape/tant pis si la version avec le raspberry mette un peu plus de temps.

@+

Nanawel 28/07/2013 09:55

Bonjour Nabla,

Je ne connaissais pas HomeGenie mais cela me donne à présent plein d'idées pour poursuivre sur ma lancée ! Le projet semble en tout cas très intéressant.

À présent pour répondre à tes questions :

- Il est tout à fait possible d'enregistrer les photos et vidéos issues de Motion sur un serveur FTP ou Samba (ou NFS, SFTP, ...) grâce à la magie des montages réseau. Pour FTP puisque c'est ton premier choix, tu peux voir cette page : https://wiki.archlinux.org/index.php/Mount_FTP )

- Concernant l'autonomie de l'onduleur, je pense qu'elle ne sera que très faiblement diminuée après l'ajout du RPi (à la louche je dirais 1 à 2 minutes de moins, grand maximum). La carte consomme en effet extrêmement peu (3,5 W selon cette page : http://fr.wikipedia.org/wiki/Raspberry_Pi#Tableau_comparatif ) Pour répondre précisément il faudrait connaître la consommation de l'ensemble de l'équipement, notamment du PC, le plus gourmand des quatre.

- La C510 de Logitech offre des images et vidéos de bonne qualité sous un éclairage suffisant, mais comme (presque) toutes les webcams il ne faut pas s'attendre à voir dans le noir ! Ou même simplement dans un environnement sombre, car tout ressemble alors à une bouillie de pixels difficilement utilisable...
Je réfléchis depuis quelques temps d'ailleurs à utiliser les ports GPIO du RPi pour commander une petite lampe à LEDs qui me permettrait d'éclairer la scène à la demande, et/ou dès qu'un mouvement est détecté. Mais pour le moment ce n'est qu'une idée que j'ai en tête, n'ayant pas encore le matériel pour le réaliser.

J'espère t'avoir aidé à faire avancer ton Schmilblick :)

Nabla 28/07/2013 08:00

Bonjour,
Je suis tombé, sur votre tuto qui semble bien impressionnant au vu dés différents éléments abordés. Je suis en train de réfléchir à faire l'investissement inconsidéré :p d'une framboise.

Mon but étant de faire un petit système domotique ayant une bonne autonomie :
- J'ai déjà une première version sur mon PC composé d'une solution domotique gratuite mais fonctionnant sur Framework .NET 4 et Runtime C++ 2010, il y a bien des solution raspberry comme homegenie mais mes tests ne permettent pas d'utiliser mon capteur de porte. Je pourrais utiliser la librairie open zwave et coder moi même mais ça risque d'être long :p. (Actuellement je fais clé/détecteur et je joue sur le PC le son, l'alarme n'étant pas pour l'instant reconnu)
- J'ai craqué pour une c910 de logitech et je pense au vu de vos problèmes sur la c510 qu'elle sera considérablement bridée.
- J'ai un onduleur APC 700 pour l'autonomie (20 min actuellement avec PC/Routeur/Box et ampli 5.1)

Mes questions sont :
- Avez vous pu enregistrer directement sur un serveur distant (FTP ou seulement via samba)
- Si je pars sur raspberry, à combien d'autonomie puis je m'attendre avec l'onduleur
- Est ce que avec la C510 offre de bonne vidéo même dans un environnement sombre ? Ma c910 sera t'elle compatible d'après vous.

J'ai limité les questions car plusieurs me viennent en tête mais on verra en fonction de nos échanges.

D'avance merci

Nanawel 11/07/2013 14:56

Au niveau CPU, il faut compter que Motion utilise facilement 30 à 40% à lui tout seul selon htop (et un Load Average d'environ 1.00 en permanence). On est très vite limité avec ce CPU ! J'ai également une instance de Munin qui tourne pour monitorer le système et si trop de plugins sont activés on fait facilement exploser la charge !

Pour la RAM ça ne dépasse jamais 150 Mo chez moi. Parmi les services un peu gourmands tournant en permanence (en plus de Motion) j'ai aussi Webmin, Munin, Lighttpd et Fail2ban. Et en moyenne seuls 100 Mo sont utilisés.

Pour les débits d'écriture j'obtiens 10 Mo/s avec dd. Pour l'upload en utilisant scp je ne dépasse pas 1.5 Mo/s. Idem avec Samba. On peut peut-être espérer un peu plus avec du rsync pur, sans dépasser 2 Mo/s AMHA (cela dit je n'ai pas fait les tests).
Il faut noter que le chipset réseau et les ports USB étant câblés ensemble, la webcam empêche sûrement de monter plus haut en termes de débit.

matthieu 11/07/2013 14:28

Ah d'accord merci pour la réactivité et l'information.
Quand au niveau de CPU utilisé, la mémoire RAM/disque, et surtout le débit d'upload, pouvez-vous en dire plus ?

Nanawel 11/07/2013 14:19

En fait moins que ce que je ne pensais. Quand j'ai eu les problèmes d'alimentation ( http://lanterne-rouge.over-blog.org/raspberry-pi-usb-webcam-et-probl%C3%A8mes-d-alimentation ) j'ai acheté une carte Catégorie 4 de même capacité et je n'ai pas ressenti de grosses différences.
De manière générale, les débits vont surtout avoir leur importance lors de l'installation du système. Après, en fonctionnement de "croisière" il n'y a pas trop d'écritures donc même du 2 Mo/s suffirait en théorie.

Jo' 04/04/2013 14:24

Merci pour ta réponse rapide Nanawel,

Je vais essayer de refaire la tutoriel pour voir si je n'ai pas raté une étape. Je peux t'ajouter sur skype (ou par mail) si je rencontre des problèmes?

Nanawel 04/04/2013 14:50



Non désolé ce n'est pas possible. Le mieux pour que cela profite à tout le monde reste de détailler les étapes sur lesquelles tu bloques ici-même et je tâcherai de t'aider au mieux.



Jo' 04/04/2013 10:41

Salut,

Je voudrais savoir si tu pouvais upload ta configuration, j'ai essayé de reproduire ta tuto mais j'ai eu quelque problème...

Merci d'avance.

Nanawel 04/04/2013 11:57



Salut Jo',


Tous les éléments de ma configuration sont déjà présents dans l'article. Quels sont les problèmes que tu rencontres ? Je peux peut-être t'indiquer ce qu'il te faut corriger.