Composants pour interface web

La configuration de l'accès à l'arduino est en DeMilitarized Zone (DMZ) http://www.commentcamarche.net/contents/protect/dmz-cloisonnement.php3

La seul différence entre ce que j'ai fait et de la domotique, peut-être un peu plus réaliste. C'est que pour moi le serveur WEB ne ce trouve pas chez moi mais sur un de mes site personnel. D'ailleurs ton schéma est correct Powerpack :slight_smile: Ceci pourrais être une seconde étape avoir un petit ordinateur dédié pour servir comme serveur ce trouvant chez moi et communiquant avec l'arduino. D'ailleurs mon prochaine essai et de pouvoir communiquer dans les deux sens. Que je puisse allumer la lumière physiquement (un bouton) et que ceci change la valeur d'état dans la base de donnée qui est à distance et inversement.

Question risque ça l'est si tu ne protège pas les informations auxquelles tu peux accéder. Pour moi c'est le cas en ce moment, mais rien ne m'empêche de développer un système d'accès sécurisé avec clé crypté pour rendre la tâche difficile à mon voisin, qui n'a d'ailleurs certainement pas de notion de hacking :stuck_out_tongue:

Bonjour,

Je ne suis pas convaincu de la nécessité de mettre l'ARDUINO en DMZ... Il faut configurer le routeur, je ne vois pas l'impossibilité... En DMZ, il me semble très vulnérable aux attaques extérieures... s'il doit y en avoir 8)
Le serveur hébergé est la meilleure solution quand cela est possible... Aucun intérêt à avoir un serveur qui tourne chez soi... La seule limitation est que certains hébergeurs ne donnent pas accès à toutes les options... Le must étant son propre serveur en mode hébergé... Il y a des choses pas trop chères maintenant... Par exemple http://www.kimsufi.com/fr/cloud/ à 10.50 € TTC / mois... :slight_smile:

ojal:
Bonjour,

Je ne suis pas convaincu de la nécessité de mettre l'ARDUINO en DMZ...

En faite la DMZ c'est la zone ou ce trouve l'arduino, non le serveur web php/mysql qui a les informations. Il n'y a, à ma connaissance, pas d'autre alternative. Ton arduino est forcément brancher sur un routeur et il faut éviter les intrusions.

Sinon l'intéret d'avoir un serveur chez soi c'est pour la rapidité de communication Serveur <-> arduino qui est certainement limité quand ton serveur web ce trouve sur un herbergement (ce qui est mon cas) Mais pour des exercice comme celui-ci ce n'est pas nécessaire.

L'ARDUINO obtient une adresse IP du routeur et je ne vois pas pourquoi cette adresse ne serait pas accessible depuis l'extérieur avec une bonne config du routeur...?
C'est ce que j'avais fait à une époque pour accéder à mon serveur PHP MYSQL depuis l'extérieur... A valider quand même...

Un hébergement extérieur ne sera pas forcément beaucoup plus lent... Il n'y a pas de volumes de données à transférer... Et c'est quand même un ENORME soucis de moins à gérer... Je ne connais personne qui ai un serveur 'fiable' sur son réseau local... Cela génère souvent une nuisance sonore, ventilation du serveur, une dépense énergétique non nulle et tous les soucis de redémarrage en cas de coupure de courant etc...

Perso les serveurs doivent tous être chez des hébergeurs et OVH est assez bon pour ça... En tous cas pour l’Europe...

ojal:
L'ARDUINO obtient une adresse IP du routeur et je ne vois pas pourquoi cette adresse ne serait pas accessible depuis l'extérieur avec une bonne config du routeur...?
C'est ce que j'avais fait à une époque pour accéder à mon serveur PHP MYSQL depuis l'extérieur... A valider quand même...

Mais c'est tout à fait ça. l'adresse IP qu'obtiens ton arduino est une ip adresse local. en Configurant ton routeur tu assignes l'adresse ip qui permet d'accéder à ton ordinateur depuis le web à l'ip local de ton arduino. Mais tout ceci est configurer en DMZ tout simplement (enfin corrigé moi si je me tormpe :p)

C'est clair que ça peut être embêtant à gérer un serveur local. Je ne m'y connais pas en domotique mais je suis pas certains qu'il accède à un seveur distant. Mais pour nos projets il est clair que c'est suffisant. Je serais curieux de savoir comment cela fonctionne pour les maisons domotique, jvais aller googeler ! :slight_smile:

Vous pouvez router les informations via la DMZ ou uniquement certains port avec NAT/PAT.
Toutefois, il est important de sécuriser la communication entre la carte et le serveur.

ClientWeb --->(identification basé sur php ou htaccess )--> ServeurWeb --> ( sécuriser cette connexion avec un jeton unique)--> CarteArduino

Je viens de voir que sous IE ça ne fonctionne pas. En effet, la méthode GET utilisé en jquery pose quelque problème, uniquement avec Internet Explorer... Étonnant :stuck_out_tongue:

@ chesnel,

Si je comprends bien...
Tu lance un serveur sur ton arduino
Depuis tons script PHP situé n'importe ou, tu appels des pages situées sur ton ARDUINO du type
www.url_arduino.com/page_de_pilotage_des_leds.htm?led1:0z&led2:255z&led3:122z
Est-ce bien cela que te génère ton script php?

Ensuite le serveur de l'ARDUINO est capable de récupérer l'URL de la page qui est chargée et désosse l'URL afin de connaître les valeurs passées dans l'URL???

Est-ce ça le mécanisme???

exactement. De cette manière l'arduino ne traite les informations que quand il les reçois, contrairement à l'autre méthode ou l'arduino interrogé en continue une page php extérieur.

  $.get($link,{led1:value+"z"});

C'est cette ligne en jquery qui envoi les informations. $link est le liens vers l'arduino et ensuite les valeurs à transmettre en GET :slight_smile:

je viens tout juste de penser à autre chose qui n'est pas terrible niveau sécurité. Si quelqu'un arrive à intercepter les commandes que j'envois en GET vers L'arduino par exemple :
http://adress_vers_arduino.com?valeur=1/
Rien ne l'empêche de le taper dans son navigateur et voir ce que ça fait :S

Bon j'ai trouvé une solution pour éviter que la requête soit faite depuis n'importe ou.
J'ai constaté que dans les informations que l'ont reçois sur l'arduino il y à l'host. Dans mon cas c'est mon sous-domaine ou je met mes pages php en ligne. Donc j'ai mis en place une petite vérification de la présence de l'host :

      if (client.connected()) { // si le client est connecté
     
           while (client.available()) { 

                char c = client.read(); 
                //Serial.print(c);
                comptChar=comptChar+1; 
                //récuperation des 100 premier caractères
                if (comptChar<=100){ 
                  chaineRecue=chaineRecue+c; 
                }
                
               chaineTotal = chaineTotal+c;

    

      } // --- fin while client.available
    

   String page_host = "http://arduiboo.weeboo.net";
   int tag_referer = chaineTotale.indexOf(page_referer);
    
    if(tag_referer != -1){
    
    }

Si l'host est bien présent il doit me retourner la position du 1er caractère si il n'est pas présent il retourne -1

Par contre de charger ce que l'ont reçois entièrement dans la chaineTotale ralentie pas mal l'exécution de la suite :frowning:

Globalement, comment se positionne cette manière de faire par rapport au simple fait d'envoyer un message UDP?
Je comprends bien que ça fonctionne, néanmoins, cela m'apparait un peu comme babare :astonished:

chesnel:
Par contre de charger ce que l'ont reçois entièrement dans la chaineTotale ralentie pas mal l'exécution de la suite :frowning:

Pourrais-tu préciser ?

Je vais peut-être dire des âneries mais que ce soit UDP ou par le GET tu reçois une chaine de caractère dans arduino qui faut de toute manière retraiter pour récupérer les différentes info envoyées.
le GET envoi un peu plus d'information que l'UDP.

Là ou il y a peut-être un avantage en passant par l'UDP c'est que la requête n'est pas directement visible ou imitable par l'url, contrairement au GET.

Entre les deux méthode je préfère l'UDP mais je n'ai malheureusement pas réussi à la faire marché depuis mon site web.

Pourrais-tu préciser ?

Voici ce que tu reçois quand tu envois coté arduino quand tu lui transmet des informations en GET

GET /?led1=255z HTTP/1.1
Host: XX.XX.XX.XX
Origin: http://sous_domaine.site_internet.net
User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; fr-fr) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5
Accept: */*
Referer: http://sous_domaine.site_internet.net/client_switch_light.php
Accept-Language: fr-fr
Accept-Encoding: gzip, deflate
Connection: keep-alive

C'est à partir de tout ceci que tu récupère les valeurs qui t'intéresse. et pour faire la vérification qui permet de savoir d'où proviens la requete GET je charge dans le String chaineTotale plus de caractère donc ça ralentie l’exécution de la suite du code... je sais pas si je suis plus claire :s

et il est vrai que coté UDP tu reçois juste :

Received packet of size 32
Contents:
12345678abcdefghijklmnop¾Û

:slight_smile:

Yeah ! Bonne nouvelle ! j'ai pris contact avec la compagnie qui héberge mon site internet et j'ai eu comme information que tout les ports n'était pas ouvert. Donc il m'a fourni la liste et j'ai pus créer un échange via UDP avec le port DNS ! Je vais pouvoir tester la version UDP maintenant pour voir la différence et je vous reviens la dessus :slight_smile:

Par contre le petit inconvéniant si on souhaite garder le tout dynamqiue, c'est que l'envoi par get ce fait plutôt facilement avec jquery pour la requête UDP il va falloir passer par une méthode POST envoyé sur une page contenant la requête UDP...

Bon j'ai testé avec le transfert par UDP. Comme je l'ai mentionné juste avant j'appelle une page contenant la requête UDP via Jquery donc l'envoi ce fait comment en deux temps... c'est lent et vraiment moins réactif qu'en utilisant un GET directement vers l'arduino. Dommage car coté code arduino les informations sont plus facile à récupérer.

Je vous mets en pièces jointes les deux fichiers pour tester le code si vous le voulez.

Coté arduino j'ai utilisé l'exemple Ethernet > UDPSendReceiveString et j'ai juste ajouté dans le loop analogWrite(9, atoi(packetBuffer)); Le atoi(); permet de transformer le char en int.

php_udp_control_led.php (371 Bytes)

udp_control_led.php (1.99 KB)

Je suis désolé de ce monologue... je suis vraiment captivé par tout ceci et je le partage peut-être un peu trop :blush:

Bon il y à une erreur présente ou quelque chose de mal programmé dans le code de base du UDPSendReceiveString. Lors de l'envoi de l'UDP le char packetBuffer ne ce vide pas à chaque nouvelle réception de donnée. Un exemple : Si la première valeur transmise est 244 et ensuite 0 nous allons parfaitement recevoir 244 mais nous allons recevoir 044 pour le suivant... J'ai fait différents essai, mais sans succès. Donc en attendant de trouver une meilleur solution j'ai ajouté ce code. C'est un peu barbare comme dirais Ojal :stuck_out_tongue: Mais au moins le contrôle avec Slide de la lumière fonctionne parfaitement et est très fluide en local ! Par contre en ligne, vite surchargé de requête, la fluidité se perd.

    // read the packet into packetBufffer and get the senders IP addr and port number
    Udp.readPacket(packetBuffer,UDP_TX_PACKET_MAX_SIZE, remoteIp, remotePort);
     
    Serial.println("Contents:");
    
    //je convertis le char en string pour pouvoir utiliser substring
    String packetBuffer_str = String(packetBuffer);

    //je ne garde que les caractères qui sont entre 0 et le nombre total d'octet transmis
    packetBuffer_str = packetBuffer_str.substring(0,packetSize);

    //String en int est possible avec ses changements http://code.google.com/p/arduino/issues/detail?id=468
    long packetBuffer2 = packetBuffer_str.toInt();
    
    Serial.println(packetBuffer2);
    
    analogWrite(9, packetBuffer2);

Le soucis viens de cette partie :

  // read the packet into packetBufffer and get the senders IP addr and port number
    Udp.readPacket(packetBuffer,UDP_TX_PACKET_MAX_SIZE, remoteIp, remotePort);

le UDP_TX_PACKET_MAX_SIZE est initialisé dans le fichier UDP.h de la libraire à 24 de base. J'ai essayé de le remplacer par le packetSize mais ça ne fonctionne pas. À réfléchir et pour le moment dodo ! :stuck_out_tongue:

Bonsoir chesnel :slight_smile:

J'avais remarqué le bug de réception en UDP, mais je ne suis pas allé plus loin pour le moment...
Aujourd'hui j'ai eu une journée très chargée et pas eu du tout le temps d'ARDUINISER...
Je vois que l'appellation "barbare" t'a plue :smiley:

Je reviens sur ce sujet dès que possible, demain peut être :slight_smile:

Tu as donc réussi aussi à faire fonctionner le slider en local? Super!
Pour éviter de surcharger les envois de requêtes, je pensais mettre une graduation sur le slider de façon à ne déclencher que lorsq'un cran est franchi, mais il y a peut être mieux dans la bibkliothèque JQUERY... L'idéal aurait été d'envoyer un callback - je crois que c'est le nom - au maximum tous les 1/10 ème de secondes...

@ suivre :wink:

Bizarre, mais j'ai l'impression que le sujet ne passionne pas les foules??? On ne serait que 2 dans ce cas?? :roll_eyes:

Non, non, passionnant, mais je n'ai pas grand chose à amener au moulin.

faut dire que pour en placer une sur ce topic enflammé... :wink:

j'utilises beaucoup l'UDP dans mon projet. Voici comment je procède en gros:

	if(Udp.available()){
		byte packetBuffer[MAX_SIZE]; //buffer to hold incoming packet
		int valeur;

		// initialize the new buffer
		memset(packetBuffer, 0, MAX_SIZE);

		packetSize = Udp.readPacket(packetBuffer,MAX_SIZE,remoteIp,(uint16_t *)&remotePort); // read the RX buffer

		sscanf(packetBuffer, "%i", &valeur);
	}

Si ça peut vous aider.

pour ne pas avoir le problème d'anciennes valeurs qui réapparaissent dans le buffer, il est important de l'initialiser systématiquement avant utilisation, même si il vient d'être créée. On ne peut pas savoir ce qui il y avait dans l'espace mémoire occupée auparavant (ancien buffer par exemple).
Utiliser par exemple:

memset(packetBuffer, 0, MAX_SIZE);

Gromain

ojal:
je pensais mettre une graduation sur le slider de façon à ne déclencher que lorsqu'un cran est franchi,

Rien de plus simple, l'API du slider embarque déjà cette possibilité

$( "#slider" ).slider({ max: 255 },{ value: 0 },{step : 5});

Il suffit juste d'ajouter comme paramètre le step et par combien de tranche cela doit être transmis ! Ça réduit pas mal le nombre de requête transmise mais il ne faut pas s'attendre, de toute manière, à avoir quelque chose de réactif via le web :stuck_out_tongue:

J'ai aussi pris le temps de refaire un essai avec le GET, la première méthode que j'ai testé. Je confirme que le transfert par UDP est bien plus rapide. De plus même si il y à existe une surchage d'envoi de requête dans les deux modes au moins par UDP l'ordre d'envoi est respecté, contrairement au GET ou l'ordre de réception est parfois aléatoire.