Oui c’est vrai j’ai oublié de supprimer les deux autres LED de visualisation qui ne servent plus a rien.
Je laisse tombé l’EJP alors (maintenant tu peux le lire sur l’arduino et actionner en fonction de l’EJP)
Une dernière question concernant ce montage avant que je fasse le typon, tu peux mettre un lien sur le type d’interrupteur que tu utilises s’il te plait.
Pour les condensateurs du régulateur, ce sont des chimiques ?
Skuzmitoo: Une dernière question concernant ce montage avant que je fasse le typon, tu peux mettre un lien sur le type d'interrupteur que tu utilises s'il te plait.
Pour le switch c'est le modèle DPDT On-Off-On 1MD3T1B5M1QE sur la page http://fr.farnell.com/jsp/level5/module.jsp?moduleId=fr/311897.xml
Skuzmitoo: Pour les condensateurs du régulateur, ce sont des chimiques ?
Le condensateur avant le régulateur est un chimique et celui après un tantale goutte.
Bon, maintenant que nous avons bien avancé sur l’aspect matériel du pilotage d’un chauffage électrique, nous pouvons passer à autre chose !
Pour moi, se posent des tas de questions, je vais essayer de les ordonner et de ne pas toutes les poser en même temps, je commence par les deux qui me préoccupent le plus et qui conditionnent la suite.
1) Je veux pouvoir faire fonctionner mon chauffage (mais, c’est aussi vrai pour d’autres fonctions : arrosage, éclairage ?, …) selon des plages horaires déterminées, par exemple. a) pour les zones 1,2 et 4 : - les lundi, mardi, mercredi, jeudi et vendredi selon : de HH1:MM1 à HH2:MM2 et de HH3:MM3 à HH4:MM4 - les samedi et dimanche selon : HH5 :MM5 à HH6:MM6 et de HH7:MM7 à HH8:MM8 b) pour les zones 3 et 5 : les lundi, mardi, jeudi et vendredi selon : de HH9:MM9 à HH10:MM10 et de HH11:MM11 à HH12:MM12 - les mercredi, samedi et dimanche selon : HH13 :MM13 à HH14:MM14 et de HH15:MM15 à HH16:MM16
C’est vraiment un exemple, il faut que cela soit le plus souple et malgré tout le plus simple possible !
J’ai une horloge temps réel DS1307 connectée sur mon arduino.
Ma question : Où est-il le plus pratique de stocker les différentes données des plages horaires ? Dans l’arduino, en mémoire flash ? Toutes ou celles de la journée en cours ? Si c’est uniquement celles de la journée en cours => les autres données sont stockées sur le serveur web.
2) Ma deuxième question concerne le serveur web : il en a déjà été question dans des contributions précédentes de ce même sujet, des avis ont été donnés mais il n’y a pas d’option choisie. - J’ai une carte Ethernet shield W5100 avec lecteur SD, mais j’ai aussi une carte Ethernet shield ENC28J60. - J’ai également un disque dur NAS (Iomega Home Media) qui tourne en permanence et est branché le réseau local, avec lequel je crois pouvoir faire un serveur web. - J’ai également un (petit) espace hébergé avec un nom de domaine.
J’ai donc plusieurs possibilités : 1) utiliser uniquement l’arduino Mega 2560 avec Ethernet Shield, s’il est possible de stocker une partie des données et des images sur la carte SD. - Avantage : l’accès aux données est facile (si ce n’est que je n’ai pas trouvé comment stocker et lire sur la carte SD). - Inconvénients : espace de stockage limité (sauf si SD fonctionnelle), accès par le web ? 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 3) utiliser un espace hébergé. - Avantage : accès facile depuis le web - Inconvénient : ne marche pas si pas de connexion ADSL ou si hébergeur inaccessible (rare).
Vers quelle solution me conseilleriez-vous de m’orienter, en sachant que je ne suis pas du tout un spécialiste des réseaux et de la programmation web ?
Brisebee: J’ai une horloge temps réel DS1307 connectée sur mon arduino.
Ma question : Où est-il le plus pratique de stocker les différentes données des plages horaires ? Dans l’arduino, en mémoire flash ? Toutes ou celles de la journée en cours ? Si c’est uniquement celles de la journée en cours => les autres données sont stockées sur le serveur web.
reflexion rapide 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 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
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).