Aidez nous ! Projet - Gestion domotique

[Oliv4945]

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

[Brisebee]

Merci pour tes encouragements.

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

[Oliv4945]

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

[Brisebee]

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 !

[Oliv4945]

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

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

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 

[Brisebee]

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 !

[Gromain59]

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

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 

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

[Chajo]

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

[zoroastre]

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.

[osaka]

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

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. 

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.  

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

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.

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


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

[osaka]

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

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.

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. 

[Brisebee]

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

Mon idée est d'avoir un Arduino maître qui « gère » des unités de commandes autonomes, qui selon le cas peuvent être :

1) simplement des éléments matériels avec les parties puissance par exemple pour la commande des fils pilote d'une installation de chauffage électrique où chaque pièce est équipée d'un thermostat avec un fil pilote, cette unité de commande (dont je joins le schéma pour une voie) est autonome puisqu'elle peut fonctionner en mode manuel (avec l'interrupteur) ou en mode automatique, alors l'automate (arduino) lui envoie :
- 0V : mode normal => la température de consigne est celle affichée sur le thermostat,
- 5V : mode réduit => la température de consigne est celle affichée sur le thermostat - 5°C
En fonction de plages horaires et ou de commandes (forçage dans un mode ou l'autre) par le web.

2) des dispositifs plus complexes qui peuvent nécessiter d'avoir leur propre processeur pour être autonomes, et ne recevoir que des commandes simples ou avec passage de paramètres de l'unité « maitre » et renvoyer des comptes rendus et des données là aussi limités. Je pense que dans un premier temps je n'aurai pas besoin de tels dispositifs.

Pour ce qui est de la maintenabilité du code, tu as raison. Même si on essaye de faire les choses très proprement, de documenter un maximum et de programmer d'une façon modulaire, c'est tout de même problématique.

Pour la question de la mise à jour et du black-out, si toutes les unités de commande sont autonomes, cela ne devrait pas poser de problème.

Pour ce qui est du boitier, je n'ai pas ce problème, j'ai un local technique, où j'ai mes tableaux électriques, alarmes, répartiteur téléphonie, système domotique actuel, switch Ethernet et NAS.

[Artouste]

bonjour
je lis ce topic depuis quelques jours.

ma petite expérience sur la "domotisation" qui vaut ce qu'elle vaut :
il y a quelques années j'ai voulu un peu "domotiser ma "petite campagne"    que j'occupe très épisodiquement.

l'écueil principal est AMHA le vecteur du transfert fiable de l'info.
Si sur de la construction neuve, il est facile de réfléchir et d'intégrer du câble, ce n'est pas évident sur de l'ancien.

j'avais donc regardé du coté du X10 (à l'époque le CPL du pauvre  ) et j'avais implémenté ça sur de la base PIC.
pour mémoire, je me souviens avoir bien galéré sur de l'implémentation issue de schéma/code  US , jusqu'à ce que je me rappelle qu'il y a une grande différence pour le X10 entre réseaux 50 et 60 Hz    )

mais j'ai assez vite abandonné l'évolution , mon "cahier des charges" se limitant à
être prévenu d'une ouverture d'accès, d'une baisse de t°, de pouvoir à distance mettre hors gel , mettre en route chauffage/eau chaude
quelques heures avant que j'arrive.

je fais ça "à l'ancienne" depuis pas mal d'année avec un bon vieux modem RTC  à 4800 devant un PIC     (mais ça pourrait maintenant être arduino based )

La RS485 dont la fiabilité n'est plus à démontrer (différentiel) avec des compo dispos éprouvés à "pas trop cher" est une bonne solution, mais il faut quand même et toujours d'abord "tirer du câble"

[osaka]

l'écueil principal est AMHA le vecteur du transfert fiable de l'info.
Si sur de la construction neuve, il est facile de réfléchir et d'intégrer du câble, ce n'est pas évident sur de l'ancien.

j'avais donc regardé du coté du X10 (à l'époque le CPL du pauvre  )

Ça rejoint tout à fais ma remarque précédente.

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.

La RS485 dont la fiabilité n'est plus à démontrer (différentiel) avec des compo dispos éprouvés à "pas trop cher" est une bonne solution, mais il faut quand même et toujours d'abord "tirer du câble"

Ça nous conforte dans notre choix. 

[Skuzmitoo]

Ce que je peu retenir, c'est que dans l'idéal,il faut :

- un arduino + ethernet pour les commandes depuis l'extérieur qui jouerait le rôle de maître
- un arduino par pièce pour gérer les différents capteurs et actionneurs (plus de problème pour la distance entre capteurs et arduino)(pourquoi pas intégrer le tout dans un plafonnier a voir)
- un bus RS485 pour faire communiquer les arduinos entre eux
- le protocole Xpl pour le transmission des consignes et des valeurs des capteurs

Maintenant il y a des câbles a tirer et encore pas trop, mais dans n'importe quel cas il faudra tirer des câbles.

Vous êtes d'accord avec moi ?