GROWDUINO [Zone de partage]

[Gen 2 808]

re

 

J'ai fais la mise à jour de l'archive V1_40 post#1

 

++

GEN

[Viker 147]

yop j'ai trouvé mon étourderie (j'aime bien ce mot)

 

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,invertedRelay);

 

à remplacer par

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

 

j'ai supprimé la variable invertedRelay qui ne sert plus

 

ce qui donne au niveau des déclaration ceci

DailyTimer          TIMER_1(TIMER1_PIN    , false);    
DailyTimer          TIMER_2(TIMER2_PIN    , true);
Cyclic              CYCLIC_1(CYCLIC1_PIN  , CYCLIC1_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
Cyclic              CYCLIC_2(CYCLIC2_PIN  , CYCLIC2_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
HystDrive           TEMP_DRIVER(TEMP_U_PIN,TEMP_D_PIN,true);
HystDrive           HUMIDITY_DRIVER(HR_U_PIN , HR_D_PIN, true);
MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

j'ai mis pour le test l'echantillonage à 2 sec pour le test, (ça fonctionne nickel) perso je travaillerai avec 30s pour les petits espaces et 60-120 pour les grandes salles

 

Merci pour tes interventions, cela fait avancer le schmilblick

 

++

GEN

 

Alors moi je suis en true mais c'est selon le relais.

Et pour mon espace j'ai mis 30s et c'est nickel.

 

++

Viker

Modifié août 28, 2017 par Viker

[Gen 2 808]

Re:

Suite à une réflexion, je me suis dit pourquoi ne pas laisser aux gens la possibilité de choisir le mode de fonctionnement des relais via un menu. Certains utilisent des relais SSR actif état haut ou état bas, d'autres des relais mécaniques etc

 

Je vais modifier le code afin que l'on ne doivent pas à chaque fois compiler et recharger le menu si l'on désire modifier le type de relais.

 

Qu'en pensez-vous ?

 

++

GEN

[Roucass 61]

Slt, je pense que ça serait une bonne idée. Si j'ai bien compris il s'agit de la partie moteur (intraction extra).

Je pense que si y en a qui utilise différent montage c'est qu'il en on besoin, du coup ça permettra d'avoir un code "universel " adapté à tous

[Gen 2 808]

Salut roucass

 

Pas que pour les moteurs (intra et extra), pour toutes les sorties Timer1,Timer2 etc..

 

++

GEN

[Roucass 61]

Ah d'accord encore mieux

Modifié août 29, 2017 par Roucass

[Viker 147]

Re:

Suite à une réflexion, je me suis dit pourquoi ne pas laisser aux gens la possibilité de choisir le mode de fonctionnement des relais via un menu. Certains utilisent des relais SSR actif état haut ou état bas, d'autres des relais mécaniques etc

 

Je vais modifier le code afin que l'on ne doivent pas à chaque fois compiler et recharger le menu si l'on désire modifier le type de relais.

 

Qu'en pensez-vous ?

 

++

GEN

 

Salut,

 

c'est un plus mais est-ce indispensable?

je m'explique. Quand j'ai fait ma box j'ai initialisé mon programme en fonction des relais que j'utilisais (état haut ou état bas) on jouant sur invertedRelay ou en mettant true ou false en fin de lignes 88 à 94.

 

A priori je ne change pas de si tôt de relais et au pire je reprends le même type de relais si je dois le changer.

Et de toute façon si je change de type de relais comme ma box est ouverte je peux bien changer le programme sur l'arduino.

 

Ensuite que ce soit en relais ssr ou relais mécanique le problème ne se pose que sur la partie intra et extra vu que les relais partagent une même sortie. La sécurité de 500 ms de MotorDriver s'applique au deux cas sans problème.

 

Au final, ce que je veux dire, il est intéressant de changer dans l'interface les paramètres des conditions de gestions de la culture mais pas vraiment la gestion hardware puisque faite une seule fois à l'initialisation lors du firstcompile.

Je trouverais plus intéressant la gestion du hardware "plug & play" type sonde ph, ec et co2.

Exemple, j'enlève ma sonde pH alors je la positionne sur off dans un menu.

 

++

Viker

[Gen 2 808]

yop

 

Tu oublies juste un détail.. Tous ne savent pas programmer.

Je vais ajouter encore d'autres options au fur et à mesure des développements.

 

++

GEN

Modifié août 30, 2017 par Gen

[Viker 147]

yop

 

Alors en effet pour cette raison il n'y pas photo cela devient indispensable

 

Mais j'ajoute que tout de même c'est dommage d'avoir un arduino et de ne pas mettre les mains dans le cambouis.

A la base je ne savais rien de la programmation il y a moins d'un an et à force je commence à avoir quelques notions.

J'encourage donc ceux qui veulent Growduinoter de mettre la main à la pâte.

 

++

Viker

[Gen 2 808]

Salut..

 

Aujourd'hui, toutes les classes sont modifiées pour y intégrer le type de relais utilisé, je m'en servirai également pour ajouter ces options dans le proto du compu-grow. (Je sais pas encore où dans le design de l'écran + grattage de tête)

J'ai crée un menu déroulant pour le LCD afin d'accéder aux options de menu (code simple sans utilisation de classe et réutilisable pour tout type de LCD)

J'y intègre toutes les variables, ainsi plus besoin d'aller chipoter dans le code pour les néophytes

Autre différence majeure dans le code, je l'ai structuré par page.

Je vous tiens au jus

 

++

GEN

Modifié août 30, 2017 par Gen

[Viker 147]

Salut,

 

le soucis du détail et du travail bien fait. J'aime.

Sinon suggestion pour le menu du proto compu-grow, quand tu accèdes aux paramètres matériel d'ajouter sur cette page un onglet réglage des différents relais.

 

++

Viker

[Gen 2 808]

Yop.

 

C'est déjà prévu.. Toutes les modifications développées ici seront reportées sur le compu-grow.

L'idée était d'utiliser le développement du Mini-growduino comme burning test pour le proto

(les 2 projets utilisent les mêmes classes)

 

++

GEN

[Roucass 61]

Bonsoir, j'aurais une petite question technique ( pour mon niveau), voilà je voulais savoir comment trouver l'adresse hexa des différents éléments (écran,...). J'ai trouver un code qui me permettrais de trouver l'adresse hexa par l I2C.

 

Voici le lien:

http://playground.arduino.cc/Main/I2cScanner#.UxJJG_0xJFI

 

Quand penser vous? Si je fais ça il faut que le SCHIELD soit débrancher ? Je voudrais pas faire d'erreur fatal.

 

Merci d'avance

++

[Gen 2 808]

yop

 

les adresses du shield sont

 

0x20 pour le MCP23017  (circuit gérant les moteurs)

0x27 pour le LCD

0x68 pour le RTC

 

Bien sur que le shield doit être installé sinon comment y trouver les adresses des devices inclus ?

maintenant si c'est pour un autre élément non contenu sur le shield alors tu peux l'enlever et tester

 

++

GEN

[Roucass 61]

Ah d'accord, je penser que l'adresse hexa dépend du composant ( que 2 écran lcd 20×4 n'ont pas forcément la même adresse hexa ), après je sais pas trop les accessoires ou on doit paramétrer l'adresse hexa (le clavier?).

 

Ps en réfléchissant en même temps que j'écrivais j'ai penser à quelque chose, tu a peut être programmer une adresse hexa à certains connecteur spécifique ( emplacement lcd,...)

[Gen 2 808]

re:

 

Non, il faut paramétrer via des jumpers ou des solder jumpers directement chaque élément

pour le RTC on ne peut le modifier, pour le MCP23017 c'est réalisable grâce aux petits switch blanc qui se trouvent sur le shield

concernant les LCD, certains sont fournis avec l'option de changement d'adresse, d'autres non

 

 

 

++

GEN

Modifié septembre 1, 2017 par Gen

[Roucass 61]

Ok ça marche merci

[Viker 147]

Salut,

 

le soucis du détail et du travail bien fait. J'aime.

Sinon suggestion pour le menu du proto compu-grow, quand tu accèdes aux paramètres matériel d'ajouter sur cette page un onglet réglage des différents relais.

 

++

Viker

 

 

Yop.

 

C'est déjà prévu.. Toutes les modifications développées ici seront reportées sur le compu-grow.

L'idée était d'utiliser le développement du Mini-growduino comme burning test pour le proto

(les 2 projets utilisent les mêmes classes)

 

++

GEN

 

Salut,

 

j'ai bien saisi que les classes et une partie du programme sont commun aux deux projets. Pourquoi réinventer la roue. Mon propos, vu que tu grattais la tête, était une proposition du type de menu à intégrer au compu grow

 

Bon sinon mes ssr crament toujours, j'ai entièrement démonté ma box afin de vérifier chaque liaisons et là rien pas de courts jus tout est ok.

Donc je pense que les ssr sont merdiques et restent légèrement passant après switch off.

Problème qui s'était déjà posé sur la commande des gros ssr fotek quand je ne les commandais via ces petit ssr.

 

Donc je vais mettre de bon vieux relais mécaniques et voir si cela fonctionne.

Autre  solution serait de "fabriquer" des petits relais ssr au dimensions des omron 1565 mais avec des composants de qualité selon ce schéma.

 

++

Viker

Modifié septembre 2, 2017 par Viker

[Gen 2 808]

j'ai bien saisi que les classes et une partie du programme sont commun aux deux projets. Pourquoi réinventer la roue. Mon propos, vu que tu grattais la tête, était une proposition du type de menu à intégrer au compu grow

 

 

Salut Viker.

 

Je penses que tu n'as pas compris, les classes sont écrites 1x et utilisée dans tous mes projets.

Cependant l'expérimentation par les gens du shield mini-growDuino me permet une mise au banc d'essais afin de déceler des problèmes éventuels.

 

des exemples pour étayer ce que je dis :

 

l'ajout d'une tempo de commutation

la définition des états hauts en fonction des types de relais

etc etc..

 

de fait,j'ai modifié les classes et dorénavant tous les projets en cours bénéficieront de ces fonctionnalités.

 

Pour expliquer mon 'grattage de tête' au sujet du compu-grow, c'est que tout ce qui est interface graphique est écrit en ligne de code, je ne dirai pas pixel par pixel, mais pas loin.. d'où à l'état d'avancement actuel, je me demandais comme l'intégrer.

C'est chose faite, vous verrez cela sous peu dans une vidéo.

 

 

++

GEN

[Viker 147]

Salut Viker.

 

Je penses que tu n'as pas compris, les classes sont écrites 1x et utilisée dans tous mes projets.

Cependant l'expérimentation par les gens du shield mini-growDuino me permet une mise au banc d'essais afin de déceler des problèmes éventuels.

 

des exemples pour étayer ce que je dis :

 

l'ajout d'une tempo de commutation

la définition des états hauts en fonction des types de relais

etc etc..

 

de fait,j'ai modifié les classes et dorénavant tous les projets en cours bénéficieront de ces fonctionnalités.

 

Pour expliquer mon 'grattage de tête' au sujet du compu-grow, c'est que tout ce qui est interface graphique est écrit en ligne de code, je ne dirai pas pixel par pixel, mais pas loin.. d'où à l'état d'avancement actuel, je me demandais comme l'intégrer.

C'est chose faite, vous verrez cela sous peu dans une vidéo.

 

 

++

GEN

 

Heu... bah si en fait c'est exactement ce que j'avais compris mais visiblement nous ne nous comprenons pas sur le fait que nous parlons de la même chose. S'pas grave au final tous les chemins mènent à Rome

 

Bon sinon après changement des platines relais et modification de ma box pour que ça rentre je viens de bencher.

Maintenant ça marche nickel. Donc au final je déconseille vivement d'utiliser ces relais ssr.

 

++

Viker