Raspberry Pi et domotique

raspberry-ban
Afin d’appareiller nos maisons respectives, nous cherchions une solution domotique abordable.
Après avoir fait le tour du net et des magasins de bricolage, nous nous sommes fixés sur les équipements avec une fréquence de 433Mhz. Ces équipements sont économiques, les protocoles utilisés sont statiques et il est très simple de trouver de quoi communiquer avec.

Le projet

Nous avons profité d’un projet lancé par l’ENSICAEN en partenariat avec Radiospare. Nous souhaitons d’ailleurs les remercier tous les deux pour nous avoir accompagner tant financièrement que techniquement durant ce projet.

La base du projet est la réalisation d’un projet domotique avec Raspberry Pi.

Nous avons choisi de réaliser un petit module à greffer sur les ports du Raspberry Pi afin de pouvoir éteindre et allumer des équipements en RF433 (volets roulants, prises, lumières, etc…).
Une fois ce module réalisé, nous avons développé une interface web afin de pouvoir utiliser et scénariser les équipements.

L’architecture

Nous avons développé notre module à l’aide d’un composant permettant de moduler et démoduler les signaux RF433, le RTX MID 3V.

Afin de capturer les signaux, nous avions besoin d’un système temps réel. La première solution consiste à installer un OS temps réel sur le Raspberry Pi. La seconde consiste à utiliser un micro-contrôleur. Nous sommes partis sur la seconde solution et avons développé sur un PIC18F24k50. Il présente l’avantage d’être petit, économique et de disposer de suffisamment de RAM.

architexture_hard

Les signaux

Les signaux qui permettent de commander les équipements sont statiques. Ceci implique que pour chaque commande allumer et éteindre, le signal émit est identique. La figure ci dessous représente un signal quelconque.

signal

L’objectif de notre module est donc de faire un enregistreur de signal capable de le réémettre. Nous avons remarqué que le signal de commande était réémis plusieurs fois de suite par les émetteurs du commerce. Ceci est dû au fait que le protocole est à sens unique. Il n’y a donc pas de validation (ACK) une fois le signal reçu. Ces espaces vides sont cependant présents sur plusieurs protocoles RF433 que nous avons observé à l’oscilloscope (équipements des marques DIO et Carrefour).

Afin d’acquérir correctement le signal émis à l’intention de ces équipements, nous utilisons l’algorithme suivant :

  1. Lire état (haut/bas)
  2. Si état haut continuer, sinon revenir à 1
  3. Enregistrer le plus longtemps possible
  4. Chercher la plus longue série d’états bas consécutifs
  5. Chercher la plus proche série d’états bas consécutifs de longueur équivalente
  6. Le signal se trouve entre les deux séries d’états bas

Il suffit ensuite d’émettre plusieurs fois ce signal pour allumer ou éteindre un équipement. Cet algorithme a été implémenté en C. L’enregistrement fonctionne sur le module et la recherche du signal (étape 4 à 6) tourne sur le Raspberry Pi.

Le module

Le module se connecte sur les PIN du Raspberry Pi. La communication entre le Raspberry Pi et le PIC18F24k50 est assuré au travers du port série. Pour cela, il a été nécessaire d’utiliser une astuce pour retirer la console du port série d’un Raspberry Pi.
Le module tient dans un boîtier de Raspberry Pi avec une antenne de 8.175 cm de long.
IMG_20141122_172059

Les prochains travaux consisterons à améliorer l’antenne afin d’optimiser la porté en réception afin de permettre l’ajout de nouveaux modules.

Interface Web

Afin de mettre en place l’interface web, nous avons installé un serveur Nginx. La base php et les interfaces ont été développés par Antoine Choquet.

home

equipements

Quand est ce que ça sort

Nous réalisons encore quelques tests avec l’antenne, ce qui peut entraîner quelques changements sur le PCB. En parallèle, nous testons encore un peu le scripts d’installation. Tout ça devrait être prêt dans le courant de décembre, avant noël. Comme toujours, les sources et les schematics seront libres.

Raspberry Pi : Installation Archlinux sur carte SD 16GO


Installation d’Archlinux sur Carte SD 16 Go pour un Raspberry Pi Modèle B.

Télechargement de la derniere version de archlinux ARM, sur le site de Raspberry Pi : http://www.raspberrypi.org/downloads

Actuellement la dernière version est celle datant du 18 Septembre 2012 :

$ wget http://files.velocix.com/c1410/images/archlinuxarm/archlinux-hf-2012-09-18/archlinux-hf-2012-09-18.zip

On vérifie l’intégrité (toujours utile) :

$ sha1sum archlinux-hf-2012-09-18.zip
56e043f3c629f6c408759bcc157d2d635ce0b6af  archlinux-hf-2012-09-18.zip

On extrait notre archive zip :

 unzip archlinux-hf-2012-09-18.zip

On met en place notre Carte SD, pour connaitre quel périphérique est utilisé on fait un petit « dmesg »

$ dmesg
...(extrait)...
[ 6685.088186] scsi 7:0:0:0: Direct-Access     Multiple Card  Reader     1.00 PQ: 0 ANSI: 0
[ 6685.826912] sd 7:0:0:0: [sdb] 31504384 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 6685.828905] sd 7:0:0:0: [sdb] Write Protect is off
[ 6685.828911] sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 6685.830904] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.830910] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.836904] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.836910] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.838290]  sdb: sdb1 sdb2
[ 6685.843910] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.843917] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.843921] sd 7:0:0:0: [sdb] Attached SCSI removable disk

on voit que notre carte SD correspond, au device /dev/sdb

On pose notre systeme :

$ sudo dd if=archlinux-hf-2012-09-18.img of=/dev/sdb bs=1M
1886+0 records in
1886+0 records out
1977614336 bytes (2.0 GB) copied, 168.367 s, 11.7 MB/s

On place notre carte dans le raspberry, on branche écran hdmi/clavier usb OU le cable ethernet, on boot et on peut se connecter en ssh sur notre raspberry 😉 (root/root)
Pour connaître notre ip, si on a pas d’écran HDMI (ou d’apdateur HDMI, VGA/DVI) : nmap -sn 192.168.1.0/24

$ nmap 192.168.1.0/24
 
Nmap scan report for 192.168.1.16
Host is up (0.040s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh

On se connecte :

ssh root@192.168.1.16

Maintenant, on partitionne les 16 GO sur la Carte SD

# fdisk /dev/mmcblk0

On regarde les partitions avec la commande p :

Command (m for help): p
Disk /dev/mmcblk0: 16.1 GB, 16130244608 bytes
4 heads, 16 sectors/track, 492256 cylinders, total 31504384 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c21e5
 
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *        2048      194559       96256    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          194560     3862527     1833984   83  Linux

On supprime la partition 2 afin de la refaire pour nos 16GO, il est possible si vous le désirez de partionner d’une autre manière mais cela reste le même principe

Command (m for help): d  
Partition number (1-4): 2
Partition 2 is deleted

On peut vérifier le résultat :

Command (m for help): p  
Disk /dev/mmcblk0: 16.1 GB, 16130244608 bytes
4 heads, 16 sectors/track, 492256 cylinders, total 31504384 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c21e5
 
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *        2048      194559       96256    c  W95 FAT32 (LBA)

On crée une nouvelle partition avec les mêmes infos seul le last sector change.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (194560-31504383, default 194560): 
Using default value 194560
Last sector, +sectors or +size{K,M,G} (194560-31504383, default 31504383): 
Using default value 31504383
Partition 2 of type Linux and of size 15 GiB is set

On enregistre avec la commande w

Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
 
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

On redémarre.

Le travail n’est pas terminé, il faut l’appliquer pour le filesystem.

Pour cela on resize, c’est assez long.

# resize2fs /dev/mmcblk0p2 
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p2 to 3913728 (4k) blocks.

Et après, c’est terminé ! On reboot notre système et voila 🙂

Après un petit redémarrage on peut faire les mises à jour, ainsi que changer le nom de la machine.

Pour les mises à jour :

# pacman -Suy

On modifie notre nom de machine.

vi /etc/hostname

Et si vous désirez installer des packages qui ne sont pas présents dans le mirror list pour ARM mais présent sur les dépôts pour x86 et x86_64 :
On récupère un package, on modifie son PKGBUILD de manière à remplacer les architectures existantes par la notre : uname -m
Et après c’est la routine : makepkg –asroot PKGBUILD et voilà
Après on installe notre archive. Dans mon cas, cela a été nécessaire lors de l’installation du package dsniff.

It’s OverSimple, isn’t it ?

Et si on sauvegardait notre base de données ?

Avoir un site web c’est bien, mais en faire des sauvegardes ça peut toujours être utile. L’objectif de cet article est de vous montrer comment on sauvegarde notre base de données. Le principe de cette sauvegarde est simple. Ovh éxecute un script que l’on aura stocké sur notre espace personnel. Ce script sauvegardera notre base de données et on obtiendra un fichier SQL contenant notre BDD. Ensuite, un autre script, qui se trouve sur mon serveur personnel, se connectera afin d’aller chercher cette sauvegarde. Vous allez me dire, pourquoi c’est mon serveur qui se connecte au serveur Oversimple ? Tout simplement car je considère que mon serveur est « fiable » contrairement à un serveur mutualisé d’OVH.

Script PHP sur serveur OVH.

<?php
#php doit être supérieur à 5.1

$user="login";
$password="mot de passe";
$nom_de_la_base="baseName";
$serveur_sql="le serveur";
 
#Recupération de la date du jour : JJ-MM-AAAA 
$dateArchive =  date("d-m-Y");
 
#Sauvegarde de la base -> sortie vers un fichier sql -> overSimple-DD-MM-YYYY.sql
system("mysqldump --host=$serveur_sql --user=$user --password=$password $nom_de_la_base > overSimple-$dateArchive.sql");
 
#Récupération de la date a moins 28 jours afin de viser une ancienne archive
$newDate = strtotime('-28 day', strtotime ($dateArchive) );
$newDate = date('d-m-Y', $newDate);
 
#Verification si l'archive existe, on la supprime afin de ne pas en avoir de trop
if(file_exists("overSimple-$newDate.sql")){
	unlink("overSimple-$newDate.sql");
}
 
?>

Script Shell sur mon serveur personnel

#!/bin/sh
 
HOST='le ftp'
PORT='21'
USER='le login'
PASSWORD='un mot de passe ;)'
 
DATE=`date +%d-%m-%Y`
NAME_FILE=overSimple-$DATE.sql
 
#On va dans le repertoire de sauvegarde
cd `dirname $0`
ftp -n $HOST $PORT <<END
quote USER $USER
quote PASS $PASSWORD
cd sauvegarde/
get $NAME_FILE
quit
END
 
#On vérifie si on a télècharger le fichier.
if [ ! -f $NAME_FILE ]
then
    echo "Le fichier n'existe pas !, on le reprogramme pour dans 2 heures"
    echo sh $0 | at now + 2 hours
fi
 
exit

On plannifie l’execute sur OVH

Tous les lundis à 1h du matin. (Hébergement -> Planificateur de tâches)

On planifie sur le serveur

Pour cela rien de bien compliqué, une petite tache cron chaque lundi à 2h du matin (on a de la marge) :

$ crontab -e
00 02 * * 1 /home/overSimple/sauvegarde/sauvegarde.sh
 
On quitte (:wq) et on obtient :
crontab: installing new crontab

Et voilà, on obtient une petite sauvegarde hebdomadaire !