Où sommes nous ?

Retour

Connexion à un bus 1-wire

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 ...

Connection au Banana (ou n'importe quel SBC)

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

Un peu de théories

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é.

C’est le moment de sortir le fer à souder

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.

La famillie DS248x

La famille DS248x se composent (entre autre) :

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.

Comme on peut le voir, pour plus de sécurité, j'ai ajouté un fusible 1A sur l'alimentation du bus en 5 volts. Efforts parfaitement inutiles avec les BananaPI et BananaPro, car le 5v passe avant par la PMU. En cas de cours-circuit ou simplement d'une surcharge, il se mettra en sécurité.

La résistance de 100Ω est préconisée par Maxim protège le convertisseur des "effets dû à la ligne" (réverbération, parasites, courants induits, mais aussi charge des sondes alimentées en mode parasite).

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).

Ne faites pas la même bêtise que moi : NE LANCEZ PAS i2cdetect DEPUIS LA CONSOLE, mais depuis un terminal secondaire (par exemple par ssh) car sinon, vous n'allez que voir des

incomplete xfer (0x20)

et penser que quelque chose est HS. En fait, ce message indique simplement qu'il n'y a personne à l'adresse demandée.

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

Côté logiciel

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.

Installation sous Gentoo

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

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

Impossible de lancer le service ?

Même sans sondes, owdir devrait afficher au moins bus.0 ... si ce n'est pas le cas, vérifier si le démon owserver tourne. Vérifiez alors les droits sur /dev/i2c-2 : s'il n'est pas lisible par l'utilisateur ou le group owfs, il faut créer une règle pour udev.

Ca se passe par la création de /lib/udev/rules.d/60-i2c.rules avec le contenu suivant (pour Gentoo bien sûr) :

KERNEL=="i2c-*", GROUP="owfs", MODE="0660"

Rebootez et le service devrait démarrer sans problème.

# ls -l /dev/i2c*
crw-rw---- 1 root owfs 89, 0 May 31 16:09 /dev/i2c-0
crw-rw---- 1 root owfs 89, 1 May 31 16:09 /dev/i2c-1
crw-rw---- 1 root owfs 89, 2 May 31 16:09 /dev/i2c-2
crw-rw---- 1 root owfs 89, 3 May 31 16:09 /dev/i2c-3
crw-rw---- 1 root owfs 89, 4 May 31 16:09 /dev/i2c-4

owfs

Plus d'info

PIO en entrée

PIO en sortie

Alarme sur les PIOs

Température

Alarme sur les Températures

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

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

Résultat

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.

Conclusion

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.

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.

DS482, 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 part 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.

Testons ...

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 !


Visitez :
La liste de nos voyages
Nos sorties Ski et rando
Copyright Laurent Faillie 2001-2017
N'oubliez pas d'entrer le mot de passe pour voir aussi les photos perso.
Contactez moi si vous souhaitez réutiliser ces photos et pour les obtenir avec une plus grande résolution.
Visites durant les 7 derniers jours Nombre de visites au total.

Vous pouvez laissez un commentaire sur cette page.