DigitalSpirit / Blog

Après de multiples recherches sur Internet, je m'avoue vaincu : pas moyen de trouver un système d'alarme libre suffisamment avancé et les systèmes propriétaires sont beaucoup trop chères, même d'occasion...

Bien sûr, il reste les systèmes d'alarmes bas de gamme mais que valent t'ils vraiment face à des pros du vol qui connaissent bien les parades...

J'ai donc décidé de développer mon propre système libre, les toutes premières briques ont été posées sur le wiki SystèmeDAlarmeLibre et dans cet article, je vais détailler mes choix.

Cahier des charges

• Multi-zones sans fil, hors de question de tirer des cables partout, il faudra donc prévoir des capteurs autonomes en énergie et capable de communiquer avec la base par radio
• Système d'avertissement local sonore et lumineux ainsi qu'un envoi de SMS avec détail sur l'incident (zone, type d’évènement, horodatage)
• Type de capteurs : Infra rouge (PIR), ouverture (reed switch), vibration, sonore, lumière, fumée, fuite d'eau et pourquoi pas la température et l'humidité
• Communications sécurisées : Multi-bandes et il ne doit pas être possible de brouiller la bande de fréquences utilisée sans déclencher d'alerte, on ne doit pas pouvoir forger de faux messages de « tout va bien »
• Alarmes techniques en cas de batterie faible des capteurs autonomes ou perte du signal d'un capteur
• Watchdog : La centrale doit être capable de se sortir elle même d'un plantage inopiné
• Autonomie électrique de la centrale : en cas de coupure d'alimentation, elle doit tenir suffisamment longtemps pour avoir le temps de lancer ces alertes
• Les boitiers des capteurs et de la centrale devront être autant que possible réalisables grâce aux outils d'un fablab (impression 3d, découpe laser, etc...)

Choix techniques

Centrale

La centrale devra donc gérer la communication avec les capteurs, être capable de déclencher des alertes en rapport avec l'incident reporté (effraction supposée : signal sonore et lumineux, envoi de SMS), gérer l'interface utilisateur par le biais d'un serveur web embarqué et d'un clavier déporté.

Le coeur

Le coeur du système sera un RaspberryPi, tout simplement car je connais bien cette carte, elle est peu onéreuse et ces capacités seront largement suffisantes pour ce qu'on va lui demander de faire... La faible consommation du RaspberryPi facilitera son alimentation en cas de perte de la tension du secteur.

En terme de logiciel, Python sera employé et le système sera donc adaptable à toute carte ou PC...

La communication

La communication avec les capteurs sera effectuée à l'aide d'un nRF905 (http://www.nordicsemi.com/eng/Products/Sub-1-GHz-RF/nRF905), un circuit intégré spécialisé ayant la particularité de pouvoir émettre au choix sur 3 bandes (433, 868 et 915MHz), d'avoir une très faible consommation et d'être très simple à mettre en oeuvre.

Le module GSM pour l'envoi de SMS sera un SIM900.

Module capteurs

Une des partie les plus critiques du système est la capture des événements par le biais de capteurs (infra-rouge, etc...), ces modules doivent être totalement autonome, alimenté par batterie, voici les parties communes :

• La partie radio basé sur un nRF905
• Le coeur : Un Avr (tinyAvr) d'Atmel se chargera de lire l'état du capteur, de communiquer avec la base, de vérifier l'état de la batterie
• Des entrées / sorties pour y brancher le ou les capteurs
• Une batterie

L'autonomie étant critique, l'AVR pourra se mettre en veille et en sortir soit au bout d'un temps déterminé pour vérifier l'état du capteur et avertir la base que tout va bien (ou que tout va mal), ou il pourra également sortir de veille par le biais d'un changement d'état du capteur.

Je pense faire une carte électronique générique pour tous les capteurs afin de gagner en coût et en facilité.

La suite

Dans un premier temps, je veux m'assurer de la bonne portée pratique des modules radios ainsi que de leur consommation car il s'agit DES parties critiques du système.

Ayant d'autres projets sur le feu (dont certain qui trainent depuis bien trop longtemps), j'essaierai d'avancer sur OpenAlarm au mieux...En attendant, j'attends vos retours / avis / conseils / idées, etc...

Un dépôt GitHub OpenAlarm à été ouvert oû je mettrai toutes les informations utiles au développement, le wiki sur GitHub sera aussi tenu à jour.

Voici la suite du billet précédent Intervallomètre, Acte 1 ou je décrivais la réalisation d'un intervallomètre programmable avec possibilité d'ajout de capteurs externes basé sur un article d'Elektor.

Je poursuis aujourd'hui l'article avec l'acte 2 et la fin de la réalisation du schéma de principe et du typon que vous pouvez voir ci-dessous.

Quelques explications sur le schéma :

• Le bloc d'alimentation en haut à gauche, il est constitué d'un MAX1555 qui s'occupe de charger l'élément Lipo lorsqu'une alimentation externe est branchée, il est d'ailleurs possible de sélectionner le courant de charge en faisant un pont de IN_USB sur COMMON pour avoir un courant de charge de 100mA ou un pont de IN_DC à COMMON pour avoir 300mA, tout dépend de l'élément Lipo, mais 300mA devrait convenir dans la plupart des cas. La Led CHARGE permet comme son nom l'indique d'indiquer que l'élément est en charge. En sortie, on trouve un régulateur élévateur de tension à découpage (Switcher Step-Up Voltage Regulator) basé sur un LM2577, rien de particulier ici, notez juste que 2 potentiomètres sont reliés à la broche FeedBack, bien sûr, il ne faut en mettre qu'un des 2, cela permet de laisser le choix sur le type de potentiomètre (CMS ou DIP)
• En dessous, on trouve un bloc « Optional », qui permet d'alimenter le montage en 12V, c'est un peu juste et ça risque de chauffer (12 - 5 * ~0,1A = 700mW à dissiper), le mieux aurait été d'avoir un régulateur à découpage comme celui décrit dans l'article Régulateur à découpage embarqué mais là, ça commençe à faire beaucoup...
• Encore en dessous, le capteur de son, rien de particulier à part les 2 potentiomètres, même note qu'au dessus, on en met qu'un seul
• Pour la partie controlleur, c'est la même chose que dans l'article originale, notez aussi qu'un seul des 2 mosfet doit être placé...

Pour le typon, les dimensions de la carte sont basées sur celle de l'afficheur, les boutons sont situés sur une autre platine.



La suite, prochainement, sera pleine de soudure ;)...

Dans un article d'Elektor du numéro de février est décrit un intervallomètre programmable nommé le TimeClick plutôt intéressant et basé sur un Avr d'Atmel, rien de révolutionnaire mais l'interface à l'air plutôt bien conçue et il est possible de rajouter à peu près n'importe quel capteur pour déclencher les prises de vues.

De mon côté, m'essayant depuis peu à faire des TimeLapses (Mont-Royal Time Lapse #2, Fabriquer son propre Space Invader), la fabrication d'un tel appareil me simplifierait grandement les choses, cependant, pour mon utilisation personnelle, il manque quelques petits choses :

• Il me le faut le plus petit possible pour tenir dans le sac d'appareil photo qui est déjà bien chargé, donc, utilisation au maximum de composants CMS, de plus, le choix de 6 piles 1,5V AA de la version originale n'est pas envisageable, je vais m'orienter vers une alimentation basé sur un seul élément Lipo associé à une alimentation à découpage dite « STEP-UP »
• Dans le cas de TimeLapse très long, pouvoir être alimenté en 12V histoire d'y brancher directement une batterie au plomb.

Le schéma de principe ne devrait plus bouger, la phase de routage est en cours.