Si vous avez suivi mon petit "tutorial" il y a quelques semaines vous devriez avoir grâce à votre Raspberry Pi et une simple webcam, un système de vidéo-surveillance pleinement fonctionnel, autonome, et avec détection de mouvements.
"Pleinement fonctionnel" ? Vraiment ?
Si je me fie à mon expérience personnelle, c'est loin d'être le cas.
Troubles de l'alimentation
J'ai remarqué quelques jours après la mise en place de ce système que mon RPi devenait – après un laps de temps aléatoire (quelques heures à quelques jours) – injoignable, que ce soit par SSH ou par HTTP. Il était alors nécessaire de le rebooter méchamment.
En consultant les logs et notamment /var/log/kernel.log, j'ai noté de nombreux signalements de défauts d'écriture sur le système de fichiers (la carte SD).
$ tail /var/log/kernel.log
Apr 2 20:12:11 comeye kernel: [42422.489985] mmcblk0: error -110 transferring data, sector 6721728, nr 96, cmd response 0x900, card status 0x0
Apr 2 20:12:11 comeye kernel: [42422.490989] end_request: I/O error, dev mmcblk0, sector 6721736
Apr 2 20:12:11 comeye kernel: [42422.491051] Buffer I/O error on device mmcblk0p3, logical block 37657
Apr 2 20:12:11 comeye kernel: [42422.491068] lost page write due to I/O error on mmcblk0p3
Apr 2 20:12:11 comeye kernel: [42422.491095] end_request: I/O error, dev mmcblk0, sector 6721744
Apr 2 20:12:11 comeye kernel: [42422.491145] Buffer I/O error on device mmcblk0p3, logical block 37658
Apr 2 20:12:11 comeye kernel: [42422.491163] lost page write due to I/O error on mmcblk0p3
Apr 2 20:12:11 comeye kernel: [42422.491188] end_request: I/O error, dev mmcblk0, sector 6721752
Apr 2 20:12:11 comeye kernel: [42422.491206] Buffer I/O error on device mmcblk0p3, logical block 37659
Ces défauts entraînaient parfois des corruptions de données, qui à leur tour obligeaient à terme le noyau à remonter la ou les partitions concernées en lecture seule. Une fois la partition / en lecture seule, je pouvais obtenir l'invite de login en SSH mais impossible de m'identifier : la connexion était toujours coupée à l'ouverture de la session.
Après d'intensives recherches plus ou moins fructueuses, j'ai fini par déduire que ce comportement résultait de défauts d'alimentation, probablement causés par la webcam qui "tirait" trop sur l'USB. La seule solution dans ce cas était de la brancher sur un hub USB alimenté indépendamment, relié ensuite au Pi.
Mais la plupart des hubs qu'on trouve sur le marché ne respectent pas les spécifications qui imposent que celui-ci ne doit pas alimenter l'appareil auquel il est relié (c'est-à-dire l'appareil "maître", les périphériques eux doivent être alimentés bien sûr).
Si la plupart des ordinateurs ne trouveront rien à redire à un hub présentant cette anomalie, le Raspberry Pi lui ne l'entend pas de cette oreille, et cela entraîne des erreurs de connexion avec les périphériques (donc ma webcam). Strictement inutilisable en l'état.
J'ai pu d'ailleurs vérifier cela avec un hub pas cher de cette célèbre marque discount qu'est Heden : le simple fait de brancher le RPi sur le port d'entrée allumait les diodes d'activité, signe que le hub lui envoyait du courant, ce qui est potentiellement dangeureux pour la carte (pour info, le terme anglais à rechercher est "backfeed" : si ça backfeed c'est pas bon).
Troubles du... heu, transit
Heureusement, il existe une liste des hubs USB notés "Raspberry Pi-compliant", parmi lesquels j'ai choisi et commandé celui proposé par le site anglais de ModMyPi. Après deux semaines d'attente sans réception, l'envoi d'une deuxième exemplaire par ModMyPi (très sympa pour le coup) et la non-réception de celui-ci après trois semaines, j'ai finalement commandé le même modèle sur eBay, également expédié d'outre-Manche. Et je l'ai reçu ! (à vrai dire je commençais un peu à désespérer...)
Hub NewLink NLUSB2-222
Mes lectures concernant ce modèle indiquaient qu'il était capable d'alimenter à la fois le RPi via un des quatre ports, en plus des autres périphériques qu'on pouvait y brancher. Le transfo d'origine du RPi devenait donc inutile, ce qui permettait d'économiser une prise secteur (et ce n'est pas du luxe, tout geek vous le confirmera !). J'ai donc effectué le branchement pendant que dd recopiait une image saine du système sur la carte SD, pour partir sur de bonnes bases.
Un petit méli-mélo de câbles plus tard, le petit ordinateur, le hub et la webcam étaient reliés et fonctionnels.
Le montage final avec RPi, hub et webcam
Une solution à l'hub-ifidus actif
Ce système fonctionne maintenant depuis quelques jours et, sans vouloir crier victoire trop vite, je pense que cela a bien résolu les problèmes d'instabilité. Je n'ai strictement plus rien dans les logs indiquant des corruptions de données, alors qu'il suffisait aurapavant de 24h maximum pour les voir apparaître. Si vous subissez les mêmes symptômes, essayez ce hub (ou un autre de la liste) et cela devrait être suffisant pour les faire disparaître.
Il est par contre assez décevant de constater qu'un défaut d'alimentation, plutôt que d'engendrer des problèmes de communication avec le périphérique responsable, provoque sur le Raspberry Pi une défaillance d'organes "vitaux" tels que le lecteur de carte SD, seule mémoire de masse disponible.La conséquence étant, comme j'en ai fait l'expérience, de rendre le mini ordinateur instable et finalement de le planter (sans parler des données potentiellement perdues au passage).
Cela fait sérieusement douter sur la fiabilité d'un système "embarqué" dont il serait la base. Je pense ici à une installation fonctionnant 24h/24 et à l'accès peu aisé, type caméra de surveillance extérieure, capteur météo, etc. Dommage.
Avant de terminer, je tiens à mentionner qu'il est fortement conseillé de mettre en place le watchdog de Linux sur un tel système.
Mais dans mon cas cela ne servait à rien car celui-ci n'était que rarement totalement planté (seulement inaccessible par le réseau), et quand il l'était le reboot ne permettait pas de reprendre le contrôle car les dommages sur le système de fichiers pouvaient avoir touché des fichiers vitaux et empêcher ainsi le boot.
Il est cependant important de noter qu'il existe sur le RPi un watchdog matériel qui permet de rebooter automatiquement la carte quand le système est complètement planté. Pour faire court, il s'agit d'un compteur incrémenté régulièrement par un composant externe au CPU et qui, s'il atteint une valeur limite préalablement définie, délenche un hard-reset. L'OS a donc pour tâche de remettre ce compteur à zéro à intervalle régulier afin de signaler qu'il répond toujours. S'il est planté, le compteur ne sera jamais remis à zéro, ce qui entraînera à terme le hard-reset par le watchdog. La durée limite du watchdog présent sur le RPi est de 16 secondes.