Dès que l’on parle de Domotique, le protocole 1-Wire rentre rapidement dans le jeu : il s’agit d’un bus série, nécessitant au minimum 1 fil (d’où son nom) + la masse sans contraintes techniques fortes (du fil téléphonique suffit, voir même du fil volant si les distances sont courtes).   Les sondes quant à  elles, relativement réduites en nombre, se trouvent facilement et a des prix très abordables. Enfin, pour peu qu’on utilise du câble de qualité (enfin, quoi que), des distances peuvent même dépasser la centaine de mètres (une note intéressante sur le sujet).
Bref, une solution à la fois pratique et économique pour câbler sa maison. Reste à le connecter à un Banana ...

Il existe plusieurs possibilités pour connecter un bus 1-Wire à notre SBC :

• Par un adaptateur USB ou série : c’est la solution la plus simple pour connecter un PC.
• Une connexion directe sur le bus du Banana :
  • L’avantage évident est le coût : rien à ajouter si ce n’est une résistance de pull-up.
  • Sauf que le driver du bus 1-wire est entièrement logiciel et avec les kernel 3.4 actuels, il y a des problèmes de timing lorsque l’horloge CPU est trop basse (mode gouvernor pour économiser de l’énergie). Bug avec usleep() qui ne serait plus fiable à faible vitesse.
  • Mais le gros problème que j’y vois est que l’électronique (fragile) du CPU est directement exposée à l’environnement extérieur : risque de surtensions en cas d’orage ou d’électricité statique / parasitaire. A la longue, c’est une cause de vieillissement accéléré du processeur.
  • Enfin, le CPU délivre du 3.3v alors que je souhaitais utiliser un bus 5v pour améliorer l’insensibilité aux bruits parasites. On trouvera à foison sur le web ce genre de montage pour le Raspberry : ils s’appliquent évidement au BananaPI. Avantage, driver logiciel oblige, n’importe quel GPIO peut être utilisé.

• Il existe des circuits tels que le DS2482 qui font le pont entre un I2C et l’1-wire : en plus de décharger le CPU pour la prise en charge du protocole, il offre aussi une (petite) protection pour le CPU face aux perturbations provenant du réseau. C’est la solution que j’ai choisie …

Le bus 1-wire fonctionne en mode maitre-esclaves. Le maître contrôle le bus, envoie des commandes et interroge les sondes. Il ne peut y avoir qu’un seul maître sur un réseau et les sondes ne peuvent d’elles-mêmes envoyer des données sur le bus : pas d’interruptions comme en I2C.

Au repos, le bus présente un niveau électrique haut, ce qui permet d’alimenter les sondes par l’entrée data : c’est le mode « parasite » et seulement 2 fils sont nécessaires, data et masse. L’inconvénient est alors qu’il faut un certain temps pour qu’une sonde se « recharge » entre 2 interrogations. Mais il est aussi possible d’alimenter par un fil dédié les sondes (enfin, celles qui le peuvent, certaines ne fonctionnent qu'en parasite).

Côté topologie, on peut faire quasiment ce que l’on veut à partir du moment où il n’y a pas de boucle : la doc indique que les meilleurs performances s’obtiennent avec un bus linéaire classique (toutes les sondes alignées sur un seul et unique fil), mais rien n’empêche d’y ajouter des branches voir même d’installer un réseau en étoile.

Le bus fonctionne indifféremment en 3.3 ou en 5 volts. Ce 5 volts sera à privilégier pour un réseau long et/ou parasité.

Ma commande :

en haut, les sondes de températures DS18b20
au milieu, le DS2482S-100+ sur son adaptateur
en bas, le convertisseur de niveau 3,3 -> 5v

Le premier étage est un « adaptateur de niveau », montage classique à base de FET qui permet de passer du 3.3v du BananaPI à 5v, et le tout, de manière bidirectionnelle.
Ici, le model que j’ai commandé comporte 4 canaux alors que 2 était nécessaires : pas plus cher et les 2 restants seront peut-être utilisés … un jour. On notera que dans ce cas, il n’y a pas besoin de résistance de pullup sur le bus I2C.

Suit le DS2482 : il n’est disponible qu’en version SIOC, j’ai donc acheté aussi un adaptateur vers du DIL, plus simple à souder sur un véroboard classique. A noter qu’il peut aussi fonctionner aussi en 3.3v si on souhaite s’affranchir de l’étage précédent.

Voilà ce que ça donne :
les composants discrets que l'on voit sur le haut sont pour le convertisseur RS-232
et en haut à gauche, les 2 lignes Téléinformation.

Avant même de brancher le moindre bus 1-wire, on peut déjà vérifier qu’il apparait sur le bus I2C.

bPI ~ # i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --            

i2cdetect, qui fait parti de l'ebuild i2ctools, détecte bien le DS2482 à l'adresse 18 (adresse qui peut être 19, 1A ou 1B en fonction des niveaux que nous appliquons sur les broches A0-A1).

Enfin, j’ai ajouté un bornier pour faciliter les branchements.

Comme nous passons par l'I2C, il n'est pas possible d'utiliser le driver 1-wire du kernel : la solution passe par le package OWFS.

A l'heure où j'écris ces lignes, owfs est encore marqué comme "instable" : il faut donc modifier le fichier /etc/portage/package.keyword (la version est bien évidemment à adapter)

=sys-fs/owfs-2.7_p21-r3 ~arm

La fonctionnalité la plus pratique est d'exposer les sondes à travers un pseudo filesystem (il en tire son nom d'ailleurs). Sauf que le USE "fuse" qui l'active est masquée sous ARM. On l'autorise grâce au fichier /etc/portage/profile/use.mask

-fuse

Voici les USEs que j'utilise, fichier /etc/portage/package.use bien entendu

sys-fs/owfs fuse server zeroconf

owserver est le démon qui scrute le bus 1-wire, découvre et interagit avec les périphériques connectés. Il faut lui indiquer que nous passons par l'i2c et bus utilisé. Ça se fait par l'option --i2c=/dev/i2c-2 : l'i2c présent sur CON3 est le numéro 2.
Dans la pratique, owserver sera lancé au boot du système et la configuration passe par le fichier /etc/conf.d/owserver

# owfs owserver configuration
OWSERVER_OPTS="--zero -p 4304 --i2c=/dev/i2c-2 --error_print 0 --timeout_volatile 5"

Testons s'il découvre quelque chose :

bPI ~ # owdir
/28.FF5EEF001502
/28.FF4B30021503
/28.FF7BF0001502
/bus.0
/settings
/system
/statistics
/structure
/simultaneous
/alarm

Les 28.* représentent les DS18b20 et on obtient la température lue par

bPI ~ # owread /28.FF5EEF001502/temperature
      14.125

owfs est le client qui expose les données fournies par owserver dans un pseudo filesystem. Ici aussi, la configuration se fait en passant des paramètres. Pour le service, ils sont placés dans le fichier /etc/conf.d/owfs

• -m /var/lib/owfs/mnt : le point de montage du filesystem
• --allow_other : tous les utilisateurs peuvent y accéder (attention, il faut aussi que FUSE soit autorisé à le faire : ajouter user_allow_other dans le fichier /etc/fuse.conf)
• -s 127.0.0.1:4304 : adresse pour contacter owserver. Et oui, ça fonctionne même à distance : le must pour developper depuis une autre machine !

Ce qui donne

bPI ~ # ls -l /var/lib/owfs/mnt/
total 0
drwxrwxrwx 1 root root  8 23 mai   23:30 28.FF4B30021503
drwxrwxrwx 1 root root  8 23 mai   23:30 28.FF5EEF001502
drwxrwxrwx 1 root root  8 23 mai   23:30 28.FF7BF0001502
drwxr-xr-x 1 root root  8 19 mai   10:42 bus.0
drwxr-xr-x 1 root root  8 19 mai   10:42 settings
drwxr-xr-x 1 root root  8 19 mai   10:42 statistics
drwxr-xr-x 1 root root 30 19 mai   10:42 structure
drwxr-xr-x 1 root root  8 19 mai   10:42 system
drwxr-xr-x 1 root root  8 19 mai   10:42 uncached
bPI ~ # cat /var/lib/owfs/mnt/28.FF4B30021503/temperature
      17.625

Les informations sont à la fois exposées sur Domestik pour archivage, tendances, etc ... et sur mon broker MQTT pour une utilisation en temps réel.

Après presque 1 an d'utilisation, je ne peux que me féliciter de cette solution qui n'était à l'origine qu'un POC : mon réseau parcourt maintenant ma maison sur environ 70m, avec une quinzaine de sondes et ce, sur plusieurs branches.

J'ai plein de nouvelles idées de montages à ajouter à mon réseau ... et je vais peut-être atteindre les limites de ma topologie actuelle. Si c'est le cas, je passerai sans doute au DS2482-800 pour découper physiquement mon réseau et éviter les problèmes de réverbération.

J'ai d'autres projets avec des bus totalement séparés : j'utiliserai alors un DS2484 qui me permettra de m'affranchir du convertisseur de niveau externe.

Le DS2484 est grosso modo un DS2482-100 avec un convertisseur de niveau intégré (je simplifie, si on fait du bas niveau, il a aussi d'autres possibilités), mais on perd le signal PCT ... inutilisé dans mon cas et la possibilité de choisir son adresse sur le bus I2C.

Une bien belle image honteusement piquée sur le site http://stammersdorfer.at

Comme on peut le voir : il est ridiculement petit dans son boitier SOT23 (toujours super pratique à souder) et n'a que 6 pattes.

1. SLPZ : Alimentation de la partie I2C à connecter au 3,3 Volts ... vu que c'est la tension du GPIO de notre Banane. Non alimenté ou mis à la masse, le circuit est désactivé (sleep mode)
2. SDA : données I2C - à connecter au SDA du bPI
3. SCL : horloge I2C - à connecter au SCL du bPI
4. GND : masse, qui est commune entre la partie I2C et le bus 1-wire
5. IO : Notre bus 1-wire. A noter, l'absence de la résistance protégeant des effets de la ligne nécessaire aux autres circuits (elle n'est pas présente dans le datasheet du DS2484 ... donc je ne l'ai pas mis). Le dit datasheet indique aussi que le circuit protège aussi contre les charges électro-statiques.
6. VCC : la tension du bus 1-wire ... 5 volts.

Comme on peut le voir, la connexion au BananaPI est réduite à sa plus simple expression. Normalement, il faudrait rajouter des résistances de pull-up sur le bus I2C ... sauf qu'il semblerait que le BananaPI les actives par défaut en mode I2C (car je ne l'ai pas spécifié dans son Fex) ...

On vérifie qu'il est bien connecté

Torchwood ~ # i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --            

et son utilisation est totalement transparente dans owfs (comme d'hab quoi !).

torchwood # ls /var/lib/owfs/mnt.1/
12.16CCCC000000  bus.0     statistics  system
alarm            settings  structure   uncached

Printemps 2017

Refonte complète de l'électronique que j'ai ajouté pour ma domotique : pour le 1-Wire, je découpe mon réseau pour éviter d'avoir trop de branches (ce qui va en l'encontre des préconisations de Maxim). Le DS2482S-100+ est remplacé par un DS2482-800.

DS2482, c'est un convertisseur I2C / 1-wire, mais -800 indique qu'il fournit donc 8 bus électriquement indépendants. Plus de bus implique aussi plus de pattes : nous avons 16 dans ce boitier SOIC. Inutile de dire que ça être encore plus sportif que son petit frère -100 (heureusement, j'ai fait les frais pour une pince loupe ...) !

Les pins d'adresses passent maintenant à 3 : la puce répond aux adresses 0x18 à 0x1f, les 4 premières offrent donc une compatibilité avec le reste de la famille. Par contre, contrairement au DS2482-100, nous perdons la possibilité d'imposer une alimentation forte sur le bus par la pin PCT ... inutile avec un bus alimenté comme le miens.

Si les bus sont distincts, les données passent par un chemin unique : la puce fonctionne comme un switch entre un unique convertisseur I2C/1-wire et les différents bus. Une demande broadcast (recherche, lancement de mesures simultanées ...) n'est passée qu'au bus actif.

Le DS2482-800,
un adaptateur SOIC /DIL
et un convertisseur de niveau 3,3v/5v.

J'ai connecté AD0, 1 et 2 à la masse : la puce devrait apparaitre sur le bus à l'adresse de base (0x18 si vous avez bien suivi).

torchwood laurent # i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

Bingo !

Même adresse que le DS2482-100 donc même pas besoin de changer le fichier de conf d'owserver.

J'ai mis 2 sondes DS2406 que j'ai connecté sur le bus #5 (IO5) et une dernière seule sur le bus #7. Voyons le résultat :

/12.AC0BD0000000
/12.BC0ED0000000
/12.C212D0000000
/bus.7
/bus.6
/bus.5
/bus.4
/bus.3
/bus.2
/bus.1
/bus.0
/uncached
/settings
/system
/statistics
/structure
/alarm

Et oui, pas besoin de se prendre le choux avec les bascules de bus, à savoir sur lequel est installé une sonde ... tout est transparent dans owserver ! Donc côté logiciel, avoir 1 bus ou 8, c'est pareil !

Le DS2482-800 souffre d'un bogue qui fait qu'il se bloque et du coup, plus aucune sonde n'est visible : cela arrive de façons parfaitement aléatoires (ça tient plusieurs mois et d'un coup, paf, plusieurs plantages dans la même semaine), et seul lui couper l'alimentation le remet en état de marche.
Le montage ci-dessous permet de le contrôler pas un GPIO du PI.

Le GPIO étant en 3.3 volts alors que bus est lui alimenté en 5v, ce montage à 2 transistors est nécessaire :

• le NPN sépare les 2 tensions
• le PNP transmet la "puissance"

Une fois de plus, pas de chichi : ils proviennent de mon écran HS canibalisé et peuvent être remplacés par n'importe quelles références courantes.

Evidemment, n'importe quel GPIO ferait l'affaire. Cependant, optimisons

• l'I2C étant exposé sur le CON3, autant utiliser un GPIO qui l'est aussi
• pour ne pas se fermer la porte à de nouvelles extensions, autant en prendre un qui n'a pas d'autre fonction.

Du coup, il n'en reste qu'un le GPIO18 connecté à la broche 12, libellé GPIO0 sur BananaPI (ou GPIO1 sur les éclateurs pour Raspberry).

Exposons le GPIO

# cd /sys/class/gpio/
# echo 18 > exportcd gpio18/
# ls -l
total 0
-rw-r--r-- 1 root root 4096 Jul 3 13:01 active_low
lrwxrwxrwx 1 root root 0 Jul 3 13:01 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Jul 3 13:01 direction
-rw-r--r-- 1 root root 4096 Jul 3 13:01 edge
drwxr-xr-x 2 root root 0 Jul 3 13:01 power
-rw-r--r-- 1 root root 4096 Jul 3 13:01 pull
lrwxrwxrwx 1 root root 0 Jul 3 13:01 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jul 3 13:00 uevent
-rw-r--r-- 1 root root 4096 Jul 3 13:01 value

Par défaut, le GPIO est configuré en entrée pour des raisons de sécurité. Il est possible par une seule commande de le faire basculer en sortie au niveau souhaité

# echo "high" > direction

Le DS2482 est alimenté. Par la suite, il est possible de l'activer ou non en écrivant respectivement 1 ou 0 dans le fichier value.

Si on fait abstraction des prix (que je n'ai pas vérifié), les seuls avantages du DS2482-100 sont

• le signal PCT pour forcer une alimentation forte sur le bus si on a beaucoup de sondes en mode parasite
• le fait qu'on puisse sélectionner son adresse I2C

Le DS2482-800 est quant à lui indispensable pour un (trop) long bus que l'on souhaite tronçonner.

Le DS2484 est celui qui permet la plus grande intégration avec le moins de composants externes (convertisseur de niveau interne, pas de résistance de protection) et est surtout idéale dans un environnement agressif ou pour du prototypage grâce à sa protection ESD. Mais n'offrant pas la possibilité de choisir son adresse, il n'y en aura qu'un par bus I2C.

Dans tous les cas, le support par OWFS est parfait et surtout totalement transparent. Et même si je me répète, l'utilisation de ces convertisseurs protèges les GPIO de notre PI, soulage le CPU et améliore le multi-tâche (certains timings nécessitent des opérations atomiques en bit banging).