Aidez nous ! Projet - Gestion domotique

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) :wink:

@+

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) :wink:

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

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.

:wink:

Bonjour à tous,

Un petit point sur l'état d'avancement de mon projet : DOMOWEB 2012.

  1. J'ai complété et amendé le cahier des charges qui deviendra le descriptif du système et de son fonctionnement, il va donc évoluer au fur et à mesure de l'avancement du projet (je joins à ce post la nouvelle version 1.0 du cahier des charges).

  2. Le système fonctionne actuellement dans une configuration "minimale" : uniquement la partie arrosage, sans la connexion web.
    C'est à dire :

  • les paramètres (plages horaires) sont stockés sur la carte SD
  • je capte la température à l'aide d'un capteur OneWire DS18B20.
  • les sorties de l'unité d'interfaçage arrosage (module E/S en I2C) sont activées en fonction des plages horaires
    il me reste à faire la partie stockage puis lecture des paramètres par défaut en EEPROM (je crois que c'est assez simple).
  1. J'ai passé tout le sketch en .ino pour pouvoir travailler avec l'IDE 1.01, ça a été laborieux pour trouver les différentes bibliothèques, mais j'y suis arrivé (je joins le sketch).

J'aimerai maintenant commencer à faire des essais pour la partie web, mais je suis dans la posture de la poule qui a trouvé un couteau : je ne sais pas quoi en faire ! En fait je ne sais pas trop par où commencer.

Je joins également 2 photos du système actuel.

@+

Cahier des charges détaillé du système domotique avec interface web ver. 1.0.pdf (713 KB)

Domo_RTC_LCD_PCF8574lib_UIA_PH_DS18B20_LED_SD.ino (23.7 KB)

Yop bribri,
J'adore suivre l'évolution de ta solution et photos en prime :grin:, vivement que j'en sois aussi.
J'ai très rapidement parcouru ton code, juste une petite remarque concernant le type de variable.

Pour l'attribution des broches le type byte ou unsigned char suffit (1 octet) à la place de int (2 octet) pour des valeur n'excédant pas les 255 décimal, idem pour ton tableau de 120 pour la plage horaire de l’arrosage donc 120 octet de gaspillé :~ .
Je regarderais attentivement la façon dont tu gère les plage horaire ça m’intéresse, faut que je réfléchisse également pour la gestion de scénarios, enfin j'ai déjà ma petite idée mais à étudier.
:wink:

Merci Osaka pour tes remarques.

Je vais corriger cela !

Et pour la partie web aurais-tu un conseil pour m'aider à démarrer ?

@+

Brisebee:
Et pour la partie web aurais-tu un conseil pour m'aider à démarrer ?

A mon avis peut être commencer par de simple requêtes POST, GET, voir comment interagir avec l'arduino et y aller tout en douceur même s'il ne s'agira pas de la solution définitive et voir les différentes solutions qui peuvent s'offrir à toi ?
Je vais regarder un peux ce que je pourrais te proposer comme "exercices" ?

Yop Yop,
J'ai fais quelque testes hier pour voir les différentes solutions possible.

  1. Simple requête http GET/POST

Transmission de la requête et récupération de l'entête http par l'arduino ensuite l'arduino retourne une simple entête avec redirection pour forcer un retour vers la page d'origine.

  • marche parfaitement en local ou mutualisé
  • pas de valeurs de retour possible en réponse à la requête
  1. Requête ajax POST/GET vers l'arduino

Transmission de la requête directement à l'arduino, l'arduino envoie une ou des valeurs en retour de la requête.

  • transmission de la requête marche parfaitement en local ou mutualisé vers l'arduino
  • retour de valeur(s) en réponse à la requête impossible, le navigateur bloque toute entrée pour cause de faille xss possible si le chemin de destination est différent de celui qui en fait la demande ...
  1. Requête ajax POST/GET redirection PHP/socket

Transmission de la requête vers une page php chargé de redirigé la requête entière ou partiel vers l'arduino via socket, l'arduino répond au socket avec valeur(s) possible, la page php répond à la requête originel avec les éventuels valeurs transmises par l'arduino.

  • transmission de la requête, marche parfaitement en local ou mutualisé vers la page php
  • socket impossible sur du mutualisé ... donc la requête ne peux être redirigé vers l'arduino
  • marche parfaitement en hébergement local
  1. Requête ajax POST/GET vers page PHP/cURL/HttpRequest/... ?

Pas tester ...

  • demande l’installation de lib (HttpRequest,cURL, ...) qui manipule les sockets de toute fessons donc aucun avantage avec la solution 3.

Hé bien au final il n'y a qu'une solution possible si on veux du bidirectionnel, via socket et en local exclusivement ... parce que c'est soit l’hébergeur qui ne veut pas soit le navigateur qui bloque tout retour ...
Il reste également les websocket mais toujours pas standardisé ...

Yep!

Tu as oublié XAP (XPL)...

Bref description : domotique arduino XAP protocol : Tous les messages sur domotique arduino XAP protocol - Maison Passive projet Pilote

http://www.xapautomation.org/index.php?title=xAP_Home_Automation_protocol

Un exemple : This domain was registered by Youdot.io

C'est pas toujours super documenté, cependant, le proto est plutôt à la portée de tous :wink:

Gromain59 m'avait à une époque lancé sur le sujet...faudrait que je m'y rejette tantôt :grin:

@+

Zoroastre.

zoroastre:
Tu as oublié XAP (XPL)...

Oui mais là il s'agit d'un protocole (langage ici) comme l'est le html, xml, plcbus, modbus, knx, ... que l'on peut diffusé quelque soit le moyen de transport, série, ethernet, usb, etc.
On peux parfaitement diffusé une requête xpl via socket ou requête http comme dans mes testes.
Le problème ici c'est comment échangé ses informations sur le réseau (tcp/ip ou udp) via requête http ou socket ?
Entre () au final tout est socket, même les requête http ce font via socket, il ne s'agit que d'une couche (un protocole) supplémentaire à destination du serveur afin d'échanger les informations d'un autre protocole (xap par exemple) :~
Sinon pour xpl et arduino je ne suis pas un grand fan, du parsing de chaines de caractères c'est extrêmement lourd en processus et mémoire pour nos pauvre petit µc. :drooling_face:

Yep!

Osaka:
du parsing de chaines de caractères c'est extrêmement lourd en processus et mémoire pour nos pauvre petit µc

C'est aussi ce que l'on peut reprocher au html, si on pouvait se contenter d'envoyer une trame sans balises contenant uniquement un entête, les infos avec séparateurs et une confirmation de fin de data, les choses seraient on ne peut plus simple.
Les solutions sont à priori d'utiliser un langage interprété afin de parser les infos vers les bonnes pages ou requettes.

Ne peut-on pas également et quel en est la difficulté, discuter directement avec une base de données genre sql ou access (via XML ou mieux JSON) ???

@+

Zoroastre.

EDIT1 : Tiens çà me rappelle qu'il y a un projet interessant nommé AJSON (arduino-json lib)
http://www.domotichome.net/tutorials/4-json-protocol-for-home/public_show
(les + : pas lourd et facilement interpretable)

zoroastre:

Osaka:
du parsing de chaines de caractères c'est extrêmement lourd en processus et mémoire pour nos pauvre petit µc

C'est aussi ce que l'on peut reprocher au html, si on pouvait se contenter d'envoyer une trame sans balises

C'est exactement ce que je fais actuellement, tout du moin côté arduino de simple donnée binaire en réception et transmission c'est exactement le même protocole que celui que j'utilise sur le rs-485.
Maintenant dans la solution requête Http(navigateur) <-> serveur de contenu web/socket <-> socket/arduino il y a quand même parsing ou autre au niveau serveur pour convertir la requête Http en donnée binaire mais bon ça limite fortement les ressource demandé à l'arduino et délégué plutôt celle ci au serveur qui lui est prévu pour.
Il reste encore la solution websocket que j'utilise actuellement webSocket (navigateur) <-> serveur de websocket (handshake,masking) <-> socket/arduino , il n'y a aucun parsing ou conversion à effectuer juste un "masking/unmasking" qui devrait être optionnel dans le futur normalement, les pages web en eux même pourront être hébergé en local ou extérieurement sur le websocket ne transiteront que les donnée utiles à l'arduino et gros avantage en plus l'arduino peut initié de lui même la conversassion et modifié le contenu web sans demande explicité côté navigateur .

zoroastre:
Ne peut-on pas également et quel en est la difficulté, discuter directement avec une base de données genre sql ou access ???

Ici on peux parfaitement imaginés un client socket supplémentaire (php ou autre) directement associé à une base de donnée tel que mysql, sqLite, prosgreSql, ... là il faudra encore réfléchir. :grin:

Edit:

EDIT1 :

zoroastre:
Tiens çà me rappelle qu'il y a un projet interessant nommé AJSON (arduino-json lib)
http://www.domotichome.net/tutorials/4-json-protocol-for-home/public_show
(les + : pas lourd et facilement interpretable)

J'ai utilisé le format JSon dans mes solutions précédente.

http://arduino.cc/forum/index.php/topic,72035.0.html

uniquement côté navigateur de ce côté ci.

Le gros avantage c'est que le parsing est natif du côté javascript, donc ultra simple à interprété côté navigateur.

Yep!

Osaka, nos posts ont dûs se croiser, je refais un petit up sur AJSON et demande ton avis d'expert dessus XD

Ne peut-on pas également et quel en est la difficulté, discuter directement avec une base de données genre sql ou access (via XML ou mieux JSON) ???

@+

Zoroastre.

EDIT1 : Tiens çà me rappelle qu'il y a un projet interessant nommé AJSON (arduino-json lib)
http://www.domotichome.net/tutorials/4-json-protocol-for-home/public_show
(les + : pas lourd et facilement interpretable)

@+

Zoroastre.

lol j'avais edit ton edit mais ça c'est recroisé donc je remet ici. :grin:

zoroastre:
Tiens çà me rappelle qu'il y a un projet interessant nommé AJSON (arduino-json lib)
http://www.domotichome.net/tutorials/4-json-protocol-for-home/public_show
(les + : pas lourd et facilement interpretable)

J'ai utilisé le format JSon dans mes solutions précédente.

http://arduino.cc/forum/index.php/topic,72035.0.html

uniquement côté navigateur ici, parser côté php.

Le gros avantage c'est que le parsing est natif du côté javascript, donc ultra simple à interprété côté navigateur.
Ca peut être une très bonne solution à ceux qui ne veulent pas gérer des données format binaire, de mon côté je préfère toujours évité les caractères et les chaines qui doivent de toute façons être reconvertie, mais bon c'est toujours une préférence perso.

Gromain59 m'avait à une époque lancé sur le sujet...faudrait que je m'y rejette tantôt

ouiii ?
je confirme que xPL (dérivé simplifié d'XAP) est assez gourmand en ressource.
Ceci dit, moyennant quelques astuces, on arrive à limiter la consommation de RAM. En placant les parties "fixes" des trames émises en mémoire flash par ex.
Pareil pour le parsing, en analysant la trame entrante caractère par caractère au lieu d'utiliser des fonctions type scanf, on utilise beaucoup moins de mémoire.

Pour ma part, comme mes modules xplduino doivent causer entre eux en exécutant des scénarios "évolués", j'ai mis au point un protocole plus léger, via UDP, composé d'un header et d'une partie data. Chaque trame pésera de 5 à 20 octets. Ce même protocole me permettra de configurer les modules à distance au moyen du manager (soft java), et pourra être transporté via RF ou RS485 par ex.
Que devient xPL alors ? C'est un protocole "haut niveau" donc, les états et commandes sont toujours traités et émis. Il sert aux échanges avec l'extérieur (IHM Domogik...)

Voila pour ma contribution au sujet (hors sujet ?)

Gromain

Bonjour à tous,

J'ai essayé de suivre vos discussions sur le sujet, mais plus ça va, moins j'y comprends !

C'est normal ?

@+