Aidez nous ! Projet - Gestion domotique

Donc si j'ai bien compris, on utilise le RS485 pour la liaison inter-arduino mais également pour actionner et lire les capteurs.

Pour moi il faut rester sur le RS485 car pour la domotique on a rarement des distances inférieures a 1 mètre.

Je pense également que l'utilisation de websockets est la plus appropriée.

Skuzmitoo: Donc si j'ai bien compris, on utilise le RS485 pour la liaison inter-arduino mais également pour actionner et lire les capteurs.

Il faut faire des essais, et/ou obtenir des informations de personnes qui ont mis réellement mis en oeuvre des liaisons RS 485.

Skuzmitoo: pour la domotique on a rarement des distances inférieures a 1 mètre.

Pour ce qui me concerne, la distance entre mon automate que j'ai appellé "unité de gestion domotique" et l' "unité de commande" chauffage, est de 1m à peine et celle avec "l'unité de commande" arrosage est de moins de 50cm. Mais je n'ai pas mis en oeuvre les capteurs de pluviométrie et de température, mon système fonctionne donc plutôt en boucle ouverte (pour faire une analogie avec les systèmes bouclés, même si ici, ce n'est pas tout à fait de cela dont il s'agit). Il était prévu dès le départ de rajouter les capteurs (au moins celui de pluviométrie), mais je ne l'ai jamais fait, cela fonctionne très bien comme cela, et depuis bien longtemps ! Alors, que cela optimiserai le dispositif en me permettant de moins consommer d'eau inutilement.

Skuzmitoo: Pour moi il faut rester sur le RS485 car pour la domotique on a rarement des distances inférieures a 1 mètre.

En fait c'est ce que j'expliquais par différente installations électrique.

Chez Bribri (je t'ai choisis un petit surnom plus court :grin:) chaque point actionneur et récepteur (lumineux, prise, ...) reviennent en 1 seul point (étoile) et ne sont pas directement "lié" l'un à la suite de l'autre (actionneur-> automate ->récepteur).

Chez toi ça devrait être comme ceci, un point de départ coffret -> actionneur -> récepteur.

Donc chez Bribri tout les modules devraient être rassemblé en 1 seul point donc faible distance entre eux (pour certaine raison on pourrais avoir un module plus distant comme chaudière, ...), tandis que chez toi (installation classique) chaque module serait plutôt local à chaque pièces d’habitation donc distant.

Pour moi le mieux serait une installation électrique comme Bribri en étoile (je suppose qu'il l'avait prévu à la construction ou rénovation), mais bon difficile de demandé de modifier son installation existante ... (seignée, cablage, ... :~) C'est la principale raison pour beaucoup du choix du x10 (courant porteur) ou du sans fils.

Skuzmitoo: Je pense également que l'utilisation de websockets est la plus appropriée.

Je pense aussi pour le côté full-duplex, j'espère seulement que la normalisation soit bientôt vite définitive, mon autre projet est en pause à cause de cela :( .

Concerant la partie trame de communication entre modules, je pense à quelque chose comme ça.

Trame globale: - un octet de début - un octet de longueur des données de la trame variable (voir la partie DATA). - Des données dont la taille dépendra du type de donnée (numérique nombre entier, nombre flottant, caractère ou chaine de caractère, ...) :% :grin: - un crc de contrôle (16: 2 octet) - un octet de fin de trame

Détails de la partie DATA: - un octet de groupe (de 0 à 255) une adresse de groupe pourrais être attribué à un type de groupe par exemple les modules d'entrée/sortie numérique, on pourais spécifié également une adresse de broadcasting genre 255 pour tout les module de ce groupe, ALL UNIT On ou Off. - un octet d'unité, l'entrée ou sortie spécifique à un module. - la commande en elle même on/off, demande mesures, ... - les données de commandes (variable: 1-n, maximum 252 d'après la longueur spécifié en retirant group, unit, command), par exemple 1(on) ou 0(off), pwm (0 à 255), flottant (température, ...), chaine de caractères, ...

La trame ressemblerait à quelque chose comme [0x02-0x04-0xF1-0x05-0x02-0x01-0xC9-0xD3-0x03] , 0x02 start, trame avec 0x04 octet de données, action vers l'unité 0x05 du groupe 0xF1, commande 0x02 (action num) avec pour valeur 0x01 (on), crc de contrôle 0xC9-0xD3, 0x03 end. Entre () déjà tester http://arduino.cc/forum/index.php/topic,72035.0.html .

Pour la partie RS-485 le maître devra géré les transactions, demande d'envois des modules, ..., gérer le risque de collision (CSMA/DA ?) (collision possible uniquement lors d'une demande de transaction par un esclave puisque les esclaves ne pourront parler ou écouter entre eux que sous ordre du maître ).

Osaka super travail ce que tu viens de nous faire. Actuellement moi je n’ai aucun système en place mais je souhaite développer une solution “étoile” pour pouvoir l’intégrer dans ma future maison que j’aurais un jour.

Un peu d’aide, je cherche comment lire un capteur ou actionner un capteur en RS485 et je ne trouve rien sur le net. Pour la communication entre arduino ok pas de souci, mais si le capteur est a 100m de l’arduino on fait comment ? Quelqu’un a des sujets qui abordent ce problème ?

Skuzmitoo: future maison que j'aurais un jour.

me too, on pourra adapter l’installation suivant le système. :grin:

Skuzmitoo: Un peu d'aide, je cherche comment lire un capteur ou actionner un capteur en RS485 et je ne trouve rien sur le net. Pour la communication entre arduino ok pas de souci, mais si le capteur est a 100m de l'arduino on fait comment ? Quelqu'un a des sujets qui abordent ce problème ?

J'avais trouvé ceci et d'autre discutions concernant le rs-485 et l'arduino, donc via adaptateur rs-232/485 genre SN75176 ou max-585 qui ne coute pas grand chose. http://gdallaire.net/blog/?tag=network http://real2electronics.blogspot.com/2009/09/arduino-and-rs485-english-version.html

Skuzmitoo: Un peu d'aide, je cherche comment lire un capteur ou actionner un capteur en RS485 et je ne trouve rien sur le net. Pour la communication entre arduino ok pas de souci, mais si le capteur est a 100m de l'arduino on fait comment ? Quelqu'un a des sujets qui abordent ce problème ?

Déjà il y a plusieurs types de capteurs, des capteurs passifs (par exemple LDR, roues codeuses) et d'autres actifs. Comme je l'ai déjà écrit plus haut la majeure parties des capteurs (non conditionnés) produisent des grandeurs analogiques (microphone pour le son, LDR pour la luminosité, Jauge de contrainte pour la pression, thermistance pour la température, ...). Une grandeur analogique est une grandeur qui varie de manière continue entre une valeur minimale et une valeur maximale (la variation n’est pas nécessairement linéaire). Pour placer ce type de capteur à grande distance, tout dépend des caractéristiques électriques du dit capteur, l’influence du câblage peut-être importante et donc fausser complètement les mesures. C’est pour cela que l’on conditionne les capteurs et que l’on converti en général les grandeurs analogiques en grandeurs numériques, que l’on va pouvoir transmettre avec beaucoup moins de risques de perturbations. Ensuite si l’on veut produire la bonne séquence en fonction du protocole choisi, il va falloir la générer. Pour certains protocoles standards (par exemple I2C), il existe des composants spécialisés, sinon il faut générer les signaux correspondants au protocole et donc autant le faire avec une petite carte Arduino.

Comme certains capteurs conditionnés ont des sorties I2C et qu'il existe des interface matérielles I2C <=> RS 485, il faudra voir dans ces cas là, si cette solution n'est pas plus simple et moins chère que de mettre une Arduino (même la moins chère) juste pour un capteur.

J'espère avoir répondu clairement à ta question.

Cool encore un projet domotique ;) bon courage pour ce projet qui prend pas mal de temps ...

Yep!

Comme certains capteurs conditionnés ont des sorties I2C et qu’il existe des interface matérielles I2C <=> RS 485, il faudra voir dans ces cas là, si cette solution n’est pas plus simple et moins chère que de mettre une Arduino (même la moins chère) juste pour un capteur.

Mes cartes relais sont pilotés en Rs485 (cartes achetés toutes faites chez www.sigma-shop.com ). Ce qui est interessant est qu’elles sont pilotées en fait par une carte intitulé “RS485 Output Board”. Pour rappel, la carte relais possède 8 relais, ce qui sous-entends que la carte controlleur gère 8 canaux. Le controleur est un ATTiny2313/DIP :wink:
Il semble être un bon candidat pour accépter 8 sorties, faut voir le datasheet pour l’aspect entrée. Sa limite se situe du côté de la mémoire flash 2Kb. (18 entrées/sorties max, 4 Pwm, 1 full duplex UART). J’ai rien vu côté entrées analogiques par contre…

Les cartes sont pré-adressées et chainables…

Fabriquer un système identique à base d’opto ne doit pas coûter trop cher.

Une question comme çà aux hasard, comment pensez-vous alimenter tout çà ? alimentation unique (ligne 12v/24v + regulateurs), déportée (point par point) ??

@+

Zoroastre.

PS: 2€74 l’unité chez Farnell, 2€22 chez Digikey

Brisebee:
Ensuite si l’on veut produire la bonne séquence en fonction du protocole choisi, il va falloir la générer.
Pour certains protocoles standards (par exemple I2C), il existe des composants spécialisés, sinon il faut générer les signaux correspondants au protocole et donc autant le faire avec une petite carte Arduino.

N’étant pas spécialisé dans le domaine j’avais pensé aux 1 wire pour les mesures basique tels que température,humidité, … via ce genre d’interface :
http://www.embeddeddatasystems.com/HA7E--ASCII-1-Wire-Host-Adapter_p_21.html. “1000 feet, 100 devices per CAT-5 twisted net” .
http://www.ibuttonlink.com/linkoem.aspx LinkOEM autonome.
http://www.thermodata.com.au/node/62

J’ai vu ça également
http://www.phanderson.com/arduino/ds2450_1.html
http://code.google.com/p/gfb/source/browse/arduino/DS2450/DS2450.cpp?spec=svn60&r=60

Maintenant je suis sure qu’avec tes compétences il y aurait moyen de faire mieux. :slight_smile: :slight_smile: :slight_smile:

chicotore:
Cool encore un projet domotique :wink: bon courage pour ce projet qui prend pas mal de temps …

Tu parles en connaissance de cause ? :grin: .
Tu n’as pas encore testé la dernière solution que je t’avais proposé pour ton shield ?

zoroastre: Il semble être un bon candidat pour accépter 8 sorties, faut voir le datasheet pour l'aspect entrée. Sa limite se situe du côté de la mémoire flash 2Kb. (18 entrées/sorties max, 4 Pwm, 1 full duplex UART). J'ai rien vu côté entrées analogiques par contre...

Intéressant ce petit microcontroleur, si je comprend bien c'est de l'atmega light ? En cherchant un peux j'ai trouvé un chouette tuto ici qui explique un peux le microcontroleur (avec justement unATTiny2313) pour les amateurs comme moi. :open_mouth:

zoroastre: Une question comme çà aux hasard, comment pensez-vous alimenter tout çà ? alimentation unique (ligne 12v/24v + regulateurs), déportée (point par point) ??

Excellente question, je comptais justement sur la communauté pour répondre à ce genre de question qui peux paraitre simple mais compliqué en réalité :grin:

zoroastre: Une question comme çà aux hasard, comment pensez-vous alimenter tout çà ? alimentation unique (ligne 12v/24v + regulateurs), déportée (point par point) ??

Excellente question, je comptais justement sur la communauté pour répondre à ce genre de question qui peux paraitre simple mais compliqué en réalité :grin:

Je pense qu'il y a deux solutions réalistes : 1) il faut 2x2 fils : 2 fils pour l'alimentation et 2 fils pour la liaison différentielle RS 485. A partir du moment où il faut tirer un câble ! 2) on refait une petite alimentation (même sans transfo) s'il y a du 230VAC à proximité du point d'arrivée où sera installé le capteur et on ne tire qu'une paire torsadée pour la liaison différentielle.

Tu parles en connaissance de cause ? . Tu n'as pas encore testé la dernière solution que je t'avais proposé pour ton shield ?

Ne t’inquiète pas j'ai bien gardé sous le coude ton dernier code et t'en remercie mais pour le moment je n'est absolument pas le temps de bidouiller mon arduino et même de passer sur le forum ...

Beau projet ! ça ne va pas du tout avec mes besoins donc je vais juste me contenter de suivre sans être actif mais bon courage !!

Merci pour tes encouragements.

Quels sont tes besoins, cela peut donner des idées si c'est en domotique.

Salut,

Je vais faire un sujet tout à l'heure pour présenter mon projet mais en gros mon but est de mettre le moins d'éléments possible par soucis de place, de coût, d'esthétisme et… de câblage, contrairement à vous je suis en location et je n'ai pas de câbles utilisables ;) Du coup pour le moment j'ai un Arduino qui fait tout mais je pense que je vais tendre vers un uC par pièce + un qui gèrera l'ethernet, et un autre pour l'acquisition téléinfo EDF pour vérifier les ordres sur le chauffage électrique, le tout sans fils ;)

Edit : présentation de mon projet

Nos objectifs, et donc nos préoccupations, même si elles ne sont pas identiques ne sont pas si éloignés que cela ; J’ai jeté un coup d’œil à la présentation de ton projet, pour ce que tu décris comme étant fait, correspond d’un point de vue fonctionnel (et pour une grande partie matérielle) à ce que je veux faire : A partir d’un Arduino Mega + Ethernet shield + horloge temps réel (DS 1307) commander des sorties en fonction de l’état de capteurs et selon des plages horaires. Pouvoir visualiser et modifier l’état du système et modifier les plages horaires via le web, ou au minimum par le réseau local. Si j’en étais là où tu en es, j’aurais réglé une grande part de ce qui me préoccupe !

Brisebee: Nos objectifs, et donc nos préoccupations, même si elles ne sont pas identiques ne sont pas si éloignés que cela ;

Effectivement, mais je pense que les réalisations seront très différente. Enfin selon comment vous orientez tout ça je viendrais me greffer ;)

Brisebee: Pouvoir visualiser et modifier l’état du système et modifier les plages horaires via le web, ou au minimum par le réseau local.

Via le web et en local à très peu de choses près c'est pareil ne t'en fais pas là dessus

Brisebee: Si j’en étais là où tu en es, j’aurais réglé une grande part de ce qui me préoccupe !

Je suis pas loin si vous avez des questions. Mais sur tout ce qui est "web" Osaka à l'air d'avoir des connaissances bien plus grandes que les miennes :)

Oliv4945: Je suis pas loin si vous avez des questions

Merci pour tes réponses et ta proposition.

Je vais avancer tout doucement, et essayer de comprendre ce que je fais et ce que cela produit comme effets. Je suis un électronicien de la vieille école, j'ai pas mal programmé en assembleur mais très peu sur des langages plus éloignés de la machine. J'ai du mal à accepter d'utiliser des fonctions que je ne maîtrise pas, comme des boîtes noires, mais cela viendra !

Bonjour à tous les férus de domotique,

je découvre seulement ce topic donc j’arrive un peu tard…

J’ai lu que vous faisiez référence à mon projet xPLduino, un ensemble de module compatible arduino interconnectés via Ethernet (protocole UDP pour le transport, protocole XPL pour le formatage des messages). :slight_smile:

Je confirme que le choix d’un seul arduino gérant une multitude de fonction (volet, éclairage…) est un mauvais choix. C’était mon choix avec xplduino_v1. L’idée était de profiter du grand nombre d’E/S d’une Mega et de limiter les couts car le shield Ethernet Wiznet n’est pas donné.
Le point fort:

  • ça marche en production depuis 1 an, sans problème majeur
    Les points faibles:
  • une maintenabilité du code assez pénible (nombreuses fonctions logicielles empilées)
  • une mise à jour impossible sans black-out de la maison (au moins le temps du chargement du soft, plus si loupé dans les modifs)
  • une intégration mécanique de l’arduino dans un boitier délicate

Entre temps, j’ai étudié la solution Ethernet à base d’ENC28J60. Elle fut plus complexe à mettre en oeuvre au départ car l’arduino à plus de travail à réaliser: les datagrammes arrivent brutes de décoffrage au contraire du wiznet qui fait le gros du boulot.
Mais finalement ce n’était pas la mer à boire. En a découlé xplduino_v2 qui est bien avancé désormais. Le code de la v1 est porté à 80% en v2, les performances sont satisfaisantes.
La version 2 s’architecture autour d’un µC plus modeste (atmega328p) et d’un ethernet plus basique (débit 10mbps). Tous les composants existent au format DIP, donc je vais pouvoir réaliser une carte 2-en-1 qui s’intégrera parfaitement dans les boitiers sur rail DIN du marché, et qui sera très peu cher. La répartition des fonctions sur plusieurs modules interconnectés mais néanmoins autonomes apporte une plus grande fiabilité et flexibilité. Le code est commun à toutes les modules, mais optimisé pour chaque type de modules (éclairage, volet, E/S). La maintenance est simplifié.

Maintenant, pourquoi le choix de l’ethernet UDP ? je dirais le choix d’une certaine modernité lol. C’est le média universel et moderne par excellence. Alors oui, il nécessite un switch pour faire communiquer plusieurs modules entre eux, mais qui n’a pas de switch chez lui ? Il permet de s’affranchir des distances, et est modulaire (topologie en étoile, pas besoin de faire courir un bus dans toute la maison, on peut étendre le réseau à l’infini).

J’ai bien hésité un moment entre RS485, I2C et CAN, mais je trouve ces technos certes éprouvés, mais soit pas adpatés (I2C) soit d’une autre époque (RS485). Pour le CAN, d’une grand fiabilité, il est malheureusement très mal implémenté dans les arduino/atmega. Pour l’utiliser, autant partir sur l’excellent projet Domocan de BigOnOff, mais c’est du Pic. Toute la documentation est en wallon.

Au début du projet j’avais commencé à écrire mon propre protocole (largement pompé sur domocan d’ailleurs), mais je me suis vite rendu compte que l’ouverture vers le monde extérieur serait vite limitée. Puis j’ai découvert le protocole xPL (à ne pas confondre avec la techno CPL hein !!!). C’est un protocole ouvert, assez bien documenté, et supporté par un nombre croissant d’équipement (Squeezebox par ex) et de solutions logiciel (DOMOGIK étant ma préférée car 100% open-source, avec une IHM web, une appli android fonctionnelle et cerise sur le gateau, française). Son but est justement d’unifier l’incroyable profusion de techno plus ou moins propriétaires du monde de la domotique en faisant abstraction de la techno (plcbus, knx, x10, RF etc.).

Mais bon, libre à vous de créer un n nième protocole domotique :smiley:

Voilà pour mon modeste point de vue.

@ bientôt

Gromain59

PS1: un début de spécification de xplduino_v2 ici.
PS2: je suis toujours ouvert à toute collaboration :wink:

Bonsoir,

J'ai découvert ce forum et particulièrement ce post cet après-midi. J'aime la démarche collaborative, d'autant plus que je ne dispose pas de toutes les compétences. Je suis moi-même intéressé par certaines fonctions domotiques et leur implémentation sur des modules arduino.

Tout comme Brisebee je suis un électronicien de la vieille école ayant programmé beaucoup en assembleur sur le 6809 entre autres et en turbopascal (un peu de C également). Depuis quelques années, je suis en retraite et forcément, je dispose de peu de temps...pour moi.

Ceci dit, je réfléchis depuis pas mal de temps sur un système de gestion domotique qui incluerait au minimum les fonctions suivantes :

  • commande chauffage électrique (modif consignes, contrôle température donc bouclage des ordres)
  • contrôle consommation électrique générale
  • contrôle production photovoltaïque (comptabilisation production et pour vérifier que le différentiel n'a pas disjoncté)
  • système d'alarme intrusion
  • consultation par le web
  • envoi de sms sur portable sur évènements prédéfinis (plus performant que la retransmission tph)

Je dispose d'ores et déjà d'un serveur que j'ai construit sous ubuntu sur mon réseau local.

Charles