Aidez nous ! Projet - Gestion domotique

Brisebee: A priori je pense m'orienter vers la solution 3.

Qu'en dis-tu ?

C'est la solution que j'ai présenté il y a quelques pages. http://arduino.cc/forum/index.php/topic,80422.msg732055.html#msg732055

C'est une très bonne solution pour avoir une communication presque full-duplex et presque temps réel (enfin possible mais en chipotant). Par contre c'est plus ou moin du chipotage, faut dribler entre les différents langages et bidouillages. :grin: C'est pour ça que j'ai choisi la solution websocket, liaison direct possible et moin chipotage intermédiaire, mais bon pas encore à 100% au point.

osaka: C'est la solution que j'ai présenté il y a quelques pages.

Je viens de jeter à nouveau un oeil, mais pour l'instant, je n'y comprends pas grand chose, il va falloir que je reprenne tous ces éléments au début, et commencer par faire des choses très simples pour comprendre.

Pour le moment je galère car j'essaye de passer un sketch simple qui lit un capteur OneWire DS18B20 et affiche la température sur un LCD, qui fonctionne très bien de l'IDE 023 à l'IDE 1.0, je n'arrive absolument pas à implanter la librairie OneWire, j'ai plein d'erreurs de compilation.

Je crois que je suis trop fatigué ce soir. Je verrai demain soir.

zoroastre: Petite question au passage : On peut se créer un interface avec Pachube ou c'est plutôt fermé.

Alors là je ne serais pas te dire, je connais de nom mais jamais trop bien compris son intérêt, partage de données (capteur, temp, ...), graphique ??? :~ Mais : http://arduino.cc/en/Tutorial/CosmClientString?from=Tutorial.PachubeClientString

Brisebee: Je viens de jeter à nouveau un oeil, mais pour l'instant, je n'y comprends pas grand chose, il va falloir que je reprenne tous ces éléments au début, et commencer par faire des choses très simples pour comprendre.

Il va falloir le faire pas à pas, on commencera par utilisé les requêtes http (get, post), puis les sockets, etc.

Brisebee: Pour le moment je galère car j'essaye de passer un sketch simple qui lit un capteur OneWire DS18B20 et affiche la température sur un LCD, qui fonctionne très bien de l'IDE 023 à l'IDE 1.0, je n'arrive absolument pas à implanter la librairie OneWire, j'ai plein d'erreurs de compilation.

Il n'y a pas màj de la lib ou autres, quelqu'un a ou va surement rencontré les même problèmes ?

Ca y est, j'ai effectivement trouvé une librairie à jour, ça marche !

D'abord, Je vais mettre au propre mon programme (enlever toutes les scories) essayer de faire un truc lisible, pour que je puisse partir sur de bonnes bases.

@+

zoroastre: Première remarque, tu peux déjà dissocier la gestion de l'horloge du serveur web. Un serveur ntp est justement fait pour çà.(vf librairie)

C'est d'accord, j'ai trouvé de l'info et des exemples => je mets cela de coté pour plus tard. => je vais modifier le cahier des charges en ce sens.

zoroastre: Egalement, tu peux trés bien intégrer dans ton serveur web, un évenementiel indiquant au système de gestion qu'un utilisateur est entrer en mode paramétrage et renvoyer un echo de connectivité établi. De même pour la lecture des sondes...

En fait pour éviter de stocker toutes les données (plages horaires + ...) => que j'estime à environ 2ko, dans l'arduino, j'ai imaginé n'en transférer que ceux nécessaires durant une périodes données par exemple 1 jour. Mais en fait si je peux stocker ces données sur la carte SD, il n'y a plus de problème, je n'ai pas besoin d'avoir une connexion pour fonctionner. J'aurai besoin d'une connexion pour connaître à distance les états du système et les grandeurs mesurées, mais du coup ce sera beaucoup plus simple => je vais là aussi modifier mon cahier des charges.

Encore merci pour votre aide.

Bonjour,
je suis revenu :stuck_out_tongue:
Ci-joint mon cahier des charges concernant le projet Hexintelli pour avis et commentaires
Je cherche aussi conseils concernant :
Type de composants ou cartes manquantes ou de meilleure qualité/rentabilité
Orientation concernant le serveur Web « langage de programmation, Nom serveur Web, interface avec smartphone…etc. »
Merci d’avance :D.

cahier des charges Hexintelli.pdf (270 KB)

Très sympa ton projet.
Cela me donne des idées pour prolonger le mien !

Tes questions sont très larges, quelles solutions as-tu déjà retenues et validées ?
Sur quelles parties cherche tu de l’aide ?
As-tu déjà travaillé sur la partie mécanique de ton robot ?

Ton cahier des charges est assez global, c’est comme cela qu’il faut commencer.
Mais ensuite il faudra rentrer plus dans le détail.

Pour ce qui me concerne, j’ai plus de compétences sur la partie électronique que sur la partie programmation.
Parmi les contributeurs à ce Forum il y a de grands spécialistes sur les différentes parties.

@+

J’ai corrigé ma partie du cahier des charges concernant de l’unité de gestion, suites aux remarques (merci Zoroastre).

Je vous le soumets à nouveau, puis je l’intègrerai dans le cahier des charges global.

@+

Cahier des charges détaillé de l’unité de gestion v1.pdf (12.3 KB)

Merci Pour ma part je du domaine informatique « option BDD XD», je cherche de l’aide sur la partie électronique, surtout pour le volet IR « car je n’arrive pas à bien comprendre comment puis-je schématiser et avec quel composants je peux le faire» et la protection des composants « alimentation des relais et servo » pour la partie mecanique j'ai pas encore commencé :) @+

nadirovick:
je cherche de l’aide sur la partie électronique, surtout pour le volet IR « car je n’arrive pas à bien comprendre comment puis-je schématiser et avec quel composants je peux le faire

Il faudrait que tu en dises plus sur ce que tu veux faire exactement, comment cela doit fonctionner.

Pour ta partie IR qui semble relier un écran (TV ?) que veux tu afficher ?

Il y aura probablement une partie fixe (au moins certains actionneurs et peut-être capteurs + …) pour commander les éléments domotiques, et d’autres mobiles embarqués sur le robot. Il faudrait déjà déterminer cela.
Après on peut voir comment il faut alimenter cela.

Si tout est mobile (mais cela ne me semble pas réaliste => poids + communications avec les différents éléments domotiques)=> l’alimentation se fera sur batterie => il faudra voir comment la dimensionner (poids, capacité, …) et comment la recharger.
Sinon il y aura aussi une partie sur secteur.

@+

Pour la partie IR elle est très simple, je veux piloter ma télévision et le climatiseur via Arduino [u]Exemple pour la télévision :[/u] Je peux l’allumer ou l’eteindre « elle est alimentée et en mode veille » via arduino [u]Exemple pour le climatiseur :[/u] Allumer/éteindre et Changer la température du climatiseur via Arduino « Toujours à partir du Mode veille » [u]Exemple pour le démodulateur starsat 4200D ou autre :[/u] Changer les chaines de télévision via arduino et commandes vocales Globalement l’arduino va jouer le rôle des télécommandes en plus à commande vocale @+

OK, je comprends mieux.

Je n'ai pas grande expérience dans ce domaine, mais à une époque j'ai cherché de l'info sur ce sujet, j'avais pour projet de piloter un petit robot (self bricolated) en le commandant par une télécommande IR, mais finalement je ne l'ai jamais fait (mais j'y pense toujours !).

En fait, c'est la fonction inverse, mais cela revient à mettre en œuvre les mêmes technologies, pas forcément les mêmes composants, puisque tu auras besoins d'émettre et non de recevoir.

Je vais voir ce soir si je retrouve des choses.

@+

Je n'ai pas retrouvé grand chose sur le sujet des télécommandes IR, car il s'agit de cela, il faut se substituer à la télécommande, il faut fabriquer une télécommande universelle.

Il y a quelques infos ici : http://www.robot-mobile-irbot.com/8-telecommander-robot-irbot.htm http://www.roboticus.org/electronique/15-la-telecommande-infrarouge-theorie

Mais peut-être en cherchant sur un moteur de recherche : "principe de fonctionnement d'une télécommande universelle IR". Je sais que cela se faisait (remplacer la télécommande) avec un PAD et maintenant avec un smartphone => il doit bien être possible de trouver des information sur le fonctionnement des télécommandes IR.

@+

Salut a tous.
Apres avoir lu d’une traite les 24 pages de ce topic, j’ai appris beaucoup de chose, et j’entrevoie certaine solutions pour mon projet.
Pour faire avancer le schmilblick, je me permet une petite réflexion:
Concernant la partie serveur Web:
Il existe de petite machine sur plateforme ATOM, qui ne coute pas très chère genre Zotac Zbox, et qui ne consomme pas grand chose. Ça c’est disponible de suite, et opérationnel sous Windows/Linux. Sur une plateforme ATOM D525, on peut faire tourner Windows 2003 Serveur, avec virtualbox qui fait tourner une Debian Squeeze. Le tout ne consomme que quelques dizaine de watts.
Pour moi, toute la partie Web dois se trouver en dehors de l’arduino. Les contraintes sont trop importantes. Pour palier celles-ci, il faudra trouver des astuces, déporter une partie du code sur le client, etc…
Il est, a mon sens, bien plus simple de réduire la partie web de l’arduino a appeler des page php sur un serveur local en passant les paramètres en arguments. Voir même, via une liaison série Arduino <-> Serveur Web.
C’est le serveur Web qui s’occupe ensuite de mettre les données en formes, de les stocker, etc…
De la même façon, l’arduino possède en dur, des paramètres de départ a froid, qu’il utilise jusqu’à ce qu’il puisse obtenir les donnée a jour du serveur (ou que l’utilisateur les modifie en direct).
Une fois obtenu les info, on les stocke dans l’EEPROM: en cas de reset (soft ou hard), le système repart comme il était avant le problème (je ne parle pas de l’état des actionneurs qui retrouverons un état “quelconque” selon leur mode de fonctionnement)
Pour déclencher la mise en mémoire des info nouvellement modifier, un simple appel d’une page sur l’arduino (qui ne renvoi rien, si ce n’est un http 200) qui déclenche la lecture d’un fichier texte sur le serveur (par ex: http://serveurweb/infoparametage.txt)
De la même façon, on peut même imaginer que c’est le serveur Web qui se signale “vivant” a l’arduino suite à un problème, et non à l’arduino de monopoliser des ressources pour faire des appels régulier au serveur.

Merci de ne pas taper sur le nez, je suis fragile :grin: :grin: :grin:

Yep!

Quitte à faire tourner debian sur un serveur à moins de 5 watts de conso, autant s'orienter vers un plug pc. Le sheevaplug étant celui qui a le plus de notoriété et en plus ce sont des processeurs ARM (increvables) ;)

@+

Zoroastre.

Mouais. C'est une solution, mais pas très "userfriendly": pas de port VGA, pas de HDD et 512Mo de RAM. A réserver aux plus "geek" des utilisateurs. Rien que l'installation de l'OS n'est pas super aisée. De plus, c'est Linux only. Mais c'est effectivement une solution.

CocoVFR: Pour moi, toute la partie Web dois se trouver en dehors de l'arduino. Les contraintes sont trop importantes.

C'est la conclusion à laquelle je suis arrivé grâce aux conseils des contributeurs à ce topic.

Cette partie communication et échanges de données avec le Web est celle qui me pose le plus de problèmes, je suis donc très attentif et preneur de tous les conseils à ce sujet.

Pour ce qui concerne le serveur web en lui-même, je pense dans un tout premier temps, et pour ne pas multiplier les difficultés, utiliser un vieux PC (noteboock ou PC fixe, j'ai les deux en stock) sous windows XP avec un serveur apache et faire fonctionner le système en local, j'avais déjà fait un truc très simpliste dans ce genre (petit site html disponible sur mon réseau local => c'est le maximum dont je suis capable aujourd'hui). Et ensuite je verrai : - comment le rendre accessible au delà de mon réseau local - mettre en place un serveur fiable, qui consomme peu ...

Est ce que j'écris des bêtises ?

CocoVFR: De la même façon, l'arduino possède en dur, des paramètres de départ a froid, qu'il utilise jusqu'à ce qu'il puisse obtenir les donnée a jour du serveur (ou que l'utilisateur les modifie en direct). Une fois obtenu les info, on les stocke dans l'EEPROM: en cas de reset (soft ou hard), le système repart comme il était avant le problème

Je m'oriente vers l'utilisation de la carte SD (sur l'éthernet shield) pour stocker les paramètres, ce qui permet à la fois d'avoir une capacité importante, et d'avoir des données non volatiles, je suis en train de faire des essais en ce sens, même si en ce moment je n'ai que peu de temps, je ne vais donc pas très vite.

zoroastre: Quitte à faire tourner debian sur un serveur à moins de 5 watts de conso, autant s'orienter vers un plug pc. Le sheevaplug étant celui qui a le plus de notoriété et en plus ce sont des processeurs ARM (increvables) ;)

Ca a l'air très sympa. Il faudra que je vois de plus près le moment venu.

@+

Yep!

Mouais. C'est une solution, mais pas très "userfriendly": pas de port VGA, pas de HDD et 512Mo de RAM. A réserver aux plus "geek" des utilisateurs. Rien que l'installation de l'OS n'est pas super aisée. De plus, c'est Linux only.

Un peu comme les routeurs que nous avons à la maison, c'est du linux dedans en fait, parfeu, serveur web, serveur d'imprimantes, media avec beaucoup, beaucoup moins de vélocité et de ram. Pourtant, çà fait son job et plutôt pas mal. L'enorme avantage de linux sur windows est justement que l'on peut se passer de tout l'aspect "userfriendly", l'interface graphique devenant complètement ostentatoire. De plus, c'est open, communautaire et free ;) On peut largement faire tourner linux sur un vieux truc genre 400 Mhz et 128 Mo de ram...

Il n'y pas moins "userfriendly" que windaube, microsoft n'a jamais été notre ami :grin:.

Mais c'est effectivement une solution.

Merci ;)

Une autre solution beaucoup plus ardue est d'utiliser certains routeurs comme serveur perso en y installant openwrt ou dd-wrt (encore linux XD). Certains routeurs sont nativement pourvus d'une liaison série TTL 5volts (vf fonera = 30€).

Mais bon, quitte à choisir : vieux netbook ou sheevaplug.

@+

Zoroastre.

Pas de meprise. Je n'ai rien contre Linux. :grin: J'ai cru lire en debut de topic, que le but était de pouvoir faire quelque chose d'a la fois simple et adaptable pour le plus grand nombre. Hors, Linux n'est pas la plateforme de prédilection du plus grand nombre :P. Sachant que tout ce qui tourne sous Windows, trouve sont équivalent sous Linux, et que les utilisateur Linux sont bien souvent plus a même de mettre les mains dans le cambouis.

CocoVFR: Il existe de petite machine sur plateforme ATOM, qui ne coute pas très chère genre Zotac Zbox, et qui ne consomme pas grand chose. Ça c'est disponible de suite, et opérationnel sous Windows/Linux. Sur une plateforme ATOM D525, on peut faire tourner Windows 2003 Serveur, avec virtualbox qui fait tourner une Debian Squeeze. Le tout ne consomme que quelques dizaine de watts. . . . pas de port VGA, pas de HDD et 512Mo de RAM. A réserver aux plus "geek" des utilisateurs. Rien que l'installation de l'OS n'est pas super aisée. De plus, c'est Linux only.

En perso je pars plus sur du minima comme le propose zoro, point besoin de 512 de ram ou hdd qui seraient disproportionné pour l’hébergement d'un serveur cantonné à de petite tache pour 1 seul site et 2 visiteurs simultané et même en ajoutant ma petite appli serveur de websocket/rs232 qui demande 24Ko pour le stockage et une 10 ène de Mo en ram. :sweat_smile: Maintenant ici c'est perso, mais la solution Zotac par exemple pourrait être intéressant pour celui qui désire faire du tout en un comme serveur web,de fichiers, multimédia (blue-ray ? ... :cold_sweat:), etc. Mais ses possibilités ne me plaisent guère ou ne m’intéresse pas comme tu l'auras sans doute remarqué depuis le début de ce topic, je n'aime pas tout mélanger, chaque chose à sa place et chacun son rôle :grin:. Bon au final concernant la partie interface/web je suis pas encore arrêté à 100% sur une solution, j’attends de voire avec toute ses petites plateformes minimaliste qui sortent comme le raspberry à base d'arm, etc, qui sont assé prometteurs en terme possibilités/perf/conso et qui me permettrait d'atteindre mes objectifs qui sont un minimum d'intermédiaires pour de grande possibilités.

CocoVFR: J'ai cru lire en debut de topic, que le but était de pouvoir faire quelque chose d'a la fois simple et adaptable pour le plus grand nombre.

En fait au départ du topic on étais partis sur un projet commun, mais au final on a plutôt dérivé sur une entraide pour un but commun avec des idées et solutions différentes ou identiques sur certaine parties, donc tous le monde est le bienvenue avec sa propre solution. :open_mouth:

CocoVFR: Hors, Linux n'est pas la plateforme de prédilection du plus grand nombre :P. Sachant que tout ce qui tourne sous Windows, trouve sont équivalent sous Linux, et que les utilisateur Linux sont bien souvent plus a même de mettre les mains dans le cambouis.

Pour ce qui est des membres actif du forum c'est étonnant mais on trouve au temps d'utilisateurs de windows que de linux et qu'osx 8) (non skywood je ne parle pas de pron :grin:). Maintenant qui dit arduino ou µc dit obligatoirement main dans le cambouis de toute façon.

;)