Nous avions découvert le DS2406 avec la commande d'un ventilateur : il s'agissait donc d'une sortie vers le monde extérieur. Les PIOs permettent aussi de récupérer des informations, c'est le sujet de cet article.

Mon but est ici de détecter si la porte de la cave a été fermée et correctement verrouillée.

(Ce billet a été mis à jour le 16 juillet 2016 après réception du capteur de porte ouverte.)

Je vous laisse relire mon billet précédent où j'avais présenté ce circuit, son brochage et ses équivalents ... mais ici, nous avons besoin de 2 PIOs et donc d'utiliser la version TSOC.
Précisons tout de suite, il est minuscule, les contacts sont eux-mêmes riquiquis, la soudure promet d'être sportive ... et elle l'a été !

Pas de surprise au niveau de ce qui est exposé dans owfs : nous avons déjà utilisé ce type de circuit.

laurent@bPI ~ $ cd /var/lib/owfs/mnt/
laurent@bPI /var/lib/owfs/mnt $ cd 12.16CCCC000000
laurent@bPI /var/lib/owfs/mnt/12.16CCCC000000 $ ls
PIO.A     T8A      channels    flipflop.ALL   latch.A     locator  present    sensed.A     set_alarm
PIO.ALL   TAI8570  crc8        flipflop.B     latch.ALL   memory   r_address  sensed.ALL   type
PIO.B     address  family      flipflop.BYTE  latch.B     pages    r_id       sensed.B
PIO.BYTE  alias    flipflop.A  id             latch.BYTE  power    r_locator  sensed.BYTE

Pour chacun des paramètres, nous avons

• *.A & *.B : les valeurs des ports A et B individuellement
• *.BYTE : les valeurs sous forme d'un octet unique, bit 0 pour le port A, bit 1 pour le port B
• *.ALL : les valeurs sous forme de chaîne avec les valeurs séparées par une virgule dans le format A,B

PIO.* contrôle un PIO en mode sortie, collecteur ouvert (open drain) :

0. le port est laissé flottant. Si on veut l'utiliser comme une sortie, il faut ajouter une résistance de pull-up vers le +5 volt. Sans cette résistance, le PIO peut être utilisé en entrée.
1. le port est relié à la masse. En sortie uniquement donc.

Plus d'information sur l'utilisation d'un PIO en sortie sur ma page consacrée notre test avec le ventilo.

Indique le niveau logique présent sur le port, ce qui n'est évidemment utile que si le PIO correspondant est à 0 :

0. niveau bas, 0 volt donc
1. niveau haut, pour toute tension à ses bornes supérieure à environ 2,4 volts (et inférieur à Vdd donc 5 volt dans mon cas, sinon pchitttt le composant)

Indique s'il y a eu au moins un changement d'état du PIO correspondant, passage de l'état bas à l'état haut comme passage de l'état haut à l'état bas. Ce champ est très intéressant pour surveiller un changement d'état ponctuel/rapide/transitoire : par exemple, "est-ce que la trappe du chat a été ouverte durant les 5 dernières minutes ?".

0. Il n'y a pas eu de changement
1. Il y a eu un changement : voir sensed pour connaître la valeur actuelle (qui éventuellement n'est déjà plus celle qui a créé le changement d'état).

Cette valeur est remise à 0 pour les 2 PIOs en écrivant n'importe quelle valeur dans ce champ.

Je n'ai rien trouvé dans la doc à son propos ... je subodore qu'il s'agit d'un alias pour PIO, il faudra que je fasse des tests.

Bon, autant prévenir tout de suite les âmes sensibles, j'ai fait dans le gras, le sale, la grosse grosse bidouille.

Pour le verrou du haut, j'avais de la place, j'ai donc utilisé un vieux poussoir "bouton reset" sur un PC HS. Sa course est suffisante pour que je puisse le placer dans le prolongement du pêne.

Pour la serrure, ce n'était plus possible par manque de place et pour éviter de trop charcuter la boiserie. J'ai donc utilisé un petit poussoir d'un panneau de contrôle d'un écran lui aussi HS. Le problème est que sa course est vraiment ridicule (moins d'un demi-millimetre) : lorsque le pêne est fermé, une feuille de plastique semi-rigide appui ... sur un bout de fil lui rigide qui pousse alors sur le bouton. C'est franchement de la bidouille hardcore, ça demande un réglage pointilleux et l'un dans l'autre, ça ne fonctionne que lorsque la serrure est fermée à double tour (sinon, sa course n'est pas suffisante). Sans changer le mécanisme, je n'ai pas trouvé mieux et ça fonctionne ... pour le moment.

De plus, ce montage est très exposé aux passages et n'a résisté que quelques heures à mes enfants lors de mes premiers tests : c'est pourquoi je l'ai protégé par des tôles métalliques.

Ici, j'ai fait dans le simple et classique avec un capteur tout fait, composé d'un ILS "Normalement Ouvert" sur la partie "dormante" de la porte et d'un aimant sur la partie "ouvrante" ... capteur qui ne m'a coûté que quelques dizaines de centimes (ou 20 fois plus si vous aimez la vaseline des détaillants du coin).
J'ai testé : l'ILS est suffisamment sensible pour permettre un "jeu" d'1,5 cm ... ce qui n'est pas un lux vu que la dite porte est un peu voilée.

Côté câblage, c'est simplissime :

• une résistance de pull-up d'environ 100kΩ vers le 5 volts : dans mon cas, c'est du 220kΩ car j'en avais sous la main . Comme d'habitude, il faut prendre une valeur assez haute pour ne pas trop consommer, mais suffisamment basse pour éviter les problèmes de parasites qui rendrait l'entrée instable.
• l'interrupteur relié à la masse.

Nous fonctionnerons donc en mode logique inversée : 1 le contact est ouvert, 0 le contact est fermé.

Ne pas le faire dans l'autre sens, à savoir l'inter entre le +5 et le PIO : si vous vous souvenez de mon billet précédent, le PIO en mode sortie force la sortie à la masse à la demande. Donc si pour une raison ou pour une autre, vous configurez même temporairement le mode sortie ... ça risque de se finir pas un joli cours-cuircuit.

Comme nous l'avions vu, les sorties sont gérées par les PIO.* : il faut mettre à 0 pour basculer les 2 PIOs en entrée.

laurent@bPI /var/lib/owfs/mnt/12.16CCCC000000 $ echo 0 > PIO.BYTE
laurent@bPI /var/lib/owfs/mnt/12.16CCCC000000 $ head PIO.ALL
0,0

Lorsque les verrous sont ouverts, les PIOs correspondants sont 1 ... nous sommes en logique inversée, ne l'oublions pas.

laurent@bPI /var/lib/owfs/mnt/12.16CCCC000000 $ head sensed.ALL
1,1

Fermons le verrou du haut, le PIO A passe à 0.

laurent@bPI /var/lib/owfs/mnt/12.16CCCC000000 $ head sensed.ALL
0,1

La partie hardware semble résister aux passages et remplit son rôle. Les tests avec owfs et le DS2406 sont eux aussi concluants (même si c'est le binse pour le souder, celui-là).
Je valide donc la solution.

Et bien donc, ça n'a pas été long, j'ai un peu joué avec les alarmes 1-wire et je les ai implémentées dans Marcel : voici donc le résultat.

Le bus 1-wire fonctionne en mode maître/esclave sans qu'une sonde ne puisse générer d'interruption. Pour palier à ce manque, le bus implémente la notion d'alertes : le maître envoie un ordre particulier et seules les sondes en état d'alerte lui répondent, un peu comme lors de la phase de découverte.

Dans owfs, la source des alarmes se configure par le champ set_alarm du pseudo-repertoire des sondes ; son argument est un entier de 3 digits XYZ dont les valeurs sont

• X - quelles sources
0. aucune
1. port A
2. port B
3. A ou B
• Y - pour quoi ?
0. aucun
1. latch
2. PIO
3. sensed
• Z - niveau
0. Bas
1. Haut

Ainsi, 321 indique que nous surveillons les 2 ports (le 3), pour le changement d'une sortie PIO (2), qui passe à l'étant haut (1).

Dans la racine du point de montage, on trouvera un répertoire nommé alarm dont les sous répertoires sont les sondes en alarme.
Petit test avec le DS2406P de notre porte, commençons par un :

laurent@torchwood ~ $ echo 331 > /var/lib/owfs/mnt/12.16CCCC000000/set_alarm

On demande d'être notifié lorsque l'un des ports (both : 3), à son entrée (sensed : 3) au niveau haut ( 1 ). La serrure étant fermée, j'obtiens

laurent@torchwood ~ $ ls /var/lib/owfs/mnt/alarm/
12.16CCCC000000

Et si je regarde si le PIO A est bien à 1 :

laurent@torchwood ~ $ cat /var/lib/owfs/mnt/alarm/12.16CCCC000000/sensed.ALL
1,0

Si on ouvre la serrure, l'entrée dans alarm va disparaître et le sensed.all redevient 0,0.

Marcel gère les alarmes 1-wire depuis la version 5.01. Dans sa configuration ça se traduit par

• Déclaration du répertoire dans lequel se trouveront les alarmes (la valeur ci-dessous correspond à la config par défaut d'owfs).

1wire-Alarm=/var/lib/owfs/mnt/alarm

• le délai entre 2 scan du bus, en secondes

1wire-Alarm-sample=300

Se trouve ensuite la définition des différentes sondes.

*FFV=Porte cave
File=/var/lib/owfs/mnt/12.16CCCC000000/sensed.BYTE
Topic=maison/IO/Porte_Cave/Brute
Sample=-1
Latch=/var/lib/owfs/mnt/12.16CCCC000000/latch.BYTE

A noter le Sample=-1 : il indique que la sonde doit être interrogée uniquement au lancement de Marcel (on obtient la valeur initiale).

J'appelle ensuite une fonction

*DPD=Porte Cave
Topic=maison/IO/Porte_Cave/Brute
Func=SituationPorteCave

dont le but est de convertir les codes numériques en statut de la porte.

function SituationPorteCave( topic, val )
    local res = 'Verrouillee'
    val = tonumber( val )

    if val==3 then
        res = 'Ouverte'
    elseif val==1 then
        res = 'Fermee'
    end

    Marcel.MQTTPublish( topic:sub(1, -6), res, true )
    Marcel.SendNamedMessage('i', "Porte de la cave", res)
end

A noter qu'il n'y a pas de code '2' qui correspondrait à "porte verrouillée mais pas fermée" ce qui n'est bien sûr pas possible.

Ce que je souhaite, c'est être notifié uniquement lorsque la valeur change, il faut donc configurer la sonde pour qu'elle émette des alarme par rapport au latch, ce qui qui se fait par un

laurent@torchwood ~ $ echo 311 >  /var/lib/owfs/mnt/12.16CCCC000000/set_alarm

Dans Marcel, on aura remarqué que j'avais utilisé la directive latch : à chaque fois que la valeur sera lue, le latch sera remis à zéro et donc l'alerte levée.

Avec la configuration donnée ici, Marcel va regarder toutes les 5 minutes le contenu du répertoire alarm.
S'il y trouve une sonde, qui a été déclarée en FFV et qu'en plus son Sample est à -1, il va lire le fichier correspondant, publiée la valeur lue (attention, une valeur comme on le trouve dans sensed.BYTE, pas une chaîne comme dans sensed.ALL) et libérer l'alarme en écrivant dans son latch.

Ma cave traversant toute la longueur de la maison, soit une bonne 20^e de mètres et ma sonde actuelle étant à une de ses extrémité alors que la porte est à l'autre, j'ai décidé de remplacer le montage ci-dessous par un DS28EA00 pour obtenir en plus l'information température.

Le DS28EA00 est une puce bien sympathique (que je détaillerai sur ma page consacrée au détecteur de pluie) qui allie sonde de température à 2 PIOs ... le fils des DS18B20 et DS2406P en quelque sorte.

A l'exception des numéros des broches, le schéma reste strictement identique ... mais est encore (beaucoup) plus chiant à souder ... même avec un adaptateur uSOP vers DIL : 0,65mm, c'est vraiment petit et c'est bien la première fois que je suis obligé de souder quelque chose avec une loupe !

Côté soft, on se retrouve en terrain connu ... sauf que la gestion des PIOs est vraiment réduites par rapport du DS2406 : pas d'alarme (il reste cependant possible d'avoir des alertes sur la température), pas de gestion de latch.

laurent@torchwood /var/lib/owfs/mnt/uncached/42.886847000000 $ ls
address  fasttemp   latch.B     PIO.ALL   r_address  sensed.ALL   temperature10  type
alias    id         latch.BYTE  PIO.B     r_id       sensed.B     temperature11
crc8     latch.A    locator     PIO.BYTE  r_locator  sensed.BYTE  temperature12
family   latch.ALL  PIO.A       power     sensed.A   temperature  temperature9

Le champs latch exposé pour un DS28EA00 n'est en fait que l'inverse de la valeur sensed et ne permet donc pas de détecter un changement transitoire.

Exit donc les alarmes, la configuration de Marcel devient donc :

*FFV=Temperature Porte Cave
File=/var/lib/owfs/mnt/42.9E5247000000/temperature
Topic=maison/Temperature/CaveP
Offset=-0.1069182813
Sample=300

*FFV=Porte cave
File=/var/lib/owfs/mnt/42.9E5247000000/sensed.BYTE
Topic=maison/IO/Porte_Cave/Brute
Sample=30
#Latch=/var/lib/owfs/mnt/12.16CCCC000000/latch.BYTE

On conserve l'appel à la fonction lua

*DPD=Porte Cave
Topic=maison/IO/Porte_Cave/Brute
Func=SituationPorteCave

mais la fonction elle-même devient

-- SituationPorteCave.lua
--
-- Translate gate's code to human readable condition
-- Notify as well

function SituationPorteCave( topic, val )
    local res = 'Verrouillee'
    val = tonumber( val )

    if val==3 then
        res = 'Ouverte'
    elseif val==1 then
        res = 'Fermee'
    end

    if ans_PorteCave ~= res then
        ans_PorteCave = res

        Marcel.MQTTPublish( topic:sub(1, -6), res, true )
        Marcel.SendNamedMessage('i', "Porte de la cave", res)
    end
end