Aidez nous ! Projet - Gestion domotique

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

Yep!

Je ne suis pas tout à fait d’accord sur la multiplication des arduinos…Je concois naturellement qui’il faut quelque-chose à l’autre bout pour interpréter les messages.
Gromain59, d’ailleurs, nous apporte une solution qui va à contrario, même si au demeurant, j’ai bien entendu son bêmol.
Il faut considérer que dans un système de communication multiple, les appels, traitements et retours d’information feront certainement appel à une gestion des latences rigoureuses. Les trains d’informations devront être entre-coupés d’attentes afin de libérer le bus le temps que se forme la réponse. De plus, Je choisirais plutôt une liaison 4 fils. Deux pour l’émission, deux pour la réception. Dans ce cas ci, les trains seront plus rapides, mais les attentes existeront toujours, l’arduino maître aura sa propre latence et il ne peut se passer des retours.
Si l’idée est de gérer 4 pièces par exemples, en sus du maestro, nous avons 5 arduinos à considérer avec chacunes sa propre vitesse d’execution, sa propre faculté à composer le message et l’envoyer. Vous me direz, qu’est-ce 50 ou 80 ms !!! Cependant, si l’on double les arduinos, je vous laisse deviner…(pas sûr que ce soit proportionnel en plus)

Gromain59 utilise le protocole UDP via une liaison ethernet 10Mbit. Mais que veut dire

les performances sont satisfaisantes.

et combien d’arduino as-tu sur ta nouvelle topologie ?? UDP = perte possible, qu’en est-il ???

Je suis persuadé que l’on est loin d’utiliser toutes les capacités du langage de programmation. Sans évoquer le multitâche (*qui n’existe pas en fait), je pense qu’il faut cependant s’en inspirer. La principale limitation de la plupart des micro-controleur se situe dans la gestion serie des tâches qui lui incombe, séquentielle, j’ai souvent mesuré les temps d’execution de mes programmes, pour voir, et j’ai été régulièrement surpris de constater que le programme mettait 3 fois plus de temps à dérouler sa boucle dés qu’il y a communication (en moyenne 30-40 ms).

Vous me direz qu’une arduino par tâche est plus rapide qu’une seule qui s’occupe de tout, cependant ce que vous gagnez en vitesse d’execution, vous risquez de le perdre en communication.

Pour en revenir à la programmation, il manque plusieurs chose pour optimiser la gestion des tâches. Premièrement, il faut établir des règles de priorités et des règles de décisions. Je m’entends, si deux informations arrivent en même temps ou à peu d’intervalle, une avec un priorité “0”, l’autre “1” (ou 2, ou 3, etc), j’execute d’abord la première.
Secondement, il faut stocker ces tâches, les trier, les executer en utilisant une partie de la mémoire flash (rapide?) et en s’inspirant des règles du premièrement. Ainsi, on se rapprocherait du *préemptif que je suggérais plus haut. J’ai un ordre local et distant simultanément, je donne la priorité à l’ordre local. Le message y, arrivé aprés x, est plus important. Etc.

Pour ma part, je commence à envisager également une évolution de mon projet, je m’oriente plutôt sur une carte à deux microcontroleurs (ATMEGA644), avec règles de décision, priorités et délégations vers le second processeurs au cas par cas. Du simili-clustering ou par analogie avec les automates modernes, une tâche rapide et une seconde pour le reste. J’y vois comme avantage la proximité entre les deux processeurs, donc des temps de communication trés réduit, doublement de la force de calcul (si j’arrive à implémenter du vrai clustering), une plus grande réactivité face aux événements multiples.
Je commence à me documenter sur différents algos qui pourraient m’aider dans cette tâche. Je ne suis pas encore arrété sur le protocole “ethernet”.

@+

Zoroastre.

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

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

Disons que l'idée d'utilisé l'udp ou tcp/ip est tentant niveau "facilité" de communication, mais comme tu le dis le Wiznet n'est pas donné et l'enc28j60 rajoute une grosse surcouche niveau programme donc source processeur et mémoire :~ Le fait d'être limité par le nombre de ports du/des switch me dérange également, sauf à prendre en conséquence ou en les empilant, mais bon consommation et cout serait également de la partie. J'aime également la pensée de maitrisé la chaine d'un bout à l'autre d'où le choix d'une solution "simple" :sweat_smile: à déployé tel que rs-485. Enfin tout ça est plutôt un avis et une réflexion personnel parce que cette solution est parfaitement sensée et valable et je ne contredirais pas ton choix là dessus .

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

J'avais également pensé au can mais c'est clair mal implémenté et les solutions rencontrée (shield tout aussi couteux que le wiznet) n'apporte rien de plus à comparé avec udp ou tcp/ip par exemple. L'I2C je préfère le réservé à d'autre chose. Le rs-485 d'une autre époque d'accord mais toujours maintenue et largement utilisé en entreprise (ce n'est pas pour rien). Une chose qui a tendance à saouler de nos jours c'est l'utilisation à outrance de nouvelle technologies certe moderne mais surdimensionné pour des chose simple et basique qui n'en on pas besoin. Je pense par exemple à l'usb qui ne fait que rajouté une complexité (drivers donc dépendance constructeur, os, etc ...) pour certaine tache qui n'en on pas l'utilité, une utilité c'est indéniable il en a mais c'est surtout le fait d'en faire une généralité et l'unique moyen de communiqué.

"Toute la documentation est en wallon" en effet, on distingue quelques mots c'est tout. :grin:

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

xpl est bien pour ceux qui veulent profité d'équipements existant, sans trop se prendre le choux ou avoir besoin de maitrisé tel ou tel technologie, mais bon une nouvelle fois personnellement je n'aime pas justement ce côté dispersion/profusion de technologies. Par contre je peux parfaitement comprendre que ce système est intéressant pour ceux qui n'ont pas la patience, connaissances ou motivation dans ce genre de projet et qu'il est certainement plus utile à la communauté que le notre. Ça peux paraitre égoïste mais ici ce projet je le fais d'abord pour moi, je ne fais que le partagé et je vais surement avoir plus besoin d'aide de votre part que le contraire. ;)

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

Pas vraiment créer, par exemple ici je ne fais que m'inspiré de ce qui existe déjà et assez commun (simple) entre tout ce que j'ai déjà vu dans le domaine.

Gromain59: 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 ;)

Tout les points de vue sont bon à prendre, même si je peux paraitre têtu et en désaccord je les respectes et comprends parfaitement. Ton projet risque d’intéressé beaucoup de monde surtout http://www.touteladomotique.com :grin: Pour la collaboration pourquoi pas un module xpl justement, c'est tout à fais envisageable sur le bus prévu (surtout pour ce qui est du genre Squeezebox justement :grin:) ;)

Ps: Vous m'entendez et m'entendrez souvent parlé de "dépendance", développeur objet oblige, le plus gros des différents point de vue avec les "électroniciens" viennent probablement de là.

zoroastre: Je ne suis pas tout à fait d'accord sur la multiplication des arduinos...

Il faut considérer que dans un système de communication multiple, les appels, traitements et retours d'information feront certainement appel à une gestion des latences rigoureuses. Les trains d'informations devront être entre-coupés d'attentes afin de libérer le bus le temps que se forme la réponse. De plus, Je choisirais plutôt une liaison 4 fils. Deux pour l'émission, deux pour la réception. Dans ce cas ci, les trains seront plus rapides, mais les attentes existeront toujours, l'arduino maître aura sa propre latence et il ne peut se passer des retours. Si l'idée est de gérer 4 pièces par exemples, en sus du maestro, nous avons 5 arduinos à considérer avec chacunes sa propre vitesse d'execution, sa propre faculté à composer le message et l'envoyer. Vous me direz, qu'est-ce 50 ou 80 ms !!! Cependant, si l'on double les arduinos, je vous laisse deviner...(pas sûr que ce soit proportionnel en plus)

Gromain59 utilise le protocole UDP via une liaison ethernet 10Mbit. Mais que veut dire

les performances sont satisfaisantes.

et combien d'arduino as-tu sur ta nouvelle topologie ?? UDP = perte possible, qu'en est-il ???

Je suis persuadé que l'on est loin d'utiliser toutes les capacités du langage de programmation. Sans évoquer le multitâche (*qui n'existe pas en fait), je pense qu'il faut cependant s'en inspirer. La principale limitation de la plupart des micro-controleur se situe dans la gestion serie des tâches qui lui incombe, séquentielle, j'ai souvent mesuré les temps d'execution de mes programmes, pour voir, et j'ai été régulièrement surpris de constater que le programme mettait 3 fois plus de temps à dérouler sa boucle dés qu'il y a communication (en moyenne 30-40 ms).

Vous me direz qu'une arduino par tâche est plus rapide qu'une seule qui s'occupe de tout, cependant ce que vous gagnez en vitesse d'execution, vous risquez de le perdre en communication.

Là dessus il s'agit plus du choix entre dépendances et performances, disons qu'il faut chercher le meilleurs compromis mais que l'un n’empêche pas l'autre. La seule solution c'est de testé et comparé, mais je me doute que les choses ne seront pas simple à mettre en œuvre (mais le plaisir dans tous ça est peut être justement là :) ).

zoroastre: Pour en revenir à la programmation, il manque plusieurs chose pour optimiser la gestion des tâches. Premièrement, il faut établir des règles de priorités et des règles de décisions. Je m'entends, si deux informations arrivent en même temps ou à peu d'intervalle, une avec un priorité "0", l'autre "1" (ou 2, ou 3, etc), j'execute d'abord la première. Secondement, il faut stocker ces tâches, les trier, les executer en utilisant une partie de la mémoire flash (rapide?) et en s'inspirant des règles du premièrement. Ainsi, on se rapprocherait du *préemptif que je suggérais plus haut. J'ai un ordre local et distant simultanément, je donne la priorité à l'ordre local. Le message y, arrivé aprés x, est plus important. Etc.

Pour cela j'avais pensé à la méthode/protocole CSMA (CA/DA ...) similaire à ta description.

zoroastre: Pour ma part, je commence à envisager également une évolution de mon projet, je m'oriente plutôt sur une carte à deux microcontroleurs (ATMEGA644), avec règles de décision, priorités et délégations vers le second processeurs au cas par cas. Du simili-clustering ou par analogie avec les automates modernes, une tâche rapide et une seconde pour le reste. J'y vois comme avantage la proximité entre les deux processeurs, donc des temps de communication trés réduit, doublement de la force de calcul (si j'arrive à implémenter du vrai clustering), une plus grande réactivité face aux événements multiples. Je commence à me documenter sur différents algos qui pourraient m'aider dans cette tâche. Je ne suis pas encore arrété sur le protocole "ethernet".

J'ai également pensé au 644p que j'ai vu sur le projet sanguino, enfin ce qui m'avais intéressé ce sont les deux uart pour justement faire du full-duplex rs-485 4 fils. Faudra absolument que tu nous tiennes aux courant de tes évolutions très intéressante. ;)