Encore un pti coup de pub pour une série de podcast francophone d’origine belge franchement super intéressantes. Il y a deux interlocuteurs (maintenant 3) qui invitent un développeur et cause technique, autour des technos .net http://devapps.be/ Les sujets sont super intéressant.
Ca y est, un livre est sortie, le 22 aout, en français sur la techno Xamarin. Ecrit par Olivier Dahan, MVP Microsoft. http://www.e-naxos.com/Blog/post/Rappel-Xamarin-Forms-ENFIN-LE-LIVRE-EN-FRANCAIS-!.aspx Ce livre est pas donné (comme tous les bouquin de tech), mais au dire de l’auteur, il ne se fait pas beaucoup d’argent avec. Et on peut le croire, car il est l’auteur d’une remarquable série de pdf, gratuit, que je vous recommande : http://www.e-naxos.com/AllDotBlog.html Je vais sans doute m’appuyer sur ce bouquin pour mes prochains articles. Alors un peu de pub pour son auteur n’est qu’un juste retour des choses.
Vous avez tous pu constater le buzz récent autour de Xamarin. J’étais à deux doigts d’acheter une licence iOS qui m’aurait couté dans les 700€. Un brave de chez Xamarin m’a conseillé d’attendre la build de Microsoft, ce que j’ai fait. Un grand merci à ce monsieur de chez Xamarin sans quoi j’aurai été bien bien vénère, il m’a fait économiser beaucoup… Xamarin est donc gratuit ! Et c’est une excellente nouvelle. Car sans ça, les étudiants, les amateurs, les petit auto-entrepreneur comme moi voir même quelques TPE aurait bien eu du mal à se lancer sur cette techno. Microsoft rachète donc Xamarin et l’offre dans toutes ses éditions Visual Studio 2015 (community, pro et entreprise). Par contre le reste des offres de Xamarin, à savoir les cours via l’university Xamarin et son centre de test restent payant. Je comprends que Xamarin doit trouver son modèle économique, mais maintenant que Microsoft est derrière, j’espère que les cours seront gratuit. D’autant plus qu’ils font des efforts fou pour que les développeurs codent pour Microsoft. Donc pourquoi faire payer des cours sur une technos qui permettrait d’universaliser nos apps, dont celle sur WUP. Bref, l’academy de Microsoft est gratuite, j’imagine qu’a terme on aura des cours Xamarin dessus aussi. Autre bonne nouvelle, c’est l’arrivé depuis qq jours du simulateur iOS sur Windows. Oui oui, j’ai bien dit un simulateur iOS sur Windows. Il est inclu dans la version stable de Xamarin depuis début juin 2016. Je l’ai testé en version alpha puis stable depuis un mois. Et ca marche plutôt bien ! 1) Situation J’ai donc testé Xamarin iOS. J’ai une application (Trackus) que je développe depuis maintenant 2 ans sur divers plateformes (Windows Phone, Android, Web App, WUP), mais il me manquait iOS. Comment faire ? – Choix 1 : natif (Objective C ou Swift). Je préfère en générale cette approche. Coder en natif permet d’apprendre pas mal de chose, d’avoir des ressources (docs, communauté, billet Stackoverflow…). Mais ici je n’avais même pas le matériel. Et chez Apple ça coute un bras. De plus il faut tout réapprendre. Je bosse sur Windows depuis toujours. Et le mac… je connais pas ou mal. Je galère pour faire des trucs tout simple. Mon temps d’apprentissage va devoir impacter en plus l’OS et les outils de l’OS. Ca fait beaucoup pour un noob. – Choix 2 : Hybride (Cordova, Ionic). Pourquoi pas. J’ai passé un mois à me former sur AngularJS, Ionic aurait été un choix. Mais mon application nécessite de tourner en background, utilise des maps et le GPS… J’ai des doutes sur la fiabilité de tout cela en hybride. Peut être ai-je tort. Cela pourrait être un sujet prochain. Je n’ai pas vraiment étudier la question à fond. – Choix 3 : Xamarin iOS. C’est mon choix. Plus par curiosité qu’autre chose. Je suis les divers évolutions de Xamarin et le ressenti des développeurs. Cette techno est prometteuse. Mais dans les faits ? – Choix 4 : Xamarin Forms : autre solution, non étudié. Je voulais d’abord me rapprocher du natif et aborder éventuellement Xamarin Forms plus tard. Pour info, mon application (http://trackus.reactor.fr) propose de géo-localiser un utilisateur A et de permettre à un utilisateur B de le suivre sur une carte. J’utilise pour cela un code alphanumérique sur 6 chiffres qui va identifier un parcours. L’utilisateur A envoi ce code à l’utilisateur B qui peut alors suivre sa trace. Ce code est modifiable ce qui permet de garder un certain anonymat. J’ai donc un serveur qui permet d’échanger ces informations (Web API2 + Entity-Framework). Voici les apps déjà en prod (bêta): Web App : http://trackus.reactor.fr/pages/observer.html?code=AAAAAA Windows Phone (Silverlight) : https://www.microsoft.com/fr-fr/store/apps/trackus/9nblgggxzpg7 Windows 10 : https://www.microsoft.com/fr-fr/store/apps/trackus-10/9nblggh5xq6q Android : https://play.google.com/store/apps/details?id=fr.reactor.trackus Je trouve le sujet intéressant car il aborde d’autre sujet que la classique “liste de tâches” ou le flux RSS qu’on affiche en liste. Ici on a du GPS (droits utilisateurs), du offline/online à gérer (perte de réseau pendant un déplacement, stockage des données, gestion http REST), une tâche en background (cycle de vie) et la manipulation de maps (iOS, Google, Bing). Bref ya du boulot mine de rien. 2) à fond les ballons On y va on code. Ha oui, mais attends, d’abord le matériel… Peux importe ce que vous faites, si vous créez une app pour iOS il vous faudra un mac. Si vous êtes un peu short, il existe des solutions comme MacInTheCloud qui vous permet de louer un mac sur internet. Mais vous ne pourrez faire que du simulateur car impossible de brancher un device physique sur la machine. Sinon vous achetez un mac. Un mac mini fera l’affaire. J’ai acheté le mien sur le bon coin. Une pure affaire. Ca part comme des petits pains, donc sauter sur l’occasion. Vous avez donc un poste Windows, un poste Mac, branché sur le même réseau. C’est parti. Faut tout installer. Yen a pour un moment si comme moi vous tourner max à 2 Mbps (oui ca existe encore !). Il faut installer Xamarin sur le mac et installer Visual Studio 2015 update 2 + le kit simulateur. Tout est dis sur le site de Xamarin : https://developer.xamarin.com/guides/ios/getting_started/installation/ https://developer.xamarin.com/guides/cross-platform/windows/ios-simulator/ Quand tout est installé il faudra créer un projet iOS et tester la connexion avec le Mac (agent de build) Il faut que votre icone soit verte. Sans ça pas de connexion avec le mac, donc pas de build ni de simulateur. Dans l’ensemble le setup se fait pas trop mal. Xamarin améliore grandement la simplicité car avant il fallait gérer l’agent de build à la main (voir précédent post sur le sujet). 3) Les mains dans le cambouis J’ai travaillé essentiellement sur Visual Studio avec le simulateur. Ce dernier propose pas mal de petites options intéressantes. Il y a même un simulateur de déplacement (à pied, en vélo et en voiture) ce qui permet de tester le GPS. Idéale dans mon cas. Il manque cependant un bouton pour couper le réseau ou un “dégradateur de réception 3G/4G” histoire de tester…
Prise de notes : J’ai suivis deux tutos gratuit assez complet sur Xamarin, depuis la MVA (Microsoft Virtual Academy). Ces tutaux commencent a être un peut vieux (tout est relatif, il date de 2014 quand meme, l’année de lancement de Xamarin Forms). Cependant j’y ai appris pas mal de chose. Certaine question ont eu leurs réponses, mais beaucoup d’autre ont été soulevées. Je noterai ici mes notes concernants Xamarin. Ce n’est pas un tuto mais plutôt quelques réflexions, astuces, mémo et lien en tout genre. Ressouces : Développer une application cross-plateformes avec Xamarin Cross-Platform Development with Xamarin & Visual Studio Design Chaque OS possède son propre design. Par exemple ici le date picker : 3 écrans iOS Android et WP avec une même interface graphique (Xamarin.Forms) Xamarin permet de créer des applications natives respectant chaque UI. Mais il faut les construire une à une. Pour aller plus vite, on peut utiliser Xamarin.Forms qui va mutualiser la création d’interface graphique pour les 3 OS. Shared Project VS Portable Library ? Shared Project : Contient des éléments partagé (code, image data). Il n’est pas compilé mais importé dans chaque projet (WP, Android, iOS) et ensuite il sera compilé. MVVM + IoC + dependency injection. Peut inclure des #ifdef (if IOS, if Android…) Portable Class Library (PCL) : projet compilé puis importé par d’autre projet WP, Android, iOS. Ne contient que du code par définition (business logic). Peut contenir du data static (fichier xml, json… le passer en ressource embarquée). Xamarin PCL a une class nommé Device qui permet de de jongler avec les plateformes (Device.OS, Device.OnPlatform, Device.Idiom, Device.GetNamedSize) Plus d’info : Explication officielle de Xamarin Wiki de MvvMCross Device class de Xamarin article intéressant, retour d’expérience Mais attention, sous android, les données sont situées normalement dans le répertoire Ressource. A priori on ne peut pas charger des données sur android depuis un shared project. Du coup une image ne peut pas être mutualisée. A voir si ca a pas changé depuis (info de 2014) Life Cycle iOS App + View (different state) Android App + Activity Astuce : sur android, lors d’un chargement de carte, il faut attendre qu’elle soit chargée avant de lui attribuer des markers. Astuce : sur android, les cartes google map on besoin d’une clé par device en dev, à ajouter manuellement dans l’API console en ligne. https://developer.xamarin.com/guides/android/platform_features/maps_and_location/maps/obtaining_a_google_maps_api_key/ Astuce : encore sur les maps android, il faut inclure des libs (GooglePlayServicesLib.dll et des Xamarin.Android.Support…) ou aller sur les prendre directement dans le components stores de Xamarin. Ou utiliser un package Nuget Xamarin Form Maps qui s’en chargera. Astuces : les cartes google on besoin de tout un tas de permissions.
Voici un mini tuto qui va expliquer les quelques étapes pour réaliser un serveur web sur le board ESP8266, qui pilote une bande de led RGB. le tout contrôlé à distance via Wifi par une simple application windows phone (qui aurait pu être une app web directement hébergé par l’ESP, je viens seulement d’y penser…) L’idée, piloter à distance via son smartphone la couleur de la lumière d’une bande de led RGB. La démo : Outils / soft / materiel : 1 ESP 12 dev kit (ou avec un board moteur) 1 amplificateur (12V/24V) 4 fils de couleurs (blanc, rouge, vert, bleu) (connecteur male/femelle) 1 alimentation 12v ou 24v suivant votre bande led en sortie (optionnel un interrupteur) 1 ou plusieurs bandes led RGB (5050 pour moi) (exemple) 1 pince coupante ou a dénuder 1 tourne vis plat Node.js installé sur votre machine + le package esp8266 Lua Loader (windows) ou un autre soft de votre choix, ou en ligne de commande 1 smartphone (windows phone mais le code serait pas dur à réaliser sur iOS ou Android) Montage : Nous avons d’un coté l’application smartphone, autonome, connecté en wifi sur ma box. De l’autre le montage composé d’un module dev kit ESP 12 (ESP8266) relié par 4 fils (blanc pin 4, rouge pin 6, vert pin 7, bleu pin8) à l’amplificateur. Celui ci est alimenté en 12v et en sortie on a branché une bande led RGB avec 1 fil par couleur + un fil blanc (+12v). Vous n’êtes pas obligé d’avoir un amplificateur. Vous pouvez à la place réaliser un montage supplémentaire avec 3 moftsets (ici pour plus d’info). Mais il faut impérativement isoler le circuit ESP (5v) de celui de vos leds (12v ou plus) Par mesure de sécurité, je vous conseille l’amplificateur + un transfo 12v, c’est simple et pas de risque de prendre du 230v. Faites attention quand même ! Fonctionnement : L’esp boot sur le fichier init.lua. Celui ci va se connecter en mode station (paramétrable en AP si besoin) et obtenir une adresse IP de ma box (DHCP). Celle ci s’affiche (notez la pour la suite). Ensuite le code lance un serveur web http très simple, écoutant le port 80. Le serveur va donc traiter des urls de ce type http://192.168.1.18/?r=125&g=30&b=240&on=1 Les paramètres r, g, b correspondent à la couleurs désiré. Le paramètre on sert pour allumer ou éteindre la bande led. A ce stade, le serveur attend un ordre que l’on enverra depuis un smartphone. Pour savoir que mon serveur est démarré, je lance une petite séquence de lumière Code ESP: J’avais l’habitude de séparer mon code en plusieurs fichiers, histoire d’uploader mon code plus facilement (car c’est long) sur l’esp. Ce code https://github.com/couscousbzh/ESP8266-RGBServer vous permet de jouer avec. Il fonctionne tant que vous êtes connecté par usb. Mais dès que vous rebootez, c’est la catastrophe. Et je ne sais pas pourquoi. Donc lors de mon dev, tout ce passe normalement. Mais dès que je passe en mode prod, c’est dire une alimentation simple par usb de l’esp, ca ne fonctionne plus. Si quelqu’un sait pourquoi, pourriez vous me laisser un commentaire svp ? J’ai donc tout réunit dans un seul fichier init.lua, et c’est un peu mieux (ou pas). Vous le trouverez ici : https://github.com/couscousbzh/ESP8266-RGBServer/blob/master/initallinone.lua (pensez à le renommer en init.lua) Explication du code : Pour afficher une couleur, par exemple le rouge, on balance un niveau haut sur le fil rouge. Donc 5 volts avant ampli puis 12v en sortie. On a du rouge si le vert et bleu n’éclaire pas du tout. Sinon on a de la lumière blanche si le rouge vert bleu éclairent tous. En informatique, on représente souvent la couleur par un integer sur 8 bits c’est à dire un chiffre entre 0 et 255. Ecrit comme cela RGB(255,0,0) signifiera que l’on veut du rouge seulement. Pour mieux vous familiariser avec une palette de couleur RGB je vous conseille un utilitaire de dessin comme paint.net, photoshop ou des extensions pratique comme la pipette sur Firefox (colorzilla) ou Chrome. Si on veut du marron on doit avoir une moitié de rouge, pas de vert ni de bleu. Ce qui donnerait RGB(127, 0, 0) Voila, maintenant que l’on comprend la couleur traduite en RGB il faut comprendre comment fonctionne une bande led. En faite pour afficher que du rouge c’est simple, on balance 12V dessus. Mais pour afficher une moitié de rouge ? Et bien nous allons mettre du 12v puis du 0v puis du 12v etc… Ceci se traduira par un signal dit « signal carré ». Pour obtenir un marron, il faut alterner du rouge et du noir. A haute fréquence, l’oeil ne pourra pas distinguer le rouge du noir, mais verra le marron. Si la fréquence est trop basse, 1Hz par exemple (1Hz = 1 période par seconde) donc 0.5s de noir et 0.5 rouge, ce sera perceptible par l’oeil. Mise en application dans l’esp : Pour réaliser ceci nous allons utiliser pwm (pulse width modulation ou modulation de longeur d’onde) qui est une fonction livré avec l’API NodeMCU. pwm.setup(redPin, 500, 512) : ici nous allons initialiser le pin ‘redPin’ (le 6 dans mon cas) à une sortie de type PWM avec une fréquence de 500 Hz et un duty de 512 (valeur entre 0 et 1023). Considérez le duty comme un pourcentage. 0 = 0% et 1023 = 100% il suffit de convertir le chiffre de tout à l’heure compris entre 0 et 255 en chiffre de 0 à 1023. Facile c’est un multiple de 4 ! Attention toutefois, ici 1023 correspond à lumière éteinte. Donc l’opération consiste à faire 1023 – 4 * r où r correspond au chiffre compris entre 0 et 255. Le reste du code (partie serveur) est expliqué dans mes précédents articles. Code partie smarphone : Comme je le disais précédemment, on peut très bien coder cette partie en app Web avec des appels ajax par exemple ou bien la coder sur Android ou iOS. Pour ma part je l’ai…
Démo live Listy : http://listy.reactor.fr Pour la petite histoire, on m’a demandé de faire un devis concernant une application web. Normalement on ne commence pas le travail tant qu’on a pas un acompte et surtout un cahier des charges bien ficelé. Surtout lorsque le client n’est au final plus trop sur de lui… qu’il doit réfléchir. Bref vous l’avez compris, j’ai travaillé à perte. Mais j’ai beaucoup gagné en compétence… En effet le sujet est simple : créer une liste d’envie sur internet. Il en existe déjà quelques une plus ou moins abouties. Le principe consiste à faire une liste de course avec des liens web et de sortir une liste au final à partager avec ses amis. Au premier abord, pas un énorme intérêt. Dans mon cas personnel j’adhère à l’idée pour noël, au lieu d’acheter des cadeaux pourris (chose que l’on fait quand même pour le fun), on se fait une liste d’objets utiles ou qui peuvent nous intéresser, chacun s’organisant comme il veut pour offrir le ou les cadeaux en question. J’avais besoin d’un projet comme celui ci pour enfin me former sur Angular. Entre temps j’ai fait une conf sur Angular 2 et bon… je tombe mal on va dire. Mais l’expérience en valait la peine. Ici je vais vous présenter ce que j’ai fait, les méthodes utilisées, les softs, plateformes… et surtout ce qui m’a posé problème en vous donnant les solutions. 1) Architecture : Je voulais une architecture qui me permet de totalement découpler les services de l’application. Un peu d’historique : 1) Il y a quelques années, et ça se fait encore bien sur, on avait un site web (Asp.net WebForm) hébergé sur un IIS qui avait sa propre base de donnée. Du all in one. Très pratique. En effet pour accéder aux données on pouvait directement taper dans la BD pour afficher une donnée. Depuis les développeurs ont structuré leurs applications en ajoutant des couches, notamment la couche d’accès aux données (DAL) et une couche métier. Avantage : plus propre, réutilisable, maintenance plus simple, on peut changer de BD sans tout péter…Inconvénient, plus compliqué pour un débutant, plus de code donc un peu plus lourd à maintenir (oui c’est aussi écrit en avantage…) 2) On a vu ensuite apparaitre dans Visual Studio le modèle MVC. Depuis on ne parle que de lui. D’ailleurs j’ai cru lire quelque part que Microsoft allait laisser tomber WebForms dans ces prochaines versions de Visual Studio. J’ai personnellement mit du temps à m’y mettre. C’est une autre façon de concevoir son application qui a aussi ses avantages et inconvénients. Mais l’intérêt majeure face aux WebForms, c’est que l’on peut y faire des tests. J’en parlerai pas ici, c’est pas mon fort. La encore on avait tendance à accéder aux BD directement, soit en mode crado, soit via une couche. 3) Puis les sites webs ont proposé des fonctionnalités que l’on aurait bien vu dans nos mobiles, dans une application. Problème : comment accéder à nos données ? Sur le site web, on a quelques éléments de sécurité et fonctionnalités « intégrés » de façon native (la session, le système de fichier, droit utilisateurs, …) ce que j’appelle du all in one. Mais la le client, c’est à dire l’application mobile est totalement déconnecté de mon environnement de production. Qui plus est, sur un OS potentiellement différent et potentiellement dangereux, pas stable, hostile… pire entre les deux on a INTERNET le mal absolut si j’en crois mon ancien employeur Jaques Séguéla… Qui depuis à compris qu’il pouvait se faire du blé alors il a changé d’avis. Bref, comment faire ? Pour cela un web service était nécessaire. Jusque la j’avais travaillé avec SOAP. Mais bon SOAP c’est pas vraiment une archi, c’est plutot un protocole. Et puis SOAP c’est chiant. Depuis on ne parle plus (ou presque) que de REST. REST (Representational State Transfer) comme son nom ne l’indique pas est sans état (en fait dans le titre on parle d’état d’une ressource, et non de l’application). Ceci à des conséquences pour l’expérience utilisateur, surtout pour les « sessions » car en faite il n’y en a pas ! Vous pouvez laisser votre application dans un état et la retrouver dans le même état quelques temps après. En général, par exemple avec Asp.net WebForm, votre temps de sessions par défaut était de 20 min. Les développeur avait tendance à stocker pas mal de chose dedans. C’était très pratique mais on perdait tout ou presque à la fin de session (sauf bricolage ou stockage en BD). Ici pas de session. Cela va avoir un impact pour la sécurité de nos données (nous le verrons plus tard). Mais surtout, enfin pour moi, l’expérience utilisateur va en être affecté positivement : suivant le niveau de sécurité voulut, on peut maintenir un équivalent « session » sur plusieurs heure, voir jour. Comme sur Facebook ou l’on a pas besoin de se reconnecter toutes les heures. Un autre intérêt de REST c’est qu’au niveau maintenance et évolution des serveurs c’est plus simple à gérer. Mais le gros gros intérêt de REST, c’est qu’il vous permet de gérer n’importe quel type de client. Ici nous parlerons d’un client web Angular.js, mais rien ne vous empêche de créer une app Native Android ou un client Windows 10, le serveur n’aura besoin d’aucun update ! Il est prêt pour tout, ce qui change du tout au tout par rapport à un site php ou asp.net. (moins vrai avec la dernière version d’Asp.net qui combine MVC et API2) Coté client la encore, de la souplesse. J’utilise Angular principalement pour des raisons de formation, mais aussi pour éventuellement reprendre ce code et l’utiliser avec Ionic ! Ce formidable framework est basé sur Angular et propose de déployer son app, grâce à Cordova, sur plusieurs OS mobile comme iOS, Android ou Windows Phone. Donc vous l’aurez compris, utiliser ce genre d’architecture permet de voir loin ! 2) La construction Pour l’IDE, j’ai opté pour Visual Studio 2015, normal vu que je…
Dans cet article, nous allons voir comment passer du mode AP (Access Point) utilisé dans l’article précédent, en mode station, c’est à dire en client simple, comme votre smartphone ou pc portable. Le ESP 12e dev kit est livré avec le firmware NodeMCU. NodeMCU est une plateforme Iot open source qui permet l’utilisation du langage de script Lua.Etant un peu débutant, je préfère que vous alliez vous même lire les définitions officielles de toutes ces notions. Lua va vous permettre d’écrire facilement du code pour faire fonctionner votre ESP. Il est basé sur le langage C. Pensez à gérer votre mémoire. Il faut savoir que l’ESP boot sur un fichier : init.lua. L’extension .lua signifie que le fichier n’est pas compilé. L’extension .lc indique que le fichier est compilé. LuaLoader vous permet de compiler les fichiers que vous souhaitez. Mais j’ai remarqué que beaucoup de code init.lua se charge de compiler le code au démarrage, puis efface tous les fichiers Lua. Cela permet de garder un peu de mémoire. Mon fichier init.lua fait ceci puis exectue main.lc (la version compilée de main.lua). Voici les fichiers sur le repo git : https://github.com/couscousbzh/ESP8266-Proto2 init.lua (ajouté) webserver.lua (inchangé) header.htm (inchangé) main.lua (modifié) Les modifications se trouvent dans le fichier main.lua. La premiere est simple, au lieu de charger webserver.lua je charge la version compilée webserver.lc (car je rappelle que les .lua seront effacés par le init.lua, lui meme compilé en .lc et effacé ensuite) La deuxième modification concerne le mode station/ap. Pour switcher il suffit de modifier la variable local modeStation = true/false. Il faudra aussi renseigner le SSID de votre box wifi et sa clé. Dans le proto 1, le mode était AP (Access Point), c’est à dire que votre ESP se comporte comme votre box wifi maison et va gérer son propre réseau (192.168.2.x). Il faudra alors changer de wifi et passer sur le wifi de l’ESP. Je préfère rester sur le même réseau wifi que celui de ma box, car je suis fainéant et je ne souhaite pas modifier mon wifi à chaque fois que je veux utiliser l’ESP. Donc je dois passer le mode en station. Le code prévoit 5 tentatives de connexion, cela peut prendre quelques secondes. Ensuite votre box wifi va attribuer une adresse IP à votre ESP (si la box est configurée avec un server DHCP, ce qui doit être le cas par défaut). Normalement vous pouvez lire l’IP s’afficher sur LuaLoader apres un reboot. Vous pouvez vous connecter dessus depuis votre browser préféré. A plus qu’à !
Dans le précédent article, je présentais un petit bout de code pour faire clignoter une led sur le board. Simple mais pas plus efficace que sur une arduino nano. Maintenant tâchons d’exploiter pleinement l’intérêt de cet appareil : le Wifi ! Jusque la il fallait pas mal bricoler pour obtenir un objet connecté, en général fallait rajouter un shield ou un modume ethernet ou wifi. Fini tout ca, avec l’ESP12 E Dev kit on a une puce ESP8266 pour le wifi sur un board équivalent à l’arduino nano en un peu plus gros. Nous allons voir ici comment créer un simple serveur web qui répondra à deux boutons web pour actionner deux leds sur le board. Nous allons avoir besoin d’un petit outil LuaLoader qui permet de gérer les scripts que l’on balance sur l’ESP. On va lui uploader 3 fichiers : main.lua (code principal) webserver.lua (code concernant le serveur web) header.htm (page web envoyé au client) Pour obtenir ces fichiers, voici le repo git : https://github.com/couscousbzh/ESP8266-Proto1 Petite explication : main.lua va charger le fichier webserver.lua. J’aurais pu tout mettre dans un seul fichier mais vous allez vite vous rendre compte qu’uploader un fichier prends du temps. Donc autant bien répartir son code. header.htm contient du code HTML CSS et JS. Il est incomplet volontairement. La fin du code est géré par webserver.lua pour rendre dynamique les boutons (état on et off). Il faut charger ces 3 fichiers sur l’ESP avec LuaLoader. Ensuite il faut faire un dofile sur main.lua. L’application va alors démarrer et votre serveur devrait être opérationnel. Connectez vous sur le réseau wifi (il s’appelle « DoitWifi » et le mot de passe est « 12345678 »). Ensuite charger une page web sur un browser avec l’url suivante : http://192.168.2.111. Si tout ce passe bien, vous obtenez une page web très simple avec deux boutons. Cliquez dessus et admirez le résultat sur l’ESP12e, les leds s’allument sur ordre des boutons web !