La serre Connectée d-meter


Logo du projet d-meter

D’abord je voudrais clarifier le nom : Demeter est la déesse grecque de la moisson et de la fertilité des graines.

D-Meter est un projet qui a démarré autour d’une table, pendant un après-midi classique de Janvier à Paris, sous la pluie. On cherchait un sujet pour travailler sur le thème des objets connectés, quelque chose à la fois utile, facile et simple. Le résultat : une serre d’intérieur connectée !

 

Right place, right time

L’idée tombait bien, puisqu’au même moment le Hackathon “Zone 61” était lancé pour mi-janvier 2015. Il fallait donc se dépêcher et affiner le concept.

 

Pourquoi une serre ?

Pour plein de raisons :

  • Pour avoir un petit coin bio dans un appartement sombre, typiquement parisien, et participer au mouvement de l’agriculture dans la ville
  • Pour s’étonner à chaque fois de la croissance des plantes. Et faire découvrir la nature aux enfants, chez vous directement. Regardez les photos, avec 3 jours d’écart, sans engrais, sans miracles :

d-meter, ça pousse !

  • Pour avoir une base de recherche sur l’IoT et le Cloud
  • Pour ne pas avoir à s’occuper des plantes, et chercher à automatiser la problématique avec l’aide du Cloud
  • Etc.

 

Pourquoi le Cloud (Azure) ?

L’utilisation du Cloud peut sembler au départ comme inutile. Mais rappelons-nous d’un schéma assez plébiscité par Microsoft par rapport à l’IoT :

IOT selon Microsoft

(Source : « Embarquez pour l’Internet des objets avec Microsoft », Microsoft, 16 déc. 2014)

On voit bien deux sens :

  • l’information qui remonte dans le Cloud pour mieux la comprendre
  • l’information qui redescend vers le device pour le piloter

Dans le cas de notre serre, l’intérêt du Cloud est de stocker et analyser les données, puis piloter la serre, avec un algorithme qui va s’améliorer au fil du temps. Le gain pour l’utilisateur de la serre est que, sans avoir la moindre connaissance en agronomie, il pourra avoir un paramétrage éprouvé pour la croissance de ses plantes :

  • par les autres utilisateurs de la plateforme (le coté social)
  • par des algorithmes prédictifs (avec du Machine Learning)

La serre doit donc être capable de :

  • relever les informations (température, humidité, éclairage…)
  • automatiser les réglages (arrosage, éclairage…)

 

Le hardware

La construction de la serre était le premier point. On a pris du bois (prix, facilité de découpe, coté naturel) et du plexi (sécurité des enfants, facilité de découpe). La taille choisie (environ 60x60x40cm) doit permettre son utilisation dans des endroits étroits, sans pour autant empêcher la croissance des plantes moyennes.

Initialement avec la V1, pour le début du hackathon, on est parti sur une carte Micro Framework GHI Panda 2, avec un écran tactile (FEZ Touch), une carte réseau (FEZ Connect) et deux capteurs (température et éclairage). Pour prouver le concept, la carte a rempli parfaitement son devoir :

  • super vitesse de développement, c’est l’avantage du Micro Framework par rapport à d’autres plateformes, debugage dans Visual Studio, fiabilité, etc. Pour ceux qui ont des doutes entre les différentes plateformes, on a gagné énormément du temps avec cette infrastructure. Et on n’est pas les seuls à avoir cet avis: http://blog.ianlee.info/2015/01/gadgeteer-vs-arduino-vs-phidgets.html
  • le prix était raisonnable. Plus cher que l’Arduino, mais pas tant que ça.

 

Une fois la phase initiale du hackathon finalisée, les limitations nous ont fait migrer vers une solution plus scalable, tout en restant sur du Micro Framework :

  • une carte GHI Gadgeteer Hydra
  • une carte réseau ENC28
  • un écran tactile TE35
  • un capteur numérique (précis !) pour la température et l’humidité de l’air SI70
  • un capteur pour l’humidité du sol
  • une camera L2
  • des « break-out » boards (on verra plus tard pourquoi)
  • et bien sûr un module d’alimentation Gadgeteer

Le tout se base sur le système Gadgeteer. C’est un système facile à connecter, avec une intégration assez élevée dans Visual Studio. On peut connecter les modules visuellement directement dans l’IDE :

d-meter, schéma gadgeteer

Maintenant pour le petit bémol :

  • Depuis la version 4.3 le Micro Framework et le Gadgeteer GHI, on rencontre quelques petits soucis… Espérons qu’ils vont corriger les choses au plus vite. C’était la mauvaise surprise par rapport à la carte V1 que je connais depuis un bon moment, et qui a toujours été un exemple de simplicité lors de son utilisation.
  • Trouver l’ensemble des composants Gadgeteer dans le même magasin n’était pas possible. La plateforme Gadgeteer existe depuis 2012, mais comme le prix est assez élevé, les ventes ne justifient pas des stocks importants. Du coup il faut faire le tour des classiques : Farnell, Mouser, Lextronic, CoolComponents, etc.
  • Le prix. Ouch…

Pour la partie « commande », il nous a fallu :

  • Une petite pompe d’aquarium. Elle fonctionne en 220V, donc la carte Micro Framework doit couper/brancher un relais, et on a pris un relais en 5V pour simplifier le circuit.
  • Des spots, ou plutôt des leds, un sur lumière chaude et un sur lumière froide. Un socle G10 / 5.5W. L’arrêt/allumage se fait également via un relais.

Rajoutez en plus :

  • Un câble d’alimentation avec un interrupteur
  • Un chargeur de Nokia 5V / 1,3A (ils sont minuscules et fiables)
  • Un petit boîtier pour isoler la partie 220V

Et voilà nous avons la partie matérielle de la serre.

 

La partie software

Pour la partie software, le projet se décline en plusieurs parties :

  • Du Micro Framework sur la carte Gadgeteer
  • Un Azure Website. Le choix mérite une petite justification.
    • Il faut d’abord savoir que la serre remonte à un intervalle plutôt espacé les informations. On n’est donc pas dans l’urgence, et implicitement, mettre un Event Hub capable d’encaisser plusieurs millions d’appels par seconde n’est pas utile. Pourquoi pas plus tard, quand la serre sera un hit ou juste pour essayer !
    • On compte aussi sur la partie WebJobs pour faire du « stop motion » de la croissance des plantes avec la caméra. Voici un petit aperçu
    • On a voulu avoir un site web depuis le départ. Tout le monde ne veut pas installer une application pour piloter la serre.
    • Rapidité de mise en œuvre. C’est suffisamment scalable et performant pour ne pas avoir besoin d’une usine à gaz.
    • Nous avons besoin d’un scheduler (style Quartz.NET) pour automatiser la serre. Mieux vaut avoir la main là-dessus.
  • Stockage sur SQL Azure. Le volume de lignes de données monte petit à petit, pour analyser les infos c’est mieux d’avoir du potentiel disponible.
  • Stockage Azure. Pour la partie images.
  • Une appli cross-plateform. C’est une appli qui tourne sous Windows, Windows Phone, Android et iOS, grâce à WinJS et Cordova.
  • Une appli native Windows Phone. Pour le fun et parce qu’on sait le faire J !

Le Machine Learning est la prochaine étape, il faut d’abord.qu’on étudie plus en détail les besoins d’analyse.

 

La communication

Premier choix : utiliser les WebSockets entre la serre et Azure (http://jdiwebsocketclient.codeplex.com/). Mais reality check :

  • Pas le temps lors du hackathon
  • Pas la mémoire suffisante sur la V1 de la carte
  • Pas besoin du temps réel
  • Trop risqué (voir les risques avec le NETMF 4.3)

Du coup, pragmatisme à fond, le choix a été de faire du polling Azure. La carte publie les valeurs des capteurs, et récupère en retour les consignes (pompage et éclairage).

Entre le serveur et les apps (et le site), c’est du JSON. Inutile d’expliquer comment utiliser ce genre de flux.

 

Le schéma global est donc :

d-meter, schéma global

L’IHM

Pour l’écran tactile de la serre, le composant qui permet de gagner énormément de temps est GLIDE. Grosso modo, il permet d’avoir des composants graphiques réutilisables, avec un éditeur WYSIWYG :

d-meter-ecran-tactile

L’éditeur a le format suivant :

d-meter, éditeur glide

Clairement rustique, mais pour ceux qui ont l’habitude de faire du micro framework et de galérer sur le positionnement des UI, c’est vraiment une bonne aide. Il suffit de copier le code dans les ressources de l’appli NETMF, et c’est parti.

 

Pour la partie site web, de l’ASP.NET MVC, des WebAPI, un Azure WebSite, des graphiques avec la librairie NV3… Voici un screenshot de l’accueil d’une serre  :

d-meter, le dashboard sur le site web

 

Pour l’application universelle, c’est donc du Cordova avec du WinJS. N’hésitez pas à regarder nos autres articles sur le blog concernant le sujet.

d-meter, sur windows phone

 

Le fonctionnement

A priori, le fonctionnement de la serre est assez facile :

  • On l’allume
  • On la branche au réseau Ethernet de la maison. Elle récupère son IP en dynamique avec du DHCP. En théorie, car avec la ENC28 et la Micro Framework 4.3, le DHCP ne marche pas… Mais les choses vont se corriger petit à petit, Microsoft vient de mettre des ressources sur le NETMF.
  • Et on plante nos graines (disons des « Radis »).

La serre est prévue pour fonctionner d’une manière autonome, à partir d’un profil. C’est-à-dire on choisit le profil « Radis » qui lui-même prévoit des programmes journaliers :

  • Lundi arrosage 500ml, éclairage 8h-22h
  • Mardi éclairage 10-19h
  • Etc.

Le logiciel permet lui bien sûr aussi de générer son propre profil, avec ses propres critères. Mais c’est dommage de ne pas profiter de l’expérience de la communauté !

Il faut juste penser à remplir le réservoir de la pompe pour l’arrosage !

 

L’état d’avancement actuel

Actuellement la serre dans sa V2, a permis de valider le concept de la caméra pour prendre des photos. Le stop motion est un bonus évident.

Malheureusement, le prix énorme du Gadgeteer et le prix dérisoire du Raspberry Pi2 vont nous faire changer de solution pour le Raspberry. La seule chose qui nous manque : le Windows 10 for IoT. Mais il ne devrait pas trop tarder, la carte est déjà achetée.

L’autre chantier est le Machine Learning, pour détecter la croissance de la plante à partir de l’image et ajuster les paramètres de croissance. Nous sommes en pleine récolte (!) d’information, avec une librairie d’images qui s’agrandit constamment et des valeurs qui remontent 24/24.

 

Conclusion

En tant qu’équipe, c’était et c’est toujours un bon projet. On a appris, on s’est éclatés et surtout on s’est confrontés à d’autres problématiques qu’on ne voit pas traditionnellement sur un projet classique.

Il y a eu des déceptions (la partie NETMF 4.3, avec des problèmes, le Gadgeteer…), il y a eu de belles surprises (le Stop Motion, la croissance ultrarapide des plantes), il y a eu du désespoir (faire marcher la caméra et le réseau en même temps sur la carte micro framework), de l’émotion (quand on nous a annoncé qu’on était le “Coup de cœur” Microsoft pour le Hackathon), et surtout de beaux souvenirs.

 

Je souhaite remercier :

  • Cyril pour la partie Azure
  • Mehdi et Guillaume pour la partie Universal Apps
  • David et Edwige pour Windows Phone
  • Julien, Marine et Pauline pour les inputs au niveau du design
  • Hubert, Pierre-Yves (l’idée de la serre) et toute la boite MCNEXT pour le support logistique, moral et financier
  • Ceux qui nous ont encouragé pendant les jours et nuits du hackathon, sur les Techdays ou tout simplement par mail

Croisons les doigts, l’annonce du résultat du hackathon Zone61 est prévue pour le 24 mars. En attendant les radis poussent, la serre fonctionne et il reste de belles choses à découvrir !

Si le sujet vous intéresse, n’hésitez pas à nous faire un signe.

 

Alex.

Débuguer une Universal Windows app et d’une application Cordova dans Visual Studio

Petit rappel : Vu l’architecture du projet (Applications natives en Universal App + application cordova) il faut bien penser à ajouter les fichiers copiés depuis le shared project en as link dans l’application cordova. C’est le seule moyen de débuguer/modifier le bon fichier.

 

Dans les applications universelles aucune configuration spéciale n’est nécessaire, Visual Studio gère parfaitement le debug. Il suffit de lancer l’application en mode debug et avoir accès dès le lancement au dom ainsi qu’aux points d’arrêts. Les choses se compliquent légèrement avec les applications cordova. En effet Visual studio met plusieurs secondes (voir minutes) avant d’attacher correctement et d’une façon stable le debugger. Et si on souhaite débuguer les premières lignes qui s’exécutent lors du lancement de l’application, cela devient rapidement compliqué, voir impossible.

Deux solutions existent :

  • La première (mais qui ne marche que si l’application s’initialise correctement = pas de crash au démarrage) c’est simplement via la console JavaScript de Visual Studio d’appeler la méthode window.location.reload() la page index.html est rechargée = les scripts se ré exécutent et on a donc accès aux debug des premières lignes de code.
  • La deuxième c’est de créer un mode debug avec une étape intermédiaire qui consistera à avoir un fichier index.html qui charge le stricte minimum de fichiers qui contient un lien (button) qui va nous permettre de naviguer vers une deuxième page qui va charger le reste des fichiers. Avec cette formule on s’assure du démarrage de l’application, on peut attendre que le debugger Visual Studio soit correctement attaché pour pourvoir charger les autres fichiers.

 

Le débogage/déploiement sous iOS requière un mac et l’installation des outils de build:

  • (Mac) Depuis le terminal lancer la commande désinstallation: sudo npm install -g vs-mda-remote –user=$USER ($user = l’utilisateur courant)
  • (Mac) Après l’installation lancer la commande: vs-mda-remote –secure false
  • Configurer Visual Sutdio: Tools => Options => Tools for Apache Cordova => remote Agent configuration:
    • Enable remote iOS processing = True
    • Host : adresse ip du mac de build.

Le déploiement peut se faire avec le simulateur ou un device.

Avec ces quelques notes vous avez maintenant les outils pour pourvoir débugger facilement votre nouvelle application.

WinJS dans une application cross plateforme Cordova

Depuis avril 2014, WinJS le Framework SPA de Microsoft est devenu libre (disponible sur github) et  surtout cross-platform.
C’est avec ces nouvelles possibilités qu’on peut maintenant l’utiliser sur d’autres plateformes que Windows 8/Phone 8.1.

Dans cette série de posts, je vais donc aborder le développement multiplateforme d’application avec WinJS.

Comment lier une application Windows 8.1 à une application Windows Phone 8.1 (Universal app)

Les applications Universelles ou Universal Apps offrent la possibilité aux développeurs de créer une application qui cible différentes plateformes, du Windows Phone 8.1 au Windows 8.1 en passant par Windows RT.

En réalité lors de la création d’un projet Universal App, Visual Studio va créer deux projets (l’app Windows 8.1 + l’app Windows Phone 8.1) et un espace de partage.

On peut intégrer dans cet espace de partage tous les fichiers susceptibles d’être communs : les vues, le code business… Dans beaucoup d’applications, l’ergonomie va être spécifique pour chaque plateforme et le partage du code d’IHM risque donc d’être très compliqué, voir impossible.

Il est maintenant possible avec Windows Phone 8.1 de développer des applications en HTML5/JS, mais il faut obligatoirement passer par le modèle Universal App.

Et voici les étapes pour lier une application W8.1 à une app WP8.1 :

Étape 1 : Le store

  1. Se connecter au backoffice du store Windows Phone : http://dev.windowsphone.com avec le même compte que celui utilisé pour le backoffice du store Windows http://dev.windows.com.
  2. Aller sur le Dashboard.
  3. Cliquer sur le bouton Submit App.
  4. Cliquer sur le chiffre 1 pour renseigner les informations de l’application.
  5. Il suffit maintenant de choisir le nom de l’application dans la liste (NB: il ne faut pas le renseigner manuellement) et de cliquer sur le bouton « Associate app ».store1store2
  6. Choisir une catégorie et enregistrer les modifications.

 

 

Étape 2 : Visual Studio

Pour transformer une application Windows 8 .1 en Universal App, il suffit de faire un clic droit sur le projet et choisir « Add Windows Phone 8.1 »

vs1

Deux nouveaux projets sont alors créés : l’application Windows Phone et le projet Shared.

vs2

Clic droit sur le nouveau projet Windows Phone, aller dans « Store » et cliquer sur « Associate App with the Store ».

vs3

 

Une fenêtre s’affiche, il faut se connecter avec le compte du store pour obtenir la liste des applications créées dans le dashboard.

vs4

On sélectionne la bonne application et on valide.

Il ne reste plus qu’à faire les développements et soumettre l’application pour la certification 🙂 !

 

[Build 14] – App packaging and deployment for windows

Mail de Mehdi
Samedi 5 avril 2014 10:17

App packaging and deployment for windows


Speaker
: Barclay Hill, Jason Salameh


Premières nouveautés
:
Seulement les ressources nécessaires (fichier de localisation, images seront téléchargées (on nous annonce un gain de 10% ou plus au niveau du stockage)

Pour les images, le système est capable de choisir quel scale d’image il lui faut.

Le speaker nous montre un projet universal app, plus précisément les manifets des projets puis, il génère une app phone, il nous montre les bundle (comme quoi ce n’est pas obligatoire mais que ça serre à optimiser les packages)

Les applications Silverlight sont générées toujours avec un xap mais sont déployés comme un appx (en plus du manifest normal on a un manifest du style Windows 8)

La création d’une application WP 8.0 est toujours possible.

Les mises à jour de 8 à 8.1 et de 8.1 Silverlight vers universal app est dans un seul sens, pas de retour en arrière possible.

Avec les applications Silverlight on joue avec deux manifest, dans cet exemple, le speaker change le mode de notification et le passe vers du WNS (dans le manifest silverlight) on voit alors que des options disparaissent, ce qui est normal puisque c’est le nouveau manifest (type Windows) qui gère ça.

Pour les nouvelles features, elles sont toutes gérées dans le nouveau manifest.

Dans le store, on peut maintenant réserver un nom d’application pour toute la « famille » phone/windows en même temps.

On parle maintenant des améliorations de stockage :

On peut partager des fichiers entre applications !
Résultat, on consomme de 10 à 25 % de mois en disque. Le speaker nous conseille de ne pas minifier les fichiers (exemple de jQuery) pour que toutes les applications qui l’utilisent, prennent un seul fichier commun.

Les utilisateurs peuvent maintenant installer des applications sur carte SD, les applications peuvent être encryptées et les développeurs peuvent interdire l’installation des apps sur les cartes SD avec une option dans le manifest.

C’est l’utilisateur qui choisit ou il installe les applications par défaut depuis l’application storage sence.

Il nous montre un exemple d’appli lourde (Halo) qui tourne très bien sur une carte SD (milieu de gamme) avec un téléphone bas de gamme.

Mehdi

[Build 14] – Building a Converged Phone and PC App using HTML and JavaScript

Mail de Mehdi
Vendredi 4 avril 2014 10:25

Building a Converged Phone and PC App using HTML and JavaScript
// Speakers : Ryan J. Sakva et Josh Williams
Le sujet de la session est la création d’une universal app (Windows 8.1 et Windows Phone 8.1) avec WinJS

Au début de la session on nous montre qu’il faut deux defaut.html pour référencer les deux versions de WinJS (phone 2.1 et Windows 2.0)

Le dom explorer fonctionne avec le simulateur windows phone exactement comme avec windows 8.

// Première partie :
Le cycle de vie d’une application avec les différents événements (activeted, checkpoint, settings et error)
Dans l’event checkpoint c’est là où généralement c’est le moment où l’application passe en suspend, on doit donc enregistrer les données de l’appli ici pour pouvoir les restaurer à la réactivation de l’appli (dans l’event activeted)
Settings
Error

// Démo :
– Création d’une listView avec un template pour les items on nous montre comment brancher l’event clique sur un élément de la liste et comment passer un objet dans la navigation (exactement le même code que pour Windows 8.1)
– On nous explique comment styler un item dans une listeView (aucun changement par rapport à WinJS 2.0)

– Maintenant on passe à l’appBar toujours le même code

– On nous rappelle qu’il faut bien scopé les css, parce qu’au fur et à mesure de la navigation les pages de styles se chargent dans le dom sans se décharger (single page).

– On créer une nouvelle page avec un HubControl, des HubSections et un repeater (pour l’instant la page est dans le projet Shared (je pense que cela ne marchera pas pour l’appli Windows Phone et on va probablement déplacer cette page dans les projets spécifiques et créer une page spéciale avec un Pivot)

– On nous parle très rapidement des promises avec la fonction join mais rien de nouveau cela fonctionne exactement de la même manière que dans WinJS 2.0
Le speaker lance l’appli Windows 8.1 => tout fonctionne correctement.

// Ensuite le speaker lance l’appli sur le simulateur Windows phone et j’avais presque raison : l’application marche correctement, mais le hubcontrol n’est pas adapté pour Windows phone (le speaker dit qu’ils n’ont pas eu le temps de l’adapter) et donc comme prévu il crée une copie de cette page dans chaque projet (Windows et WP) et le supprime du projet shared. Il utilise pour la page WP le control pivot. Il essaye de le styler en JavaScript directement mais la démo ne marche pas (probablement une erreur de syntaxe dans la media query).

Fin de la session.
Mehdi