Aidez nous ! Projet - Gestion domotique

En ce qui concerne le bus a utiliser, le RS485 est super, mais assez complexe car il n'y a aucune couche materielle.
Pour cela, Elektor publie depuis quelque temps des articles concernant un bus R485 assez abouti, mais simple pour de la domotique.
Tout les exemple sont baés sur des atmega168, donc tres simple a porter sur arduino :wink:

si qquun a le temps d'y regarder, ca vaut la peine.

L'article Elektor à l'air très intéressant, c'est bien celui ci ?
J'ai pas d'abo Elektor vu que je suis une buse dans le domaine :blush:, mais ça pourrait être intéressant pour certaine chose; grand merci. :open_mouth:

Pour interfacer le rs-485 et l'arduino je pensais procéder comme :

http://gdallaire.net/blog/?tag=network

osaka:
je pars plus sur la même philosophie (modulaire) que Brisebee et Skuzmitoo par exemple .

osaka:
Juste une image de ma proposition global et incomplètes vu les possibilités offertes, les différents avis sont très intéressant :open_mouth:.

Je suis surpris par la "modularité" de votre découpage, vu que j'ai à peu près le même projet que tout le monde. J'ai l'impression que vous partez sur une solution avec 4/5 arduino minimum. C'est que mon avis mais je trouve ça un peu surdimensionné : Le contrôleur va contrôler quoi ? Lui intégrer le contrôleur permettrai de n'avoir qu'un élément de "contrôle." Pourquoi ne pas s'organiser plutôt en brique logicielles, comme ça les personnes qui veulent avoir un Arduino par fonction peuvent, et ceux qui veulent grouper les fonctions le peuvent aussi.

En ce qui me concerne j'ai prévu 1/2 Arduino par pièce, mais pas 4. Par contre je suis franchement intéressé pour me mettre avec vous si votre solution devient plus souple :slight_smile:

Sinon niveau communication pourquoi ne pas partir sur du RF ? Un truc qui me trote dans la tête depuis un moment c'est de brancher un module RX/TX en sortie d'une UART pour une liaison série sans fils mais je n'ai pas encore eu le temps de tester..

Oliv4945:
Je suis surpris par la "modularité" de votre découpage, vu que j'ai à peu près le même projet que tout le monde. J'ai l'impression que vous partez sur une solution avec 4/5 arduino minimum. C'est que mon avis mais je trouve ça un peu surdimensionné : Le contrôleur va contrôler quoi ? Lui intégrer le contrôleur permettrai de n'avoir qu'un élément de "contrôle." Pourquoi ne pas s'organiser plutôt en brique logicielles, comme ça les personnes qui veulent avoir un Arduino par fonction peuvent, et ceux qui veulent grouper les fonctions le peuvent aussi.

Yop Yop Oliv
Le fait d'avoir une installation modulaire permet grandement les possibilités et surtout le plus grand critère exigé en domotique c'est la fiabilité, il n'est pas question qu'en cas de panne d'un module toute l’installation sois en déroute ...
Donc pour la même raison je suis plutôt contre la brique logiciel pour les raisons invoqués.
Le ou les contrôleurs contrôle tout ce qui est contrôlable tout simplement :grin:, des e/s numérique d'un module, de la variation d'un module, ...
Maintenant ici mon schéma représente juste les possibilités et non comment elle devrait être réellement.
Le "ARDUINO MASTER BUS" ne sert qu'à la gestion de la communication entre modules ce n'est pas un CONTRÔLEUR/ACTIONNEUR, il est là parce que c'est la système de communication du bus (rs232/485) en lui même qui le veut pour pouvoir faire communiqué les module entre eux.
Pour le côté surdimensionné vu la consommation et le prix des microcontroleur utilisés (hors solution toute faite genre uno, mega, ...), les multiplier ne pose pas vraiment de problème si on compare par exemple la consommation d'un ordinateur, la tv, d'une ampoules XD ou autres ...
Tes question sont parfaitement légitimes et beaucoup de monde ce les posent parce que ça parait presque illogique et insensé, on est tenté de tout faire avec 1/2 arduino et pourtant je ne fais que me basé sur des solutions existante en domotique comme le knx, l'automate et autre bus divers.

Oliv4945:
En ce qui me concerne j'ai prévu 1/2 Arduino par pièce, mais pas 4. Par contre je suis franchement intéressé pour me mettre avec vous si votre solution devient plus souple :slight_smile:

Sinon niveau communication pourquoi ne pas partir sur du RF ? Un truc qui me trote dans la tête depuis un moment c'est de brancher un module RX/TX en sortie d'une UART pour une liaison série sans fils mais je n'ai pas encore eu le temps de tester..

En fait ici il n'est pas question d'arduino par pièces, le système se trouve à 1 seul endroit c'est ce que j'expliquais précédemment pour le type d’installation électrique général, par exemple tu as ton bouton poussoir dans ton salon, il revient vers le bus et celui ci active la sortie correspondante, tout les points (poussoir, lampes, prise, ...) son connecté au bus ce qui provoque évidement de grande longueur de fils dans ton installation électrique (en étoile), par contre ça réduit la distance entre modules ou controleurs/modules.
Donc dans ce cas si, le sans fils serait utile pour communiqué avec un contrôleur afin d'évité les fils.

pour mieux comprendre :

au final ça pourrait bien ressembler à cela. :grin:

Oliv4945:
Je suis surpris par la "modularité" de votre découpage, vu que j'ai à peu près le même projet que tout le monde. J'ai l'impression que vous partez sur une solution avec 4/5 arduino minimum. C'est que mon avis mais je trouve ça un peu surdimensionné

Mon idée initiale (et je ne l’ai pas encore complètement abandonnée), est d’avoir un Arduino « central » que j’ai appelé « unité de gestion domotique » c’est cette unité de gestion qui est l’horloge du système et qui communique avec le monde extérieur via le web. Il y a suffisamment d’entrée/sortie disponibles sur cet Arduino, surtout si c’est un Méga pour commander directement un certain nombre d’actionneurs, s’il n’y a pas de problème de distance, (ce qui est mon cas, car j’ai un local technique et tout arrive là), les éléments qui peuvent être commandés directement, (fils pilotes de chauffage électrique, électrovannes d’arrosage, …) ne nécessitent donc pas autre chose que des relais pour passer du 5VDC en 220VAC ou 24VAC (en fait comme je l’ai déjà écrit plus haut, je n’utilise pas de relais électromécaniques, mais des montages avec des opto-triacs et triacs), pour moi c’est la partie la plus importante de mon installation. Après si on veut faire des choses plus sophistiquées on peut toujours mettre en œuvre d’autres Arduino déportés qui communiquent avec l’Arduino « unité de gestion domotique » via RS 485, mais pour moi c’est secondaire, même si cela peut (et probablement doit) être prévu au départ.
Je concentrerai mes efforts dans un premier temps à réaliser cette première partie et à faire une interface avec le web fonctionnelle et commode (et là j'aurai besoin d'aide pour la partie web!).
Mais je suis tout à fait prêt à participer à la conception d’un système plus complet et plus universel, dans la mesure de mes moyens, qui sont celle d’un ingénieur électronicien (qui n’exerce plus dans le domaine technique depuis quelques années). Car je trouve que les échanges sur ce forum sont très intéressants et peuvent permettre à tous d’apporter et confronter des idées et des connaissances et à chacun de gagner en compétence dans un des relativement nombreux domaines techniques (réseau, web, programmation, télécommunications, électrotechnique, électronique, …) que recoupe la domotique actuelle.

Brisebee:
Mon idée initiale (et je ne l’ai pas encore complètement abandonnée), est d’avoir un Arduino « central » que j’ai appelé « unité de gestion domotique » c’est cette unité de gestion qui est l’horloge du système et qui communique avec le monde extérieur via le web.

Pourquoi l'abandonné ?
Par exemple dans mon schéma on aurais très bien pu appelé contrôleur/unité de gestion domotique.
Les différent type (web, client lourd, ...) de contrôleur/unité de gestion domotique peuvent être séparé ou intégré c'est aux choix (ce sera là sans doute les plus grosse différences entre chacun).
Enfin j'ai l'impression qu'on confond un peux ce qu'on ce dit les un les autres ? :sweat_smile: :grin:

osaka:
Enfin j'ai l'impression qu'on confond un peux ce qu'on ce dit les un les autres ? :sweat_smile: :grin:

Il me semble aussi ! j'ai été confronté plusieurs fois à des situations de ce type dans les dernières annèes de technicien, et notamment de chef de projet, les informaticiens et les électroniciens utilisent les mêmes mots pour désigner des choses différentes (et parfois proches, mais non identiques, ce qui rend la compréhension encore plus difficile), c'est pour cela qu'il faut chaque fois expliciter les concepts pour lever toutes les ambiguités.

De mon point de vue vous (Brisebee et Osaka) parlez de 2 solutions différentes:

Brisebee:
Mon idée initiale est d’avoir un Arduino « central » que j’ai appelé « unité de gestion domotique » c’est cette unité de gestion qui est l’horloge du système et qui communique avec le monde extérieur via le web. Il y a suffisamment d’entrée/sortie disponibles sur cet Arduino, surtout si c’est un Méga pour commander directement un certain nombre d’actionneurs, s’il n’y a pas de problème de distance, (ce qui est mon cas, car j’ai un local technique et tout arrive là), les éléments qui peuvent être commandés directement, (fils pilotes de chauffage électrique, électrovannes d’arrosage, …)

Si je comprends bien un seul Arduino central :slight_smile:

Si je parlais de briques logicielles c'est justement d'avoir un pannel de fonctions que l'on choisit d'inclure ou non pour pouvoir composer notre système comme bon nous semble, un peu dans l'approche composants si certains connaissent

Osaka : Je suis plutôt d'accord avec tes arguments, mais si le maître du réseau tombe, tu n'as plus rien. Alors que si tu as un Arduino régulation (acquisition temp/regulation/action) d'un côté, un serveur web , un gestion des volets (avec boutons de secours), si un élément lâche rien n'est paralisé

Oliv4945:
De mon point de vue vous (Brisebee et Osaka) parlez de 2 solutions différentes:
Si je comprends bien un seul Arduino central :slight_smile:

Je pense aussi, enfin je sais plus trop maintenant comme on parlais modules j'hésite lol.

Oliv4945:
Si je parlais de briques logicielles c'est justement d'avoir un pannel de fonctions que l'on choisit d'inclure ou non pour pouvoir composer notre système comme bon nous semble, un peu dans l'approche composants si certains connaissent :stuck_out_tongue_closed_eyes:

Tu parle bien du pattern ?

Oliv4945:
Osaka : Je suis plutôt d'accord avec tes arguments, mais si le maître du réseau tombe, tu n'as plus rien. Alors que si tu as un Arduino régulation (acquisition temp/regulation/action) d'un côté, un serveur web , un gestion des volets (avec boutons de secours), si un élément lâche rien n'est paralisé

Attention on a bien dit que les modules devaient pouvoir être autonome donc oui une régulation dois avoir son composant temp, un module sorties doit avoir ses entrées (je n'ai jamais dit qu'on supprimais les interrupteur local par le contrôleur web par exemple, regarde bien le premier module I/O de mon schéma l’interrupteur poussoir y est ...) et tout ceci séparé des contrôleurs type web et autres non indispensable au bon fonctionnement de chaque modules.
En fait c'est ce que j'explique depuis le début, supprimer les dépendances dissociable mais pas tout non plus ... :sweat_smile:

Oliv4945:
si le maître du réseau tombe, tu n'as plus rien. Alors que si tu as un Arduino régulation (acquisition temp/regulation/action) d'un côté, un serveur web , un gestion des volets (avec boutons de secours), si un élément lâche rien n'est paralisé

Dans mon système actuel : Description du système domotique - Mon site perso : Guy SINNIG
Les unités de commandes fonctionnement en mode "dégradé" (manuel) même si l'unité de gestion est HS, simplement il n'y a plus de communication avec le PC (donc avec le web dans le futur) et le fonctionnement sur des plages horaires définies ne se fait plus.
Mais si on le juge utile on peut tout à fait mettre un Arduino dans certaines unités de commandes qui peuvent alors fonctionner de manière autonome, avec des données préchargées (par défaut), qui ne pourront être modifiées par le web que si l'unité de gestion fonctionne à nouveau.

osaka:
Attention on a bien dit que les modules devaient pouvoir être autonome donc oui une régulation dois avoir son composant temp, un module sorties doit avoir ses entrées (je n'ai jamais dit qu'on supprimais les interrupteur local par le contrôleur web par exemple, regarde bien le premier module I/O de mon schéma l’interrupteur poussoir y est ...) et tout ceci séparé des contrôleurs type web et autres non indispensable au bon fonctionnement de chaque modules.
En fait c'est ce que j'explique depuis le début, supprimer les dépendances dissociable mais pas tout non plus ... :sweat_smile:

Ok ce n'est pas ce que j'avais compris dans ton diagramme :wink:
donc sur le principe je suis d'accord avec vous, même si dans les faits, je n'ai qu'un seul uC qui fait tout :blush:
En fait ce qu'il faut voir c'est aussi la finalité et est-ce dramatique si ça plante :
pb soft => Watchdog, redémarrage, rechargement des paramètres en ligne et envoi de mail pour avertir
pb hard => mince, c'est tout cassé :slight_smile: Mais pour le chauffage par exemple (dans mon cas) si le chauffage est resté en Off, je met un pull 1H en rentrant chez moi, si bloqué en on de toute façon les thermostats de mes chauffages sont réglés légèrement au dessus de la consigne de chauffe.

En fait ce que j'essaie de dire en m'embrouillant, c'est que parfois il est plus embêtant de protéger quelquechose qui n'est pas critique plutôt que de corriger un problème tous les ans

Au fait Bisbee : Bravo pour l'installation :astonished:

Fascinant, je vous suis dans cette démarche domotique :slight_smile:

Oliv4945:
Ok ce n'est pas ce que j'avais compris dans ton diagramme :wink:

Même avec un dessin je suis nulle ? =( :sweat_smile: :grin:

Oliv4945:
donc sur le principe je suis d'accord avec vous, même si dans les faits, je n'ai qu'un seul uC qui fait tout :blush:
En fait ce qu'il faut voir c'est aussi la finalité et est-ce dramatique si ça plante :
pb soft => Watchdog, redémarrage, rechargement des paramètres en ligne et envoi de mail pour avertir
pb hard => mince, c'est tout cassé :slight_smile: Mais pour le chauffage par exemple (dans mon cas) si le chauffage est resté en Off, je met un pull 1H en rentrant chez moi, si bloqué en on de toute façon les thermostats de mes chauffages sont réglés légèrement au dessus de la consigne de chauffe.

En fait ce que j'essaie de dire en m'embrouillant, c'est que parfois il est plus embêtant de protéger quelque chose qui n'est pas critique plutôt que de corriger un problème tous les ans

Watchdog était prévu. :slight_smile:
Chauffage oki on peux s'en passé, je compte d'ailleurs m'en passé totalement pour mon projet maison passive (un jours ... $) =() :grin: .
C'est vrai que l'on a pas besoin de protéger à outrance mais si on peux l'évité c'est mieux non ? (1 fois par ans mais la prochaine c'est pour quand ?)
Disons que la fiabilité est un point essentiel pour moi, c'est ma vision personnel (pour un projet actuellement personnel) d'un système qui doit géré une installation domestique et non un sapin de noël.
Ici pour moi c'est aussi un plaisir d’étudier, optimisé et créer tout ça donc je joins l'utile à l'agréable, c'est aussi plus satisfaisant d'avoir fais son propre système plutôt que d'avoir dépensé 5-10k€ dans du tout fais comme pour le knx et autres . :wink:
Et puis de toute façon c'est moi qui ai la plus grosse, c'est pas discutable. :* :grin:

Oliv4945:
Au fait Bisbee : Bravo pour l'installation :astonished:

Aucun mérite il vient du futur. :grin:

Yep!

Je suis un peu surpris lorsque l'on parle de fiabilité qu'on arrive à multiplier les composants. On finit par multipier les probalités de pannes, c'est un non sens !!!
Lors de l'installation de deux composants identiques à un instant t, par exemple, il y a de fortes probabilités qu'ils développent les mêmes maladies au même moment, meurent le même jour.
Pour envisager du meilleur abord cet aspect et sans réellement parler du facteur économique, il reste deux solutions viables pour assurer une maintenabilité de l'installation (on n'echaperra pas à la panne), soit on envisage de doubler l'équipement maitre, soit on s'assure d'avoir un stock de pièce de rechange prés à l'emploi. Généralement, on prend en compte les deux aspects en fait, avec comme prérogative d'assurer une disponibilité maximale et de réduire au mieux les temps de dysfonctionnement.
Je pense que si l'on veut s'assurer du fonctionnement d'un élement, il faut envisager une technologie autre que l'élement de réference : un poste informatique peut contrôler le bon fonctionnement du programme arduino (et des modules intrasèques) grace à une communication relativement simple et fiable. L'arduino peut également vérifier que la communication est effective avec l'informatique et alerter l'usager. C'est un exemple simple !

Je trouve en l'état le projet fort complexe et quelques peu coûteux en définitive. J'ai même l'impression que la souplesse d'installation et d'utilisation s'en retrouvent pénalisées.

Je trouve l'initiative fort interessante et suis avec attention vos développements.
J'acquiesse avec enthousiasme sur le choix d'un bus Rs485 que j'utilise actuellement pour piloter mes cartes relais 8 canaux (8 relais/carte).
Le seul regret relatif à mes cartes et c'est peut être en définitive le fond du problème dans une installation domotique est de ne pas pouvoir interroger de l'état actuel d'un relais.
Je suis persuadé que si nous pouvions connaitre à chaque instant l'état de nos équipements, quelques soient leurs technologies, leurs non 'communicatitivités' initiales, nous balayerons d'une main tout problème, l'arduino, unique, officierait comme maître incontestable. Le système serait 'bouclé'(langage d'automaticien).
La domotique est une technologie communicante de fait, mais son attrait principal est de pouvoir bénéficier d'un meilleur contrôle de son habitation. Et ce 'meilleur contrôle' doit s'appliquer également à l'installation domotique elle-même.

@+

Zoroastre.

Oliv4945:
pb soft => Watchdog, redémarrage, rechargement des paramètres en ligne et envoi de mail pour avertir
pb hard => mince, c'est tout cassé :slight_smile: Mais pour le chauffage par exemple (dans mon cas) si le chauffage est resté en Off, je met un pull 1H en rentrant chez moi, si bloqué en on de toute façon les thermostats de mes chauffages sont réglés légèrement au dessus de la consigne de chauffe.

Comme cela a déjà été écrit par plusieurs d’entre nous, la fiabilité doit être le maître mot de notre projet.
Pour ce qui concerne la question du watchdog :
Je vois trois stratégies possibles (de la plus légère à la plus complexe)

  1. Exploiter pleinement les possibilités du watchdog du microcontrôleur ATMEL qui équipe les Arduinos, pour le moment je ne m’y suis pas encore intéressé.
  2. Le maître (pour moi l’ « unité de gestion domotique ») envoie à intervalles réguliers (toutes les secondes ou moins, car pour un système domotique le temps de réponse n’est pas un vrai problème, quelques dixièmes de secondes voire la seconde est bien suffisant), une séquence simple mais bien identifiable. Si au bout d’un temps égal à 2 ou 3 fois le temps de cycle de l’envoi de la séquence, les différentes unités de commandes n’ont pas reçues cette séquence, elles passent en mode dégradé, en utilisant leurs paramètres internes (par défaut).
  3. Un système de watchdog entièrement matériel (j’avais fait cela pour un système d’accès sécurisé, il y a une bonne dizaine d’années) : une horloge envoi une impulsion toutes les quelques dixièmes de secondes sur un fil spécifiquement prévu à cet effet ou sur les fils utilisés pour la communication, mais alors, il faut pouvoir identifier cette impulsion (par exemple une seule impulsion très longue) par rapport aux signaux standards utilisés pour la transmission des informations. Si les unités de commande n’ont pas reçu de signal au bout de là aussi 2 ou 3 cycles d’horloge, les unités de commandes se mettent en mode dégradé, c’est probablement le procédé le plus sécure, mais aussi le plus compliqué à mettre en place car il faut soit un câblage spécial, soit concevoir une partie matérielle spécialement.
    A voir, là encore il ne faut pas surdimensionner le système.

Je suis avec beaucoup d'intérêt la gestation de votre projet bien que n'ayant pas de connaissances sur les protocoles de communication.
Je me permet de faire une remarque : si vous voulez que votre solution soit mise en oeuvre par le plus grand nombre il ne faut pas perdre de vue le coût financier. Je n'ai pas dis que c'est une priorité, absolument pas, mais il ne faut pas le reléguer à la fin du projet.

Si dans ce qui suit j'ai écrit des cnn**ies merci de le signaler.

Je pense en particulier à la multiplication des "arduino" ---> les apostrophes ne sont pas là par hasard.
Sérialiser les fonctions est souvent le moyen le plus sûr d'atteindre le but : facilité de conception et de mise au point séparées, mais 10 "arduino" à 25€ cela fait 250 € !
Remarque préventive : rien ne permet de prévoir les variations de cours $/€/Huan dans les mois qui viennent, donc les arduino à 13€ sur Ebay -> ???????

Proposition :
La faisabilité sur breadbord d'un montage à base ATMega328P n'est plus à démontrer. Un montage propre sur plaquette pastillée ne devrait pas dépasser 5 à 8 €, avec en jocker le choix du micro le mieux adapté dans la gamme de la spec commune aux 48, 88, 168, 328.
Cerise sur le gâteau : faut-il un quartz ? l'oscillateur interne n'est-il pas suffisant ?

Mais cela impose pratiquement l'abandon du bus USB et la programmation en ISP (d'où le grand intérêt pour le sujet de Jean-Marie http://arduino.cc/forum/index.php/topic,78754.0.html). Les micro n'ont plus besoin de bootloader d'où les coût moins élevés.

Conséquences :
Cela restreint le choix des protocoles de communication.
Est-ce acceptable ?
Est-ce trop tôt pour se poser la question?

Je n'en sais rien mais je vous soumet la question.

Bonne continuation et, comme je l'ai lu et que j'ai trouvé très bien, pas bon courage mais beaucoup de plaisir.
Au plaisir de continuer à vous lire.

zoroastre:
Yep!

Je suis un peu surpris lorsque l'on parle de fiabilité qu'on arrive à multiplier les composants. On finit par multipier les probalités de pannes, c'est un non sens !!!

Pas vraiment d'accord. :~
Je suis d'accord sur le fait de multiplier les composants multiplie les probabilités de pannes (logique), mais ici nous nous parlons de pannes locale à 1 ou n composants, panne contrôlée et facilement identifiés, le fait qu'un composant (indépendant) sois en panne n’empêche pas les autre de fonctionné.
J'utiliserai comme analogie le développement orienté objet qui a pour but de supprimer aux maximum les dépendances entre objets ,un objet n'entraine pas l'autre dans son erreur, sauf si lié (voir uml composition-agregation), la raison d'être de ce type de développement est justement la fiabilité , différent paterne on été étudier pour supprimer ses dépendance et c'est ce que j'applique ici.
Dans cette analogie j'en veux pour preuve le langage java (objet strict), langage le plus utilisé en entreprise pour ça fiabilité objet.
Edit: je viens de penser à une autre analogie propre au développement arduino, imagine les lib (Ethernet, spi, stepper, ...) toute dans un seul fichier, un seule classe ... :cold_sweat:
Une autre analogie pour le cas contraire serait la voiture par exemple dont tout composants s'articule autour d'un seul composant le bsi (on vas le comparé à la solution 1 arduino), c'est lui seul qui actionne et gère le bon fonctionnement de chaque composants genre interrupteur qui commande une vitre via celui-ci, he be rien que l'autoradio peux mettre toute la voiture en rade (déjà vu).

zoroastre:
Lors de l'installation de deux composants identiques à un instant t, par exemple, il y a de fortes probabilités qu'ils développent les mêmes maladies au même moment, meurent le même jour.

Là je suis d'accord, déjà eu le cas par exemple avec deux disque dure identique acheté aux même moment et en panne à 2 jours d’intervalle 2 ans plus tard ... =(

zoroastre:
Pour envisager du meilleur abord cet aspect et sans réellement parler du facteur économique, il reste deux solutions viables pour assurer une maintenabilité de l'installation (on n'echaperra pas à la panne), soit on envisage de doubler l'équipement maitre, soit on s'assure d'avoir un stock de pièce de rechange prés à l'emploi. Généralement, on prend en compte les deux aspects en fait, avec comme prérogative d'assurer une disponibilité maximale et de réduire au mieux les temps de dysfonctionnement.

Déjà prévu et pensé également, doubler le composant maître et autres comme un arduino mini par exemple ou contrôleur format dip qu'il suffirait juste d'enfiché sur pcb (du module complet) comme on l'aurais fais avec un fusible dans le coffret divisionnaire.

zoroastre:
Je pense que si l'on veut s'assurer du fonctionnement d'un élement, il faut envisager une technologie autre que l'élement de réference : un poste informatique peut contrôler le bon fonctionnement du programme arduino (et des modules intrasèques) grace à une communication relativement simple et fiable. L'arduino peut également vérifier que la communication est effective avec l'informatique et alerter l'usager. C'est un exemple simple !

Possibilité d'avoir un arduino ou autre également comme cerbère du système, c'est tout à fais envisageable.

zoroastre:
Je trouve en l'état le projet fort complexe et quelques peu coûteux en définitive. J'ai même l'impression que la souplesse d'installation et d'utilisation s'en retrouvent pénalisées.

Je trouve aux contraire qu'il est fort simple et surement beaucoup plus simple que développé une solution en 1 seul bloc et devoir géré le tout en même temps (debug, collision,..) , je préfères réglé 10 problème 1 par 1, étape par étape, que d'essayé le tout en 1 fois.
N'oublions pas non plus qu'il sagit d'une installation domestique, pas d'une guirlande de noël, on y trouve pas la même complexité évidement.
Pour le couts lorsque je compare aux solution professionnel qui prévois qu'une installation complète peux aller de 10 à 15% :astonished: de la valeur du bien, je me dis que la solution évoqué ici est dérisoire ...

zoroastre:
J'acquiesse avec enthousiasme sur le choix d'un bus Rs485 que j'utilise actuellement pour piloter mes cartes relais 8 canaux (8 relais/carte).
Le seul regret relatif à mes cartes et c'est peut être en définitive le fond du problème dans une installation domotique est de ne pas pouvoir interroger de l'état actuel d'un relais.
Je suis persuadé que si nous pouvions connaitre à chaque instant l'état de nos équipements, quelques soient leurs technologies, leurs non 'communicatitivités' initiales, nous balayerons d'une main tout problème, l'arduino, unique, officierait comme maître incontestable. Le système serait 'bouclé'(langage d'automaticien).

Oui le rs-485 semble être la solution la plus adapté et utilisé (confiance).
Ici le bus sera communiquant (logique d'un côté :grin:), donc l'état de chaque modules sera communiqué en temps réel par action à un module contrôleur genre web ou en local au module (donc possibilité de bdd et autres par exemple).

zoroastre:
La domotique est une technologie communicante de fait, mais son attrait principal est de pouvoir bénéficier d'un meilleur contrôle de son habitation. Et ce 'meilleur contrôle' doit s'appliquer également à l'installation domotique elle-même.

un meilleur contrôle de chaque composante de son habitation je dirais et quoi de mieux que le fait de pouvoir contrôler facilement chaque composante de l’installation domotique elle-même indépendamment des l'un des autres ?
J'appliquerais le proverbe "chercher une aiguille dans une botte de foin" ici.

Je conçois que cette façon de voir peux paraître déroutante, illogique, usine à gaze, etc, qu'on peux se dire "pourquoi faire simple quand on peux faire compliqué" (j'y vois le contraire), mais comme je l'ai déjà dit je n'ai rien inventé je ne me base que sur de l'existant, solutions testé et éprouvées depuis longtemps, ça fait plusieurs année que je m’intéresse aux sujet et ça a même été le sujet principal de mon travail de fin d'études (développement d'une application modulaire serveur de domotique en java).
Je ne critique pas tes propos et suggestions qui sont interessant, elles permettent le débats et l’évolution du projet. :wink:

68tjs:
Proposition :
La faisabilité sur breadbord d'un montage à base ATMega328P n'est plus à démontrer. Un montage propre sur plaquette pastillée ne devrait pas dépasser 5 à 8 €, avec en jocker le choix du micro le mieux adapté dans la gamme de la spec commune aux 48, 88, 168, 328.
Cerise sur le gâteau : faut-il un quartz ? l'oscillateur interne n'est-il pas suffisant ?

Mais cela impose pratiquement l'abandon du bus USB et la programmation en ISP (d'où le grand intérêt pour le sujet de Jean-Marie http://arduino.cc/forum/index.php/topic,78754.0.html). Les micro n'ont plus besoin de bootloader d'où les coût moins élevés.

C'est la solution que j'envisage normalement pour réduire le cout et donner un côté "professionnel" au projet, la communauté arduino est assez grande pour l'envisagé même pour un non initié comme moi. :slight_smile:
Le côté financier est à prendre en compte évidement, mais quand je vois le nombre de personnes capable de dépensé des k € dans des solutions professionnel comme le knx ou d'autre acheté des modules x10, plc-bus, ... coutant dans les 30-50€ par module rien que pour allumé une lampe et je parles pas du prix des différent contrôleur de ce type de système pouvant grimper dans les 300€ par technologies différente (contrôleur pour énergie électrique+contrôleur pour les sonde+ ...) :sweat_smile:
Tout dépend de l’intérêt de la chose également, juste faire joujou ou vraiment y trouvé une utilité ?

68tjs:
Conséquences :
Cela restreint le choix des protocoles de communication.
Est-ce acceptable ?
Est-ce trop tôt pour se poser la question?

Je n'en sais rien mais je vous soumet la question.

Bonne continuation et, comme je l'ai lu et que j'ai trouvé très bien, pas bon courage mais beaucoup de plaisir.
Au plaisir de continuer à vous lire.

Bonne et légitime question, faudra bien y pensé un jours de toute façon, enfin pour le protocole (échange de données entre modules) il ne dépendra pas du moyen de transmission (rs-232<->rs-485 facilement adaptable au différente plateforme normalement ). :grin:
Plaisir j'en ai déjà, je frétille comme un poisson accroché à un hameçon rien que dans la conception du projet. :grin:

Yep!

Je comprends parfaitement les avantages d'une topologie que l'on pourrait comparer une architecture neuronale.
L'analogie avec les langages de programmation est bien dite également.

Cependant, outre les problèmes de communications que vous aurez à résoudre (principalement le gestion des erreurs, travail le plus fastidieux), il faut également se positionner en tant que dépanneur éventuel et prendre le partie de l'actionneur.
Imaginons qu'une sonde de luminosité allume à un seuil prédefini une ampoule. Cette ampoule est neuve et ne s'allume pas. Comment remonter facilement à l'élement défectueux si le nombre d'intermédiaire est multiple. On pourrait incriminer l'ampoule, la sonde, l'arduino esclave, l'arduino maître ou encore la communication (double ici), sans parler des fils, le truc dont on pense en dernier...

Si on compare le système envisagé avec un automate industriel, il manque ce que l'on appelle le bouclage des sorties. Automatique — Wikipédia
Cette fonction renseigne sur le bon fonctionnement de l'actionneur.
On pourrait appuyer le concept de la communication entre arduino, avec des checks réguliers des entrées/sorties.
Mais en définitive en poussant cette reflexion, si on est parfaitement renseigné sur l'état des systèmes distants, une seule voir deux arduino suffisent amplement.

Dans mon exemple précité, il serait simple de mettre un place un élement qui contrôlerait le bon fonctionnement de l'ampoule. Mais on se retrouve du coup avec une entrée en plus à gérer et une probabilité de défaillance supplémentaire. Pas sur que ce soit mieux !
L'avantage des automates dans leur gestion est qu'il est le seul élement qui renseigne sur l'état des entrées/sorties, c'est relativement lisible et rapide.

A mon idée et afin d'être plus performant dans une gestion automate/domotique, le retour d'état est indispensable, fusse-t'elle seulement du point de vue de l'alimentation.
Exemple : L'arduino par le bus envoie un ordre à la partie commande de l'actionneur, celle-ci passe à l'état d'alimentation (genre relais, opto-triac, etc) et renvoie par le biais d'un fil supplémentaire une information digitale (c'est alimenté ou pas) en plus d'une del local.
C'est à mon sens, la gestion la plus simple et la plus rigoureuse du point de vue actionneur. On en revient à une entrée supplémentaire à gérer certe (mais sans technologie supplémentaire :wink: ).

Je regrette beaucoup que nombre de solutions ne prenne pas en compte cette aspect, tant il est important. Et in fine, lorsque nous commandons une lampe, un moteur, un radiateur, un volet, c'est toujours à l'aveugle...

@+

Zoroastre.

zoroastre:
Cependant, outre les problèmes de communications que vous aurez à résoudre (principalement le gestion des erreurs, travail le plus fastidieux), il faut également se positionner en tant que dépanneur éventuel et prendre le partie de l'actionneur.
Imaginons qu'une sonde de luminosité allume à un seuil prédefini une ampoule. Cette ampoule est neuve et ne s'allume pas. Comment remonter facilement à l'élement défectueux si le nombre d'intermédiaire est multiple. On pourrait incriminer l'ampoule, la sonde, l'arduino esclave, l'arduino maître ou encore la communication (double ici), sans parler des fils, le truc dont on pense en dernier...

Pour le cas ici on procèderais assez facilement par élimination et déduction, voir si l'ampoule est valide sur un autre support (un défaut de fabrication par exemple) ça prend 30 sec, si plus rien ne répond peut être l'alim vite diagnostiqué avec une diode d’état par exemple, si les autres esclaves réponde correctement c'est que le maître et bus fonctionne correctement même pas besoin de se déplacé, si le module répond via commande locale par bouton poussoir par exemple pour ce cas ci (n'oublions pas qu'ils doivent être autonome également) c'est qu'il fonctionne donc on peux incriminé la partie sonde ou bus, etc, etc, on continue étape par étape en descendant de niveau.
Dans un système combiné tout en un, la déduction est quand même moins aisée comme un problème peut venir d'un autre composant combiné directement (moins visible) de ce module, il me semble ?
Enfin on aura beau prendre le maximum de précaution le risque 0 n'existe pas de toute façon et il y aura surement des avantage et inconvénients par rapport à d'autre système.
Ici j'essaie seulement de répondre à un cahier des charges sur des réflexions personnel.

zoroastre:
Si on compare le système envisagé avec un automate industriel, il manque ce que l'on appelle le bouclage des sorties. Automatique — Wikipédia
Cette fonction renseigne sur le bon fonctionnement de l'actionneur.
On pourrait appuyer le concept de la communication entre arduino, avec des checks réguliers des entrées/sorties.
Mais en définitive en poussant cette reflexion, si on est parfaitement renseigné sur l'état des systèmes distants, une seule voir deux arduino suffisent amplement.

Dans mon exemple précité, il serait simple de mettre un place un élement qui contrôlerait le bon fonctionnement de l'ampoule. Mais on se retrouve du coup avec une entrée en plus à gérer et une probabilité de défaillance supplémentaire. Pas sur que ce soit mieux !
L'avantage des automates dans leur gestion est qu'il est le seul élement qui renseigne sur l'état des entrées/sorties, c'est relativement lisible et rapide.

A mon idée et afin d'être plus performant dans une gestion automate/domotique, le retour d'état est indispensable, fusse-t'elle seulement du point de vue de l'alimentation.
Exemple : L'arduino par le bus envoie un ordre à la partie commande de l'actionneur, celle-ci passe à l'état d'alimentation (genre relais, opto-triac, etc) et renvoie par le biais d'un fil supplémentaire une information digitale (c'est alimenté ou pas) en plus d'une del local.
C'est à mon sens, la gestion la plus simple et la plus rigoureuse du point de vue actionneur. On en revient à une entrée supplémentaire à gérer certe (mais sans technologie supplémentaire :wink: ).

Je regrette beaucoup que nombre de solutions ne prenne pas en compte cette aspect, tant il est important. Et in fine, lorsque nous commandons une lampe, un moteur, un radiateur, un volet, c'est toujours à l'aveugle...

100 % d'accord le retour d'état est pour moi également quelque chose de primordial et participe à la fiabilité du système, suffisamment primordial pour sacrifié des entrée numérique comme dans ton exemple, c'était la raison principal de l'utilisation des websocket (communication full-duplex me permettant d'avoir un retour d’état en "presque" temps réel) dans mon autre projet avec le shield ethernet.
Concernant l'automate et bouclage de sortie, Brisebee doit surement en savoir plus sur le sujet que moi :sweat_smile:, mais ça parait très intéressant :slight_smile: .