AckBerry gestion d'aquarium

[smo68170]

Bonjour,
Vous trouverez ci-dessous une description du projet que je suis en train de réaliser.
Les parties Automates ( en C++) et DB sont presque terminées ( pour la première version). Et le je doit m'attaquer à la partie Cockpit ( Pages WEB), et malheureusement je n'est que très peut de connaissances htlm ajax php etc.
Donc j'en chie grave ...
Mon premier souci c'est l'affichage en "temps réel "des entrées/sortie et autres capteurs de température/PH REDOX ect.
je connais trois solution.
1) rafraîchir la page toutes les X secondes --> vraiment merdique
2) rafraîchir les données telles que température et état toutes les X secondes avec des requettes ajax --> c'est mieux mais il y a quand même pas mal de données à chercher toutes les X secondes
3) utilise les websocket , la c'est l'Automate ( ou la Db ) qui envoie les données à la pages Web et que quand celle-ci change ( événementiel ) --> solution la plus élégante.

Connaisse vous d'autres solutions (simple ).
J'ai essayer de faire un processus Web-Server Socket En C++ sans y parvenir ...
pouvez-vous m'indiquer comment implémenter une solution simple ?

Merci
Maintenant un peut de lecture concernant mon projet.

Nom de code du projet est ACKberry

De quoi est composé l'ACKberry ?
D'une carte Raspberry Pi 2 B ou Raspberry Pi B+
D'une carte ACKberry, c'est une carte électronique d'environ 22cm sur 12cm ou viennent s'enficher la carte Raspberry ainsi que les cartes entrées/sorties, PWM, RTC etc. C'est une carte élaboré des amis électroniciens
Des cartes io ,pwm et RTC etc.()qui viendront d'enficher sur la carte ACKberry

Avancement de l'ACKberry :
Le projet a déjà été lancé depuis plusieurs mois, voila en gros ce qui est déjà fait:
Configuration/installation du Raspberry
Création de la DB ACK
Routage de la carte ACKberry
Programmation C++
les librairies :
élaboration de librairie d'accès MySql
élaboration de la librairie d'intercacage I2c
élaboration de la librairie de commande carte PWM
élaboration de la librairie de commande carte IO
élaboration de la librairie Quext( protocole d'échange de message inter-process ipc )
élaboration de la librairie tracelog
Portage de la librairie TimeAlarms (arduino ) sous Raspberry

La partie C++ est actuellement composé de 4 processus, 1 qui s'occupe de l'envoie des emails(AckMail), un qui s'occupe de la lecture des sondes de températures (AckTemp), un qui s'occupe du "nettoyage" des la DB et de l'envoie hebdomadaire d'une sauvegarde de celle-ci et enfin le module principal (ACkMng) qui s'occupe de la gestion du bac.
ACKMail: Récupère les mails à envoyer dans une table MySql et les envoie aux destinataires.
ACKTemp: Récupère dans le Raspberry la valeurs ainsi que l'adresse des sondes de températures présente et insère le résultat dans la Db MySQL pour que les données puis être utilisées par ACKMng. Si une nouvelle sondes est détecteée mise automatique de celle si dans la base MySql pour pouvoir être utilisée/attribuée pour une fonctionnalité.
ACKGarb: supprime les anciens logfile, supprime les anciennes données de la Db envoie chaque semaine par mail une sauvegarde de la DB

ACKMng :
Température :
Lecture dans MySql du résultat du relevé des sondes par ACKTemp
Si le résultats des sondes dans MySql par ACKtemp n'a pas été actualisée depuis moins de 2 minutes , envoie d'un mail d'alerte de problème de lecture température.
Si le résultats des sondes dans MySql par ACKtemp est a nouveau actualisée et qu'une alerte de lecture sondes est active , envoie d'un mail de fin de problème de lecture température.

Servo :
Gestion des oscillateurs ( jusqu'à 32 théorique )
2 plages d'angles pour simulation de phase de marrée
Plages d'exclusions ( jusqu'a 90 théorique).l'oscillateur avance rapidement durant ces plages ou si le contrôle des pompes jebao est activé, les oscillos restent en vitesse normale mais la puissance des pompes est diminuée.

Pompes doseuses :
Gestion des pompes doseuses ( jusqu'à 32 théorique )
Gestion d'un planning hebdomadaire et journalier ( jusqu'a 64 mise en marche /arrêt par jour et par pompes)
Précision théorique à 50 millisecondes;
Simulation marée :
Simulation d'un cycle de marre pour les fonctions oscillos et contrôle jebao
En cas d'arrêt du raspberry reprise du cycle dans sa continuité( pas de reprise à zéro)

Eclairage:
Gestion des LED ( jusqu'à 32 canaux théorique )
Allumage et extinction des canaux
Durée progressive d'allumage exponentielle ou linéaire
Durée progressive d'extinction exponentielle ou linéaire
Comme sur L'ACKduino gestion des nuages, éclairage fluorescent , atténuation nouveau poisson et décalage d'extinction.
Attribution pour chaque canal d'un relais ( pour extinction total de l'alimentation)
Surveillance de la température des LED:
Atténuation automatique si la température dépasse la température de consigne.
Envoie d'un mail d'alerte de problème de température LED
Si la température repasse sous la température de consigne envoie d'un mail de fin d'alerte de problème de température LED
Modulation sinusoïdale du temps d'éclairage suivant la période de l'année ( temps d'éclairage plus important en été qu'en hivers)
Contrôle Jebao:
Gestion des pompes de brassage Jebao ( jusqu'à 32 canaux théorique )
Réglage puissance Max Min et nominale
Atténuation nocturne
Atténuation Nourrissage
Atténuation sinusoïdale suivant le cycle de marrée
Atténuation Ocillo si la pompe se trouve dans une plage d'exclusion.

Ecumeur :
Gestion des Ecumeurs ( jusqu'à 32 canaux théorique )
Gestion d'une temporisation ( par exemple après l'ajout de produit , l'écumeur reste éteint pendant 1/2 heures puis se rallume automatiquement)
Contrôle de niveau via capteur pour arrêt de celui-ci si le niveau est trop haut ( évite le re-largage dans le bac )
Envoie d'un mail d'alerte de niveau ECUMEUR est dépassé
Si le niveau repasse sous le niveau d'arrêt envoie d'un mail de fin d'alerte de problème niveau ECUMEUR

Contrôle Température Bac :
Gestion Température bac avec température min, de consigne et max
Gestion sinusoïdale annuelle de température ( la température est plus basse en hivers qu'en été )
Gestion sinusoïdale journalière de température( spéciale eau-douce )( la température est plus basse la nuit que l'après midi )
Envoie d'un mail d'alerte températures la température est plus basse ou plus haute que les temps Min. et Max.
Si la température est a nouveau dans les tolérances envoie d'un mail de fin d'alerte de problème températures bac

Gestion des Alarmes:
Gestion des différentes alarmes température, niveau écumeur etc. et génération des mail.


Gestion et contrôle des périphériques I2C:
Gestion des périphériques I2C .
Attribution des cartes et pins aux différents éléments
Communication avec les cartes.

voila
Seb

[destroyedlolo]

Bonjour,
Mon premier souci c'est l'affichage en "temps réel "des entrées/sortie et autres capteurs de température/PH REDOX ect.
je connais trois solution.
1) rafraîchir la page toutes les X secondes --> vraiment merdique
2) rafraîchir les données telles que température et état toutes les X secondes avec des requettes ajax --> c'est mieux mais il y a quand même pas mal de données à chercher toutes les X secondes

Pas forcement : mon outils maison de supervision actuelle le fait avec des données assez lourdes (données de production électrique sur plusieurs mois) et ça passe sans trop de problème ... pour peu bien sur que la base de donnée et les requêtes qui l'attaquent soient correctement optimisée. Le bleme est par contre coté client car gérer beaucoup de données coté browser, c'est pas fait pour ça : ça rame et ça bouffe une quantité astronomique de mémoire.
Le problème étant aussi qu'a chaque refresh, une requête DB qui charge inutilement le serveur.

3) utilise les websocket , la c'est l'Automate ( ou la Db ) qui envoie les données à la pages Web et que quand celle-ci change ( événementiel ) --> solution la plus élégante.

Je n'ai pas encore essayé, mais c'est une solution élégante si allié a des triggers de base de données. Par contre, tu restes toujours en mode 1<->1 donc impossible (ou faut dupliquer les requêtes) si tu décide d'ajouter d'autres "consoles".

Connaisse vous d'autres solutions (simple ).

Ben j'ai la même problématique avec mon système de surveillance de production électrique, dont les données doivent être digérées à la fois par mon outils de supervisions (tendances à moyen et long terme), et par des "dashboard". Ces derniers sont soit des BananaPI + Ecran LCD, soit des scripts Conky qui tournent sur mes PCs. Il peut facilement en avoir 3 ou 4 en //.
Et j'ai trouvé la solution :

• tu envoies tes données vers un broker MQTT comme l'excellent Mosquitto
• tu consommes les données grâce à des librairies simple à utilisées et qui existent pour la majorité des langages actuels. Chez moi, c'est du C, du C++ ou du Lua

Sinon, votre carte a l'air très intéressante : vous avez des idées du prix ? Ca serait cool aussi si on pouvait l'utiliser sur des BananaPI / BananaPro / OrangePI ... Il faut juste ne pas alimenté le rPI par le port d'extension (sur les machines ci-dessus, le 5v n'est pas relié directement à l'alim mais passe par la PMU).

[Korhm]

3) utilise les websocket , la c'est l'Automate ( ou la Db ) qui envoie les données à la pages Web et que quand celle-ci change ( événementiel ) --> solution la plus élégante.

Je n'ai pas encore essayé, mais c'est une solution élégante si allié a des triggers de base de données. Par contre, tu restes toujours en mode 1<->1 donc impossible (ou faut dupliquer les requêtes) si tu décide d'ajouter d'autres "consoles".

Si le serveur WebSocket gère différent clients ya pas de raisons que ça ne marche pas.
Je ne connais pas en C++, mais mes serveurs tcp en perl utilisent la fonction "fork" pour se dupliquer à chaque nouveau client.
Attention cependant à bien gérer la déconnexion des clients, même quand elle est implicite, au risque d'avoir des processus fils à ne plus en finir

Si ça t'interesses, je peux te passer mes bout de code de test d'un client/serveur websocket (serveur fait en perl mais ça donne un idée)
C'est vraiment que des tests de faisabilité que j'avais fait, et c'est mono-client

[destroyedlolo]

Salut,

Quand je parlais de "plusieurs requetes", je voulais dire qu'à chaque fois qu'un client va demandé les infos, une nouvelle requête coté serveur sera générée ... a moins d'utiliser un système de cache comme le fait Symphonie. Mais il faut bien penser au mécanisme d'expiration pour s'assurer qu'on envoie bien des données fraiches.

Avec Un brocker, les données ne sont générées qu'une fois.

A+