ZEUS-2: Gestion aquarium avec Arduino

Denisio · le 3 août 2017

Merci. Là, j'utilise la seconde méthode qui fonctionne bien pour mes 3 tests actuels. C'est la fermeture dans le loop, selon les actions en cours, qui me perturbe. Mais je ne veux pas pourrir plus ton topique. J'y retourne

Frenatus · le 3 août 2017

Ce n'est pas mon topic... Oh l'autre....

On est 5 dessus, c'est notre fenêtre de chat.. :bonjour

Je ne sais pas trop ce qui coince.

Donne le code, on regarde.

Sinon, pense à bien déclarer la variable en global.

C'est à dire au tout début du code avant la boucle set up.

Si par exemple, la variable "futur_milli" est déclaré dans loop ou dans un void.

Ben elle est oublié à la boucle suivante.

Frenatus · le 3 août 2017

C'est la loose....

J'ai commencé à bossé sur l'utilisation de l'écran nextion avec une carte UNO.....

Ben..... Ca va poser problème... :

Compiling debug version of 'Affichage Nextion' for 'Arduino/Genuino Uno'

Program size: 28 210 bytes (used 87% of a 32 256 byte maximum) (3,01 secs)

Minimum Memory Usage: 2239 bytes (109% of a 2048 byte maximum)

J'suis bon pour commander une nouvelle carte Mega

Denisio · le 3 août 2017

C'est valable pour tous les écrans ? J'ai le 2.8".

Mais bon, la carte Mega, j'en aurai surement besoin, plus tard, bien plus tard au rythme de mon avancement.

J'en ai enfin terminé avec mes soucis. Je n'étais pas le seul fautif :

- un relais qui ne fonctionnait pas toujours correctement. Le signal était correct (led témoin du relais) mais la bobine ne réagissait pas. Est ce que la lecture du moniteur série peut influer ? Bref un comportement aléatoire qui semble être rentré dans l'ordre sans que je sache pourquoi. Je lis 4.6 v sur la commande, c'est bien suffisant pour la bobine.

- une mauvais lecture de Visual Studio qui signale (en petit, en bas de l'écran) le non chargement du programme que je croyais chargé. Les modifications attendues restaient donc sans effet.... et les modifications qui suivaient aussi

- une erreur d'écriture : J'avais les yeux rivés dessus mais ne la voyais pas. Visual ne signale pas l'emploi de "==" au lieu de "=" dans une instruction de type " variable = 0; ". Bizarre !

Je souhaiterais mettre un bouton d'arrêt pour intervenir : pour arrêter le déroulement du programme et pourquoi pas le rebooter au redémarrage par la même occasion, on ne sait jamais ce qui peut se passer. J'ai vu pas mal de pistes sur le Net et je suis un peu embrouillé. Quelle serait la meilleure démarche simple ?

EDIT : sur la question de la communication sans fil, pourquoi tu t'es arrêté sur la technologie NRF24L01 plutôt qu'une classique Wifi ? J'envisageais Wifi avec ESP8266.

Frenatus · le 3 août 2017

Parce à==0 est une expression valide.

Pour le reboot, tu as la libraire watchdog.

Pour une pause, tu as un moyen simple.

Dans ta loop, tu mets un truc du genre au debut

Boolean pause=false

While (!pause)

Exécuté le programme

Si appui sur bouton changer pause en tenue.

Et en dessous du while

Ben tu testes que tu n'appuie pas sur le bouton et si oui.

Pause = false

bubble_maxi · le 3 août 2017

L' esp c est pas mal non plus, ca vaut 2€ en Chine.... la porte de l esp n est pas top par contre

Si vous voulez l utiliser au mieux il y a un code mesh pour l esp, la cela commencerai à être intéressant

Denisio · le 3 août 2017

Merci pour les orientations de code

L'ESP8266 m'a paru relativement courant, pas mal de données sur le net, des vidéos et des infos et exemples sur le site du constructeur Esspressif. C'est crucial pour moi. La portée avoisine(rait) les 10 mètres et jusqu'à 50 m en terrain découvert. Ce sont les performances de ma Wifi actuelle, ça devrait convenir pour communiquer jusque dans mon garage. Le shield est commandé. Si besoin, il y a peut-être possibilité de rajouter une antenne extérieure..

Frenatus · le 4 août 2017

Oups, j'avais loupé ton édit.

Pas de wifi parce que j'ai régulièrement la box qui merde.

Elle bugge, je perds le wifi et il faut la rebooter. La orange m'en a filé une nouvelle ça a l'air d'être plus stable, mais je ne veux pas tenter le diable.

bubble_maxi · le 4 août 2017

si vous utilisez l'esp dans les modes standards, à vous de bien définir la topologie de votre réseau:

Une box en point d accès et tout les esp en clients ( dans ce cas tout les modules doivent être à proximité de la box )

Ou un esp adhoc et un esp qui se connecte dessus, dans ce cas pas de box, mais pas d'internet non plus ...

Sinon comme je l ai déjà écrit, reflasher l'esp avec un firmware qui gère le mesh et dans ce cas les esp feront relayer les infos vers d'autres esp. Regarder sur Google mesh esp

-> deniso
50 m avec l'esp c est un peu un défi, on arrive à avoir des connections mais la stabilité n'est pas évidente. (On trouve bien sur des modules avec antenne extérieure )

Frenatus · le 4 août 2017

50m, je pense que j'aurais regardé la possibilité de passer par du courant porteur plutôt que du wifi.

Si tu mets le garage sur le même circuit électrique que la pièce ou va être ton automate (même différentiel), le CPl porte à 200 ou 300 m.

Frenatus · le 4 août 2017

Hier j'ai discuté avec un copain qui..... Ben disons qu'il est balaise en gestion et conception d'installation industriel.

On a papoté de Zeus et de l'osmolation...

Et il s'est bien foutu de ma gueule..

C'est trop complexe, je teste des trucs improbables et gère des situations qui n'existeront jamais.

Bref, du coup j'en ai refait un ce midi.

Logigramme :

- Capteur haut et capteur de travail activé ----> osmolation normale.

Sinon.... Tu ne fais rien. Pourquoi.. parce que le capteur haut, n'as aucune chance de se mettre à remonter tout seul par l'action du saint esprit.

Et si ton capteur de travail est bloqué en bas, l'osmolation se gérera au niveau du capteur haut.

- Capteur bas et capteur haut activé ---> osmolation importante pour désactivé le capteur bas.

Si cela ne fonctionne pas, c'est que ton osmolation est en panne, mets tes pompes en sécurité.

Tu en as deux tu le faire en différencié.

- Si tu fais plus de x injection d'eau/unité de temps et que ça ne fonctionne pas, ton osmolation ne fonctionne pas...

Arrête de t'énerver...

Du coup, niveau code, ca devient 'achement plus simple :

Pour les déclarations globales :

int compteur_tempo_niveau = 0;
int compteur_nb_osmo = 0;
boolean pompe1_coupee = false;
boolean pompe2_coupee = false;
boolean osmo_fonctionne = true;
unsigned long osmo_milli = 0;

Dans le set up :

osmo_milli = millis() + 1060000;

Dans la loop.... Ou mieux dans un fichier library.

if (compteur_tempo_niveau > 5000) {// 5 seconde pour éviter injection si intervention dans le bac
		compteur_tempo_niveau = 0;
		if ((digitalRead(niveau_travail) == HIGH) && (digitalRead(niveau_haut) == HIGH)) {
			if (osmo_fonctionne) {
				digitalWrite(relais_osmolation, HIGH);
				delay(temps_injection);// 20 seconde d'injection
				digitalWrite(relais_osmolation, LOW);
				compteur_nb_osmo = compteur_nb_osmo + 1;
			}
		}
		// si c'est le capteur sécurité bas qui se déclenche
		if ((digitalRead(niveau_bas) == HIGH) && (digitalRead(niveau_haut) == HIGH)) {
			if (osmo_fonctionne) {
				digitalWrite(relais_osmolation, HIGH);
				delay(temps_injection);
				delay(10000);// je rajoute encore 10 secondes pour être bien sur de désactiver.
				digitalWrite(relais_osmolation, LOW);
				compteur_nb_osmo = compteur_nb_osmo + 1;
			}
			if ((digitalRead(niveau_bas) == HIGH) && (digitalRead(niveau_haut) == HIGH)) {// 20 seconde d'osmolation n'ont tjs pas suffit
				// donc je coupe une pompe de remontée
				if (!pompe1_coupee) { // si la pompe1 n'est pas encore coupée je coupe
					digitalWrite(pompe_remontee1, HIGH);
					pompe1_coupee = true;
				}
				else{//je coupe la seconde la première est déjà coupée.
					digitalWrite(pompe_remontee2, HIGH);
					pompe2_coupee = true;
				}

			}
		}
	}
	compteur_tempo_niveau++;

	// compteur pour stopper les osmo si trop par unité de temps (osmolation en panne ou débranché)

	if (millis()>osmo_milli){// 10 minutes depuis le dernier test
		if (compteur_nb_osmo >= 10) { // 10 injection en 10 minutes c'est trop donc en panne.
			osmo_fonctionne = false;
		}
		else {
			compteur_nb_osmo = 0; // reinitialise les compteurs.
			osmo_milli = millis() + 1060000;
		}
	}

Ca me plait beaucoup mieux....

Denisio · le 4 août 2017

Merci Frenatus pour cette évolution.

----------------------

Juste pour être sûr :

Quand tu évoques les capteurs c'est :

- capteur haut : s'agit-il du capteur haut dans la cuve technique (ce que je ne crois pas) ou d'un capteur de sécurité juste au-dessus du capteur de travail ? Je ne vois pas l' intérêt de gérer un second capteur pour l'osmolation :

* ces flotteurs ont une inertie suffisante pour provoquer des osmolations brèves et suffisantes. HIGH ça osmole et LOW ça n'osmole pas. Si le niveau monte plus haut, ça n'osmole pas, et si il y a problème, il est géré par une autre fonction que l'osmolation... avec un capteur cuve haut.

* tout au plus on peut doubler le capteur travail ( 1 cm plus haut) mais branché en parallèle, seulement pour défaillance mécanique, sans incidence sur le programme. Ou bien ce dernier prend le relais (mécaniquement), fonctionne en doublure, mais ne fait qu'informer (par le programme) d'un incident.

J'ai du mal comprendre.

- capteur de travail : bien sûr dans la CT

- capteur bas : capteur de niveau bas... dans la réserve je suppose ?

J'étais parti sur quelque chose de relativement simple. Ceci dit, je n'ai pas (encore) une gestion ds events. Ca va venir avec le branchement de l'écran LCD. Dans mon système d'osmolation, je n'ai que 2 capteurs : un capteurCuveTravail ( capteur de travail dans la cuve technique) et un capteurOsmolBas (capteur de niveau bas dans la réserve d'eau osmosée).

Pourquoi 2 pompes : tu évoques des pompes de remontée... des pompes d'osmolation je suppose, dont une de sécurité ?

Pourquoi "osmo_milli = millis() + 1060000" ? 1 060 000, c'est 17 mn 40 s

--------------------

J'ai prévu comme sécurités :

- détection anti clapots (environ 3 à 5 secondes, bien que ce ne soit pas essentiel pour laurite du système) ;

- détection d'osmolation trop longue (2 mn environ) ; c'est capital puisque ça peut signifier une fuite dans le système principal. Faut voir si le comptage des osmolations rapprochées comme tu le proposes, est plus pertinent ;

- et enfin, dans ce dernier cas, une tempo (environ 2h ) pour éviter d'envoyer trop d'eau (capital aussi pour ne pas faire baisser la densité dans l'aquarium). Ce paramètre devrait être adapté au volume du système et débit d'osmolation pour éviter un déséquilibre, selon la rapidité d'intervention (vacances...) ;

- détection niveau réserve bas : capital aussi pour le système. Ca ne devrait jamais se produire. Comme je vérifie très rarement le niveau d'eau osmosée, je rajoute une alarme sonore (un évènement qui mérite d'être communiqué aussi sans fil).

Dernière question de syntaxe : quand tu mets des tirets bas dans tes variables ( ex : "niveau_travail") , c'est pour les distinguer des variables Arduino ? Dans quels cas débutes-tu tes variables par un tiret bas (ex : "if (_alarme == 5)" ) ? Je n'ai pas véritablement trouvé de règle à ce sujet.

Bubule · le 4 août 2017

Denis,

J'utilise également un capteur 'très haut' dans la zone variable.

Outre un problème d'osmolation, il permet de couper l'ecumeur qui verrait le niveau plus haut que ce qu'il est habituellement.

Cela évite son débordement (emballement) au redémarrage suite à une coupure de la pompe de remonté. (maintenance, coupure d'électricité,...)

Alors autant l'utiliser dans le programme pour traiter une sécurité sur le capteur principal. ;-)

Denisio · le 4 août 2017

50m, je pense que j'aurais regardé la possibilité de passer par du courant porteur plutôt que du wifi.

Si tu mets le garage sur le même circuit électrique que la pièce ou va être ton automate (même différentiel), le CPl porte à 200 ou 300 m.

J'évoquais 50 m comme la distance de transmission en terrain découvert, mesurée par un type sur le Net. Chez moi, tout est à moins de 10 m de la box, avec un mur.

Moi aussi j'avais trop de fluctuations : quelques mois sans aucun problème puis soudainement des coupures intempestives, puis après réclamations du meilleur, puis plus tard à nouveau du n'importe et ainsi de suite... de guerre lasse, j'ai demandé le câble, ce qui semble bien avoir résolu tous mes problèmes. Ca semble être la politique des fournisseurs d'accès pour inciter les clients à se diriger vers le câble. Ils n'arrivent plus à tenir les débits en ADS, alors il jonglent avec leurs clients

Denisio · le 4 août 2017

Denis,

J'utilise également un capteur 'très haut' dans la zone variable.

Outre un problème d'osmolation, il permet de couper l'ecumeur qui verrait le niveau plus haut que ce qu'il est habituellement.

Cela évite son débordement (emballement) au redémarrage suite à une coupure de la pompe de remonté. (maintenance, coupure d'électricité,...)

Alors autant l'utiliser dans le programme pour traiter une sécurité sur le capteur principal. ;-)

Oui Franck, je comprends cette logique qui peut s'expliquer si on centralise toutes les infos. De mon côté, je travaille avec des modules indépendants. L'avenir dira si je centralise leurs infos. Je gère donc l'osmolation à part.

Le "capteur cuve haut" reste indispensable pour une gestion de l'écumeur et de la pompe de remontée. Concernant l'osmolation, je ne suis pas sûr que cette information soit nécessaire, ni même utile. Par exemple, dans le cas de ma cuve technique, la différence entre le niveau de travail (dans un compartiment restreint) et le niveau haut (qui occupe toute la surface de la CT), représente bien plus de 5 litres. Je compte bien que l'osmolation n'attend pas cette information (même en info de secours) pour s'arrêter. L'avantage des automates, c'est de coller au mieux à notre perception de ce qui est primordial et de l'organisation de notre système. Les deux évoluent d'un aquariophile à l'autre, c'est pourquoi le DIY de l'un ne répondra jamais aux besoins de l'autre.

Je pars du principe qu'il vaut mieux bien exploiter peu d'évènements fiables que beaucoup qui seraient moins pertinents. J'avoue aussi, que je reste méfiant sur la complication de mon système qui, devenu trop complexe, me ferait perdre en réactivité. Jusqu'à ce jour, toujours dans l'âge de pierre avec mes programmateurs à la minute et mes relais basiques ça m'a plutôt facilité ma maintenance.

Frenatus · le 4 août 2017

-capteur haut : capteur de sécurité au dessus du capteur de travail. Il est là, pour bloquer l'osmolation si jamais le capteur de travail est coincé et lance des osmolations en permanence. L'osmolation ne s’arrête plus.Il ne sert qu'à ça en régime normal.

Je pense que tu as déjà vécu un flotteur qui ne remonte pas, c'est pour cela qu'on en met tjrs un au dessus.

Et du coup, si l'osmolateur de travail est coincé "actif" (il est bloqué en activation permanente, il n'est pas remonté), la gestion de l'osmolation sera faite sur le capteur haut (le niveau de référence dans la cuve technique est géré par le capteur haut, si le capteur de travail est activé en permanence).

Si le capteur de travail est bloqué 'actif", chaque fois que le capteur haut devient actif, ça osmole et dès qu'il se désactive, ça stoppe.

Dans le code, je n'osmole que si a et b sont actif (capteur travail et haut).

Donc si a déconne (tjrs actif), l'osmolation se fera uniquement suivant les indication de b (le capteur haut).

Le capteur haut ne peut pas déconner en régime normal, puisqu'il est tjrs haut de l'eau donc tjrs en position basse. il ne peut donc pas être bloqué en position haute.

- capteur bas : capteur de niveau bas... dans la réserve je suppose ?

Non, les 3 capteurs sont l'un au dessus de l'autre dans la partie à niveau variable de la CT (avec les pompes de remontée).

La réserve n'est pas controlée par un arduino, juste par une electrovanne et deux capteurs en serie.

- Pourquoi 2 pompes : tu évoques des pompes de remontée... des pompes d'osmolation je suppose, dont une de sécurité ?

Non, des pompes de remontée. J'ai mis deux pompes de remontée.

Comme ça si l'une lâche durant les vacances, tu as en tjrs une autre qui fonctionne.

Elles sont même dans mon cas, sur deux circuits électriques totalement différents.

Pour moi, la remontée d'eau est l'élément le plus important.

Si tout tombe en panne mais que tu as encore une remontée d'eau, c'est un minimum de brassage, d'oxygénation pour le bac et le refuge.

A sauver quelque chose, de mon point de vue, c'est la remontée d'eau qu'il faut préserver.

- Pourquoi "osmo_milli = millis() + 1060000" ?

Ça me permet de faire un test toutes les 10 minutes.

Toutes les minutes, je regarde si j'ai fait moins de 10 osmolations.

Si j'en ai fait plus, c'est que j'ai perdu l'osmolation... par exemple, tuyau débranché qui pisse par terre au lieu du bac (c'est du vécu ca....)

Donc, avant de balance de l'eau par terre en pure perte durant mes 15 jours de vacances, je condamne l'osmolation.

Ca fera moins à éponger.. :-)

- détection anti clapots (environ 3 à 5 secondes, bien que ce ne soit pas essentiel pour laurite du système) ;

Je ne gère pas le clapot. Si capteur de travail passe à actif, il envoie 20 sec d'osmolation. Comme ca, pas de clapot à gérer.

Ce que je gère, c'est "j'ai les mains dans le bac".

Je bouge l'écumeur et le sors un peu la base de l'eau pour choper le godet.... Ca m'a pris 2 secondes... Mais hop, osmolation.

Pour éviter cela j'ai mis 5 sec de tempo.

- - détection d'osmolation trop longue (2 mn environ) ; c'est capital puisque ça peut signifier une fuite dans le système principal. Faut voir si le comptage des osmolations rapprochées comme tu le proposes, est plus pertinent ;

Je ne veux pas d'osmolation longue, car elles seront faites en tirant sur un RAH. Et 2 minutes de chaux, c'est trop pour ma config.

Déjà ca ne sera plus de l'eau de chaux saturée et ensuite ca va trop taper le pH et amener à des précipitations.

-Dernière question de syntaxe : quand tu mets des tirets bas dans tes variables ( ex : "niveau_travail") , c'est pour les distinguer des variables Arduino ? Dans quels cas débutes-tu tes variables par un tiret bas (ex : "if (_alarme == 5)" ) ? Je n'ai pas véritablement trouvé de règle à ce sujet.

Parce que tu ne peux pas utiliser d'espace ni de "-" dans un nom de variable. Donc te reste que le tiret bas pour remplacer un espace dans un nom.

Pour le coup des tirets bas devant les variables, oui y a des conventions d'écriture.

Mais je ne les utilise pas, je ne suis même plus sur de les connaitre.

En fait, tu devrais tout le temps en même quasiment.

Pour moi, c'est juste une moyen memo-technique.

Je mets un tiret bas devant une variable lorsqu'il s'agit de la propriété d'un objet.

Ca m'évite de me mélanger avec les autres types de variables. mais c'est juste mon truc à moi, ça...

C'est la convention Frenatus...

Sinon, je reviens là dessus :

"Dans mon système d'osmolation, je n'ai que 2 capteurs : un capteurCuveTravail ( capteur de travail dans la cuve technique) et un capteurOsmolBas (capteur de niveau bas dans la réserve d'eau osmosée)."

Pour la cuve d'eau osmosée, peu de risque, c'est de l'eau osmosée.

Mais un seul capteur dans la cuve technique c'est chaud.

Il n'y a qu'à voir comment on se retrouve avec des traces de sel sur tous les équipements proche de l'aqua.

Ce capteur peut assez facilement se retrouver coincé (dépot de sel sur la tige, un petit cargot ou une astéria qui fait de l'escalade sur la tige...)

Je te suggère d'en mettre au moins 2.

Si jamais il reste bloqué en position haute, tu n'auras jamais d'osmolation et tu finiras avec ta pompe de remontée qui tourne à sec.

Denisio · le 4 août 2017

Merci.

Je vois que j'ai confondu certains points.

-capteur haut : capteur de sécurité au dessus du capteur de travail. ... Je pense que tu as déjà vécu un flotteur qui ne remonte pas, c'est pour cela qu'on en met tjrs un au dessus. Oui, c'est pour cela que j'ai toujours 2 capteurs. Mais à ce jour point de programme, ils sont branchés en parallèle, celui de sécurité monté légèrement au dessus de l'autre. Si le capteur de travail coince, le second s'active. C'st rare mais c'est arrivé avec un flotteur qui avait perdu sa mobilité.

Et du coup, si l'osmolateur de travail est coincé "actif" (il est bloqué en activation permanente, il n'est pas remonté), la gestion de l'osmolation sera faite sur le capteur haut (le niveau de référence dans la cuve technique est géré par le capteur haut.... : OK, j'ai compris. Un capteur en parallèle(comme le mien actuel) ne permet pas cette analyse. Je pense que ce capteur haut est indispensable pour que l'osmolation soit rendue possible ; il faut donc gérer ses infos dans le programme. Concernant la détection du défaut, il me semble que l'analyse du temps d'activation du capteur de travail suffit à détecter le défaut "capteur coincé actif". Mais bon, pourquoi ne pas utiliser aussi le haut

Le capteur haut ne peut pas déconner en régime normal, puisqu'il est tjrs haut de l'eau donc tjrs en position basse. il ne peut donc pas être bloqué en position haute. Oui, tout à fait d'accord, d'où ma réflexion ci-dessus.

Non, les 3 capteurs sont l'un au dessus de l'autre dans la partie à niveau variable de la CT (avec les pompes de remontée). Mais alors, à quoi sert-il dans l'osmolation ?

Non, des pompes de remontée. J'ai mis deux pompes de remontée. : OK, mais pourquoi couper une pompe de remontée quand les eux capteurs sont bas ?

Ça me permet de faire un test toutes les 10 minutes. Toutes les minutes, je regarde si j'ai fait moins de 10 osmolations. Si j'en ai fait plus, c'est que j'ai perdu l'osmolation... Bien d'accord. Je gère ça par la durée d'osmolation qui retarde l'osmolation suivante, éventuelle. Je vais voir si je pars sur ce comptage.

- détection anti clapots ... :
Je ne gère pas le clapot. Si capteur de travail passe à actif, il envoie 20 sec d'osmolation. Comme ca, pas de clapot à gérer. Oui, je fais aussi exactement comme ça. Je l'ai nommé ainsi par respect pour ton premier projet

Je ne veux pas d'osmolation longue, car elles seront faites en tirant sur un RAH. Et 2 minutes de chaux, c'est trop pour ma config. Moi non plus, et plus généralement personne , d'autant plus qu'il y a un RAH dans le circuit. C'est pourquoi je gère le temps d'osmolation maxi.

C'est la convention Frenatus...

Mais un seul capteur dans la cuve technique c'est chaud. OUI, même si mes deux capteurs actuels sont dans un petit boitier, à l'abri des téméraires cagouilles). Un deuxième de secours

Tout cela me conduit à quelques réflexions :

On est dans un système d'osmolation. La pompe doit s'arrêter quand la réserve d'eau osmosée est vide, et le faire savoir. Je ne vois rien dans le programme, qui gère cette absence d'eau.

Comme je le faisais remarquer à Franck, les besoins des uns et des autres diffèrent (avec ou sans RAH, volume 200 L ou 2000 L...). Ce serait bien de paramétrer quelques variables (si ça peut éviter d'ouvrir la boite pour reprogrammer). J'ai prévu de paramétrer par l'aquariophile : la durée max d'osmolation, la tempo avant qu'une autre osmolation se fasse en cas de défaillance, le délai de détection "du_p'tit_gars_hyperactif_qui_bidouille_dans_la_décante" (puisque "anti-clapot" ne convient pas)... d'où l'utilisation d'un écran LCD + codeur rotatif (ou autre système) que je ne souhaitais pas à l'origine.

Frenatus · le 5 août 2017

Non, les 3 capteurs sont l'un au dessus de l'autre dans la partie à niveau variable de la CT (avec les pompes de remontée). Mais alors, à quoi sert-il dans l'osmolation ?

Le premier tout en bas, est un capteur de sécurité bas.

Si il se déclenche, c'est qu'il n'y a plus assez d'eau dans la CT et que les pompes de remontée vont tourner à sec dans pas longtemps.

Il est là, pour protéger le matériel.

Le second, au milieu, est le capteur d'osmolation. Si il est activé, on injecte de l'eau.

Le dernier tout en haut est une sécurité, si jamais le capteur du milieu reste coincé en position activé. Il coupe l'osmolation si jamais il est touché.

Non, des pompes de remontée. J'ai mis deux pompes de remontée. : OK, mais pourquoi couper une pompe de remontée quand les eux capteurs sont bas ?

Je coupe d'abord une pompe, cela va faire remonter un peu le niveau de remontée dans la CT.

Ensuite plus tard, si il se déclenche encore, je coupe la seconde.

C'est juste pour gagner du temps. En ne coupant une seule pompe, je permets de poursuivre le fonctionnement de la remontée d'eau durant 30 minutes ou 1 heure, ou plus.... C'est toujours ca de gagner.

On est dans un système d'osmolation. La pompe doit s'arrêter quand la réserve d'eau osmosée est vide, et le faire savoir. Je ne vois rien dans le programme, qui gère cette absence d'eau.

Chez moi la réserve d'eau n'est pas proche de l'aqua. Donc n'est pas géré par l'automate.

Mais au final, je vais le savoir.... Le programme détecte une osmolation défectueuse (10 osmolation en 10 minutes), il en déduit que l'osmolation est en panne.

"du_p'tit_gars_hyperactif_qui_bidouille_dans_la_décante" (puisque "anti-clapot" ne convient pas).

Sinon, oui....

Si nous sommes courageux, on peut faire un prog ou l'utilisateur rempli un fichier "config" et peu s'adapter à toutes les installations.

1 ou 12 rampes led, du dimmable, non dimmables, des tubes...1 pompe, 12 pompes...... :-)

Et bubulle lui, il nous fait le CI pile poil comme il faut.

En gros, comme les CMS ou autre site php.. Tu le mets à ta sauce à travers un fichier config.

Ca serait super bien de faire ca.... Tout le monde pourrait se faire facile son automate.

Mais bon, c'est aussi long et lourd à faire. Et là, pour le coup, il faut bosser sur des petits modules que tu raccordes à un master (en fil, en wifi ou en je ne sais quoi).

Moi, si ca vous branche, je suis assez partant pour participer. Ca revient à faire un apex en DIY.

Ah sinon dans le news du jour, j'ai cramé ma carte Mega...

En tripotant dans mon boitier sous tension, il fil s'est débranché, a touché je ne sais quoi.....

Et hop, la carte ne répond plus....

J'ai du rebricoler et reprogrammer deux UNO vite fait pour continuer à avoir éclairage et osmolation.

Maintenant je ne touche plus à rien, jusqu'au retour de vacances.... :siffle

bubble_maxi · le 5 août 2017

Franchement ca me gave de devoir moi aussi me mettre à l arduino, je préfère de loin le bon C sur un proc qui ne fait tourner que mon code, mais il faut reconnaître que la communauté arduino est grande, que c est simple de s'y mettre.. donc je suis partant pour fournir le hardware sur mesure de module indépendant mais communiquant, façon apex mais avec un peu d intelligence reparti ( fonction de base )

Donc je vais revoir mes modules avec un proc compatible.

C est quoi les proc des cartes arduino ( modèle exact ) ? Un truc assez puissant hein, ( en cms bien sur )

Frenatus · le 5 août 2017

Ben avant toute chose, Ahma, il faut un chef de projet.... Au hasard, Denisio...

Ensuite, il faut dans l'ordre :

- un cahier des charges assez précis

- l'équipe et les fonctions de chacun

- selectionner le hardware.

- créer le software.

- tester, debugguer

- diffuser.

À minima, il faut 3 personnes.

Un pour dire blanc.

Un pour dire noir.

Un chef pour trancher.

bubble_maxi · le 5 août 2017

Donne moi déjà la ref du proc, que je regarde la bête ...

Frenatus · le 6 août 2017

Les spéci des différentes carte Arduino :

https://www.arduino.cc/en/Products/Compare

bubble_maxi · le 6 août 2017

Merci. Ben y'a quand même des cpu intéressant

Genre ATSAM3X8E. 7,5€. Avec ethernet, USB, bus CAN

Pas mal du tout

Frenatus · le 6 août 2017

J'y connais rien.

Mais je pense qu'il y a sans problème de quoi s'amuser.

bubble_maxi · le 6 août 2017

Ben t y connais rien mmmm arrête un peu

Connexion

ZEUS-2: Gestion aquarium avec Arduino

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Archivé

Derniers sujets

Contributeurs populaires

Qui est en ligne (Afficher la liste complète)

Information importante