next topic »

[Reply #15 on:]

Pour apache+cgi tout les tuto se base sur un systéme de type linux.
Tu as de la chance d'être tombé sur un tuto utilisant perl comme langage de scripts, si tu était tombé sur le tuto "officiel" du module cgi-bin tu aurais eu droit au script en bash linux ... qui ne fonctionne que sous linux (logique).

Tout ce qui est application serveur tourne en général sous linux.
Par contre une fois ton routeur arrivé tu devras faire attention, la RAM n'est pas énorme il faudra donc limiter son utilisation.

Pour le langage de script je te conseille python (simple et documenté : http://docs.python.org/howto/webservers.html ).
Garde aussi en tête que tu devras compiler une image de openWRT pour ton routeur, ça demande 5Go de disque libre, quelques outils de base et beaucoup de temps libre.
Pour cette étape tu pourras avoir de l'aide vu que barbudor et moi même allons devoir passer par cette étape pour notre projet de domotique

[Reply #16 on:]

Salut,

Pour l'image de OpenWRT, j'espérais pouvoir utiliser celle proposée directement sur le site openwrt.org.

D'après les conseils de cette page :
http://wiki.openwrt.org/doc/howto/obtain.firmware
utiliser une image déjà faite est préférable.

Donc j'ai téléchargé :
http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin

Visiblement tu es parti avec barbudor sur une solution où vous recompilez l'image. Tu peux m'expliquer pourquoi?

Je vois deux raisons qui m'obligeraient à créer moi-même une image :
1) L'image fournie sur le site ne permet pas d'exécuter des scripts, et il faut rajouter un interpréteur (pour le perl ou le python) ?
ou
2) En créant moi-même l'image, je peux intégrer directement mon site à l'image et donc je peux me passer de clé usb?

En attendant de recevoir mon routeur, je peux travailler sur l'image alors autant avancer là-dessus et sur la création de mon site.

Merci pour tes conseils.

Edit: Je continue mes recherches, et j'ai découvert plusieurs points vraiment intéressants pour mon projet.

Le plus prometteur me semble Ardugate, qui permet d'agir directement sur les entrées de l'arduino ou d'obtenir l'état des sorties.
Je vais essayer de m'inspirer de ça au maximum.

Ce qui me semble très fort, c'est que la page web fonctionne sans apache, elle appelle des scripts javascript sans qu'apache fonctionne. Or je croyais que apache était nécessaire pour exécuter des scripts CGI.
Quelqu'un peut-il m'expliquer?

Bonne soirée.

[Reply #17 on:]

D'après les conseils de cette page :
http://wiki.openwrt.org/doc/howto/obtain.firmware
utiliser une image déjà faite est préférable.

Oui quand on veut faire un routeur
Si c'est pour faire un projet domotique les client ftp, dns, firewall, etc ne servent à rien donc autant les virer de l'image pour des choses plus utile

Visiblement tu es parti avec barbudor sur une solution où vous recompilez l'image. Tu peux m'expliquer pourquoi?

Pour moi :
- pour le plaisir d'avoir un truc fait main
- pour optimiser mon image suivant mes besoin (cf remarque plus haut)
- pour ajouter des utilitaires non présent par défaut dont j'ai besoin

Je vois deux raisons qui m'obligeraient à créer moi-même une image :
1) L'image fournie sur le site ne permet pas d'exécuter des scripts, et il faut rajouter un interpréteur (pour le perl ou le python) ?
ou
2) En créant moi-même l'image, je peux intégrer directement mon site à l'image et donc je peux me passer de clé usb?

1) oui et non,
non parce que tu a la console bash et que tu peut faire tes propres utilitaire en C/C++
oui si tu veut utiliser un langage de script (paquet "ipython" pour le python, "perl" pour le perl, "ruby" pour le ruby, ... (voir section "programmation language" de l'utilitaire buildroot -> menuconfig)).

2) oui et c'est même déja le cas pour le site web de configuration de base par exemple

Ce qui me semble très fort, c'est que la page web fonctionne sans apache, elle appelle des scripts javascript sans qu'apache fonctionne. Or je croyais que apache était nécessaire pour exécuter des scripts CGI.
Quelqu'un peut-il m'expliquer?

Le logiciel PC de Ardugate est un bête serveur web "fait maison" en réalité, il intercepte les requêtes HTTP émis par le javascript et les interprètes.

[Reply #18 on:]

Il y a aussi une solution très simple et très bête :

- Prendre un portable obsolète mais qui fonctionne.
- Mettre dedans une carte SIM prépayée avec son propre numéro.
- Le configurer en décrochage automatique.
- Faire un petit circuit intégrateur que l'on branche à la place de l'oreillette.

En logiciel :
- Ecrire un petit soft qui décode la fréquence des tonalités de touches (ca doit déja exister je pense un soft DTMF).
- Lui faire exécuter des actions en fonction des touches appuyé.

JLB

[Reply #19 on:]

- Prendre un portable obsolète mais qui fonctionne.
- Mettre dedans une carte SIM prépayée avec son propre numéro.
- Le configurer en décrochage automatique.
- Faire un petit circuit intégrateur que l'on branche à la place de l'oreillette.

C'est un idée, ou alors utiliser une shield GSM :
http://www.seeedstudio.com/depot/gprs-shield-p-779.html?cPath=132_134

Par contre avec ce systéme :
- pas d'interface web
- obligation d'avoir un systéme de gestion des touches / tonalité (un automate téléphonique DIY en gros)

Je ne suis pas sûr que ce soit ce que cherche xav01 ?

En logiciel :
- Ecrire un petit soft qui décode la fréquence des tonalités de touches (ca doit déja exister je pense un soft DTMF).
- Lui faire exécuter des actions en fonction des touches appuyé.

Décoder un flux sonore DTMF n'est pas une chose si simple !

En hardware c'est possible de manière trés simple avec des CI tout prêt (CD22204 par exemple).
En software il faut utiliser l'algorithme dit de "Goertzel" (une transformation de fourrier discrète).
Je travail justement dessus en ce moment et je peut te garantir que bien que l'algorithme soit relativement simple, obtenir un résultat fiable est trés compliqué

[Reply #20 on:]

Parfois il ne faut pas s'obstiner et laisser murir. On débouche parfois ainsi sur des solutions étonnement simples.

A t-on vraiment besoin du spectre intégral dans le cas de tonalité précise. On doit pouvoir dérivé une mesure beaucoup plus simple ?..

Je suis étonné que personne n'ai travaillé la dessus.

JLB

[Reply #21 on:]

A t-on vraiment besoin du spectre intégral dans le cas de tonalité précise. On doit pouvoir dérivé une mesure beaucoup plus simple ?..
Je suis étonné que personne n'ai travaillé la dessus.

L'algorithme "Goerztel" est justement une variante trés pratique de la FFT (transformation rapide de fourrier) à ne pas confondre avec la DFT (transformation discrète de fourrier).

Dans la première (FFT) tu calcul des bandes de fréquences sur un spectre trés large, ce qui prend beaucoup de temps.
Dans la seconde (DFT/Goertzel) tu calcul seulement un coefficient (correspondant à une fréquence cible précise) et l'algo "Goertzel" calcul l'amplitude de cette fréquence uniquement et non pas sur un spectre complet.
Ce qui est beaucoup plus rapide qu'une FFT sur un petit nombre de fréquences cibles (ex type: codage DTMF).

Par contre l'algo goertzel à deux gros inconvénient :
- les calculs en flottant qui doivent être le plus précis possible (-> calcul trés gourmand en ressource sur un AVR 8 bits)
- la fréquence d'échantillonnage qui doit être parfaitement respecter (-> timer) et dans l'idéal un multiple de la fréquence cible

[Reply #22 on:]

Salut,

Effectivement la solution "téléphone portable obsolète" ne me semble pas la plus adaptée : l'interface me paraît compliquée pour un non-bidouilleur (même si on peut développer des logiciels qui décrivent un peu mieux les fonctionnalités).

Mon système doit pouvoir être piloté par des gens qui n'ont pour l'instant aucune idée de la différence entre wifi et bluetooth.
L'interface web me permet de rendre les choses plus compréhensibles et plus conviviales.

Pour l'instant mon site web devrait ressembler à ça (code réalisé à partir de plusieurs codes trouvés sur le forum):

Code:

<html>
<!--précise que le code qui suit doit être compris comme du html -->
 
  <!-- Essai pour adapter le projet trouvé ici: http://arduino.cc/forum/index.php/topic,97750.0.html
au pilotage d'un portail -->

  <head>
<!-- description préliminaire de tout ce qui touche au fichier actuel: rapport avec d'autres fichiers, possibilités de redimensionner l'affichage, appareils particuliers acceptés, titre de la page -->
 
    <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
<!-- Je ne sais pas ce que veut dire viewport, mais ensuite les paramêtres sont: largeur=largeur de l'appareil ; échelle initiale =1 ; échelle maximale =1 ; échelle modifiable par l'utilisateur? non -->

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!-- rajouté en se calquant sur le index.html de l'ardugate -->

<meta name="HandheldFriendly" content="True" />
<!-- ça veut probablement dire: site convivial pour les appareils mobiles? oui -->

    <link rel="stylesheet" type="text/css" href="style.css" media="screen"/>
<!-- ça veut dire que les styles utilisés par la suite (ici H1, h2, light, roundrect, light p, body,... bref les styles de texte mais aussi les styles d'images) sont dfinis dans le document "style.css"  -->

    <script type="text/perl" src="bonjour.pl"></script>
<!--  déclare le fichier bonjour.pl , présent dans le même répertoire que le fichier actuel, comme un script perl
Ce script ne sert qu'à vérifier mes capacités à écrire un script perl-->

<script language="javascript" src="common.js"></script>
<script language="javascript" src="serial.js"></script>
<script language="javascript" src="arduino.js"></script>
<script language="javascript" src="app.js"></script>
<!-- les 4 scripts ci-dessus sont utiliss par l'ardugate, donc je les ai rajoutés, en attendant de savoir s'ils seront nécessaires dans mon projet final -->

    <title>Pilotage du portail par site web</title>
<!-- ça c'est le titre qui apparait en haut de la page web -->

  </head>
 <!-- fin de la zone de déclaration préliminaire -->
 
<body>
<xml:namespace ns="urn:schemas-microsoft-com:vml" prefix="v" />
<!-- ??? -->

<text-align: center>
<!--? alignement des textes : centré par défaut ? -->

<table width="device-width">
<tr valign="center">
<td>
Actions simples : <br/>
Cycles : <br/>
R&eacute;initialisation : <br/>
</td>
<td>
<input type="button" id="btnouvport" value="Ouvrir" onclick="Ouvrir() " style="width:90px" /> <br/>
<!-- appelle la fonction Ouvrir() si on clique sur le bouton nommé btnouvport, dans lequel il est écrit "Ouvrir" -->
<!-- la fonction Ouvrir() sera définie dans un script perl ou javascript -->
<input type="button" id="btnvoiture" value="Cycle voiture" onclick="Voiture()" style="width:90px"/> <br/>
<input type="button" id="btninitouv" value="en ouvrant" onclick="Initouv()" style="width:90px"/> <br/>
</td>
<td>
<input type="button" id="btnferport" value="Fermer" onclick="Fermer() " style="width:90px"/> <br/>
<input type="button" id="btnpieton" value="Cycle pi&eacute;ton" onclick="Pieton()" style="width:90px"/> <br/>
<input type="button" id="btninitfer" value="en fermant" onclick="Initfer()" style="width:90px"/> <br/>
</td>
</tr>
</table>

<div id="ouverture" style="text-align:center; width:100%" >Portail ouvert à ??? % </div>
<!-- appelle la classe "ouverture" à définir dans un script, qui affichera le taux d'ouverture du portail, dont la valeur sera envoyée en continu par l'Arduino -->

<div id="actionencours" style="text-align:center; width:100%" >Action en cours : ??? </div>
<!-- appelle la classe "actionencours" à définir dans un script, qui affichera l'action en cours, envoyée par l'Arduino -->

</body>
 
</html>

(voir image attachée pour le résultat graphique dans un navigateur).

Comme vous le voyez, j'ai annoté énormément ce bout de code, mais ça m'aide beaucoup à comprendre les significations de chaque ligne de code.
Il est encore très inachevé et très imparfait, mais le rendu est plus ou moins ce que je cherche (faudra que je travaille le rendu, mais quand ce sera mon seul souci, je m'en sortirai).

J'ai aussi commencé à rédiger mon code pour l'arduino, mais là c'est plus long, surtout parce que je n'ai aucun capteur sur la position réelle du portail.

Je suis obligé de la déduire du temps écoulé depuis le début de chaque déplacement, et comme :
- dans un cycle normal, j'ai des phases d'accélération, à vitesse constante haute, de décélération, et à vitesse constante basse (pour faire une rampe puis une phase de recherche de butée),
- je veux prendre en compte les cas où le portail s'est arrêté sans être sur une des butées
il faut que je calcule précisément sa position, et ça m'occupe un peu (mais j'aime ça ).

Du coup ça fait un programme un peu lourd (environ 3, 5 Ko pour l'instant, et il lui manque encore plein de fonctions).

Reste la partie script, pour laquelle je n'ai pas du tout commencé.
Dès que j'aurai débuté le script, je viendrai appeler au secours, ne vous en faites pas .

[Reply #23 on:]

Ma solution était une proposition avec de la recup. Elle est effectivement compliquée sur le plan soft.

Par contre comme je ne vois pas bien ce qu'on peut faire avec un portail à part l'ouvrir et le fermer j'ai bien du mal à comprendre l'utilité d'une interface web.

Ouvrir et fermet peut effectivement se faire avec une shield wifi ou bluetooth et les librairies existantes.

Peux tu préciser ce que permettra l'interface web : A part ouvrir et fermer le portail depuis n'importe quel endroit du monde je ne vois pas bien...

JLB

[Reply #24 on:]

Si le web est destiné à résoudre le problème d'écriture d'un soft sur le téléphone il y a la possibilité d'utiliser un des nombreux logiciels de télécommande par bluetooth disponibles sur le net. Ainsi rien à écrire sur le téléphone.

JLB

[Reply #25 on:]

- je veux prendre en compte les cas où le portail s'est arrêté sans être sur une des butées
il faut que je calcule précisément sa position, et ça m'occupe un peu (mais j'aime ça ).

Bonjour
Pourquoi devoir absolument connaitre la position physique relative aux butées ?

Une porte (portail) n'est à priori censé que relater trois états :

(J'evacue là d'emblée avec tristesse la grande logique manquante de P.Desproges qui imposait qu'une porte  soit ouverte ou bleue !    )

ouverte, fermée, état indéterminé/indéterminable.
Il faut seulement imposer l’état que l'on souhaite imposer après perte de l'info de positionnement (ni fermé, ni ouvert) .
ensuite l'info de capteur de portail vérifié fermé ou vérifié ouvert évacue l’état d''indetermination initial.



 

[Reply #26 on:]

J'evacue là d'emblée avec tristesse la grande logique manquante de P.Desproges qui imposait qu'une porte  soit ouverte ou bleue !   
 

Pas lorsque c'est ouvert... 

[Reply #27 on:]

J'evacue là d'emblée avec tristesse la grande logique manquante de P.Desproges qui imposait qu'une porte  soit ouverte ou bleue !   
 

Pas lorsque c'est ouvert... 

Bonjour JF

je n'ai pas à ce stade détecté d'incompatibilité avec son postulat initial
Selon Pierre, la porte ouverte peut parfaitement être bleue 

[Reply #28 on:]

Oui, c'est une probabilité qu'il faut envisager 

En gros, elle pourrait même être verte ouverte  ... ça laisse beaucoup de possibilité 

[Reply #29 on:]

Salut,

Je réponds en vrac aux derniers messages.

Merci pour les messages sur Desproges, j'adore son humour (qui pour moi lui a largement survécu, d'où le présent).

Pour les remarques-critiques (je les apprécie, je poste dans ce forum pour en avoir alors ne vous gênez pas) sur le choix interface web+wifi plutôt que télécommande bluetooth, c'est justement l'écriture(ou adaptation) d'un programme pour chaque type d'appareil que je veux éviter.

Là une fois la partie logicielle écrite, je peux piloter mon portail depuis n'importe quel appareil sans rien avoir à installer dessus, ni avoir à adapter le moindre bout de code. En poussant à l'extrême je peux envoyer les infos (mot de passe wifi+ adresse du site de l'interface) à mon invité(e) de ce soir, et il(elle) pourra se débrouiller avec mon portail.

@ Artouste : Pour toi il y a 3 états. Pour moi tu en oublies un : position intermédiaire connue (ou plutôt estimée dans mon cas).

Si je connais la position à un instant donnée, comme j'impose la vitesse, en chronométrant je peux estimer la position au cours d'un mouvement.

Mais ça se complique parce que la vitesse que j'impose n'est pas constante, elle suit un profil (voir pièce jointe) afin d'optimiser la durée du mouvement. Mais il "suffit" d'intégrer la fonction "vitesse" par rapport au temps pour obtenir la position en fonction du temps.

Connaître cette position permet d'autoriser l'interruption du mouvement n'importe quand, sans avoir à refaire l'initialisation.

L'initialisation va justement déterminer une fois pour toutes le problème. Après, comme la vitesse est une consigne mais je ne la vérifie pas, j'aurai des erreurs . Il faudra le plus souvent possible revenir à une position certaine (ouvert ou fermé).

Dernier point, le portail n'a pas de capteur de butée, parce qu'il n'en a pas besoin : en mesurant l'intensité qui alimente le moteur, on détecte les cas de blocage du portail. C'est nécessaire pour la sécurité( ne pas faire forcer le portail sur un objet qui bloque le portail et n'est pas détecté par la cellule). Du coup ça permet de trouver les butées.