Mardi, décembre 1 2015

Et la lumière fut !

Bonjour à tous.
Je fus, pendant longtemps, à la recherche d'une suspension afin de décorer l'ampoule du salon. A mon grand malheur, rien ne nous plaisait vraiment, trop moche, trop occultant, trop cher. Du coup, j'ai émis l'idée d'en faire une en bois. C'est la première fois que je me lance dans de la décoration. La contrainte principale était de ne pas trop occulter la lumière, ensuite éviter que ce soit moche, que ça prenne feu et que ce soit trop cher. Verdict ?

Je me suis lancé, dans un premier temps, dans un modèle 3D afin de faire valider l'aspect général de la bête auprès de la commission décoration de l'appartement. Je suis parti de l'idée de faire la suspension en MDF 3 mm et les dimensions ont été prises de façon à laisser beaucoup d'espace à l'ampoule (un cylindre de 40 cm de diamètre). Le résultat est une suspension japonisante (pas fait exprès !) d'environ 60 cm de diamètre au total.

3D model

L'étape suivante fut de passer d'un modèle 3D vers un modèle 2D. Pour cela, j'ai utilisé un plugin Sketchup. Petit passage sous inkscape pour organiser les pièces et les faire rentrer dans un espace capable de tenir dans la découpeuse laser où je squatte régulièrement (Mon Atelier en Ville). Vous pouvez récupérer les fichiers ICI, ICI, ICI, ICI et enfin ICI. Ensuite montage et test.

morceaux montage1 montage2 montage3 montage4 test

Une fois en place, j'ai trouvé que la suspension était un peu nue. J'ai donc décidé de mettre à l'intérieur un anneau pour donner un peu de couleur sans trop gêner la lumière. A ce point précis, je me suis quand même posé la question de ce que je pouvais placer près d'une ampoule. En gros, j'ai cherché comment faire un abat-jour. Facilement, on trouve qu'il faut utiliser une feuille de polyphane que l'on peut facilement décorer. Le polyphane étant assez rigide, j'ai tenté de le laisser se placer seul. J'ai réalisé un anneau de polyphane recouvert d'un joli papier irrégulier et fin, histoire d'avoir un aspect sympa avec la lumière. Cet anneau est de la taille de l'anneau le plus petit de la structure. Une fois placé, l'anneau tient seul sans rien ajouter, juste avec la friction. De toutes les manières, même si cela tombait, ça ne ferait pas de mal, ni de dégâts.

anneau1 anneau2 fini1 fini2 fini3 fini4

Bilan de la tentative, le design est sympa et change de ce qu'on trouve dans les magasins, il plaît à la maison et on peut facilement changer l'anneau de couleur si l'on veut (il me reste encore assez de plolyphane pour au moins un anneau). Le bilan financier est de : 5 euros de bois, 40 euros de découpe laser et 10 euros de polyphane/papier = 55 euros, ce qui est dans la moyenne des prix des suspensions du commerce.
J'espère que cela vous a donné envie de vous lancer.
A plus les gens ! Et bonne bidouille à tous :)

Lundi, novembre 30 2015

Fabriquer une poulie en bois

Aujourd'hui, pas de domotique ni même de "doigt robotisé", mais du bois.

Quand on a pas beaucoup de place et un peu de hauteur sous plafond, l'idée de stocker des choses en hauteur vient vite. Ces choses peuvent être lourdes et il faut les monter et les descendre. Le marin pense alors tout de suite à un palan. Mais qui dit palan dit poulie et qui dit poulie a vite mal au portefeuille ! Donc nous allons en fabriquer nous-même !

Vocabulaire

Pour commencer, quelques mots pour bien nommer ce dont on parle :
  • bout : nom d'un cordage sur un navire. Un marin ne parle pas de ficelle, corde ou cordage, mais de bout.
  • réa : partie mobile d'une poulie sur laquelle coulisse le bout
  • cul et tête : parties fixes de la poulie situées au-dessous/dessus du réa
  • estrope : bout fixe qui permet d'accrocher la poulie

Dimensions

On trouve assez facilement nombre de dimensions pour des poulies bois. Voici celles que j'utilise :

valeur exemple (mm)
diamètre bout d 8
épaisseur réa 6/5 d 9.6
diamètre réa 6d 48
profondeur gorge réa 1/2 d 4
diamètre axe réa d 8
longueur mortaise 6d +5mm 53
largeur mortaise 6/5 d +3mm 12.6
largeur cul/tête 3/2 d 12
largeur joues 6d + 3/2 d 60
épaisseur joues 3/2 d 12

Avec le petit dessin associé pour être bien clair :

Plan de poulie
Plan de poulie

Réalisation

Quelques outils de base (scies, limes et râpe, perceuse, ...) et un peu de bois de récupération sont suffisants.


Les outils nécessaires
Les outils nécessaires
Le bois nécessaire
Le materiel nécessaire

Le Réa

On le découpe à la scie cloche dans une planche de contreplaqué. Tant qu'à y être, faites en plusieurs, il n'est pas rare d'en casser dans les étapes suivantes.

Découpe des réas
Découpe des réas
Puis, il faut façonner la gorge. Si vous avez un tour, allez-y. Sinon, on le bloque avec boulon et rondelles et hop dans la perceuse. Idéalement une à colonne, sinon on fixe une perceuse avec un serre-joint ou un étau.

Serré avec un boulon
Serré avec un boulon

Il est temps de sortir les râpes rondes, limes et autres queues de rat. N’oubliez pas le masque ou vous allez manger de la poussière !
Le tour du pauvre
Le tour du pauvre


Et voila !
Quelle belle gorge !
Quelle belle gorge !

Le Corps

Pour celui-ci on part d'un morceau de bois brut. D’expérience il est préférable que le fil soit dans le sens de la hauteur de la poulie. Sinon, ça casse !
On trace la mortaise
Avec un trusquin
Avec un trusquin
Repassé au crayon
Repassé au crayon

Puis on la creuse. Je dégrossi à la perceuse et termine au ciseau.

D'abord la perceuse
D'abord la perceuse

Puis le ciseau
Puis le ciseau


Pour finir, on perce les trous pour l'axe. Le diamètre doit être exact pour que celui-ci entre en force et ne se fasse pas la malle après. Il ne reste plus qu'à donner la forme voulue (scie, râpe, lime, ponceuse ...)
C'est presque une poulie
C'est presque une poulie

L'axe

Pour cette touche (presque) finale, j'utilise du rond d'acier tout simple. Évidement en milieu marin, on prendrait de l'inox. On coupe et on rentre au marteau. ne pas oublier d’intercaler le réa ;) (ne rigolez pas, ça arrive)
La, c'est une poulie !
La, c'est une poulie !

Et on finira (enfin) avec la queue de rat en creusant une gorge pour l'estrope.


Petite Bibliographie

Dimanche, novembre 29 2015

Un nouveau boitier pour mon ampli

Je vous avais montré il y a quelques temps, la réalisation d'un ampli HIFI à base de TDA2050, ici, ici et ici.

J'avais fait un boitier provisoire en bois mais comme la qualité sonore de cette ampli m'a vraiment épaté, j'ai préféré lui fabriquer un boitier digne de ce nom.



Mon choix s'est porté sur du plexi pour qu'on puisse voir l'électronique DIY et les belles pièces comme le tranfo torique.



J'ai utilisé des radiateurs de PC (pris sur des ventirad INTEL), ça a un coté récup qui me plait et c'est super efficace pour dissiper la chaleur des deux ampli-op.

J'en ai profité pour rajouter des LEDs bleues sur les 2 cartes ampli et j'ai améliorer la connectique (fiches bananes pour les enceintes, prises RCA plaquées or).

Le matériel nécessaire à la fabrication du boitier:
- 2 ventirads intel
- 1 plaque de plexi 50X25 4mm d'épaisseur
- du profilé alu tubulaire brillant
- des tiges filetées
- des petites équerres
- vis, écrous
- connectiques...

Le plus difficile reste la découpe du plexi. C'est un matériau qui a tendance à casser facilement pendant la coupe (ça, c'est assez facile à gérer) mais aussi à fondre (ça, c'est plus dur à gérer).

J'ai donc fait la découpe en 2 étapes:

la première à la scie sauteuse avec une petite lame pour métaux. Je coince le plexi entre des tasseaux pour éviter qu'il bouge et qu'il ne casse. J'aspire les copeaux avec un aspirateur tout au long de la découpe pour éviter que les copeaux ne reviennent sue la lame et fondent. Je découpe un peu plus grand que la dimension voulue (2 à 3mm).


Je fais la deuxième étape à la défonceuse. C'est parfait pour obtenir un bon état de surface. J'installe ma défonceuse à l'envers sur un établi (comme une toupie) et à l'aide de guides, je redécoupe à la dimension finale. Le sens de l'avance est important, il vaut mieux être en sens opposé à la rotation de la fraise, l'état de surface est meilleur car on ne se fait pas "tirer" par la fraise.

Le guide pour la défonceuse


Après le passage à la defonceuse


Voici quelques étapes en photo de la réalisation:



Découpe des entretoises dans le tube d'alu



Fixation du transformateur toroïdal








J'ai longtemps hésité mais j'ai préféré ne pas rajouter de bouton de volume. Il est donc en direct et le contrôle du volume se fait sur la source (lecteur mp3, téléphone...). C'est un peu moins pratique mais il y a moins de perte de qualité. Si je me procure un super potentiomètre un jour, je le rajouterai.
Je pense à ce genre de réseau de résistances, réputé pour sa qualité mais surtout très esthétique dans le boitier transparent:

Voilà pour la présentation de la dernière version de l'ampli. Je trouve le résultat sympa. Tout ça m'a motivé à en réaliser d'autres...

Quelques petites photos pour finir:






Et maintenant, l'arrière:



Et le dessous:

A plus !





Vendredi, novembre 27 2015

Rpi-pi_EYE -Fin-

Suite de l'épisode précédent :
demopieye.jpg

  • Me revoici donc avec la finalisation de ce projet !

Faute de compétences suffisantes en python-html-css, je me suis vite retrouvé limité dans la compréhension de webpy pour pouvoir afficher une interface comme je voulais…
Je commençais à partir dans tous les sens, sans rien produire, avec une grosse sensation de perte de temps, un projet devenu un point noir qu'on a plus envie de voir.
Et pourtant je voulais le terminer, il était donc temps de redéfinir mes ambitions, que je sache clairement ce que je voulais faire afin de trouver la bonne méthode.
Abandon de l'idée de boutons d'incrémentation de la position de l'œil, exit donc les boutons de formulaire à côté de l'image de la picamera, ils sont une gêne pour la navigation quand on zoome avec un ordiphone, exit donc aussi le css responsive design, et puis tiens si en plus on pouvait se passer d'image à cliquer tout aussi problématique que les boutons…

  • Table en marbre, abandon de webpy, ce que je veux c'est :

- Afficher l'image de la vidéo.
- Cliquer dans l'image de la vidéo pour bouger la camera, sans que la page soit rechargée.
- Cliquer dans l'image de la vidéo pour allumer une lumière, sans que la page soit rechargée.
- Pouvoir zoomer à volonté dans le navigateur sans que ce soit un problème pour les fonctions précédentes.


Prérequis :

  1. Avoir un serveur web installé sur le Raspberry Pi.
  2. Avoir un stream vidéo MJPG-Streamer de la picamera fonctionnel.
  3. Avoir configuré son routeur pour sortir en publique le stream vidéo et le site web.
  4. Désactiver la saisie du mot de passe sudo à l'appel d'une commande python, pour l'utilisateur www-data :
sudo visudo

Ajouter cette ligne à la fin du fichier :

www-data ALL = NOPASSWD: /usr/bin/python



  • Le site web est disponible en pièce jointe à ce billet, je vais décrire ici son fonctionnement :

Plusieurs scripts en python :

  • Dans chaque scripts, ce qu'il faut pour faire bouger l'œil dans une seule position.

On continue d'utiliser la librairie RPIO décrite dans les billets précédents.
Ici le script centre.py :

#!usr/bin/env/ python

import RPIO, time
from RPIO import PWM
servo = PWM.Servo()

servo.set_servo(17, 2300)
servo.set_servo(18, 1350)
time.sleep(0.5)
PWM.cleanup()


Plusieurs scripts en php :

  • Chaque script contient une commande système permettant d'appeler le scritp python.

Ici le script centre.php :

<?php
system ("sudo python python/centre.py");
?>


  • Le script pour allumer la lumière est un peu différent, il appelle directement des commandes système liées à l'utilisation classique du logiciel wiringpi.
<?php
// allume la led connectée en 2
system ( "gpio mode 2 out" );
system ( "gpio write 2 1" );
sleep(10); // attend 10 secondes
system ( "gpio write 2 0" ); // éteint la led connectée en 2
?>


Un script en JavaScript :

  • Le script va permettre de gérer des actions sur des cliques de souris, sans recharger la page web !

Ici un morceau du script qui permet d'appeler le script centre.php.

function centre()
{
var requestC = new XMLHttpRequest();
requestC.open( "GET" , "centre.php" );
requestC.send(null);
}

J'ai laissé le JavaScript dans la page html…

La page html du site :

  • L'index.html va donc contenir le code JavaScript, l'image de la vidéo de la picamera et des zones cliquables définies par des coordonnées sur cette image.

Je rappelle que pour streamer la vidéo de la picamera, j'utilise MJPG-Streamer version spéciale Pi, le tuto par ici : Le Stream sur IP live avec MJPG-Streamer raspicam.

<!DOCTYPE html>
<html>
	<head>
        	<meta charset="utf-8" />
	        <title>Amy-Channel =^.^=</title>
	</head>

<script type="text/javascript">
function gauche()
{
var requestG = new XMLHttpRequest();
requestG.open( "GET" , "gauche.php" );
requestG.send();
}

function gauche2()
{
var requestG2 = new XMLHttpRequest();
requestG2.open( "GET" , "gauche2.php" );
requestG2.send();
}

function centre()
{
var requestC = new XMLHttpRequest();
requestC.open( "GET" , "centre.php" );
requestC.send(null);
}

function centre2()
{
var requestC2 = new XMLHttpRequest();
requestC2.open( "GET" , "centre2.php" );
requestC2.send(null);
}

function droite()
{
var requestD = new XMLHttpRequest();
requestD.open( "GET" , "droite.php" );
requestD.send(null);
}

function droite2()
{
var requestD2 = new XMLHttpRequest();
requestD2.open( "GET" , "droite2.php" );
requestD2.send(null);
}

function leds()
{
var requestL = new XMLHttpRequest();
requestL.open( "GET" , "leds.php" );
requestL.send(null);
}

</script>

	<body>
        	<center>
<!--  l'image de la picamera --> 
			<img src="http://adresse ip du stream:port/?action=stream" usemap="#panneaux" />
<!--  les zones cliquables, qui appellent chacune le java script correspondant (qui appelle le script php (qui appelle le script python) )  --> 
			<map name="panneaux">
				<area shape="rect" coords="0,0,150,150" onclick="gauche2()" alt="Haut-Gauche"  />
				<area shape="rect" coords="490,0,640,150" onclick="droite2()" alt="Haut-Droite"  />
				<area shape="rect" coords="246,0,395,150" onclick="centre2()" alt="Haut-Centre"  />
				<area shape="rect" coords="0,325,150,480" onclick="gauche()" alt="Bas-Gauche"  />
				<area shape="rect" coords="490,330,640,480" onclick="droite()" alt="Bas-Droite"  />
				<area shape="rect" coords="246,330,395,480" onclick="centre()" alt="Bas-Centre"  />
				<area shape="circle" coords="320,240,50" onclick="leds()" alt="LEDon" />
			</map>
	        </center>
    	</body>
</html>
  • Voici la démo vidéo :


Concernant la barre de lumière :

  • Il s'agit de 6 leds de 13000 mcd (3,2V@20mA) connectées en parallèles, alimentées directement par le 5V du Rpi et pilotées par le GPIO2 (pin19) via par un transistor 'Mosfet'' (BS170), câblé comme suis :

- Le drain est connecté aux cathodes des leds.
- La Grille va à la pin19 du Rpi.
- La Source va à la masse.

  • Voici le schéma mis à jour et des photos du proto soudé sur une plaque à trous :

Rpi_Pi_Eye2_bb.png
dsc00979.jpg dsc00978.jpg

Les entrailles d'OpenAlarm : Une première interface PC en Python

Je vous ai présenté dans le précédent article le principe de fonctionnement d'un OpenAlarm Node, c'est parfaitement fonctionnel et utilisable mais nous pouvons simplifier grandement tout ça et c'est là qu'intervient l'interface que je vais vous présenter dans cet article.

Un programme en Python nommé simplement base.py permet les interactions avec les OpenAlarm Node, il s'utilise en ligne de commande :

$ python3 base.py --help
OpenAlarm Base
Usage:
base.py [options] nodeid <nodeid>
base.py [options] config write <config>
base.py [options] config set <key> <value>
base.py [options] profile write <profile_name> [<profile_id>]
base.py [options] profile set <profile_id>
base.py [options] node write <node_name>
base.py [options] node read
base.py [options] listen [--csv <csv_file>]
base.py [options] remote <node_name> --set <commands>...
base.py --version
Options:
-p            Serial port
-f            Force node write even when different nodeid
-h --help     Show this screen
-d --debug    Debug mode
-v --verbose  Verbose mode
$ 

Je vais passer en revue toutes les possibilités offertes par ce programme.

nodeid

python3 base.py -p /dev/usbserial0 nodeid 2

Cette commande va donner au Node dont le périphérique série est /dev/usbserial0 l'identifiant de node 2

config write

python3 base.py -p /dev/usbserial0 config write default

Cette commande va écrire la configuration nommée default dans le node lié au périphérique /dev/usbserial0

Mais d'oû sort la configuration default ?

Toute la configuration d'OpenAlarm tient dans un fichier au format Yaml et default correspond dans l'exemple ci-dessus à la configuration du même nom du nœud config.

Ce n'est pas clair ? Regardons de plus près une partie du fichier de configuration oa.yaml :

[...]
configs:
    default: &default
        group: 210
        freq: 433
        ack: yes
        cmdtimeout: 15
        usbtimeout: 15
        autostart: yes
        power: 0
        remote:
            active: yes
            wait_error_cycle: 7
[...]

Nous y trouvons une suite de clefs / valeurs (les mêmes clefs que nous avons aperçu dans l'article précédent sur les entrailles du firmware) qui vont permettre de configurer comme nous le souhaitons notre Node.

Ainsi, dans l'exemple ci-dessus, nous donnons au Node le groupe 210, nous les spécifions une fréquence de 433Mhz, avec accusé de réception (ack = true), bref, je suppose que vous avez compris le principe de fonctionnement...

La commande config write va donc lire la configuration et l'envoyer au Node directement.

config set

python3 base.py -p /dev/usbserial0 config set group 220

Cette commande permet de modifier directement des variables de configuration, utile si on ne veut changer qu'un seule des paramètres.

profile write

python3 base.py -p /dev/usbserial0 profile write pir0

C'est assez explicite, avec cette commande, nous écrivons le profile nommé pir0 dans le périphérique /dev/usbserial0 (pour en savoir plus sur les profiles, voir le dernier article)

pir0 correspond au nœud du même nom du fichier oa.yaml :

[...]
    pir0: &profilepir
        description: Module avec capteur infrarouge 0
        feedback: yes
        period: 3
        eintwait: 3
        external_interrupts:
            io0: rising
        ios:
            io0: [ input, nopullup ]
        frame:
id: 2
content:
- counter
- waketype
- wakearg
- [ input0, input1, input2 ]
- voltage
- temperature
[...]

profile set

python3 base.py -p /dev/usbserial0 profile set 0

Change le profile courant du Node.

node write

python3 base.py -p /dev/usbserial0 node write xxx

Nous avons vu au dessus le fichier Yaml avec les nœuds configs et profiles, il existe un autre type de nœud, il s'agit de 'nodes' qui contient tous les paramètres pour un Node nommé.

Voici le contenu du nœud nodes du fichier oa.yaml :

[...]
nodes:
    pir0:
        id: 2
        config: *default
        key: abcdefghijklmnop
        profile:
            0: *profilepir
    temp:
        id: 1
        config: *default
        key: AKdlIqdjMKAQwJKz
        profile:
            0: *profiletemp
[...]

node read

python3 base.py -p /dev/usbserial0 node read

Lit le Node et affiche des informations sur sa configuration.

listen

python3 base.py -p /dev/usbserial0 node listen

Se connecte au Node via la liaison série et passe en mode promiscuous, une sorte de mode sniffer ou toutes les frames valident envoyées par les OpenAlarm Node sont retournées via l'interface série.

Si nous nous connections au node directement via l'interface série et que nous entrons la commande série, voici le format du contenu retourné :

$ ino serial
listen
OKX 010206000103047A0B16
OKX 010207000103007A0B16
OKX 010208000202007A0B16
OKX 010209000103007A0B16

À chaque réception d'une frame valide, elle est retournée sous la forme OKX 010206000103047A0B16, ou OK indique un paquet valide, X indique que le format de la frame est hexa, puis, suivi d'un espace, nous avons la frame brute.

Ce contenu n'est pas franchement lisible et c'est pour cela que nous utilisons le programme en Python qui nous simplifie grandement la vie, voici la même fonction listen mais utilisée via l'interface en Python :

$ python3 base.py -p /dev/usbserial0 node listen
Use device /dev/usbserial0
Start listen mode !
Nodeid: 1, frame type: 2 (0 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00

C'est tout de même beaucoup plus clair ainsi ! Non ?

Par curiosité, rendons cela un peu plus verbeux...

$ python3 base.py -p /dev/usbserial0 --verbose node listen
Verbose mode !
Use device /dev/usbserial0
Start listen mode !
verbose get
-> 0
verbose set 0
-> OK
listen raw
Nodeid: 1, frame type: 2, payload: 64000202007A0B15 (2 second(s))
    Counter     : 100
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2, payload: 65000202007A0B15 (5 second(s))
    Counter     : 101
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2, payload: 66000202007A0B15 (5 second(s))
    Counter     : 103
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00

Une fois ces données reçue, c'est à vous d'en faire ce que vous voulez...
Un paramètre csv vous permet de spécifier un fichier afin de stocker toutes ces informations dans un fichier.

node remote

python3 base.py -p /dev/usbserial0 remote pir --set period=1

Cette commande va se connecter à l'OpenAlarm Node connecté sur l'USB puis tenter une liaison distante avec le Node nommé pir (voir fichier format Yaml) afin de changer le paramètre period.


Voilà, vous savez tout sur l'interface actuelle en Python, si vous voulez en savoir, vous pouvez consulter le code et au sujet du fichier oa.yaml, je vous invite également à le consulter !

Mardi, novembre 24 2015

Démonter un extincteur…

…si possible sans tout se prendre dans la figure !
J’ai en ce moment 2 projets en cours, qui nécessitent des extincteurs. Les extincteurs vident sont assez difficile à trouver, en revanche, le pleins sont très courants à cause des dates d’expirations. Bien sûr, il y a toujours la possibilité de les vider à la barbare, mais c’est assez dégueu et surtout pas du tout écologique, les additifs à l’intérieur étant assez nocifs. Je vais donc vous expliquer comment ouvrir certains types d’extincteurs « proprement ».

ATTENTION ! J’ai l’habitude de vous présenter des expériences plus où moins dangereuses, là, on joue avec des bouteilles potentiellement sous pression. Une erreur sur le type de bouteille ou de manipulation, et vous vous retrouvez avec une poignée incrustée dans la tête. Les poudres ABC sont corrosives et irritantes, portez donc les protections indispensables à ce genre de manipulations (gants, lunettes, masque). Si vous avez un doute sur le type de bouteille, n’utilisez pas cette méthode.

Maintenant que c’est dit, commençons. Il nous font déjà le bon type d’extincteur. Il en existe (à ma connaissance) 3 principaux types : les extincteurs à CO2, les extincteurs à poudre/eau percutables et les extincteurs à pression permanente. Ici, on va s’intéresser aux extincteurs percutables :

Le modèle correct d'extincteur

Le modèle correct d’extincteur


Dans ces modèles, le gaz est contenu dans une petite bonbonne à l’intérieur de l’extincteur, et n’est libéré que lorsque la goupille est enlevée et la capsule percutée. En temps normal, il « n’est pas sensé » y avoir de pression dans l’extincteur.
A ne pas confondre avec
Les extincteurs à pression permanente

Les extincteurs à pression permanente


Les extincteurs à pression permanente qui, comme leur nom l’indiquent, sont sous pression tout le temps. Deux différences qui permettent de les reconnaître : l’absence des 2 boulons autour de la tête, et surtout le manomètre. (attention, tous les modèles à pression permanente n’ont pas le manomètre, mais quand il y en a un, vous êtes sûr que c’en est un). Pour ces modèles là, je ne connais pas de procédure pour les vider autrement qu’en les déclenchant, on va donc les oublier.

Maintenant qu’on a notre extincteur, on va pouvoir commencer.
Tout d’abord, prenez garde que la goupille est toujours présente et ne l’enlevez surtout pas ! Si vous faites ça, le gaz va remplir la bonbonne, et vous n’aurez pas d’autre choix que de le vider « classiquement ».
Ensuite on va dévisser les 2 boulons entourés de bleu sur la photo. Ne les dévissez pas entièrement dans un premier temps, faites juste 1 tour sur chaque et essayez de lever légèrement la tête de l’extincteur. S’il n’y a pas de fuite, continuez en faisant un tour supplémentaire, et ainsi de suite jusqu’à ce que la tête de l’extincteur soit clairement dissociée du corps. Un fois à ce stade, vous pouvez dévisser complètement. L’intérêt de cette méthode, c’est que s’il y a de la pression (la cartouche de gaz a fui par exemple), vous ne vous prendrez pas tout dans la tête en une fois. Il y aura une fuite, donc vous vous éloignez et attendez que ça se termine.

P1030927

Les boulons à dévisser

Une fois totalement dévissé, retirez la tête en tapotant légèrement les bords pour faire tomber la poudre.

Enlevez la tête

Enlevez la tête

Votre extincteur est maintenant ouvert. Videz précautionneusement la poudre dans un contenant (c’est TRES volatile, allez y doucement ou il va y en avoir de partout, pensez au masque et lunettes), et emmenez ça à la déchetterie.
Et voilà :)

Dimanche, novembre 22 2015

Contrôler le chauffage par fil pilote (épisode 2)

Previously in Fil Pilote épisode 1:

Un passage à l’échelle étant nécessaire pour commander tous les radiateurs de la maison, Jean-Robert (pseudonyme) décide de faire fi de l’existant. Armé seulement de son Kicad et de sa carte bleue, il dessine une carte modulable de contrôle du fil pilote. Nous l'avions laissé alors qu'il guettait fébrilement le passage de l'homme à la voiture jaune ...


Les cartes sont enfin arrivées de chez seeedstudio et un peu de temps s'est rendu disponible.
Featuring Marty & Doc
Je me suis donc jeté sur mon fer à souder et mon étain pas du tout ROHS. La bonne nouvelle est la : je ne me suis pas gouré :)
Je peux donc envoyer vers les fils pilotes l'alternance positive et/ou négative d'une sinusoïde à 50Hz à volonté.
Preuves à l'appui :
Mode Hors-Gel
Alternance négative
Mode Arrêt

À gauche, les fils de signal (mauve/marron) pour choisir la/les alternances à laisser passer. À droite en haut (vert), la phase. À droite en bas (blanc) le fil pilote.

Une fois ce 1er test concluant, j'ai donc soudé complètement 2 cartes ce qui va me permettre de commander les 5 ou 6 fils pilotes de la maison.
Une carte complète

Quelques temps plus tard un code pour l'Arduino qui va me permettre de commander tous ces signaux était lui aussi né. Très simple, il se contente de recevoir le mode de chauffage sur le port série et d'en déduire les signaux de commande pour les optocoupleurs.
Vous pouvez le voir sur GitHub ainsi que son script shell compagnon.
À noter qu'il permet aussi de commander des prises Chacon dont nous reparlerons sans doute sous peu.

Voila pour ce court épisode. Dans le prochain, j'aurai reçut les entretoises en nylon que j'attends  et nous pourrons enfin installer tout cela dans la GTL.

En attendant, vous pouvez retrouver plus de photos et tous les liens la : Contrôle du chauffage par Fil Pilote

Lundi, novembre 16 2015

Les entrailles d'OpenAlarm : Le firmware

Il est temps de vous parler un peu de la partie logiciel du projet OpenAlarm qui est en 2 parties : le logiciel interne (firmware) aux OpenAlarm Node et la partie qui tourne sur l'ordinateur, dans cette première partie, je vais vous présenter uniquement le fonctionnement des OpenAlarm Node.

Cet article est volontairement technique et rentre dans des détails que l'utilisateur final n'aura pas à connaître mais si vous souhaitez participer au projet, vous aurez besoin de ces informations.

Principe de fonctionnement

Le fonctionnement des OpenAlarm Node est plutôt simple, le système est conçu pour être utilisable sans base, c'est à faire qu'avec juste 2 Node (et un ordinateur), vous avez un système pleinement utilisable, en effet, chaque Node embarque le code nécessaire pour la surveillance de grandeur issue de capteur (mouvement, température, luminosité, courrier dans la boite aux lettres, etc...) mais également celui pour servir de base réceptionnant les messages des autres capteurs.

Un Node à donc plusieurs modes de fonctionnement :

  • Le mode « écoute »  (lancé par la commande listen) qui permet de recevoir tous les messages des autres nodes, ce mode sera celui utilisé par la base pour réceptionner les messages de tous les Nodes
  • Le mode « surveillance » (lancé par la commande guard) permettant de rentrer en surveillance et d'envoyer à intervalle régulier les informations contenues dans les frames (voir plus bas)
  • Le mode « remote » (lancé par la commande remote) afin de se connecter à un Node distant (par radio) afin d'en modifier les paramètres

À la mise sous tension, un Node démarrera automatiquement en mode surveillance si ce dernier n'est pas branché à un ordinateur et ne reçoit pas de commande le lançant dans un autre mode.

Difficile de faire plus simple, non ?

Les sources

Tous les fichiers sources sont disponibles dans le dossier /src dont voici l'arborescence :

  • base : Contient le code source Python utilisé sur l'ordinateur
  • lib : Les librairies utilisées par le projet voir plus bas
  • node : Le code source embarqué dans les node

Le firmware

Les sources et librairies

Le firmware de chaque node est écrit en C et compilé avec les outils Arduino, j'ai utilisé Ino (une interface en ligne de commande pour Arduino) pour compiler / programmer les OpenAlarm Node mais vous pouvez bien entendu utiliser l'environnement par défaut d'Arduino.

Les librairies utilisées :

  • Jeelib : la plus importante, elle est l'interface entre le cœur du montage, le microcontrôleur, et la partie radio, elle gère également des fonctions très utile de mise en sommeil, etc... Je vous invite à parcourir la documentation très complète sur cette librairie qui simplifie grandement le développement.
    Il existe d'autres librairies permettant l'interfaçage avec les modules radios utilisés dans OpenAlarm comme celle de LowPowerLab ou encore RadioHead que j'ai découvert il y a peu de temps. L'idée serait de les tester en profondeur afin de voir si il serait intéressant de basculer sur une autre ou pourquoi pas, prendre le meilleur des 3 pour en faire une dédiée à OpenAlarm qui permettrait notamment de prendre moins de place en mémoire (le principale problème de Jeelib)...
  • SerialCommand : Une librairie utilitaire permettant de piloter les OpenAlarm Node via des lignes de commande, elle prend peu de place et permet de gérer des commandes suivi de leur arguments simplement (ex: set power 1 envoyé via la liaison série va modifier la valeur de la puissance d'émission à 1)
  • DallasTemperature et OneWireNoResistor sont utilisées si vous souhaitez communiquer avec des modules OneWire
  • OpenAlarm qui contient les fonctions principales du projet

Afin de compiler les sources avec Ino, voici les étapes à suivre :

  1. Installer Ino, ça peut être utile ;)
  2. Placez-vous dans le dossier src/node
  3. Lancez la commande ino build et voilà, vous pouvez maintenant envoyer le firmware sur le node (après avoir appuyé sur le bouton reset de ce dernier) via la commande ino upload

Voilà, vous avez un OpenAlarm Node fonctionnel...

Les commandes

Lorsque vous branchez un OpenAlarm Node sur le port USB de votre ordinateur, un périphérique série est créé et vous permet de dialoguer directement avec ce dernier via des commandes.

Pour lire la configuration du Node connecté :

$ ino serial
config
OpenAlarm node, version oa10
- nodeid      : 1
- freq        : 433Mhz
- group       : 210
- ack         : yes
- power       : 0 (highest)
- autostart   : yes
- cmd timeout : 15 second(s)
- usb timeout : 15 second(s)
- remote      : yes (wait error cycle: 7)
- key         : AKdlIqdjMKAQwJKz
Profile 0:
- period    : 3 second(s)
- feedback  : yes
- eint wait : 3

En rouge, nous avons la commande saisie sur l'ordinateur pour démarrer la liaison serie via USB et en vert la commande saisie via la liaison série sur le Node, le reste étant la réponse faite par la Node.

Liste des commandes disponibles :

Liées à la configuration :

  • config : Affiche la configuration courante
  • verbose : Spécifie le niveau de verbosité
  • debug : Active ou non la débug
  • get : Retourne la valeur d'une variable de configuration (ex: get power pour lire la puissance d'émission)
  • set : Modifie la valeur d'une variable de configuration (ex: set key ABCDEF pour modifier la clef)
  • frame : Permet de lire / modifier les frames radio (voir plus bas)
  • int : Permet de lire / modifier les interruptions matérielles (ce qui va sortir le node du mode veille)
  • io : Permet de lire / modifier / configurer les entrées / sorties

Commandes permettant de faire rentrer la node dans des modes spécifiques :

  • guard : Entre dans le mode de surveillance
  • listen : Entre dans le mode réception
  • remote : Connexion à un node distant
  • exit : Sort du mode courant

Liées à la partie radio :

  • send : Envoie les arguments par radio
  • rfinit : Initialise la partie radio

Liées aux tests :

  • blink : Fait clignoter les leds
  • test : Commandes fourre-tout permettant de lancer divers tests (usb, io, sleep, ...)
  • read : Lit une frame
  • volt : Lit la tension
  • temp : Lecture / calibration de la température (capteur intégré à l'µC)

Toutes les commandes ne sont pas toujours directement accessibles à des fins d'économies de mémoire et sont activables ou non via des #define.

Les paquets

J'ai voulu faire un système totalement configurable, ainsi, le format des paquets envoyés par la liaison radio n'est pas fixe et modifiable à souhait.

Utilisons la commande frame afin d'afficher le format courant :

frame
Frame (type: 2, size: 9) :
-> [type] [counter] [waketype] [wakearg] [input0,input1,input2] [voltage] [temperature]

La commande frame affiche alors le contenu d'une frame telle qu'elle sera envoyée à la base, voici une explication sur les différents éléments :

  • [type] : Le type de frame sur un octet permettant à la base de décoder les informations reçues (type: 2 dans l'exemple)
  • [counter] : Le compteur de frame usr 2 octets, à chaque envoi de frame, ce compteur est incrémenté (utile à la base pour savoir si cette dernière a manqué des paquets)
  • [waketype] : Une information sur ce qui a sorti la node de la veille (ex: interruption externe, timer, etc...) sur un octet
  • [wakearg] : Informations complémentaire sur la sortie de vieille (ex: l'entrée pour une interruption externe, la période pour le timer, etc...) sur un octet
  • [input0,input1,input2] : Un octet contenant la valeur des entrées 0, 1 et 2
  • [voltage] : La tension de la batterie (sur 2 octets)
  • [temperature] : La température lue via le capteur de l'µC (sur un octet)

En rouge, il s'agit de l'entête fixe (le préambule), en vert, nous avons ce qui reste totalement configurable par l'utilisateur

Si dans votre application, vous n'avez besoin que de la température, il vous suffit de le spécifier à l'aide de la commande frame :

frame set 4 65
Frame set !

Explication des arguments envoyés :

  • frame : La commande voulue
  • set : Un argument de la commande frame : on souhaite écrire le format d'une frame
  • 4 : Le type de frame (ce sera utilisé par la base pour reconnaitre le format)
  • 65 : 65 correspond à la température (voir explication plus bas)

Si nous retapons la commande frame, nous voyons que le format à bien changé :

frame
Frame (type: 4, size: 5) :
-> [type] [counter] [waketype] [wakearg] [temperature]

Au sujet du contenu des frames, dans la précédente commande, nous voulions une frame constituée uniquement de la température et nous avons utilisé 65 pour le spécifier, voici une liste de ce qu'il est possible d'utiliser pour constituer une frame :

  • input0 à input9 (8 à 17) : Les entrées numérique du microcontrôleur sur un bit
  • analog0 à analog5 (32 à 37) : Les entrées analogiques sur 2 octets
  • voltage (64) : La tension de la batterie
  • temperature (65) : La température issue du capteur interne du microcontrôleur
  • Bien entendu, vous pouvez ajouter n'importe quel type de chose à ajouter dans une frame

Les interruptions

Nous venons de le voir, au travers des frames, nous pouvons envoyer les informations que nous voulons à la base, ces informations seront envoyées à intervalle régulier défini au préalable (par exemple, avec un intervalle d'une minute), le reste du temps, l'OpenAlarm Node reste en veille afin de consommer le moins possible.

Mais comment faire si un événement se produit exactement durant cette veille ? C'est là qu'intervienne les interruptions qui vont sortir de veille notre Node afin d'envoyer immédiatement une frame dans le but d'alerter la base.

Le microcontrôleur possède des interruptions matérielles sur certaines de ses entrées / sorties et afin de spécifier lesquelles vont nous servir pour sortir le Node du sommeil, nous utilisons la commande int comme ceci :

La commande int sans argument nous liste les interruptions actuelles :

int
Not int !

Ajoutons 2 interruptions, la 2 correspondant à l'entrée / sortie 0 afin de surveiller un front descendant (falling) et la 0 pour un front montant (rising) :

int add 2 falling
Int added !
int add 0 rising
Int added !

Listons de nouveau les interruptions :

int
Ints (size: 2) :
- 2 (input 0) falling
- 0 (input 3) rising

Voilà, lorsque l'OpenAlarm Node rentrera en mode guard, il configurera les interruptions ci-dessus afin qu'il sorte du mode veille en cas d’événement pour envoyer une frame d'alerte.

Les entrées / sorties

Voilà une dernière commande qui va nous être bien utile, elle permet de configurer les entrées / sorties dans un état prédéfinie au moment de l'entrée en veille.

io
Inputs :
- io0 : input pullup
- io1 : input nopullup
- io2 : input nopullup
- io3 : input nopullup
- io4 : input nopullup
- io5 : input nopullup
- io6 : input nopullup
- io7 : input nopullup
- io8 : input nopullup
- io9 : input nopullup

Les profiles

Nous venons de voir les paquets, les interruptions et les entrées / sorties, OpenAlarm permet de créer des profiles qui regroupent tous ces paramètres afin de changer rapidement de configuration sans avoir à renvoyer tous les réglagles.

On peut ainsi imaginer être sur un profile simple lorsque vous êtes chez vous ou l'OpenAlarm Node envoie à une période de 5 minutes les paquets contenant le contenu des mesures de ces capteurs, et, lorsque vous partez de chez vous, vous basculez à distance sur un autre profile ou la période d'envoi est de 15 secondes.
En procédant ainsi, on gagne en autonomie.

Un profile peut contenir les informations suivantes :

  • period : La période d'envoi des informations à la base
  • feedback : Faire clignoter les leds du Node selon l'action courant
  • eintwait : Lorsqu'un évènement est détecté, nombre de cycle d'attente durant laquelle l'évènement si il est reproduit doit être ignoré (si eintwait = 2 et period = 5 secondes alors, le temps durant lequel un nouvel évènement sera ignoré sera de 10 secondes)
  • external_interrupts : Il s'agit de la configuration des interruptions externes (Les interruptions)
  • ios : La configuration des entrées / sorties (Les entrées / sorties)
  • frame : Le format des paquets (Les paquets)

Chaque OpenAlarm Node peut avoir un maximum de 3 profiles différents.

Pour basculer d'un profile à un autre, il suffit d'utiliser la commande set ainsi :

set profile set 1
Done

Un exemple concret

Voici un exemple concret d'utilisation de ce que nous venons de voir.

Imaginez que vous vouliez surveiller une pièce isolée avec un détecteur de mouvement, vous souhaitez également détecter des chocs (dans le cas ou votre Node est placé sur une des portes par exemple) et tant qu'à faire, vous aimeriez connaître la température de cette pièce.

Nous avons 3 capteurs utilisées :

  • Le détecteur de mouvement (PIR) que nous allons brancher arbitrairement sur l'entrée 0, ce capteur place sa sortie à l'état haut lorsqu'une détection est faite, sa sortie est de type push / pull et ne nécessite donc pas de résistance de tirage
  • Un capteur de vibration qui peut être vue comme un simple interrupteur se fermant lorsqu'une vibration est détecté, nous aurons besoin pour lui d'une résistance de tirage et nous brancherons ce capteur sur l’entrée 1
  • Le capteur de température interne

Nous nous connectons alors sur l'OpenAlarm Node :

$ ino serial
frame set 2 8 9 64
Frame set !
io set 0 input nopullup
Io set !
io set 1 input pullup
Io set !
int add 2 falling
int set !
int add 3 rising
int set !

Explications pour chaque commande :

  • ino serial On ouvre dans un terminal une liaison série avec le Node
  • frame set 2 8 9 64
  • io set 0 input nopullup On indique que l’entrée / sortie 0 devra être configurée en entrée sans résistance de rappel
  • io set 1 input pullup On indique que l’entrée / sortie 1 devra être configurée en entrée avec résistance de rappel
  • int add 2 falling On configure une interruption matérielle 2 (correspondant a l’entrée 0) sur un front montant
  • int add 3 rising On configure une interruption matérielle 3 (correspondant a l’entrée 1) sur un front descendant

Pour voir le paquet qui sera envoyé, utilisez la commande frame :

frame
Frame (type: 2, size: 7) :
-> [type] [counter] [waketype] [wakearg] [input0,input1] [temperature]

Une fois ceci réalisé, on peut configurer la période à laquelle le Node va nous donner des nouvelles de lui (1 minute et 30 secondes ici) puis on le lance en mode surveillance :

set period 90
Done
guard
Starting guard mode !

Maintenant, l'OpenAlarm Node nous enverra toutes les 1 minute et 30 secondes la frame que nous avons configuré et si un évènement survient via le capteur de mouvement ou le capteur de vibration, une frame est immédiatement envoyée.

Notre Node est pleinement fonctionnel en surveillance de sa zone mais imaginons que nous voulions changer la période d'envoi des frames, comme nous sommes feignants, nous n'allons pas aller chercher le Node mais tout simplement nous connecter à distance dessus afin de changer le paramètre voulu :

remote 1 AKdlIqdjMKAQwJKz 
Connecting...
Success!
period 60
power 3
exit
Disconnected!

Dans cet exemple, l'utilisateur se connecte au Node 1 avec la clef AKdlIqdjMKAQwJKz, puis saisie 3 commandes (en orange) afin de changer la période d'envoi des informations à 60 secondes et modifie la puissance d'émission avant de se déconnecter avec la commande exit.

Voilà pour le tour de présentation du fonctionnement logiciel des OpenAlarm Node, dans un prochain article, je présenterai l'interface Python permettant de réaliser les mêmes opérations mais de façon automatisées...

- page 2 de 85 -