Vous n'êtes pas identifié(e).
Bonjour à tous,
Je ne savait pas trop ou poster ce genre de sujet (je déplacerai s’il faut).
Je travaille sur un projet expérimental de domotique.
J’ai en local un petit ordinateur relié à une carte à microcontrôleur (Arduino) qui est capable d’effectuer de nombreuses mesures (température hygrométrie, luminosité etc…) et qui peut piloter pas mal de choses (vannes, relais de puissance, etc…).
Je voudrais pouvoir lire les mesures et envoyer des commandes au système via internet.
Je ne souhaite pas installer un serveur web sur l’ordinateur local.
Le logiciel qui gère le système (programmé en « Processing ») est capable d’envoyer des requêtes HTTP et d’en exploiter les retours.
Je voudrais donc passer par un serveur externe :
- Le système y enverrait régulièrement les mesures effectuées et récupèrerait les commandes à exécuter (via un script PHP sur le serveur)
- Une page web permettrait de lire les mesures (avec une petite couche ajax) et d’envoyer les commandes.
Donc, les questions que je me pose :
Quelle meilleure façon de stocker les mesures et commandes ? BDD, fichier, autre ?
(il y aura peut être besoin plus tard de garder un petit historique de tout ça)
A quelle fréquence maximum le système pourrait-il envoyer ses requêtes ?
Par exemple, si une requête par seconde est faite par le système et à certains moments une requête par seconde est faite par la page distante est ce que la charge serveur ne va pas être trop importante… (Je suis une quiche sur le sujet )
J’espère avoir été assez clair, mais je peux apporter des précisions si nécessaires.
Merci de vos conseils.
A+
mcAllan.
Promotion de PPOO : Programmation Propre Orientée Objet !!
Recommande AAO : Apéritif Avec Olives...
Glop, glop
Hors ligne
Saluton,
Pour les mesures, vu la fréquence supposée des requêtes, un SGBD s'impose, lequel ? SQLite, MySQL, ou PostgreSQL, selon la volumétrie de la base.
Par contre je ne comprends pas trop ce que tu entends par stocker les commandes, tu parles des requêtes HTTP qu'enverrait le logiciel ?
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Merci MK de t'intéresser au sujet
L'idée est qu'à distance je dépose une commande sur le serveur et lorsque le système interroge via une requête HTTP il récupère la commande et l'exécute.
Peut être renvoyer une sorte d'accusé de réception aussi après l'exécution de la commande.
Je pense coder la commande sous une forme du genre label/valeur, par exemple : relais1/on. Le tout sur 3 ou 4 octets (2 pour le label et 1 ou 2 pour la valeur).
Même chose d'ailleurs pour les mesures.
Promotion de PPOO : Programmation Propre Orientée Objet !!
Recommande AAO : Apéritif Avec Olives...
Glop, glop
Hors ligne
Donc, si je comprends bien, sur le serveur HTTP, un formulaire permet de saisir les commandes et un autre d'interroger la base sur les mesures.
C'est le système qui prend l'initiative d'interroger le SGBD via HTTP pour y prendre connaissance des commandes à exécuter et qui, en retour, alimente le SGBD avec les mesures.
Le système informerait également le SGBD qu'il a effectué la commande.
Donc, dans ta table commande, il faut un drapeau booléen (A FAIRE/FAIT).
Que se passe-t-il si le système a plusieurs commande à effectuer, y-a-t-il une priorité d'exécution et sur quel critère ?
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Glop,
C'est exactement cela MK.
Pour ce qui est de la priorité des commandes c'est le système qui gère. Il a un peu d'intelligence (qu'on améliore) et obéit déjà à un certain nombre de lois en fonctions de paramètres qu'on lui fournit.
Je peux donc envisager une table commande avec id, label, valeur, fait, (heure ?).
Cette table serait purgée régulièrement. Pas besoin de garder d'historique, l'état des sorties faisant partie des mesures.
Ensuite une table mesure avec id, label, valeur, date/heure.
Reste la fréquence des requêtes. Si je veux une bonne réactivité, le système doit interroger la table commande très souvent (temps < 5 secondes).
Je pense mettre en place un genre de webservice avec en réponse une chaîne XML.
Par contre l'alimentation de la table mesure ne pourrait être faite qu'en cas de changement notables de celles-ci (le "notable" étant défini au niveau du système).
Sur le serveur il y aura bien un formulaire pour saisir les commandes avec des "radio bouton" ON/OFF et champs de saisie de valeur de consigne.
Il y aura ensuite un affichage des mesures, états et alarmes (avec un peu d'ajax pour le fun )
Bon, je continue à creuser tout cela , j'en suis à pas mal de pages de calepin gribouillées...
A+
mcAllan.
Promotion de PPOO : Programmation Propre Orientée Objet !!
Recommande AAO : Apéritif Avec Olives...
Glop, glop
Hors ligne
Salut,
Super projet (y)
a++
Hors ligne
Seuls les process du système écriront dans la table des mesures, donc il ne saurait y avoir de conflit d'accès en écriture. Cette table sera-t-elle également purgée par intervalle ? Et si oui est-ce le système qui le demandera ou HTTP via un autre formulaire ?
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Non, pas de conflit d'écriture sur la table mesures par contre cela reste possible sur la table commandes.
Pour le reste cela fait partie des questions que je me pose encore.
C'est intimement lié à la façon et la fréquence de la mise à jour de la table mesure.
- mise à jour à intervalle régulier ou bien mise à jour seulement lors de changements significatifs ?
- mise à jour avec toutes les mesures ou mise à jour avec seulement celles qui auront évolué ?
Je voudrais de plus (pour plus tard) garder la possibilité de conserver un historique à des fins de statistiques, moyennes ou courbes...
J'ai le neurone qui chauffe
Promotion de PPOO : Programmation Propre Orientée Objet !!
Recommande AAO : Apéritif Avec Olives...
Glop, glop
Hors ligne
Gare à la Fukushimite aiguë !
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Ne t'inquiètes pas, j'ai même fait une petite sieste pour refroidir tout ça.
Promotion de PPOO : Programmation Propre Orientée Objet !!
Recommande AAO : Apéritif Avec Olives...
Glop, glop
Hors ligne
Bonjour,
Oui ton projet semble bien sympathique mcAllan.
Une contrainte qui m'apparaît de suite est la suivante : il faut veiller à ce que la fréquence d'interrogation soit toujours supérieure au temps de traitement respectif de chaque interrogation sinon... ton système va planter. Je rajouterai ceci : c'est même ton CDC pour ta fréquence d'interrogation. Par ex, si tu as 1s de traitement, tu peux interroger à 1,5s de freq. Faut rajouter à ceci la gestion des temps de connexion ou d'erreur de connexion + handshake avec le système.
++
Dernière modification par Jc (10-07-2011 12:49:27)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne