Aidez nous ! Projet - Gestion domotique

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.

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.

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?

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 !

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:

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.

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:

Voila j'ai commencé un petit jet afin de donner une première orientation afin de définir les intéractions et les différents objets que nous allons utiliser. J'invite chacun a reprendre les fichiers que j'ai joint et de les modifier afin de garder le même format. Il faut oppenoffice pour ouvrir les documents. En travaillant de la sorte nous aurons une base commune.

Donc premier pavé, les intéractions :

Deuxième pavé :

Je sais cela est un peu sommaire, mais si chacun participe, cela va s'enrichir très vite.

Enfin, si l'on développe un projet, il va falloir lui trouver un nom,que pensez vous de Smart'Home

Le fichier openoffice pour les intéractions : https://rapidshare.com/files/3440798408/Intérections.ods
Le fichier openoffice pour la modélisation : https://rapidshare.com/files/3568813400/Modélisation.ods

Il faut effectivement commencer par les interactions comme tu le propose skumitoo. Merci pour ta proposition.
Je vais "amender" ton schéma dans la soirée, pour le remettre à la discussion.

Pour ce qui concerne le nom du projet :
si tu googelise "smart home" tu tombes sur une quantité impressionnante de réponses, visiblement ce nom est déjà pris et pas qu'une fois.
De même en faisant rapidement une recherche de disponibilité de nom de domaine smart-home est pris avec toutes les extensions courantes.

Moi j'aurai vu quelquechose avec "domo" dans le nom pourquoi pas "domo smart" ou "domo-smart". A discuter

Il faudra aussi penser à "protéger" le projet en le mettant sous licence open source, comme GNU, mais là ce n'est pas dans le monde linux, à voir.
Car ce serai trop bête de se faire attaquer par quelqu'un qui a piqué les idées et qui les a ensuite protégées puis commercialisées. ]:smiley:
Il suffira de faire comme cela a été fait pour le projet Arduino. A voir de plus près.

Pour l'instant il n'y a pas grand chose de concret, on verra pour la "protection" quand cela aura bien avancé, il y a encore du chemin a parcourir et plus c'est long, plus c'est bon :smiley:

Il n'y a effectivement pas grand chose de concret, c'était une remarque au passage, il n'y a aucune urgence de ce point de vue !

J'ai refais un schéma des interactions que je soumet à la discussion :
Quelques remarques :

  • Pour moi l'ordinateur ne doit servir qu'à programmer les cartes arduino, ensuite tout doit se passer par le réseau local ou le web.
  • Il n'y a besoin d'un arduino esclave que lorsqu'il faut un certain degré de traitement des informations ou des signaux.
  • Les parties opératives devraient se trouver à proximité des circuits de commande pour éviter d'avoir des commutations de puissance (qui génèrent des parasites) sur des grandes distances.
  • J'ai indiqué des types de liaisons mais là encore c'est à discuter.

Pour l'instant rien n'est arrêté.

Schema interaction.odg (15.2 KB)

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

La grosse différence entre le rs232 et le rs485, c'est qu'en rs232 c'est une communication entre seulment 2 appareils, alors qu'en rs485 on peut en adresser plusieurs, de plus, le rs485 est plus approprié, distance max jusqu’à 1,2Km et jusqu’à 32 appareils sur un bus.

Maintenant utilisé le I2C ou le rs485 pour un capteur, c'est pas trop usine a gaz, vous avez des exemples ?

Dans notre cas cela sera soit un signal numérique ou analogique, il y a juste a branché sur la bonne entrée de l'arduino. Le problème reste toujours la distance pour envoyer l'information.

On pourrais imaginer un arduino pour chaque pièce afin de réduire les distance arduino <-> capteurs et il communiquerais entre eux par le bus, mais c'est pas très esthétique a mettre en place dans un foyer.

Je rejoint plus Osaka sur son schéma un peu plus cohérent, et le fait de multiplier les arduinos n'est pas excessivement cher pour les bricoleurs http://www.instructables.com/id/LOG-10-Arduino/, cela ne sert a rien de multiplier les protocoles cela complique la mise en oeuvre il faut faire simple et fonctionnel.

J'aime bien l'idée des contrôleurs séparés (scénario - serveur web - esclaves), par compte a mon avis il faut se servir de l'arduino en client web vu la faible quantité de mémoire disponible.

Vous en pensez quoi ?

Il y a une piste pour la transmission des données vers le capteurs et les actionneurs ici : Supports de Transmission

Il y a les paires torsadées (câble de téléphone blindé) ou la transmission de données différentielle qui a l'air intéréssante une porte logique NON et un ampli AOP sa coute rien et en général, et on en a plusieurs sur un Circuit intégré.

La plupart des capteurs mesurent des grandeurs physiques analogiques et fournissent des signaux analogiques. Si on veut transmettre ces signaux sur des grandes distances (> 1 m), à moins d’utiliser des câbles blindés, les signaux vont être perturbés par les parasites. On transforme alors, à proximité des capteurs, les signaux analogiques en signaux numériques à l’aide ce convertisseurs analogiques numériques (CAN ou ADC pour Analog to Digital Converter) puis on les sérialise pour les transmettre, il existe des CAN avec des sorties I2C ce sont des composants très couramment utilisés AD7992, AD799,1 PCF 8591, ...
Mais peut-être ce type de montage n’a pas lieu d’être présent dans un projet domotique ?

Je vais me recentrer sur mes besoins plutôt que d'imaginer les possibles !

Concernant le rs-232 normalement il n'y a pas de problème pour du multipoint (1 maitre - n esclaves), il y avait une discutions récemment à ce sujet qui m'a conduit vers la doc concernant le multi-processor communication mode (idéal si c'est déjà intégré dans l'amel), je vous invite à regarder le point 19.9 page 193 pour savoir si je suis dans l'erreur ou pas ? http://www.atmel.com/dyn/resources/prod_documents/8271S.pdf .
(un adaptateur rs-232/485 coute grand max 2€ de ce que j'ai pu voir donc pas vraiment un problème à rajouté le résultat niveau code est presque le même)
Pour le "module" serveur web j'avais pensé utilisé quelque chose comme ceci, léger, 3 port série donc interfaçable avec le bus, ...
Le fait que le contrôleur soit un maillon esclave du bus permet de supprimer les dépendances , un contrôleur en panne les autres fonctionne (qui a dit fiable ? lol),multiplie également les possibilités d'évolutions et le top c'est que chacun fais comme il veut :open_mouth:.
Pour les capteurs je vous laisse en débattre, c'est hors de mes compétence tout ce que je connais c'est ce qui a déjà été utilisé ici (maxim dallas, lm35, ...) et sans doute d'autre personne ce manifesterons d'ici peux, donc continuer à m'instruire. :grin:
Enfin tout ceci est toujours à l'étude, rien de définitif on est pas à 1 jours (ans :*) près :grin:.

Edit: il y a une autre chose important dont on a pas parlé, c'est l’installation électrique général qui pour la plupart ne se prête pas (enfin moins simple) au type de bus prévu comme ça doit être le cas pour brisebee Skuzmitoo d'où le fait de parler d'arduino par pièce et de distance?
Je veux dire chaque point de commande (interrupteur) doit revenir au bus (instalation en étoile) et non contrôler directement le point à alimenté (comme pour les télérupteur)s et comme il est assé rare pour une question de cout et de longueur de câbles de revenir au coffret pour repartir sur ce point à alimenté (a moins du sans fils)... ?
Je sais pas si je me suis bien expliqué ?

quelque liens pour expliqué tout ce que je n'arrive pas a expliqué lol

http://www.pluc.fr/2011/01/domotique-description/

Tien truc que je n'avais jamais vu en be et proche de ma pensée
http://www.bcdi.be/fr/produits/domotique/domotech.html
http://www.domotech.com/index.php?Page=Technical in het neederlands :grin:

Merci osaka pour tous les liens que tu proposes.
Je vais voir cela tranquillement.
Effectivement, il n'a jamais été question dans nos échanges de l'installation électrique et des câblages, en fait pour ce qui me concerne, le système existe déjà, donc toute l'installation de base est faite, et j'ai de nombreuses réservations prévues pour faire évoluer mon installation, je n'ai pas, à priori, de soucis de ce coté ci.
En fait ce qui me pose le plus question, c'est la partie serveur web, c'est la partie que je ne maitrise pas, alors que cela semble ne pas vous poser de problème.
Je viens de recevoir mon nouveau matériel : Arduino Mega 2560, Ethernet shield W5100 avec lecteur SD et horloge DS1307 RTC (le tout pour environ 50€, port compris, sur ebay)
Je vais pouvoir tester tout cela.

arf m'étais tromper de pseudo quand je disais installation électrique moin adapté, c'est certain que la tienne est déjà adapté au type bus domotique, automate, ... (centralisation quoi) :sweat_smile: .
Pour la partie web serveur comme l'a dit Skuzmitoo le shield ethernet ne s'y prête pas vraiment du à ses limites et ceux de l'arduino (4 connections max simultanée, limite mémoire, ...), en temps que client (socket simple) ça fonctionne très bien mais bon il faudrait de toute façon un serveur externe, donc le mieux c'est d'utilisé quelque chose de plus adapté tout en restant léger et interfaçable avec le bus, on vois de plus en plus de petite machine pouvant faire office de serveur web plus adapter que l'arduino+shield (on pourait y placer d'autre chose aussi, bdd, client lourd, configuration système, ...) .
Pour les liens c'est surtout pour montrer que je ne fais que m'inspiré de ce qui existe déjà et éprouvé, pas besoin de réinventé la roue, c'est surtout le plaisir de le faire sois même, sans dépendance à un système fermé et question cout. :grin:
Entre () Je n'ai pas encore de maison ou autre, étude secondaire (BE) en construction mécanique et métallique et graduer (bac +3 ?) en informatique de gestion (changement de domaine du à un accident) et ... sans emplois ... enfin je vais pas m’étaler là dessus, mais la domotique me passionne énormément. :grin:
Félicitation pour tes nouveaux jouets :open_mouth:

Edit: pour le multi mode j'ai retrouvé le post Faire papoter deux Arduino entre elles - #9 by system - Français - Arduino Forum

hello,

Je travaille aussi sur une installation domotique en arduino. Ce topic arduino aborde aussi quelques points interressant qui m'ont pas mal aidé pour les actionneurs : http://arduino.cc/forum/index.php/topic,33445.0/topicseen.html

Ma solution est encore loin d'être au point, je posterai dès que j'ai plus de resultats (encore quelques nuits blanches en perspective!!)

J'avais suivi le projet de gromain également avec grande attention, surement le plus abouti ici et franchement je lui tire mon chapeau, mais comme je l'ai dis plusieurs point me dérangeais comme l'ethernet pour le bus (qui impique au minimum un switch pour rassembler tout ça ?), le xpl (multiplication des techno, ...), ..., je pars plus sur la même philosophie (modulaire) que Brisebee et Skuzmitoo par exemple .
Tu pourrais nous dire un peux plus vers quels solution tu te diriges ?