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
Le 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.
Comme 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" :)
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 ?
Une 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.
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
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 :
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...
Je récapitule le fonctionnement jusqu'ici :
- 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)
- 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
- 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).
- Le dépôt sur Usul est lui-même surveillé par un job incron qui va envoyer les nouveaux fichiers vers Sihaya
- 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 !