Scénario:

Je roule en direction de  mon mobil-home situé en bord de mer. Deux heures avant mon arrivée, je décide d'enclencher le chauffage. je clique sur l'application sur mon smartphone, un menu s'affiche et je presse sur la touche "PC Radiateur".

Lorsque j'arrive sur place, la température est de 19 degrés dans le mobil-home.

Pour mémoire, le détail du projet initial est décrit dans cet article.

Voici le schéma fonctionnel :

Les principales étapes :

• Application Android de mise en relation via internet avec le serveur http hébergé sur le pi.
• Mise en place, sur le Pi,  du script php enregistrant les ordres en provenance d’un client http (windows ou android) et les transmettant à l’Arduino.
• Gestion de la liaison usb-série pour transmettre les ordres du Pi à l’Arduino et recevoir des acquitements ou des informations (ie température).
• Installation, test et mise en oeuvre du module Emission RF 433Mhz.
• Gestion de la liaison "radio-commande 433 Mhz" entre l’arduino et les prises Phénix. Décodage de la trame à transmettre à chacune de ces prises pour l'activation et la désactivation.
• Ecriture du sketch permettant à l'arduino de relayer la demande du Pi vers la prise concernée.
• Assemblage des modules, test final et mise en service.

Lors de la réalisation, cet ordre n'a pas été respecté. (1)

Le véritable déroulement du développement est celui-ci:

• Gestion de la liaison "radio-commande 433 Mhz" entre l’arduino et les prises Phénix. Décodage de la trame à transmettre à chacune de ces prises pour l'activation et la désactivation.
• Gestion de la liaison usb-série pour transmettre les ordres du Pi à l’Arduino et recevoir des acquitements ou des informations.
• Ecriture du sketch permettant à l'arduino de relayer la demande du Pi vers la prise concernée.
• Mise en place, sur le Pi,  du script php enregistrant les ordres en provenance d’un client http (windows ou android) et les transmettant à l’Arduino.
• Assemblage des modules, test final et mise en service.
• Application Android de mise en relation via internet avec le serveur http hébergé sur le pi.

 (1) Ce projet aurait  perdu beaucoup de son intérêt si je n'avais pu décoder la trame de commande des prises Phénix... Valider ce point était primordial.

==>   [Liaison radio 433Mhz]                            

Il y a six mois, je n’avais vu ni un Raspberry Pi ni un Arduino de près. C’est dire que ce premier projet - aussi rudimentaire qu'il soit - n’a pas été une sinécure !

Même si, au départ, je savais faire la différence entre une résistance et un condensateur et que j’avais pratiqué plusieurs langages de programmation, l’immersion a été rude.

Des semaines de lecture, de tâtonnements avec, parfois des moments de grande incertitude…

Les principales difficultés rencontrées, les problèmes les plus chronophages ont été les suivants :

 * Dans un assez grand nombre de cas, les sketches "pompés" à titre d’exemples ne se compilaient pas à cause de librairies obsolètes.

Par exemple, la librairie VirtualWire incompatible avec la version 1.0.6 de l’IDE.  la rétro-compatibilité n’est visiblement pas respectée. D’où, modifications de :

VirtualWire.h

VirtualWire.cpp

Pas facile à trouver...

 * La récupération des codes RF des prises Phénix a été fastidieuse. C’est pourtant si simple…

 * La communication entre le Pi et le Uno via USB-Série m’a posé un gros problème et une perte de temps de plusieurs jours. Jusqu’à ce que j’apprenne que l’instruction PHP fclose émise par le Pi entraînait un reboot systématique de l’arduino…

Pour y remédier : interposer un condensateur de 10 microfarads entre la borne GND et la borne Reset de l’arduino…

Mais ce n’est pas tout ! Laisser ce condensateur lors du téléversement d’un sketch provoque une erreur "à causes multiples" qui fait couler beaucoup d’encre, si l'on peut dire,  dans les forums :

  * J’ai également appris à mes dépends qu’il fallait composer la commande sudo adduser www-data dialout sur le pi pour autoriser apache émettre et recevoir des données sur TTYACM0 le port USB attribué à l’Arduino.

Ce que je viens de présenter n’est qu’une première étape. Prochainement, je me propose de :

- Remplacer la liaison USB par une liaison sans fil XBEE

- Stocker l’état des entrées-sorties en eeprom de l’arduino et les renvoyer au Pi en guise d'acquitement.

- Afficher sur l'interface web une température acquise par l'arduino (LM35 sur une entrée analogique, ce qui justifie la présence de l'Arduino)

- Refondre l’interface web de manière plus présentable.

- Piloter la mise en marche et l'arrêt d'un équipement dans une plage horaire spécifique.

  (Utilisation de crontab sur le Pi).

Crédits:

Un petit GRAND merci à ces sources d'inspiration et à leurs auteurs dont certains ont pris la peine de répondre à mes mails parfois désespérés!

- Idleman

- timmyzophrène

- Novares

- http://fabrice.sincere.pagesperso-orange.fr/

- http://electroniqueamateur.blogspot.fr/

- http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ARDUINO

- http://eskimon.fr/category/arduino

  [Le projet] <==

Commande depuis un smartphone.

Je ne savais absolument pas comment m’y prendre. J’ai cherché des pistes, des conseils, des tutos sans grand succès.

Je me suis dit qu’il existait peut-être des générateurs d’apk.

Il en existe effectivement. De là a en trouver un bon…

J’ai fini par trouver App Inventor 2 en discutant avec un « collègue » qui développe un projet similaire également à base de Pi et de Uno.

La réalisation est bien plus simple que je le craignais !

On définit le type d’interface (ici: webviewer), l’url cible puis on rappatrie l’apk que l’on installe sur le smartphone.

L’appli (si on peut appeler ça une appli) se contente d’invoquer l’url du serveur sur le Pi. Apache et l'arduino s’occupent du reste…

Aussi simple que cela. En une heure c’était plié.

Comme je l'ai déjà indiqué, l'interface web est (très) dépouillée mais elle répond à l'objectif initial: témoigner de la faisabilité à l'aide d'un exemple simple.

Au niveau de la sécurité, pour le moment le me suis contenté de rediriger un port tcp vers le port 80 du Pi.

L’url est donc du type http://toto.ddns.net:54321/frontdemo.php

  [Test de l'ensemble] <==   ==>  [Conclusion perspectives]

 test de l’ensemble sur le réseau local

Avant d’ouvrir le service sur le web, j’ai réalisé un test de l’ensemble sur le réseau local.

- Le Pi est connecté au switch du réseau interne par son port éthernet.

- L’arduino est relié au Pi au moyen d’un cable USB.

- Une petite breadboard comprenant une led témoin et l’émetteur RF433 Mhz se raccorde sur le pi selon le schéma suivant :

Chaque module ayant été testé séparément, l’assemblage s’effectue sans mauvaise surprise selon le schéma suivant

j’ouvre le navigateur et je compose l’url du Pi : 192.168.yyy.zzz/frontdemo.php

j’obtiens un formulaire pas très joli, mais suffisant pour valider mon travail.

S1_ON / S1_OFF me permet d’allumer / éteindre la led témoin (rouge) sur le montage.

Je peux ensuite brancher successivement trois prises  (B, C et D) à proximité pour entendre (avec soulagement) le relais 'claquer' et le témoin lumineux accuser réception sur la prise.

L’essentiel de l’objectif est atteint, si ce n’est qu’il faut maintenant de préoccuper de la télécommande à partir de mon smartphone.

 [Script PHP sur le Pi] <==   ==> [Application Android]

Le sketch de commande

Le développement s’est déroulé en deux étapes.

Aaprès réception d'une commande :

1. simulation de l’exécution en allumant quatre leds selon la demande.
2. Traitement réel par émission des codes spécifiques à chaque prise.

Au final, pour le moment j’ai conservé une led « branchée » sur la touche A pour un test rapide. Les trois autres vraies prises ont maintenant leur usage réel dans la maison.

• L’une allume la radio
• L’autre allume une rampe de leds en éclairage indirect
• La troisième  désactive la veille TV, décodeur TNT et enregistreur.

Pour cette dernière, j’envisage de mettre en place une tâche CRON. (arrêt/marche en fonction de l'heure)

A noter également que la télécommande d’origine est toujours fonctionnelle et permet de déroger, si besoin est.

Voici le code téléchargeable :

 Un petit point de détail: au début de mes tests, j'ai pu envoyer les commandes aux prises sans installer une antenne sur le module d'émission, comme c'est recommandé. Un peu plus tard, cela s'est avéré nécessaire.

la longueur d'onde en 433Mhz est 70cm (gamme d'ondes décimétriques) un brin 1/4 d'onde mesure donc 70/4=17.50 cm. Voir ICI pour plus d'information. Il suffit de couper un fil de cuivre de ~ 17.5 cm (17cm marche aussi bien), plutôt souple, isolé et de section ~ 0.4mm2 et de le souder à l'endroit adéquat sur le module d'émission.

   [Liaison USB série] <==  ==> [script PHP du Pi]

Test de la liaison série

Ce n’est pas le plus fastidieux, encore faut-il découvrir comment ça marche.

Je n’ai eu que l’embarras du choix lorsqu’il s’est agi de réaliser l’essai. Je suis parti d’un exemple portant sur le scénario suivant :

-         le Pi envoie un ordre

-         Arduino le reçoit, l’exécute et renvoie le résultat au Pi.

-         Le pi récupère et affiche le résultat sur la console

Pour les besoins du test,  je récupère une valeur analogique quelconque en branchant sur le port analogique A0 un fil de raccordement laissé en antenne, ce qui suffit pour afficher des valeurs différentes à chaque mesure.

Le résultat qui s’affiche sur la console prouve la bonne marche :

Le script python est celui-ci :

Le sketch est celui-là :

 Tout est dit!

   [Liaison USB série] <==  ==>  [Sketch Arduino]

Validation de la radio-commande des prises Phénix par l’arduino.

Pour ce projet, la plupart des étapes a mettre en œuvre est largement décrite et utilisée depuis plusieurs années.

Il en reste une qui l’est un peu moins et qui est dépendante du matériel, c’est la télécommande des prises Phenix en ma possession.

J’avais acheté précédemment un lot comprenant deux prises YC2000B avec une télécommande et il était impératif que je valide en priorité la faisabilité d’une télécommande à l’aide de mon module émetteur RF 433.

Sur la télécommande, la configuration du dip-switch est comme ceci. (combinaison déterminée par mes soins)

Sur les prises, on ajoute un bloc identifiant (A, B, C ou D). ci-dessous: la prise A.

Même si la technique est largement décrite, il m’a fallu tout d’abord installer et tester le module d’émission RF 433 Mhz.

Etape 1 : test des deux modules RF 433 Mhz, émission et réception.

Pour savoir si l’émission fonctionne, il faut mettre aussi en œuvre la partie réception et je ne pouvais pas réaliser ce test à l’aide d’une de mes prises Phénix car je ne connaissais pas encore la trame de commande…

En conséquence je dois utiliser aussi le module de réception.

Des scripts de test existent déjà « dans le commerce ». Je consulte divers blogs pour faire mon choix.

Il s’agira de brancher le module d’émission sur l’arduino et le module de réception sur le Pi.

Heureusement, il y a Findus l’excellent blog Electronique en amateur.

Tout y est parfaitement décrit et j’ai ainsi, gagné beaucoup de temps.

Etape 2 : Décoder les trames à émettre pour actionner une prise Phenix.

Le système d’adressage des prises étant connu, cela ne me donne pas la nature du code à envoyer pour allumer et pour éteindre une prise donnée !

Et c’est là que la galère commence…

J’ai fouillé des heures durant sur la toile en Français d’abord puis en Anglais. J’ai essayé plusieurs combines sans succès. Un peu démoralisé, je commençais à envisager une refonte importante et décevante du projet, me bornant à récupérer de l’information en provenance de divers capteurs (présence, température, humidité, etc…) et à actionner en conséquence quelques relais de puissance pour quelques fonctions réduites comme un éclairage indirect en corniche.

Vous le savez tout comme moi, nous cherchons souvent bien loin ce que nous avons à portée de la main.

La piste m’a été fournie par un blogueur  du « bout du monde ». Qu’il en soit remercié.

Pour décoder les trames émises par la zapette phenix, la solution résidait tout simplement dans un exemple fourni par l’IDE d’Arduino sous la forme d’un sketch baptisé ReceiveDemo_Advanced de la librairie RCSwitch.

 Le résultat a donné pour ma configuration :

Je choisis arbitrairement le mode Tri-state. La commande permettant, par exemple, d’activer la prise B dans le sketch sera :

mySwitch.sendTriState("F000FF0FFF0F");  

A noter enfin qu'il n'est pas interdit de commander plusieurs prises en même temps.

  [Présentation]  <==  ==> [liaison USB série Pi-Uno ]

Mise en place du script PHP

prérequis:

Le serveur Apache est déjà installé sur le Pi (cf saison 1)

Je dispose par ailleurs des deux outils de base pour travailler sur le Pi depuis mon PC :

-         PUTTY, émulateur de terminal

-         WinSCP, client SFTP vraiment bien fait.

Je téléporte dans le répertoire /var/www du Pi un script php de ma fabrication, bien que fortement inspiré de ce que j’ai pu glaner sur le net à ce sujet.

C'est à dessein que l'interface est dépouillée. pour le moment, seul l'aspect fonctionnel me préoccupe. Ensuite, il sera toujours temps "d'embellir la mariée".

Le script PHP frontdemo visible ci-dessous et téléchargeable ici affiche un formulaire qui enregistre une commande et la transmet à l'arduino par l'intermédiaire d'une liaison USB-Série.

Notes: 

Pour déterminer sur quelle voie tty se trouve l'arduino, procéder de la manière suivante (câble USB débranché):

- à partir de la console Putty, se connecter au pi et s'identifier.

- au prompt, composer la commande ls -l /dev/tty*

- relever les lignes qui suivent tty9

- brancher le cable usb sur l'arduino

- composer à nouveau la commande ls -l /dev/tty*

- la ligne supplémentaire affichée après tty9 est la bonne. c'est elle qu'il faudra invoquer dans la commande $comport en début du script.

  [script PHP] <==  ==>  [Test général]