Aidez nous ! Projet - Gestion domotique

International Français
#1

Tout d'abord bonjour a tous. J'ai 27 ans, j'ai fait des études en informatique industrielle mais j'ai changé de voie. J'ai donc de bonne bases en C,C++, HTML, PHP.

Je vous sollicite car je souhaiterais réalisé un projet domotique afin de pouvoir réaliser plusieurs choses au sein d'une pièce de ma maison à savoir :

  • Mesure de la température et sauvegarde cyclique des données pour exploitation( par la suite peu être une gestion du chauffage par pièce )
  • Mesure de la luminosité de la pièce et sauvegarde cyclique des données pour exploitation
  • Détection de présence dans la pièce
  • Allumage commandé de la lumière tout en gardant un contrôle manuel
  • Prises électriques commandées tout en gardant un contrôle manuel
  • Mesure de la consommation électrique d'une pièce et sauvegarde cyclique des données pour exploitation ( par la suite la mesure s'effectuera pour toute les pièces )
  • Possibilité de créer des scénarios et de simuler une présence en cas d'absence prolongée

Les informations de l'arduino seront échangés avec un serveur web qui permettra de lire les valeurs et d'envoyer les ordres a l'arduino. Je souhaite que le serveur web ne soit pas programmer dans un langage "exotique" car je veut qu'il soit interpréter par ma freebox révolution afin de pouvoir me servir de ma télé comme centre de contrôle principal ou encore par un téléphone portable avec un accès internet de plus je souhaite que chacun puisse profiter du projet afin de réaliser quelque chose de similaire.

Je vais donc commencer par ma première question de ce projet :

De quoi ais-je besoin ? Quel arduino ? ( "arduino ethernet" ou "arduino + un shield ethernet" et pourquoi ?) Quel capteur de température ? ( un capteur pas cher, facile a mettre en oeuvre avec une précision de 0,1°C ) Quel capteur de présence ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel capteur de luminosité ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel capteur pour la consommation électrique ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel type de relais commandé ? ( un module en kit du commerce, un montage électronique)

Merci d'avance pour vos réponses.

#2

Bonjour, J'avais une fois rassemblé quelques postes concernant la domotique, ça pourra peut être t’aiguiller un peux pour la partie arduino-web et domotique.

http://arduino.cc/forum/index.php/topic,75687.msg571513.html#msg571513

sur mon club-elec

http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ArduinoInitiationBP http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ArduinoInitiationCommandePuissance http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ArduinoExpertCan http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.MaterielInterfaceONOFFSingleRelaisDFRobot http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.MATERIELCapteurOnOffIRDetecteurMouvementSparkfun http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.MATERIELCapteurIRGrayScaleSensorDFRobot

. . .

#3

Répondre à tes questions c'est faisable, répondre efficacement est plus difficile.

Pour commencer as tu commencé a te documenter ? Il y a deux sources à consulter en priorité : ici même le guide Arduino qui renvoie sur des nombreux articles et sites intéressants et le playground Arduino . Une fois ce travail préalable effectué tu sera en mesure de poser des questions beaucoup moins générales et il sera plus facile de répondre efficacement.

J'ai une remarque sur tes besoins en capteurs : pas chers, facile à mettre en oeuvre et précis. Ma traduction amusée : le beurre, l'argent du beurre et le sourire de la crémière. :grin:

Regardes bien tes besoins par exemple capteur de température précis à 0,1 °C : est-ce utile ? Et que veux dire précis ? --> valeur exacte en absolu --> à part pour un centre officiel de météorologie quel intérêt ? --> valeur reproductible on dit aussi "fidèle" --> ce qui veut dire : mis dans les mêmes conditions de température, même à des semaines d'écart, le capteur donnera la même indication, cette indication pouvant par ailleurs être décalée de 0,3 ou 0,5°C en absolu. Cette dernière conception est beaucoup plus utile. Tiens compte aussi que la mise en oeuvre d'un capteur, quel qu'il soit, est tout aussi importante que ses performances intrinsèques.

Autre point : Tout à fait d'accord avec toi pour commencer petit avec une seule pièce et étendre à la maison tout entière par la suite. Néanmoins pour éviter de te retrouver dans une impasse gardes toujours un oeil sur le nombre d'entrées et de sorties nécessaire. Dès fois un peu de réflexion au départ du projet permet de diminuer le nombre d'E/S nécessaires. Exemple personnel : j'ai trois afficheurs à commander soit 3*7=21 segments. solution 1 : utiliser 21 broches --> c'est idiot. solution 2 : utiliser des décodeur BCD/7 segments ce qui revient à utiliser 12 broches -> c'est mieux mais pas encore optimisé. solution 3 : utiliser trois registres à décalage (8bits) chaînés ce qui revient à utiliser 2 broches, Horloge et Data, et une troisième facultative pour le latch -> 3 c'est mieux que 21, cela demande juste un peux plus de complication logicielle. C'est bien sur un exemple très basique mais c'est ce genre de réflexion à mener au début d'un projet avant de foncer bille en tête.

Gardes aussi un oeil sur les broches utilisées par les extensions ('"shields"). Jouer au Lego en empilant les "shields" c'est pratique mais du coup c'est souvent mal documenté et il faut lire les bibliothèques associées pour connaître le nombre et les références des broches utilisées.

#4

Je me suis déjà beaucoup documenté sur l'arduino.

Ma première question pour travailler avec l'ethernet : arduino ethernet ou arduino + ethernet shield, il y a t'il une différence importante ?

Pour le capteur cela sera la définition que tu appels "fidèle" Pour le capteur pas chers, facile à mettre en oeuvre et précis j'entends par la un capteur qui dispose d'une librairie pour arduino (facilité de mise en oeuvre), pas chers (bon rapport qualité prix)

Je veux d'abord bien me focaliser sur une pièce et après pour étendre a la maison : un arduino par pièce (pas très économique) ou multiplexage (plus compliqué a mettre en œuvre et encore mais beaucoup plus rentable)

Donc pour ceux qui ont déjà travaillé avec ces différents types de capteurs lesquels avez vous utilisés et pourquoi ?

#5

Skuzmitoo: ... Je vais donc commencer par ma première question de ce projet :

De quoi ais-je besoin ? Quel arduino ? ( "arduino ethernet" ou "arduino + un shield ethernet" et pourquoi ?) Quel capteur de température ? ( un capteur pas cher, facile a mettre en oeuvre avec une précision de 0,1°C ) Quel capteur de présence ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel capteur de luminosité ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel capteur pour la consommation électrique ? ( un capteur pas cher, facile a mettre en oeuvre ) Quel type de relais commandé ? ( un module en kit du commerce, un montage électronique)

Merci d'avance pour vos réponses.

Bonjour Il y a pas mal de post sur ce sujet en ce qui me concerne je vais me limiter pour l'instant aux capteurs

Quel capteur de température ? ( un capteur pas cher, facile a mettre en oeuvre avec une précision de 0,1°C ) des capteurs T° pas chers et facile à mettre en œuvre avec une precision de 0.1 °C c'est moins évident qu'il n'y parait :grin: avec une résolution de 0.1°C c'est déjà plus simple (LM35 en ana , ds18B20 en num par exemple)

Quel capteur de présence ? ( un capteur pas cher, facile a mettre en oeuvre ) un capteur IR qui sort en contact sec ou en collecteur ouvert (exemples) http://www.electronique-diffusion.fr/product_info.php?products_id=61490 http://www.selectronic.fr/module-de-detection-de-presence.html

Quel capteur de luminosité ? ( un capteur pas cher, facile a mettre en oeuvre ) une bonne vieille LDR à 0,20 € XD

Quel capteur pour la consommation électrique ? ( un capteur pas cher, facile a mettre en oeuvre ) C'est peut être le capteur le plus "compliqué" à dimensionner, simple shunt et redressement, ou couplage , a rediscuter plus tard

#6

LM35 en ana , ds18B20 en num

Ok, cela sera donc le LM35 pour la facilité de mise en oeuvre (utilisation du can de l'ATM et le prix XD) je verrais quand tout sera fonctionel pour les ds18B20 en One Wire.

#7

Pour arduino ethernet ou arduino+ ethernet shield c'est kif kif le premier est le deuxième tout intégré, peut être prendre les deux séparé pour commencé tout dépend des tes moyens plutôt. Pour ma part je suis quand même fortement déçus du shield ethernet, en temps que serveur de sockets ou comme client web ça va mais comme serveur web on est vite fortement limité (4 connexion simultanée, mémoire, ...). J'ai déployé ma propre solution mais ce n'est toujours pas vraiment satisfaisant à mon gout http://arduino.cc/forum/index.php/topic,72035.0.html, trop de dépendance et surtout les websockets qui n'arrête pas de bouger encore niveau standardisation. Pour ma part je préconise plutôt serveur web normal genre nas ou plugcomputer ou autre et communication série par exemple avec l'arduino pour les commandes. Concernant les limite E/S je préconise également pour ma part la multiplication d'arduino, non pas par pièce mais par traitement, capteur (températur, luminosité, gestion de l'énergie (lumière, gradateur, prises, volet, ...), alarme, ..., chacun sa propre fonction et interconnecté via bus http://fr.wikipedia.org/wiki/Bus_de_terrain avec protocole maison, similaire aux automates programmable.

#8

merci pour ce complément d'information, je comptais l'utiliser en client web pour envoyer et recevoir les données car en effet le serveur web est limité d'une part par ce que tu viens de cité et d'autre part par la mémoire disponible. En effet j’envisageais un multiplexage par type de capteur.

#9

Bonjour, j'ai plus ou moins le même projet, donc je peux essayer de te donner mon point de vue.

Comme le dis 68js, mieux vaut commencer petit et rajouter brique par brique :)

Pour le matériel j'ai pris un 1280 il y a un petit moment comme ça j'ai pas mal d'IO et de place RAM/ROM pour développer mes projets et je les passe sur plus petit si possible une fois terminés. Du coup c'est forcément un shield pour l'ethernet.

Pour la mesure de température j'ai un LM35 avec un AOP pour augmenter la résolution. Mais bon j'ai pris ce que j'avais comme AOP du coup j'ai un gros offset. Si c'était à refaire je pense que je prendrais directement des 18B20 ça ne coute pas forcément plus chère et moins d'aspects CEM.

Comme dit pour la luminosité un LDR ça va très bien, pour la consommation je vais mettre un montage téléinfo sur le compteur EDF, juste pour vérifier que mon chauffage électrique commute bien quand je lui demande. Si tu as besoin de plus précis peut-être regarder du coté des pinces ampèremétriques il y a eu un sujet dessus il n'y a pas bien longtemps

Pour la partie commande j'ai des relais 300W, mais pour tout ce qui est chauffage j'ai utilisé des modules domotique RF avec le protocole HomeEasy qui est connu, marque chacon ou DI-O. ça permet de ne pas jouer avec la puissance et au final un pack 3 prises+télécommande=25€. Pour le moment j'ai soudé l'Arduino sur la télécommande mais je devrais recevoir un émetteur pour pouvoir garder la télécommande en secours.

Pour la partie interface tout est sur un serveur web en PHP/mysql/javascript mais comme le dit Osaka un petit serveur en local avec une connexion série c'est ce qu'il a de mieux, surtout quand la freebox fait des siennes… J'attends les Rasbery PI :)

#10

Bonjour,

Je profite de ce sujet de forum pour vous parler de mon projet, qui globalement ressemble à celui projeté par Skuzmitoo. J'ai conçu et réalisé un système domotique, il y a déjà pas mal de temps (1994), vous trouverez un bref descriptif ici :http://g.sinnig.free.fr/spip.php?article3 J'ai prévu de remplacer ce système par un dispositif à base d'arduino. Ce qui aurait pour avantage de pouvoir, dans un premier temps, pouvoir utiliser n'importe quel PC (ou tablette) connecté sur mon réseau local, comme interface, et donc ne plus utiliser un PC dédié, puis dans un second temps directement depuis le net. J'ai commandé une Mega 2560, un ethernet shield et un module clock RTC DS1307. Je ne devrai pas tarder à recevoir tout cela. Je vous donnerai des infos sur l'avancement de mon projet. Si quelqu'un est intéressé par ce type de projets, ce serait sympa et peut-être plus productif de travailler d'une manière collaborative sur ces projets. Bien à vous

#11

Impressionnant pour un projet initié en 1994 :astonished:, très en avance sur l'avènement (pas encore) de la domotique. Pour la collaboration un sujet avait déjà fait débat. http://arduino.cc/forum/index.php/topic,63983.0.html Les problèmes le plus souvent rencontré c'est que chacun à ses propres objectifs, besoins,sa propre vision de la manière de procédé. Par exemple ma vision des choses, c'est plusieurs arduino interconnecté entre eux (bus de terrain, j'ésite encore entre le rs232 simplement et le rs485) et chacun auraient son propre travail, ses propre responsabilités, pas question d'utilisé un seul arduino pour de multiple usages (capteurs, lumières, volets, arosage, ...) , enfin le principe de l'automate genre knx, wago, ... ,mais avec l'arduino. Pas question non plus d'entendre parlé d'ordinateur allumé 24/24 pour gérer tout ça, la seule chose acceptée ce serait quelque chose d’extrêmement minimaliste (plugcomputer, rasbery, ...) pour l'interfaçage web mais c'est secondaire par rapport au système principal, pas question non plus de multiplier les technologies genre xpl(pc), zibase,zwave, x10, plcbus, ... comme 99% ici (pourtant c'est là que j'ai commencé mes fouilles et découvert l'arduino). Donc j'ai beaucoup d'impératif et d'exigence c'est pourquoi je n'ai pas accroché à la plupart des projets vus ici, par exemple celui de gromain est celui qui me paraissait le plus abouti, mais je n'ai pas du tout aimé la partie xpl (multiplication des technologies) et domogic sur pc (que je ne veux pas). Faut dire aussi que je suis têtu dans mes idées donc la collabo difficile (même si j'en aurais besoin pour la partie "hardware", mon domaine c'est la programmation) :grin:.

#12

Je n'avais pas vu ce sujet, je viens d'arriver sur ce forum. Mais la plus grande partie de ce que j’ai vu sur ce sujet me semble trop complexe et utilise trop de technologies et de protocoles différents, pour être mis en œuvre de manière fiable par des amateurs, même éclairés. Je pense que, comme je l’avais déjà fait sur mon ancien (mais toujours actuel) système de domotique, chaque unité de commande doit être autonome, alors que le système de gestion domotique doit « piloter » les différentes unités de commande et échanger des données simples (on/off) avec eux, les données plus complexes étant intrinsèques à chaque unité de commande. Alors le système de gestion domotique devient un automate qui gère des entrées et des sorties logiques, les unes en fonction des autres et de plages horaires. On pourrait d’ailleurs utiliser un automate industriel, si ce n’est le prix, et le fait d’avoir un système qui correspond vraiment au besoin. Si l’étude est bien faite, de sorte à avoir un système modulaire, ce système de gestion domotique doit pouvoir s’adapter à des « besoins standards » de gestion d’une maison : chauffage, volets, arrosage, alarme, … Les dispositifs plus complexes, ambiances musicales ou lumineuses … ne font pas partie de mon projet s’ils ne peuvent pas être traités par une unité de commande autonome (mais pourquoi ne serait-ce pas le cas ?). Pour ce qui me concerne, je suis électronicien et je maitrise plus les parties matérielles et les couches les plus proches du matériel. Je pense qu’un projet collaboratif peut fonctionner, si : 1) Les participants sont peu nombreux, sérieux et complémentaires, l’objectif n’est pas d’en mettre plein la vue aux autres mais avancer et progresser ensemble. 2) Les objectifs sont clairs et partagés dès le départ et tous les participants s’engagent à s’y tenir. En fait je me sens tout à fait capable de faire à minima ce que je veux faire, mais travailler à plusieurs devrait permettre d’une part d’avancer plus vite et peut-être finalement d’obtenir vers un produit final « meilleur » que ce que je pourrai faire seul.

#13

Brisebee: - trop complexe et utilise trop de technologies et de protocoles différents, pour être mis en œuvre de manière fiable - chaque unité de commande doit être autonome, alors que le système de gestion domotique doit « piloter » les différentes unités de commande - Alors le système de gestion domotique devient un automate qui gère des entrées et des sorties logiques - avoir un système modulaire

C'est exactement ce que je pense, on va dire à 99 ... ,ah be non 100% :grin: Mon côté développeur objet me pousse aussi à supprimer au maximum les dépendances, d'où un système modulaires autonome comme tu le précises mais avec un bus et protocole commun. De plus ça ne ferme pas la porte comme tu le dis aux dispositifs plus complexes, ambiances musicales ou lumineuses, ... , puisque chaque module est autonome et indépendant. J'avais regardé les automates programmable et c'est l'idéal niveau fiabilité mais bon, prix, dépendance matériel aux constructeur et quelques limites niveau possibilités selon besoins, l'arduino comblerait "facilement" ses quelques lacunes et la gestion d'entrées et sorties logiques c'est le principe de base de celui ci. Le bus knx aussi est intéressant et similaire au résultat que je souhaiterais, mais faut savoir le financé genre 20-30k € semble banale pour une installation. Pour le projet collaboratif le mieux il me semble serait d'agir en petits groupes et à chacun ça tache tout en restant complémentaire, communications et protocole (plus ciblé programmation), modules (plus ciblé hardware), ... Le plus dur ce trouve dans la motivation, la disponibilité, l'entente, ...

#14

Mon projet vise a faire un système domotique, je ne veux pas non plus commencer a interfacer avec du KNX, XPL, X10, etc... trop compliqué a mon gout et quand on dispose de ces matériels je ne vois pas l'intérêt de passer par un arduino. Je cherche une solution que chacun pourrais intégrer a moindre coût quitte a développer des petits modules électronique pour la commutation de prises et de lampes. Maintenant je veux disposer d'une interface web afin de pouvoir gérer depuis ma télé ou de n'importe quel endroit. Et enfin je veux que le système ne bloque pas la maison en cas de défaillance. Cela fait beaucoup de contrainte je sais mais rien n'est insurmontable.

Maintenant il est tout a fait possible de réaliser un projet commun car chacun a son domaine de prédilection (programmation , électronique , technologie web , etc), l'essentiel est de bien fixer les bases de l'édifice en commençant par une analyse détaillée de l'ensemble ainsi, chacun pourra s'occuper d'un module tout en étant sur que son travail soit compatible avec le reste.

Donc si il y a des volontaires pour ce projet, contactez moi par MP en me donnant vos compétences et l'on pourrais former un petit groupe de travail.

#15

Bonsoir,

J’ai commencé par faire un premier descriptif très général, qui est loin d’être abouti, ce n’est qu’un tout premier jet pour servir de base de discussion avec ceux d’entre vous qui sont intéressés par ce projet.
Je vous soumets cette première approche, les différents éléments devront être précisés, des choix sont à faire, et les descriptions fonctionnelles (peut-être avec plusieurs options) arrêtées avant d’aller beaucoup plus loin.

Système domotique avec interface par serveur web :

A Les principes généraux de ce système domotique pourraient être :

  1. Le système domotique est composé d’une unité de gestion domotique qui pilote diverses unités de commandes qui devront pouvoir fonctionner de manière autonomes lorsque le système de gestion est défaillant ou absent.
    L’unité de gestion domotique est connecté (en permanence ou périodiquement) à un serveur web qui lui fournit les « données consignes » nécessaires aux diverses unités de commande lorsque celles-ci sont en mode automatique et qui recueille à des fins de traitement (affichage, statistiques, stockage, …) les « données comptes rendus » éventuellement renvoyées par ces unités de commande.

  2. Les parties opératives, commandes de chauffages électriques, électrovannes d’arrosage, moteurs de volets électriques, lampes d’éclairage, …, sont commandées par diverses unités de commandes. Ces unités de commandes devront pouvoir fonctionner :

  • en mode manuel, c’est-à-dire de manière autonome, sans liaison avec l’unité de gestion
  • en mode automatique, le pilotage de l’unité de commande se faisant alors par l’unité de gestion domotique.
    Les diverses unités de commandes devront être robustes et fiables. Il s’agira de privilégier les technologies les plus simples, en excluant chaque fois que cela sera possible les systèmes mécaniques et électromécaniques, les relais électromécaniques étant remplacés par des relais statiques (à bases d’opto-triacs et/ou de triacs).

  1. Les liaisons entre les différents éléments devront être fiables et les plus simples possible, en mettant en œuvre des technologies et des protocoles standards adaptés à la nature des données et aux longueurs des liaisons nécessaires. Le nombre de technologies et protocoles mis en œuvre pour les liaisons devra être réduit à un strict minimum.

  2. Le serveur web doit être compatible avec divers éléments reliés à l’internet : ordinateurs (PC ou Mac), tablettes, smartphone.

B Exemples d’éléments de commandes :

• Modules chauffage.
Il pourrait y avoir trois types de modules pour commander le chauffage :

  1. Commande d’un fil pilote en TOR (Tout Ou Rien) : (*)
    Chaque thermostat est équipé d’un fil pilote qui lorsqu’il est alimenté réduit la consigne de température affichée (souvent d’environ 5°C)
  2. Commande d’un fil pilote avec les 6 ordres standards :
    o Confort
    o Confort -1°C
    o Confort -2°C
    o Réduit (souvent Confort-5°C)
    o Hors gel
    o Arrêt
    Bon nombre de dispositifs de chauffages électriques utilisent actuellement ce type de commande.
  3. Commande d’un bruleur de chaudière.

• Module arrosage : (*)
Commande en mode manuel ou automatique d’une électrovanne 24VAC

• Module commande de volet électrique :
Commande d’un moteur de volets électrique dans les deux sens, montée et descente, soit par les boutons de commandes standards soit automatiquement.

•Module commande d’un dispositif en 220VAC (prise commandée, éclairage, …) :
Commande d’un dispositif en 220VAC (puissance maximale à définir) soit manuellement par un interrupteur standard soit automatiquement.

• Divers modules capteurs pour mesurer des grandeurs physiques utilisées à des fins d’affichage, de traitement, ou conditionnels au fonctionnement d’autres unités de commandes.
• Module capteur (TOR) : Pour savoir par exemple si une porte est fermée ou non.
• Module mesure de la température.
• Module mesure de l’humidité.
• Module mesure de la pluviométrie.
• Module mesure d’éclairement.
• …

• …

(*) Ce dispositif est opérationnel sur mon système actuel (fonctionne donc parfaitement depuis plus de 15 ans).

En attendant vos remarques constructives.

Bien à vous.

#16

On peut dire que tu ne chaume pas toi. Il pourrais être intéressant de pouvoir agir sur la variation de l'intensité lumineuse pour les ampoules a filament ou les spots, a ma connaissance, cela est impossible avec les ampoules a économie d'énergie. Cela permettrais de créer des ambiances en fonction de l'heure : réveil -> faible luminosité; début de soirée -> plein pot; ambiance film; etc ....

Je pense que pour débuter on pourrait essayer de poser a plat un diagramme UML (petite recherche sur le net pour ceux qui ne connaissent pas) représentant les différents objets avec leurs différentes méthodes que l'on peut avoir dans notre programme ainsi la communauté pourrais nous faire par de ses connaissances acquises afin de faire évoluer le diagramme et orienter le projet dans la bonne direction.

De plus cela permettrais aux néophytes qui programment d'apprendre la démarche a suivre afin d'avoir un code propre et bien structuré (réduisant de beaucoup les erreurs et les bugs dans les programmes)

Qu'en pensez vous?

#17

Skuzmitoo:
pouvoir agir sur la variation de l’intensité lumineuse pour les ampoules a filament ou les spots, a ma connaissance, cela est impossible avec les ampoules a économie d’énergie. Cela permettrais de créer des ambiances en fonction de l’heure : réveil → faible luminosité; début de soirée → plein pot; ambiance film; etc …

Oui, il faut définir un peu mieux le fonctionnement d’un tel module, (est ce que l’intensité lumineuse n’est commandée que par commande externe, la variation est-elle forcément progressive => analogique ou par bonds, …), pour ce qui est des ampoules cela fonctionnera avec des ampoules halogènes et très probablement avec des ampoules (au moins avec certains types) à LED, je viens d’acheter des ampoules 80 LED avec culot GU10 (donc en 220VAC) et les mêmes en 12V, à l’occasion je ferai un essai de variation d’intensité lumineuse pour voir.

Skuzmitoo:
Je pense que pour débuter on pourrait essayer de poser a plat un diagramme UML (petite recherche sur le net pour ceux qui ne connaissent pas) représentant les différents objets avec leurs différentes méthodes que l’on peut avoir dans notre programme ainsi la communauté pourrais nous faire par de ses connaissances acquises afin de faire évoluer le diagramme et orienter le projet dans la bonne direction.

Je n’ai jamais utilisé cette représentation, j’utilise assez souvent les mapminds pour mes projets (qui ne sont en général pas techniques).
Je suis partisan de tout ce qui peut faciliter le partage d’informations, donc d’obliger à une clarification des concepts, une confrontation des points de vue, et si en plus cela permet à certains (et à moi en premier lieu) d’apprendre à maitriser nos nouvelles techniques, ce ne sera que mieux !

#18

Bonne idée la modélisation uml (simplifié, sans que ça corresponde à 100% à la spécification de chaque diagramme ) Sinon pour ce qui concerne les modules il existe des ampoules éco dimmable compatible avec gradateur classique il me semble. Concernant la partie chauffage contrairement à la France chez nous les mangeurs de moule frittes :grin:, se chauffer au full électrique est assez rare (on vas démantelé nos centrale nucléaire ici :grin:) . Enfin pour les modules c'est plutôt au cas par cas ? (le côté "hardware" je ne suis surement pas le mieux placé pour orienté ou conseillé mes compétences étant très limité dans ce domaine :sleeping: :blush:) Il faudrait peut être regarder la gestion du système dans sa globalité d'abord (bus de terrain, protocole, ...) ? En fait dans mes recherches actuel, j'étais parti sur une communication via rs-232/485 half-duplex du type maître-esclaves (voir Multi-processor Communication Mode de la doc atmel que je trouve pas mal) avec gestion des collision type csma(/cd) et protocole simple souvent rencontrer dans les solutions domotique, un peux comme je l'ai fais dans mon autre projet . J'attend l'arrivée d'un mega et d'un mini commandé en chine pour commencé mes testes :% . J'aurais bien voulu connaître des avis, idées et suggestions sur ce point. :open_mouth:

#19

Effectivement, il faut définir le système dans sa globalité et choisir des liaisons et le (ou les) protocole(s) de communication, j’avais pensé utiliser le Bus I2C, car il y a de nombreux composants matériels qui utilisent ce bus et Arduino l’interface facilement, avec une interface I2C <=> RS485 pour régler les questions de distance.

Je peux m’occuper des aspects matériels et mettre à votre disposition tous mes schémas, ceux que j’ai déjà fait et ceux à venir ainsi que toutes les explications et les tests liés.
Il va falloir que je refasse tous mes anciens schémas, car depuis 1994, j’ai changé n fois de logiciel de DAO et les tous premiers schémas ne sont que sur papier. Mais c’est l’occasion de mettre au propre et à jour un certain nombre de choses.

Osaka, j’ai regardé ton projet, je ne comprends pas tout, mais cela me semble très intéressant, bravo ! Je pense qu’en conjuguant nos efforts et en travaillant intelligemment ensemble, en faisant des efforts de pédagogie d’une part et d’adaptation aux problématiques ou préoccupations des uns et des autres d’autre part, le tout dans un esprit d’humilité et de respect mutuel, on devrait arriver à faire quelque chose de fonctionnel.

Il faut se mettre d’accord sur un noyau dur commun, et chacun pourra ensuite développer autour ses propres éléments (matériels et/ou logiciels) en fonction de ses besoins.
C’est pour cela que l’esprit Arduino me plait bien.

#20

Brisebee:
j’avais pensé utiliser le Bus I2C, car il y a de nombreux composants matériels qui utilisent ce bus et Arduino l’interface facilement, avec une interface I2C <=> RS485 pour régler les questions de distance.

J’avais pensé également à l’i2c et même spi mais deux problème me contrariais dans ses solutions, le fait que le maître doive interrogé chaque esclave tour à tour pour savoir s’il a quelque chose à dire (token ring ?) et le fait de partager le bus avec d’autres composants matériels (ds1307,…) disponibles pour l’arduino.
Le port série étant vraiment dédié à la communication et la possibilité d’en avoir plusieurs (mega par exemple) au cas ou (je pense au module gsm/gprs, …), il me paraissait plus adapté, sans compté que atmel à prévu dans ses registres le Multi-processor Communication Mode :open_mouth: .

Brisebee:
Je peux m’occuper des aspects matériels et mettre à votre disposition tous mes schémas, ceux que j’ai déjà fait et ceux à venir ainsi que toutes les explications et les tests liés.
Il va falloir que je refasse tous mes anciens schémas, car depuis 1994, j’ai changé n fois de logiciel de DAO et les tous premiers schémas ne sont que sur papier. Mais c’est l’occasion de mettre au propre et à jour un certain nombre de choses.

C’est clair que tu as de la bouteille dans le domaine, expérience plus que bienvenue :grin: .

Brisebee:
Osaka, j’ai regardé ton projet, je ne comprends pas tout, mais cela me semble très intéressant, bravo ! Je pense qu’en conjuguant nos efforts et en travaillant intelligemment ensemble, en faisant des efforts de pédagogie d’une part et d’adaptation aux problématiques ou préoccupations des uns et des autres d’autre part, le tout dans un esprit d’humilité et de respect mutuel, on devrait arriver à faire quelque chose de fonctionnel.

Je l’avoue que par exemple pour mon autre projet (adaptable à notre besoin), j’ai beaucoup de mal à exprimer et décrire mes idées et pensées, j’écris comme je pense et ça doit pas être facile à décrypter :grin:.
Je pense également qu’en combinant ses compétence on peux arrivé à un bien meilleur résultat.

Brisebee:
Il faut se mettre d’accord sur un noyau dur commun, et chacun pourra ensuite développer autour ses propres éléments (matériels et/ou logiciels) en fonction de ses besoins.
C’est pour cela que l’esprit Arduino me plait bien.

Oui il faudrait d’abord délimité ce qui est commun et ensuite développé ses propres éléments (ou d’autre personnes pourront également y trouvé leurs intérêts commune).
Dans tout les cas je reste ouvert :wink: