Aidez nous ! Projet - Gestion domotique

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

La question de la boucle de retour est un sujet primordial en automatisme, mais il faut savoir de quoi on parle et pour quoi faire. Je ne m’étendrai pas sur les systèmes bouclés du type asservissement ou régulation, de vitesse ou de positionnement, il y a de très nombreuses théories et publications sur ce thème, et avec les systèmes numériques ont encore modifié les choses. Mais revenons à notre sujet.
Pour ce qui concerne la domotique, il faut, je pense prendre les différentes situations une à une, et d’une manière tout à fait pragmatique, voir ce qu’il en est.
Par exemple pour l’éclairement si on allume une lampe, le capteur doit le détecter, c’est peut-être suffisant, si on commande une électrovanne d’arrosage, le capteur de pluviométrie, à condition qu’il soit placé au bon endroit, doit le détecter, alors faut-il asservir le système, à savoir fermer l’électrovanne s’il y a assez d’eau avec une relative précision, ou s’il suffit de mettre des seuils, en dessous du seuil bas on ouvre l’électrovanne à l’heure déterminée et pour un certain temps et au dessus on ne l’ouvre pas. Pour les volets roulants (par exemple sur ma porte de garage), il suffit de mettre un capteur du type microswitch ou contact d’alarme, si le capteur est activé, cela signifie que volet est baissé, si le capteur est, désactivé c’est qu’elle est ouverte, je pense que là encore, ce sera bien suffisant.
Ainsi en prenant fonction par fonction, chacun pourra prendre la décision, de mettre un capteur ou pas, pour en tenir compte dans l’automatisation, ou pas. Mais ne faisons pas des choses trop compliquées, qui ne serviront pas à grand-chose !
Dans d’autres situations, il faudra peut-être des boucles de retour plus élaborées.

Avant d’aller beaucoup plus loin dans la discussion des solutions techniques
Je pense qu’il faudrait que chacun de ceux qui sont réellement intéressés par ce projets décrivent les fonctions qu’ils souhaitent, peut-être avec un niveau d’importance.
Ce qui permettrait :

  1. de voir les convergences et les divergences en terme de fonctionnalités
  2. de définir des fonctionnalités commune (et d’autres optionnelles ou personnelles)
  3. de faire des choix technologiques en fonctions des discussions précédentes (et futures)
  4. de donner des idées

Je vous ferai très prochainement un descriptif des fonctionnalités que je souhaite.

Oulaaa ! Je n'étais pas là hier, et je vois que de l'encre a coulée depuis, c'est bon signe :slight_smile:

Première remarque :
La surveillance du système (watchdog), il ne faut pas faire une usine a gaz non plus, il faut que cela reste relativement simple et pour cela l'idée que j'avais était le capteur de luminosité.

Exemples :
J'ouvre le volet , la luminosité augmente sinon problème
Je ferme le volet, la luminosité diminue sinon problème
J'allume une lumière , la luminosité augmente sinon problème
Je ferme le volet, la luminosité diminue sinon problème
L'avantage d'ajouter un capteur de luminosité, (fermeture et ouverture automatique des volets et des lumières en fonction de la luminosité possible)
Maintenant le chauffage on compare la valeur de la température actuelle avec la valeur précédente si trop d'écart problème, on définit une plage (0 à 30°) en dehors de cette plage problème
Savoir si une prise c'est allumée, on créer une tension image de la sortie du relais ou triac, si on allume une prise et que pas d'image en retour problème et vice versa
Voila pour moi cela suffit amplement

Deuxièmement :
Le nombre d'arduino a utiliser ne doit pas être figé car il sont sur un bus, ce qu'il faut ces que chacun puisse choisir les modules de sont choix et les mettre sur l'arduino de sont choix (température, éclairage, arrosage, volets, ...) et qu'il puisse les intégrer très facilement, je grossis un peu la chose mais un truc du genre :
void loop (
GestionTempératures();
GestionEclairages();
GestionVolets();
)

Troisièmement :
Le choix des technologies :

  • Communication inter arduino - RS425 je pense qu'il a fait l'unanimité
  • 1 arduino maître - 1 arduino (accès pc et web) - X arduino pour le reste

Il reste a définir l'acheminement des données pour les capteurs et actionneurs analogiques et numériques qui a mon avis est l'étape la plus importante maintenant avant d'aller plus loin

Quatrièmement :
Je suis content de voir que je ne serais pas tout seul sur le projet

Voici les fonctions dont j’ai besoin avec un niveau d’importance :

  1. Commande fil pilote chauffage 1 ordre : 0VAC ou 220VAC Selon des plages horaires et si pas EJP
    très important
  2. Commande fil pilote chauffage 6 ordres : 0VAC ou 220VAC (ou partie signal ?) Selon des plages horaires et si pas EJP
    important
  3. Commande arrosage : 0VAC ou 24VAC Selon des plages horaires et si pas de pluie
    très important
  4. Commande volet (porte de garage) : 0VAC ou 220VAC Montée : 0VAC ou 220VAC Descente si pas d’obstacle
    important
  5. Visualisation état porte de garage : Visualisation sur tablette (ou PC)
    important
  6. Commande volets : 0VAC ou 220VAC Montée; 0VAC ou 220VAC Descente; en fonction de l’ensoleillement
    important
  7. Mémorisation alarme : Mémorisation heure mise en route ou arrêt alarme (quand et quelle zone ?)
    très important
    8 ) Mémorisation jours EJP : Mémorisation pour traitement et affichage
    important
  8. Mémorisation coupures secteur : Mémorisation pour traitement et affichage
    important
  9. Commande éclairage : 0VAC ou 220VAC Selon des plages horaires et selon éclairement
    peu important
  10. Visualisation température : Visualisation sur tablette (ou PC) température d’une pièce
    peu important

c'est mieux sous forme d'un tableau (je joints le doc)
On pourra ainsi voir quelles fonctionalités nous souhaitons avoir, en faisant une synhtèse des différents besoins.
Dites moi si vous êtes OK avec ma démarche, sinon proposez en une autre pour que nous puission avancer.

Oups, j'ai oublié de joindre le tableau

tableau fonctions.doc (33.5 KB)

C'est top, ton tableau donne matière à réfléchir. :open_mouth:
Surtout ce qui concerne la mémorisation de données, le temps et plage horaire, scénarios.
Va falloir faire du cas par cas et qu'on ce triture les méninges. :grin:
Pour ma liste à moi ça serait que du classique pour commencé sans vraiment de priorité (fonctionnel ça serait déjà bien :P).

  • 220v éclairages/prises
  • volet roulant
  • alarme
  • température, humidité, ensoleillement, ...

tien, tu donnes une grosse priorité à l’arrosage, pelouse, potagé, champs de maïs, marie-jeanne :grin: ... ?

Yep!

Considerons que nous n'avons pas tous les mêmes maisons, je commencerais par les ponts communs ;

  1. Chauffage ++

  2. Volets roulants ++

  3. Alarme +

  4. Eclairages. +

...

  1. Eclairages exterieurs +
  2. Garage (porte) 0
  3. Jardin -

Et pourquoi pas,

  1. diffusion musique
  2. interphonie (J'ai une maison de 62000 m2 $) )

Pour ma part, peu importe le mode de communication, ethernet, tablette, télécommande, il en faut au moins un.
L'ethernet me semble être le choix minimal.

@+

Zoroastre.

osaka:
tien, tu donnes une grosse priorité à l’arrosage, pelouse, potagé, champs de maïs, marie-jeanne :grin: ... ?

J'habite en Provence et j'ai un grand terrain dans la colline, si je n'arrose pas d'avril à octobre tout jauni et crève, c'est pour cela que j'ai 10 électrovannes.

Mais techniquement l'arrosage ne pose pas de problème : suivi de plages horaires, éventuellemnt modifiées en fonction des saisons et de la pluviométrie, pas la peine d'arroser les jours de pluie ou d'orage (même s'il ne pleut pas souvent).

Pour le chauffage, il faudrait préciser quelle type de commande(s) et de capteur(s).