Aidez nous ! Projet - Gestion domotique

Artouste: data en demi dur pour un scenario de "reveil" de l'arduino en eeprom, je prévoirais au moins 2 jours J et J+1 de sequençage, en pratique (mais voir occupation de l'eeprom) un certain idéal serait d'avoir une semaine (7 jours) de sequençage, en cas de gros probleme de MAJ , ça permet de tourner sur le cycle des 7 jours precedant la derniere MAJ

C'est vrai qu'il faut voir ce que cela donne : une plage horaire de HH1:MM1 à HH2:MM2 peut être stockée sur 4 octets, je vais avoir au maximum : 7 zones de chauffage + 10 zones d'arrosage + 10 zones d'éclairage + 5 zones pour les volets (je ne sais pas encore si les volets suivront des plages horaires) mais mettons ! soit 32 zones avec au maximum 3 plages horaires => 96 plages horaires de 4 octets => 384 octets/jour ce qui fait au total 2688 octets ce qui est jouable sur une Mega 2560 (si je n'ai pas fait d'erreur !)

Artouste: Accessoirement en regardant un produit évoqué sur une autre topic, je suis tombé sur ça shield RS485 (en half) http://www.robotshop.com/eu/rs485-shield-arduino-3.html

C'est pas mal, mais j'ai ça http://www.goodluckbuy.com/arduino-io-expansion-shield-v5-xbee-sensor-shield-rs485.html en commande. Je pense que c'est pareil avec des choses en plus.

Yop Artouste, j'avais déjà vu ce shield et je me posais la question de savoir à quoi servait le bss123 (q1) que je vois dans son schéma, sélection "automatique" entre transmission/réception, enfin surtout pour la transmission ?

2) essayer d’utiliser le serveur du disque dur NAS (je ne sais pas si cela est possible). - Avantage : accès facile depuis réseau local ? - Inconvénient : pb si NAS HS

Moi j'opterais bien pour cette solution avec un produit de ce type : Synology Disk Station DS110j 500 Go, si vous connaissez moins cher je suis preneur du tuyaux, car je le trouve un peu cher quand même.

Maintenant pour le problème du NAS HS, c'est vrai cela peu arriver, mais bien protéger avec un onduleur, je trouve que cela est la solution la plus fiable. Le serveur web ne sera pas toujours joignable (j'ai de gros problème avec celui de mon fournisseur), l'espace de stockage de l'arduino est trop limitée et il ne gère ni le PHP, ni le sql (moins pratique pour le stockage et l'utilisation des données).

Donc pour commencer mes essais, je vais commencer par le serveur web sur internet pour migrer par la suite vers une solution de ce type si je ne suis pas satisfait de l'hébergement en ligne.

Comme je l'ai déjà spécifié moi je compte sur un arduino contrôleur uniquement dédié au scénario, plage horaire, ... Il enverrait la/les trame(s) trame correspondante préfixé selon horaire ou autre conditions. Maintenant la solution web est pas plus mal, pour cette solution je verrais bien la proposition du nas ou plutôt encore plus minime mais largement suffisant, quelque chose comme ça, simple, pas chère (entre 60-70€ sur baybay, 20-30€ sans l'écran tactil) http://www.pobot.org/Rapide-presentation-de-la-carte.html avec openWrt d'installer.

Yep!

Je rejoins osaka dans sa reflexion, je préfère que ce soit l'arduino qui s'occupe de la gestion des plages horaires. Utiliser un serveur ou une mini-board revient en définitive à déporter le cerveau sur un équipement de ce genre. Donc, à priori, l'arduino maître est mort ?

Une autre option qui me plairait plus serait de séparer l'applicatif du contexte hardware, l'applicatif dans mon sens ne doit pas piloter les cartes, il sert à ajuster les paramètres et prendre compte des anomalies. Un historique des manipulations diverses peut être sauvegardé sur celui-ci, ce n'est pas vraiment un problème. Mais le cerveau doit être le plus embarqué possible dans la partie hardware et ne doit pas souffrir d'une multitude d'applicatif ou de contexte trop différent. Openwrt ou consors, reviendrait à ajouter une tâche supplémentaire à un projet en plein essors. Linux est un monde à lui seul. Ce que l'on recherche en définitive est que l'installation soit la plus autonome possible. Naturellement, un sîte web est bien jolie. Mais ce n'est qu'une option possible.

Pour évoluer en terme d'espace de stockage, la solution la plus simple est d'ajouter une eeprom. Il existe des eeprom de 512K bus I2C à des tarifs raisonnables.

@+

Zoroastre.

@osaka, elle a l'air sympa cette carte !

Est ce qu'on peut imaginer dupliquer le site automatiquement avec rafraichissement régulier (toutes les x heures), par exemple chez un hébergeur et sur le NAS (ou carte serveur web) et faire en sorte que l'arduino se connecte sur l'un et s'il n'arrive pas à se connecter, il va chercher les infos sur l'autre site ?

zoroastre: Une autre option qui me plairait plus serait de séparer l'applicatif du contexte hardware, l'applicatif dans mon sens ne doit pas piloter les cartes, il sert à ajuster les paramètres et prendre compte des anomalies. Un historique des manipulations diverses peut être sauvegardé sur celui-ci, ce n'est pas vraiment un problème. Mais le cerveau doit être le plus embarqué possible dans la partie hardware et ne doit pas souffrir d'une multitude d'applicatif ou de contexte trop différent. Openwrt ou consors, reviendrait à ajouter une tâche supplémentaire à un projet en plein essors. Linux est un monde à lui seul.

Je ne comprends pas tout ce que tu écris là, comme je l'ai déjà expliqué, je ne suis pas familier des technologies réseau. Pourrais-tu stp développer un peu ? Merci

Donc, à priori, l’arduino maître est mort ?

Non pas du tout bien au contraire, il est le coeur du système.

Pour moi le serveur servira a recueillir et stocker les données de l’arduino, températures, consommation, etc… et a activer les modules en fonction d’ambiances par exemple. L’interface web me permettra aussi de programmer les plages horaires des différents modules, maintenant en aucun cas elles seront stocker sur le web le serveur les enverra sur l’arduino et ira chercher les valeurs sur l’arduino, maintenant si il y a une panne sur le serveur l’arduino sera complètement autonome et c’est cela qu’il faut.

Maintenant pour le stockage des données horaires etc j’avais envisager l’emploi de la SD card en y créant des fichers txt. L’arduino est tout a fait capable de gérer un fichier texte en faisant du parsing. Il y aurait un fichier texte pour le chauffage, un pour l’arrosage etc… et dans le fichiers texte il y aurait par exemple :
[LUNDI][MARCHE][08:00][ARRET][10:00] [LUNDI][MARCHE][20:00][ARRET][22:00]
[MARDI][.......] [MERCREDI]…

et cela serait ces données qui seront écrites par le serveur web et c’est également ces données que le serveur irait lire.

Yep!

Est ce qu'on peut imaginer dupliquer le site automatiquement avec rafraichissement régulier (toutes les x heures), par exemple chez un hébergeur et sur le NAS (ou carte serveur web) et faire en sorte que l'arduino se connecte sur l'un et s'il n'arrive pas à se connecter, il va chercher les infos sur l'autre site ?

Je réponds à la place d'osaka, car j'ai déjà réalisé ce type d'opération. Et je répondrais "oui". La seule réserve que l'on peut apporter se trouve au niveau des données à synchroniser, si elles sont importantes en terme de taille, il y risque que le site en cours de synchro soit inactif ou difficilement joignable. Mais bon, si on programme la synchro à 2 heure du mat, c'est quasi-transparent. (rsync fait çà trés bien, par exemple.) Le second petit bémôl est que les hebergeurs utilisent le protocole ftp pour nourrir l'espace d'hebergement. C'est pas trés "secure".

... Pourrais-tu stp développer un peu ?

Je voulais simplement appuyer le fait que le développement logiciel était une chose, mais que l'objectif principal est de proposer une solution hardware AUTONOME. En définitive, dés le moment où la carte arduino a la faculté de communiquer avec l'exterieur, nous ne devrions pas nous occuper de se qui se passe à l'autre bout. Dés le moment où la carte est programmée, il n'y plus d'intervention humaine ou trés peu.

EDIT1: La carte Sd me plait bien aussi, mais dans mes précedents essais, j'ai eu des résultats peu concluants. En plus, les librairies sont lourdes.

@+

Zoroastre.

Merci pour vos réponses.
Les choses se mettent petit à petit en place.
Il y a encore beaucoup de travail, mais c’est super interessant.

zoroastre: Ce que l'on recherche en définitive est que l'installation soit la plus autonome possible. Naturellement, un sîte web est bien jolie. Mais ce n'est qu'une option possible.

Tu résumes parfaitement le côté le plus intéressant du projet, autonomie, optionnel. :) Quelque soit la solution choisie par chacun, pas de problème pour donner un coup de main en tout cas. (chacun a ses propre compétences) ;)

Pour la synchro comme le dit zoroastre en choisissant le bon moment ça devrait pas posé de problème. Pour l'eeprom ou sd je peux pas vraiment conseillé comme jamais testé, mais comme le dit zoroaste j'ai souvent constaté sur le forum des problèmes (carte hs, perte de données, ...) avec la sd ainsi qu'une lib plutôt lourde (apparemment il y en a une plus performante que l'officiel dont je sais plus le nom) :zipper_mouth_face: .

J'arrive un peu après la bataille mais bon :P Pour le stockage des paramètres je pense qu'ils doivent être initialisés à des valeurs logique (par exemple chauffage de 6 à 8h et 16 à 23h) au démarrage du programme. Reglage via le web au démarrage si possible, et dès qu'un paramètre est changé dans l'interface web il est envoyé à l'Arduino. J'envisage le stockage en EEPROM mais pas eu le temps :)

Si je résume ce qui est proposé pour le stockage des données, et particulièrement celles de type "plages horaires" : - On fixe des plages horaires par défaut, en dur => EEPROM ou flash (à voir en fonction de la carte arduino), ce qui permet d'avoir un système qui fonctionne en autonomie, même sans connexion au web. - On vient modifier les plages horaires sur un serveur web externe (plusieurs possibilités : hébergement, NAS, petit serveur autonome, ...) ces plages modifiées deviennent les nouvelles plages par défaut (donc remplace les anciennes ?). Comment identifier les plages horaires qui ont été modifiées par le web pour pouvoir les changer en mémoire EEPROM ou Flash de l'arduino ? J'ai pensé : - le serveur web vient récupérer toutes les données pour les afficher, on les regroupe par paquets (par jour, ou par zone, ou ...) on fait un checksum par paquet, - on vérifie les checksum des paquets en mémoire dans l'arduino et ceux des données affichées, - si les checksum ne sont pas identiques, on transmet le paquet. Qu'en pensez-vous ? Ou avez vous d'autres solutions plus opérationnelles.

Brisebee: Si je résume ce qui est proposé pour le stockage des données, et particulièrement celles de type "plages horaires" : - On fixe des plages horaires par défaut, en dur => EEPROM ou flash (à voir en fonction de la carte arduino), ce qui permet d'avoir un système qui fonctionne en autonomie, même sans connexion au web. - On vient modifier les plages horaires sur un serveur web externe (plusieurs possibilités : hébergement, NAS, petit serveur autonome, ...) ces plages modifiées deviennent les nouvelles plages par défaut (donc remplace les anciennes ?). Comment identifier les plages horaires qui ont été modifiées par le web pour pouvoir les changer en mémoire EEPROM ou Flash de l'arduino ? J'ai pensé : - le serveur web vient récupérer toutes les données pour les afficher, on les regroupe par paquets (par jour, ou par zone, ou ...) on fait un checksum par paquet, - on vérifie les checksum des paquets en mémoire dans l'arduino et ceux des données affichées, - si les checksum ne sont pas identiques, on transmet le paquet. Qu'en pensez-vous ? Ou avez vous d'autres solutions plus opérationnelles.

réflexion L'index simple est aussi utilisée dans certains domaine pour verifier si une nouvelle MAJ distante doit être faite en local. L'index 0 faisant office de RAZ L'interrogation du distant par le local ne faisant que vérifier périodiquement si le dernier index distant est supérieur au dernier index local récupéré/enregistré (l’écrasement de l'index local par celui distant étant la dernière opération à effectuer) pour enregistrer en EEP (ou autre demi dur) la dernière version dispo. un index de type word sur une MAJ possible de 12 fois par jour (c'est déjà luxe) permet déjà sans débordement de frôler les 15 ans .. et dans 15 ans .... 8)

Bonjour,

Ayant lu l'ensemble des participations à ce fil très intéressant et compte tenu du besoin que j'avais exprimé il y a quelques jours, il me semble important de définir la structure du système. Je viens donc vous faire part de cette réflexion.

Voici comment je vois la structure d'un tel système :

1) Un réseau temps réel constitué d'une carte arduino maître et de cartes esclaves spécialisées en terme de fonctions. Pour respecter l'aspect temps réel, les modules dialoguent à l'aide d'un bus terrain sur RS 485 par exemple. J'imagine que les librairies existent déjà pour l'arduino. Ce sous-système gère les capteurs et actionneurs ; il doit être totalement autonome en terme de process, les paramètres de fonctionnement étant stockés dans l'arduino maître, avec des paramètres par défaut et des paramètres "courants" issus de la dernière modification par l'utilisateur, les valeurs par défaut permettant un démarrage initial. Par ailleurs, chaque carte de fonction, en plus de faire tourner ses algorithmes (régulation, autosurveillance...) renvoie des infos de valeurs et d'états à la carte maître. Ce sous-système est relié au reste du monde par une liaison Ethernet sur le réseau local de la maison.

2) Un sous-système de supervision chargé d'assurer l'interface homme-machine. Il est inutile que la supervision soit "temps réel", un bus informatique lui convient ce qui autorise de la même manière, les actions locales et distantes à travers le web. La supervision consisterait donc en un site web installé sur un serveur (NAS ou autre) implanté sur le réseau local de la maison. Quelques pages web devraient suffire pour permettre de modifier les paramètres "courants" contenus dans la carte maître du sous-sytème 1 et donc son comportement. La supervision rapatrierait également les infos d'état du sous-sytème 1 ainsi que des données des capteurs…à définir.

3) Une fonction d'alerte La fonction d'alerte est nécessaire pour signaler spontanément des informations de dysfonctionnement du sous-système 1 ou encore des alarmes d'intrusion si la fonction de système d'alarme est utilisée. Sur occurrence d'un tel évènement, la carte maître pourrait faire émettre un sms circonstancié par le web vers un téléphone programmé.

En conclusion, la structure définie ci-dessus est autonome sur le process, consultable et modifiable en local ou à distance grâce à la supervision ; elle génère "également des messages spontanés (alarme, dysfonctionnement…).

Qu'en pensez-vous ?

C'est en gros ma vision des choses et celle des autres participants de ce fil. Je vois en tout cas que beaucoup de personnes suivent celui-ci et toutes les contributions sont intérréssantes.

Une question mais venue a l'esprit ce soir, le contrôle d'une ampoule peu facilement s'effectuer a l'aide d'un MOC + TRIAC mais qu'en est t'il de ces fameuses ampoules a économies d'énergie, sont t-elles toutes des charges inductives cas dans lequel il faudra adapter le dispositif de commande a la puissance de l'ampoule si j'ai bien compris, c'est un peu galère cela. De plus en faisant des recherches a ce sujet j'ai appris deux choses concernant ces ampoules elle rayonnent beaucoup et de plus celui-ci change en fonction de la polarité de l'ampoule (position de la phase et du neutre).

Bonsoir,

Les ampoules à économie d’énergie peuvent être commandées par un triac mais uniquement en tout ou rien, elles sont généralement spécifiées “non dimmable” ce qui signifie qu’elle ne peuvent être modulées par un variateur équipé d’un triac qui fait varier l’angle de passage du courant pour diminuer la valeur efficace.
Seules les lampes halogènes (encore autorisées…) permettent de les connecter à un variateur.

Que les lampes à économie d’énergie rayonnent un champ électromagnétique, c’est normal puisqu’elles contiennent un convertisseur haute fréquence. Par contre, je ne vois pas pourquoi ce champ serait dépendant du sens de connexion à la phase et au neutre…

Je me posais également cette question sur les lampe à économie d'énergie et la variation, il semble y en avoir de plus en plus avec cette possibilité. exemples : http://www.produits-economiques.com/produkt.php?lang=fr&pm_id=1495 http://www.produits-economiques.com/products/stufenlos_dimmbare_esl.php?lang=fr

Ca devrait passé non ?

Post précédent apparemment pas envoyé ce W-E.

En ce qui concerne le stockage des données du programme pour les plages horaires, pour un MEGA je recommande vraiment l'EEPROM : facile à utiliser, largement assez grand (4K), fiable, et surtout, limite les dépendances (tant des librairies que de "l'environnement").

La carte SD, c'est peut--être plus pratique, mais il faut alors aussi inclure dans le sketch toute une série de "précautions" : que faire si elle est absente lors d'un reset, comment détecter le changement, quid des erreurs de format dans le fichier, etc.

Evidemmmnt, on peut rajouter un système de commande déporté avec site web, mais il faut plus voir çà comme de l'OAM (gestion des opérations), çà doit pouvoir "foirer".

A noter au sujet des ampoules économiques et dimmer : j'ai expérimenté à ce sujet, et si les halogènes sont bien dimmables, ce n'est pas à recommander : J'ai une suspension avec 6 lampes 220V G9, dimmée, et deux appliques assorties (une ampoule) non dimmées. La durée de vie des ampoules dimmées est bien inférieure aux autres. J'ai lu quelque part qu'il fallait faire tourner les ampoules halogènes à 100% régulièrement pour redéposer les particules gazeuses sur le filament, ou quelque chose comme çà. Pour en terminer sur les halogènes : le rendement des 12V est supérieur à celui des ampoules 220V, même en tenant compte des pertes du transfo.

Pour les TL dimmables, pas trop recommandé non plus : plus de scintillement visible, et perte sensible d'efficacité, car la lampe à 80% de puissance a probablement perdu 50% de lumière émise.

En plus, les dimmers coûtent cher, et chauffent, donc durée de vie limitée aussi.

Au sujet des LED, méfiance : toujours se rappeler que la LED n'est que 10x plus efficace que l'incandescence. Donc une 'super LED' 3W ne brille que comme une ampoule 30W.

Conclusion : mieux vaut éviter les dimmers, et choisir la source de lumière adaptée (luminaire, ampoules) pour la faire fonctionner à 100%.