Toujours en étude de la solution Arduino pour mon installation domotique ( )
je souhaiterais connaitre les limites de nos chers arduino, non pas purement hardware mais dans la capacité à accomplir certaines taches comme par exemple :
Est-il possible de rétablir par un quelconque moyen les entrées et sorties après un coupure d'alimentation dans l'état précédent celle-ci ( watch dog) ?
Est-il possible de lire et écrire des données dans une base de donnée ( par ex Mysql) sur un pc local SANS shield ethernet => usb ?
Dans la même optique, quel est le moyen le plus efficace pour réaliser une interface Arduino <=> Logiciel VB .net ?
Mes post non en général pas beaucoup de succès, je remercie donc d'avance toute personne sachant amener un élément
Ce n'est pas le Watchdog qui surveille la tension d'alimentation, mais le Brown-Out Detector. S'il est activé et que la tension d'alimentation descend en dessous d'un certain, il provoquera un reset. Je n'ai jamais testé, mais toutes les informations doivent être dans la doc...
En cas de coupure d'alimentation, il y aura vraisemblablement un Power-On Reset.
Le Watchdof va plutôt provoquer un reset quand l'exécution du logiciel est bloquée quelque part.
Pour récupérer les données, il faudra développer un logiciel résident sur le PC qui récupèrera les données pour les enregistrer en base de données : Arduino -> Logiciel PC -> Base de données.
Il te faudra concevoir un protocole de communication. Si tu regardes dans les tutos, Barbudor donne des pistes ici... Ou alors dans les sujets sur la domotique.
Est-il possible de rétablir par un quelconque moyen les entrées et sorties après un coupure d'alimentation dans l'état précédent celle-ci ( watch dog) ?
Est-il possible de lire et écrire des données dans une base de donnée ( par ex Mysql) sur un pc local SANS shield ethernet => usb ?
Sans logiciel relai entre l'usb et la bdd non, mais avec un logiciel (python + pyserial + mysql, php + phpserial + mysqli, ...) tu peut le faire sans probléme.
Il faudra quand même prévoir un protocole de communication même minimaliste
chestroled:
Dans la même optique, quel est le moyen le plus efficace pour réaliser une interface Arduino <=> Logiciel VB .net ?
En VB.net, simple System.IO.Ports.SerialPort + protocole maison (voir le tuto de barbudor sur le forum)
Je suis au boulot, je te répond donc avec ma tartine
D'abord merci pour ta réponse surtout ton lien vers le travail de Barbudor qui est exactement le genre d'explications et documentation que je recherche !
Concernant le "watchdog" le mot employé n'est pas réelement ce que je veux eprimer car c'est différent. Je vais dons essayer de complteter : l'idée est de savoir si hormis le reset qui relance simplement le programme il était possible de mettre en place un systeme à mémoire capable de replacer les entrées et sorties dans le même état précédent à la coupure de l'alimentation ?
Toujours dans cette optique de "limite", et en lisant l'exposé de Barbudor , en terme de mémoire et de charge locigicelle, un arduino MEGA avec toutes ces entrée et sorties utilisées peut-il gerer un protocole ASCII full ou half duplex avec verification CRC sans grosses latences ? Dans quelles proportions ? Ouf que de reflexions ....
Entre temps arrive la réponse de notre cher skywodd dont son blog me vaut des réprimendes de ma femme ( ben oui les explications y sont longues et pasionnante ma 'ptite dame)
Revenons en donc au sujet : je lrai tout à l'heure les explications concernant les EEPROM.
au sujet de la BDD, je vais donc faire plus simple : Arduino <=> Homeseer <=> Serveur Mysql
Et enfin si je parlais du VB ce n'ast pas un hasard mais bien du au fait que le logiciel qui sera présent sur le serveur domotique sera en VB .net j'ai nommé Homeseer ( désolé les fan linux..)
chestroled:
l'idée est de savoir si hormis le reset qui relance simplement le programme il était possible de mettre en place un systeme à mémoire capable de replacer les entrées et sorties dans le même état précédent à la coupure de l'alimentation ?
bonjour
la solution passe inévitablement (pour rester dans le simple) par l'eeprom
avec comme corollaire l'obligation de prendre en compte le nombre de cycles d'ecritures qui est là le point critique.
il faut donc enregistrer le moins souvent possible, mais enregistrer quand même l'etat.
Il faut poser sur le papier ce qui est imperatif de sauvegarder pour remise en etat apres coupure
chestroled:
Concernant le "watchdog" le mot employé n'est pas réelement ce que je veux eprimer car c'est différent. Je vais dons essayer de complteter : l'idée est de savoir si hormis le reset qui relance simplement le programme il était possible de mettre en place un systeme à mémoire capable de replacer les entrées et sorties dans le même état précédent à la coupure de l'alimentation ?
La seule solution réellement envisageable c'est l'EEPROM, comme le précise Artouste le nombre de cycles d'écriture est un point critique.
Il faut sauvegarder l'état des pin certes, mais le moins souvent possible.
Pour éviter d'avoir à changer l'ATmega après n jours/mois/années l'idéal serait d'avoir une EEPROM externe, exemple 24Cxxx (EEPROM I2C).
Ou mieux d'utiliser une mémoire NVRAM (mémoire RAM non volatile, avantage d'une RAM en terme de cycles d'écriture + conservation de données en cas de coupure d'alim).
chestroled:
Toujours dans cette optique de "limite", et en lisant l'exposé de Barbudor , en terme de mémoire et de charge logicielle, un arduino MEGA avec toutes ces entrée et sorties utilisées peut-il gerer un protocole ASCII full ou half duplex avec verification CRC sans grosses latences ? Dans quelles proportions ? Ouf que de reflexions
Ho oui sans probléme
Regarde sur le forum, la partie tuto et sur mon blog il y a un nombre relativement conséquent d'exemple de "mini protocole" ASCII + décodeur arduino.
Pour le calcul de CRC c'est déja inclut dans la avr-libc http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html
chestroled:
Entre temps arrive la réponse de notre cher skywodd dont son blog me vaut des réprimendes de ma femme ( ben oui les explications y sont longues et pasionnante ma 'ptite dame)
skywodd:
La seule solution réellement envisageable c'est l'EEPROM, comme le précise Artouste le nombre de cycles d'écriture est un point critique.
Il faut sauvegarder l'état des pin certes, mais le moins souvent possible.
...
Pour éviter d'avoir à changer l'ATmega après n jours/mois/années l'idéal serait d'avoir une EEPROM externe, exemple 24Cxxx (EEPROM I2C).
Bonjour skywodd
ta reponse me fait penser que generalement les "projets domotique" embarque une RTC
la plus utilisée étant la DS1307 en I²C et qu'elle embarque une zone RAM generalement oubliée/inutilisée (debut en 08H)
56-Byte, Battery-Backed, General-Purpose RAM with Unlimited Writes
I2C Serial Interface
c'est aussi une option envisageable et facile à intégrer
Tout ce que tu demandes est facilement soluble à condition de savoir développer sur Arduino et sur PC.
A priori ce n'est pas un travail de débutant. Tu peux y arriver en assemblant des bout de codes provenant des uns et des autres mais ce genre de réalisation fonctionne rarement bien.
Je pense que tu devrais d'abord essayer d'acquérir une certaine expérience de la programmation et des concepts associés avant de te lancer dans ce projet.
L'ideal sur le PC est d'écrire un service qui tourne en tâche de fond en dehors de toute session utilisateurs. Ce simple point nécessite déja de savoir programmer sur PC. Il te faudra avant tout définir sur le papier un protocole de communication entre ce service et l'Arduino.
En ce qui concerne l'EEPROM le nombre de cycles erase/write est de 100 000. Il ne faut donc pas faire d'écriture systématique mais n'écrire que les valeurs qui changent. En domotique cela ne doit poser aucun problème.
Afin de gérer réellement les problèmes de transition j'essaierai d'utiliser des relais bistables qui resteront dans la dernière position au retour secteur alors que dans les autres cas ca risque de bagotter pendant le reset.
En ce qui concerne l'EEPROM le nombre de cycles erase/write est de 100 000.
Pour l'eeprom interne au micro-controleur oui, mais pour les eeproms externes la limite est 10 fois plus avec l'avantage de pouvoir les changer aisément alors qu'avec celle interne au micro c'est le micro qu'il faut changer.
Les eeproms externes se trouvent en boîtier dip8 protocole I2C (ou ISP pour certaines).
Il y a aussi un autre point non négligeable : la taille.
Avec l'EEPROM interne la taille est fixe, avec une EEPROM externe c'est toi qui choisi en fonction de ton application.
(Bon ok faut le vouloir pour remplir 1Ko d'EEPROM (m328p) ou 4Ko (m2560) avec des info de configuration ...)
jihelbi:
Tout ce que tu demandes est facilement soluble à condition de savoir développer sur Arduino et sur PC.
A priori ce n'est pas un travail de débutant. Tu peux y arriver en assemblant des bout de codes provenant des uns et des autres mais ce genre de réalisation fonctionne rarement bien.
Je pense que tu devrais d'abord essayer d'acquérir une certaine expérience de la programmation et des concepts associés avant de te lancer dans ce projet.
Tu soulève un point critique de mon projet ,la programmation . En effet j'ai d'assez bonne connaissances dans beaucoup de domaine mais n'ai pas d'expérience en prog. Du coup je sais que je suis capable de développer ce genre de choses même si il me faudra du temps je pense qu'avec l'aide de la communauté je peux y arriver. Je n'aime pas passer par des solutions toute faites qui ne répondent pas à mes besoins, puis de toute manière cela n'existe pas ou alors on parle en K€ .... Puis faut avouer, mettre les mains dans le cambouis j'adore !
Dans cette optique d'un long développement et pour ne pas brider les fonctions de la maison mais aussi par sécurité, toute les fonctions primaires sont câblées en direct . Le système domotique est alors la uniquement pour connaitre l'état d'un élément et pouvoir le modifier , mais a tout moment, les commandes physiques on l’absolue priorité.
Je commence dès à présent un cahier des charges global afin de vous exposer le principe de fonctionnement et aussi écouter vos commentaires et corrections .
Pour en revenir à l'eeprom, le fait d'imposer d'entrée de jeux des limites d'écriture ne me plait gère, le but est d’obtenir une solution la plus pérenne possible. Je vais étudier la solution des relais bistables.
J'ai 1000 questions précises, c'est à la fois très motivant mais aussi frustrant d’espérer que tout va fonctionner comme prévu....
Bonne soirée et bon weekend, je met en ligne le cahier dès que je l'ai terminé.
Les informations concernant la carte Velleman K8006 sont indiquées dans les commentaires sur Google Document mais vous pouvez aussi découvrir l'infosheet ici :
Vu la faible consommation d'un arduino, on peut envisager de garder la carte de commande sur batterie, avec une entrée qui surveille la présence du secteur et une qui surveille l'état de la batterie.
En effet, plutôt que d'ajouter une fonction de mémorisation des E/S il est je pense plus simple et fiable de maintenir l'alimentation des composants principaux.
L'ensemble Serveur + Cartes Arduino + Switch + NAS seront maintenus par un onduleur piloté ( à choisir en fonctions des puissances nécessaires).
Voici concernant la platine K8006 un essai rapide après montage.
Sans doute a cause de mon métier d'électricien industriel qui fait un peu d'automatisme de tps en tps, j'imagine plutot une architecture qui se rapproche de ce qu'on fait dans l'industrie quand il y'a un automate, des peripheriques, et un systeme qui supervise l'ensemble.
Avec une archi de ce genre, seul l'arduino-automate a besoin de rester sous tension lors des coupures secteur.
Aujourd'hui j'ai une petite idée (pas très précise cependant) de quoi mettre dans l'arduinautomate (qqch qui ressemblerais a ce qu'il existe dans les API qui je connais déjà, a quelques doutes près)
Mais je ne sait pas trop que bus de terrain choisir.
L'i2c semble le plus pratique a exploiter coté arduino, mais pas sur qu'il "passe bien" dans une instal domestique. Un des membres du Forum a déjà fait pleins de trucs sur cette base il me semble, a voir ses retours d'expérience)
Le CAN pourrait etre une alternative intéressante ( Big On/Off a développé énormément de trucs sur PIC autour du bus CAN, il faut que j'y regarde de plus pres mais j'y connais que dalle en CAN, et la mise en oeuvre sur Arduino ne semble pas très pratique, ou du moins pas très commune)
Par contre je suis incapable de m'occuper de la partie serveur, du moins pour l'instant (je vais reprendre mes études prochainement (je vais faire une licence pro Automatisme & info indus), et j'espère que ce sera l'occasion d'apprendre des trucs qui me serviront pour ça)
MiGaNuTs:
Sans doute a cause de mon métier d'électricien industriel qui fait un peu d'automatisme de tps en tps, j'imagine plutot une architecture qui se rapproche de ce qu'on fait dans l'industrie quand il y'a un automate, des peripheriques, et un systeme qui supervise l'ensemble.
Avec une archi de ce genre, seul l'arduino-automate a besoin de rester sous tension lors des coupures secteur.
)
c'est le jeu ma pauvre lucette !
