Communication par câble entre modules Arduino éloignés

Bonjour à tous,

J'ai un projet de domotique :

  • 100% DIY
  • à faible consommation
  • filaire (zéro radio)
  • local (indépendant d'Internet)
    j'ai mes raisons :wink:

Ce que je souhaite piloter est assez particulier :

  • VMC avec registres motorisés pour aspirer les fumées de différents poste de travail
  • mon système de hifi avec des enceintes dans chaque pièce et un ampli central (commutation d'enceintes + pilotage de l'ampli)
  • mon gestionnaire/répeteur de sonnette et sonnerie de téléphone.
  • mon chauffage aussi (mode boost, mode normal, mode éco)
    Les systèmes domotiques du commerce ne conviennent pas

Dans chaque pièce il y aura un petit boitier de commande avec un afficheur et quelques boutons poussoirs.

Il y aura une unité centrale qui gérera les petits boitiers de commande et aussi les appareils que je veux commander dans ma maison.

Après pas mal de recherches, je pense que les arduino sont très adaptés à ce que je veux faire.

Pour les petits boitiers de commande, je pense utiliser un arduino avec le shield "lcd keypad".
C'est génial car des gens ont même déjà pensé à faire des boîtiers adaptés en impression 3D :slight_smile:

Pour l'unité centrale, un arduino "nu" avec une carte électronique maison qui pilotera des relais.

Il peut y avoir jusque 20 mètres de câbles entre les petits boitiers de commande et l'unité centrale...
Les petits boitiers de commande n'ont pas besoin de communiquer entre eux, le câblage peut être fait "en étoile" en reliant chaque boitier de commande à l'unité centrale.

=> Comment gérer la communication entre les arduinos ?

Je pense au RS485, mais il y a peut être mieux.

J'aimerais si possible utiliser du câble téléphonique, ou sinon du câble audio blindé (une masse + 4 fils). Après je peux acheter un câble spécifique.

Le câble devra également véhiculer l'alimentation des arduinos (5V). Je ne veux pas de ces satanés blocs secteurs dont la fiabilité est douteuse, je construirais une vraie alimentation avec toutes les protections nécessaires. Je peux éventuellement prévoir une alim avec une tension supérieure puis dans chaque petit boitier de commande ajouter un régulateur 5V

Le shield "lcd keypad" laisse-t-il assez d'entrées/sorties de libre pour :

  • la communication (RS485 ou autre)
  • un éventuel récepteur infrarouge (ça serait cool d'avoir en plus une télécommande IR)
  • d'éventuels boutons poussoirs supplémentaires ?

Le travail des petits boitiers de commande sera limité :

  • gestion du shield LCD keypad
  • envoi des ordres à l'unité centrale
  • réception d'ordres de l'unité centrale pour mise à jour de l'affichage
  • éventuelle réception d'ordres infrarouge

L'unité centrale aura le travail suivant :

  • réception des ordres venant des boîtiers de commande
  • envoi au boîtiers de commande de ce qu'il faut afficher
  • réception des capteurs sonnette et sonnerie de téléphone
  • pilotage des relais bistables pour commander la VMC, les registres motorisés, la commutation des haut parleurs, les répéteurs de sonnerie, le chauffage...
  • pilotage de l'ampli tuner HIFI "maitre" via des ordres infrarouges (simulation de télécommande)
  • commutation de l'antenne FM en fonction de la station de radio écouté (car je ne reçoit pas les stations de radios depuis le même émetteur...)
  • allumage, extinction et pilotage d'un raspberry pi qui sera configuré en lecteur MP3

De cette façon dans chaque pièce de la maison je peux lire mon catalogue de MP3, écouter la radio, changer le volume...

En option il y aura peut être un module internet ou gsm qui permettra de piloter à distance une ou deux fonctions (je pense à remettre le chauffage en mode "boost" deux ou trois heures avant de rentrer chez moi après une absence). Le module internet sera raccordé à l'unité centrale comme s'il était un bouton poussoir, de cette façon les possibilités de piratage seront extrêmement limitées. De plus, de bons vieux thermostats mécaniques auront le dernier mot pour éviter une surchauffe ou le gel.

Voilà tout est dit !

Qu'en pensez vous ?

Pour moi le point épineux est la communication filaire entre les modules.

A bientôt !

La RS232 imposerait une unité centrale avec pas mal de ports.
La RS485 semble tout à fait indiqué.

Gros boulot quand même ...

Y a-t-il un intérêt à utiliser une norme dans la mesure ou le volume de données est faible, et que l'on peut baisser la vitesse? Du coup cela permettrait de rester en 0/5V. Deux ports par arduino permettent d'échanger des données, mais pas à la vitesse de la RS485. Si la vitesse est faible, on n'a plus besoin d'avoir en fin de ligne une charge devant être égale à l’impédance caractéristique d la ligne. Du coup n'importe quel câble pourrait servir.

J'ai utilisé le bus 1Wire, peu utilisable dans ce cas, mais tout était en 5V, et j'allais d'un bout de la maison à l'autre. Je ne sais plus quelle était la vitesse. Pas de circuits supplémentaires, c'est pas mal.

Après, on peut utiliser le protocole sans utiliser les niveaux de tension.

olivier_pecheux:
Y a-t-il un intérêt à utiliser une norme dans la mesure ou le volume de données est faible, et que l'on peut baisser la vitesse? Du coup cela permettrait de rester en 0/5V. Deux ports par arduino permettent d'échanger des données, mais pas à la vitesse de la RS485. Si la vitesse est faible, on n'a plus besoin d'avoir en fin de ligne une charge devant être

Je pense que tu fais une confusion.
La RS232 est une norme qui défini les support physique ET le protocole de communication. Ce qui s'est révélé être une grosse erreur.
Le protocole de communication ayant été repris avec d'autre support physique et le terme RS232 continuant à être employé nous avons vu sur ce forum des cas où un vrai signal RS232 (10V à -20V/ +10V à +20V) à été appliqué sur une entrée de micro 5V ce qui a tout cramé.

Dans l'évolution des moyens de transmission pareille erreur n'a pas été reprise et il existe d'une part la norme support physique et d'autre part la norme protocole de communication.

La RS485 ne définie que le moyen physique, les fréquences du transmission et le codage sont définis ailleurs.
Sur RS485 on peut utiliser différent protocole de transmission : une simple liaison série où Mdbus, ou ...........
La RS485 a un énorme avantage : c'est une liaison différentielle adaptée sur l'impédance caractéristique du câble. C'est ce qui fait sa force dans les grandes distances.

Liaison adaptée :
On montre (pour moi c'était au programme de la terminale) que la puissance transmise est maximale quand l'impédance de la charge est égale à celle du générateur.

Liaison différentielle :
L'émetteur émet deux signaux en opposition de phase (quand l'un vaut 1 l'autre vaut 0)
La charge peut être considérée comme les entrées + et - d'un ampli opérationnel.
Cas du signal utile :
Comme l'entrée fait la différence de 2 signaux en opposition de phase et que moins par moins ça fait plus on récupère le double de signal
Cas du bruit :
Le bruit frappe de la même façon le fil+ et le fil -. Comme il y a une différence en entrée le bruit est éliminé ce qui permet d'améliorer le rapport signal/bruit et donc d'augmenter la portée.

Donc 1000 fois oui au RS485 d'autant qu'il existe des modules bon marché pour faire l'interface sortie série du micro vers RS485.

Quant au protocole de communication le mieux adapté a ce projet ce n'est pas dans mon domaine de compétence je laisse d'autres faire des propositions.

Bonjour,
Il y a aussi le bon vieux I2C + drivers pour augmenter la portée.

Liaison adaptée :
On montre (pour moi c'était au programme de la terminale) que la puissance transmise est maximale quand l'impédance de la charge est égale à celle du générateur.

C'est exact pour la puissance. Mais ce n'est pas cela qui nous intéresse. Supposons que je veuille dialoguer entre deux arduinos et que je mettes une résistance côté récepteur, égale à celle du générateur (le port de l'arduino).
Si j'ai 5V à vide et si les deux impédances sont égales, j'aurais la même tension dans l'impédance du générateur, que dans celle du récepteur soit la moitié 2,5V. Je vais avoir 2,5V sur mon récepteur et 5V (fem interne) -2,5V (perte dans la résistance) soit aussi 2,5V.
Si les deux résistances sont égales, l'arduino émetteur débite plus que ce qu'il est autorisé à faire.

Ce qui importe c'est les problèmes de vitesse de transmission.

Ce n'est pas mettre des résistances égales pour l'émetteur (en première approximation =0 ohms) et le récepteur (en première approximation infinie), mais des résistances de chaque côté égale à l'impédance caractéristique du câble. Pour comprendre ce concept, imaginons qu'un des arduino soit sur terre (émetteur avec une résistance série R) et l'autre soit sur le soleil (résistance du récepteur infinie, mais on a mis en parallèle une résistance R'), reliés par un câble dont je suppose la résistance des fils nulle. Quand sur terre je mets du 5V sur mon câble, il y a un pont diviseur entre R et R'. Seulement au moment ou je mets la tension, on ne sait pas ce qui nous attend de l'autre côté. Il faut 8 minutes pour que la tension aille jusqu'au soleil et 8 minutes de plus pour que l'information "il y a R' de l'autre côté" arrive enfin et que la tension s'établisse suivant la loi du pont diviseur. En attendant que se passe-t-il?
Le câble a une impédance caractéristique en fonction de ses dimensions et pendant les 16 premières minutes, l'émetteur verra cette impédance. Et la tension va s'établir en fonction du pont diviseur fait par R et l'impédance caractéristique du câble. Et 16 minutes plus tard une info revient qui dit que la tension est trop faible, parce qu'à l'autre bout la résistance est plus importante que celle de du câble. La tension côté émetteur va remonter et un aller retour plus tard cela ira mieux. On va donc avoir une tension qui va varier, et il faut attendre plusieurs aller retours pour avoir une valeur correcte. Et donc de pouvoir lire enfin la valeur.
Si la résistance côté émetteur et côté récepteur sont identiques à l'impédance caractéristique du câble, quand on branche l'émetteur celui ci va voir dès le départ la bonne résistance et le signal ne fera qu'un aller avant de s'établir définitivement.

C'est pour éviter les échos que l'on préconise de mettre de chaque côté une résistance égale à celle du câble. La résistance caractéristique du câble n'est pas la résistance des fils. Je ne sais plus la mesurer. Elle est indépendante de la longueur du câble. Par exemple les câbles d'oscillo ont des impédances de 50 ohms, les câbles TV étaient en 75 ohms pour 1m comme pour 100m. Je n'ai jamais été confronté à un problème car sur 1m il faut des fréquence de 100MHz (de mémoire), ce que je n'avais pas.

Si on est parfaitement adapté on peut atteindre des vitesses limites infinies. Si on ne l'est pas, il faut attendre plusieurs allers retours pour avoir la bonne valeur sur le récepteur. Avec un câble mal adapté de 1m, on peut passer 10Mbits, il aura 5 aller retour pour se stabiliser. Avec 100m, on ne peut plus dépasser 100kbits et ainsi de suite (valeurs exactes à vérifier)

Pour transmettre des données avec l'arduino, si celui-ci est capable de travailler à 115200 bauds sur 1m, il est capable de travailler à 11000 bauds sur 10m ou à 5000 bauds d'un bout de la maison à l'autre. Si on descend la vitesse, on n'est plus obligé d'adapter les résistances, et on peut prendre le câble que l'on veut.

Donc 1000 fois oui au RS485 d'autant qu'il existe des modules bon marché pour faire l'interface sortie série du micro vers RS485.

C'est un choix, mais les adaptateurs O-5V sont gratuits parce qu'il n'y en a pas besoin.

Les liaisons RS232 et suivantes on été faites pour transmettre des données le pus rapidement possible. Maintenant, si c'est pour donner l'ordre de mettre le chauffage en route, je ne pense pas utile de mettre une liaison rapide.

La liaison 1Wire est en 0-5V, pas d'adaptateurs et fonctionne très bien pour de la domotique.

Il y a aussi le bon vieux I2C + drivers pour augmenter la portée.

A vitesse donnée, passer de 0-5V à RS485 ou I2C permet effectivement d'augmenter la distance, mais diminuer la vitesse aussi. De quelle vitesse a-t-on besoin?

Bonjour,

Merci pour vos réponses.

Effectivement le débit nécessaire est faible.

Il faut tout de même transmettre sans trop de latence le texte pour l'afficheur

Pour des raisons ergonomiques (notamment la commande hifi et MP3) j'aimerais avoir un afficheur plus grand (4 lignes de 16 caractères) et aussi plus de boutons (8 touches ça serait pas mal)

Les 8 touches seraient alignées sous l'afficheur, la dernière ligne de l'afficheur indique la fonction des touches qui peut changer en fonction de l'arborescence des menus. Les 3 autres lignes permettent d'afficher d'autres informations.

Un afficheur de 4 lignes de 16 caractères se commande de la même façon qu'un afficheur de 2 lignes de 16 caractères. Pour les boutons il faut voir... Adapter le shield ou en refaire un ne serait pas trop complexe.

Quid du débit ?

On va dire qu'il faudrait pouvoir transmettre en un quart de seconde 4 lignes de 16 caractères soit 64 octets + quelques octets de "dialogue"

On arrive à 280 octets par seconde, donc 2400 bits/s suffit.

2400 bits/s ce n'est pas énorme.

Mon but est de ne pas réinventer la roue ; d'autant qu'en électronique une solution "sur mesure" peut revenir bien plus cher qu'un module prêt à l'emploi, sans parler du temps perdu pour la conception et les tests...

Il y a aussi la problématique des "collisions" : comment faire si plusieurs petits boîtiers de commande essayent de parler en même temps à l'unité centrale ?

Chez moi il y aurai 8 petits boîtiers de commande.

L'unité centrale doit être capable de communiquer avec ces 8 boitiers mais aussi avec le raspberry pi lecteur MP3

Il y a aussi l'idée de munir les petits boitiers de commande d'un recepteur infrarouge.

A bientôt !

Pour des raisons ergonomiques (notamment la commande hifi et MP3) j'aimerais avoir un afficheur plus grand (4 lignes de 16 caractères)

Pour une domotique, un écran TFT serait plus adapté.

J'utilise un 2.8 pouces ILI9341 : un-afficheur-pour-domoticz-ou-jeedom

Une NANO suffit pour le piloter.

Un petit buzzer pour une éventuelle signalisation des problèmes (température congélo trop basse, batterie de capteur trop faible, etc.).

La quantité de données ne change pas. Il s'agit lignes de texte : date & heure, températures, humidité, etc.
Il ne s'agit pas de transmettre des pixels.
Il existe des modèles tactiles, ce qui rendrait les boutons inutiles.

Re-bonjour,

Voici quelques infos sur le fameux LCD shield :

http://www.shieldlist.org/dfrobot/lcd

C'est juste du câblage, très peu de composants.
J'adore la façon astucieuse d'utiliser l'entrée analogique pour les boutons... je peux facilement mettre des boutons en plus !

Il reste 5 entrées et 7 sorties non utilisées, de quoi faire !

Pour répondre à @hbachetti :

Un TFT pourquoi pas... combien consomme-t-il ?
Quid de la durée de vie ?
La version tactile pourquoi pas c'est une bonne idée aussi !
Ca devient de plus en plus intéressant :slight_smile:

A bientôt

Un TFT pourquoi pas... combien consomme-t-il ?
Quid de la durée de vie ?

Presque rien. j'alimente la NANO avec un petit chargeur de téléphone mobile.
Durée de vie : difficile à dire. En service depuis seulement un an, allumé en permanence.
Mais il n'y a aucune raison de penser qu'un LCD alphanumérique aura une durée de vie supérieure.

Autre chose : pour un nombre important de boutons, une télécommande qui traîne dans un tiroir, une NANO et un récepteur TSOP4838 :

une-telecommande-domotique-infrarouge

Chez moi j'envoie les codes par le cordon USB à ma RASPBERRY PI, mais rien n'empêche d'utiliser une autre liaison.

Je joue pour l'instant avec un TFT tactile, je trouve que c'est génial. C'est une version sans soudures, compatible UNO, mais que je voulais de de toutes façons utiliser avec une mega.

Sa consommation: c'est le point faible: Toutes les broches de l'uno (sauf txd rxt SCL, SDA). Ah en courant? c'est 130 mA, sans doute dû au rétroéclairage.

Je m'étonne chaque jour des possibilités graphiques de cet objet. Je ne sais pas si je dois recommander le mien car je n'ai plus de broches disponibles, celui de hbachetti a l'avantage d'avoir le mode série. D'un autre côté, il n'a pas le tactile

Entre 5 à 10€ pour un 2 fois 16 lignes texte et monochrome, avec les boutons à 1€, et un afficheur couleur tactile à 20€, je n'ai pas hésité. Pour les boutons on en met autant que sur le visage d'un ado. Ça a quand même une autre tête (l'afficheur, pas l'ado).

Bonjour,

Merci pour vos réponses.

Pour la communication, après quelques recherches, le bus CAN semble le plus approprié

Tout le problème est de savoir si je peux en même temps utiliser le shield bus can avec un shield TFT tactile comme celui-ci : Shield Arduino écran TFT tactile 2,8''

Il semble plus facile d'utiliser le shield CAN avec le shield lcd keypad (seule la broche D9 "CS" est utilisée par les deux shield)

A la limite il me faudrait presque utiliser un écran TFT tactile avec interface CAN ; il n'y aurai qu'un arduino pour l'unité centrale.

A bientôt

Re-Bonjour,

En fait si on prend le problème dans sa globalité, j'ai 8 écrans tactiles qui doivent communiquer avec une unité centrale via des câbles de 5 à 20 mètres.

Ajoutons à cela des périphériques (actionneurs, échange avec le rpi MP3, infrarouge...)

Un arduino peut faire plein de choses mais pas toutes à la fois, car on ne peut pas empiler les shields à l'infini

Utiliser plusieurs arduinos ne fait que déplacer le problème, car il faut ensuite que les arduinos communiquent entre eux.

Comment faire ?

Un arduino peut faire plein de choses mais pas toutes à la fois, car on ne peut pas empiler les shields à l'infini

C'est pas le nombre de shields qui va poser le problème, c'est la taille de la mémoire de l'arduino. Tu utilise la liaison série, il y a des chances que tu utilises la bibliothèque SD. A vide, Cette bibliothèque consomme 4700o de flash (15% d'un UNO) et presque 800o de RAM (17% d'un UNO). Quel est le poids des autres librairies?

Tout le problème est de savoir si je peux en même temps utiliser le shield bus can avec un shield TFT tactile comme celui-ci : Shield Arduino écran TFT tactile 2,8''

Évite les shields si tu veux pouvoir disposer des broches de la UNO pour pouvoir brancher autre chose.

Ce ILI9341 2.8" par exemple est SPI et tactile :
aliexpress

Pour le CAN : idem
aliexpress (12€ les dix pièces)

C'est un MCP2515, comme le shield.

Ajoutons à cela des périphériques (actionneurs, échange avec le rpi MP3, infrarouge...)

Pourquoi est ce que tu n'utilise pas la RPI comme unité centrale ?
On trouve des cartes CAN pour RPI.

Bonjour,

Je souhaite une faible consommation.

Ce système domotique sera sous tension en permanence.

Si le système consomme au total 2,5A sous 5V, avec le rendement d'une alim à 80%, cela fait environ 15W

24h/24 et 7j/7 on arrive à 136 kWh par an ! C'est à dire autant que 62 heures de cuisson à plein régime avec un four.

C'est le problème des systèmes domotiques du commerce : ils consomment beaucoup.

L'avantage des arduinos et des LCD classiques envisagés au départ, c'est leur faible consommation.

Avec un RPI, il faudra que le système se mette en mode faible consommation lorsque qu'il n'y a pas d'activité sur le bus.

Le bus ne devra pas consommer beaucoup de courant.

C'est pour cela que je souhaite recourir à des relais bistables (notamment pour la commutation des haut parleurs)

A bientôt

Ta RPI n'est pas sous tension en permanence ?

Une RPI 1 , 2 ou 3 consomme entre 3W et 4W.

Il y a moyen de réduire la consommation à quelques µA sur les dispositifs émetteurs (interrupteur, télécommande, thermomètre, etc.).

Est-il possible de mettre en veille un récepteur et de le réveiller par le bus ? A voir.

En tous cas, je te recommande l'ARDUINO PRO MINI 8MHz. Elle fait le même boulot qu'une UNO pour une conso bien moindre.

consommation-dune-carte-arduino
arduino-pro-mini-basse-consommation

C'est pour cela que je souhaite recourir à des relais bistables (notamment pour la commutation des haut parleurs)

idem : bistables double bobine.
De plus cela leur évite de chauffer et de rester coincés en position ON. Cela m'est arrivé sur une prise commandée BLYSS.

une-prise-connectee-mysensors

sinon tu peux aussi utiliser des esp32, il en existe de toutes sortes avec déjà des écrans tactiles intégrés. Un esp32 peut très bien être utilisé sans activer le wifi si tu veux éviter les liaisons radio.
Il en existe même avec un codec audio intégré à la carte, ce qui permet de lire des mp3 sans soucis

par exemple ceci (mais écran non tactile) :

ou encore ça (mais sans audio) avec le boîtier tout prêt :

Bonjour,

Si vous devez tirer des câbles, pourquoi ne pas utiliser Ethernet ?
Les avantages sont nombreux :

  • tout le matériel existe, pour toutes les machines (Arduino compris avec des adaptateurs à W5100 ou W5500 à pas cher),
  • avec un hub, du câble CAT5, des prises RJ (et la pince ki-va-bien !), vous n'avez qu'à câbler, pas à vous embêter avec les impédances, les résistances de charge, la capacité linéique, etc,
  • sur un câble CAT5 vous avez 4 paires. L'Ethernet en utilise 2. Il en reste 2 pour l'alim ou autre chose,
  • tous les protocoles existent (IP) sur toutes les machines, tous les OS, et tous les langages. Tout ce monde communique facilement et très rapidement, sans latence. Toutes les bibliothèques existent, pour pourrez vous concentrer sur l'applicatif et non sur les protocoles, au risque, sans offense, de faire moins bien que ce qui existe tout fait,
  • avec Ethernet, si vous voulez remplacer un Arduino par un Raspi, c'est tout simple,
  • une fonction supplémentaire à laquelle vous n'aviez pas pensé ? Deux bidules qui doivent dialoguer ? Pas de problème de réseau,
  • la même infrastructure transporte tout : messages domotique, Internet, audio, vidéo,
  • quand vous en aurez assez des boutons et des LCD, un peu de html et un serveur Web (existe en toutes les "tailles" et sur toutes les machines), et hop, remplacement des écrans et claviers par ceux d'un PC, téléphone ou tablette,
  • accès à distance : de série ; sécurisation : option VPN ou https, il n'y a que l'embarras du choix,
  • aujourd'hui pas de radio, mais demain ? On rajoute un POA Wifi et tout roule sans aucune modif...

C'est personnellement le choix que j'ai fait après avoir expérimenté avec du filaire RS485, du XBee et du Nrf24 et je ne l'ai pas regretté.

Bonne bidouille,

MicroQuettas