La “boutonite” IoT

Non ! Avoir des boutons IoT n’est pas une maladie de peau, mais un symptôme de geekerie en Internet des objets. Les “boutons” ont pour vocation d’envoyer un message quand on appuie dessus ! Il existe d’innombrables offres et technologies. Chez OCTO nous avons donc décidé de faire notre bouton IoT ! Retour d’expérience.

Principe du bouton

C’est l'archétype de l’objet connecté :

• C’est un interrupteur temporaire, qui envoie un message quand l'interrupteur est enfoncé. C’est un système événementiel : seule la transition bouton relâché/bouton enfoncé fait émettre un message ;
• Il est en général autonome électriquement, nécessite peu d’énergie (alimentation par pile, cellule solaire...) et dispose d’une grande autonomie (au moins plusieurs mois) ;
• Il communique sur Internet, bien  souvent via une ou des passerelles, car il n’a pas toujours un stack tcp/ip intégré, mais plutôt des protocoles économes en énergie et puissance de calcul.

Les cas d’usage et les offres

L’idée est de mettre à disposition une interface élémentaire qui évite de sortir son téléphone portable et d'activer une “app” pour juste envoyer un message très simple. Les cas d’usage sont nombreux et la plupart basés sur l'idée que l’appui sur le bouton correspond à une demande d’aide ou de prestation.  Par exemple le dash button d’Amazon pour acheter des produits, le bouton Darty, le Domino de la Poste pour faire faire une relève de colis, le “The switch” de Netflix, le bt.tn...

Le bouton OCTO

Le cas d’usage

Nous avons décidé de concevoir un système de bouton de satisfaction client. Nous avons déroulé le cycle de conception d’un produit (matériel et système d’information) depuis l’idée du cas d’usage jusqu’à un MVP (Minimum Viable Product) industrialisable.

Notre bouton permet de soutenir la relation client par la mémorisation d'événements de satisfaction ou de frustration de la part de nos clients. Le cas d’usage consiste à ce que le client appuie sur un des trois boutons :

• Vert : Un événement avec OCTO m’a satisfait et est digne d’être souligné
• Rouge :  Un événement avec OCTO m’a frustré et est digne d’être souligné
• Bleu : J’ai un sujet à discuter avec OCTO

Une fois enregistrés, ces événements sont utilisés pour alimenter les échanges entre le client et OCTO.

Les contraintes

Le bouton doit respecter les contraintes d’opération suivantes :

• Autonomie en énergie (6 mois sans changer les piles)
• Respect des normes CEM et ETSI
• Indépendance avec l‘infrastructure du client qui utilise le bouton
• Fiabilité
• Coût réduit

Une architecture IoT LoRaWan-Amazon IoT

Choix fondamentaux

Nous avons donc choisi de réaliser un bouton qui communique sur LoRaWan afin de respecter les contraintes d’autonomie et d’indépendance de l’infrastructure du client qui utilise le bouton. Choix courageux, car au moment de le faire, le déploiement de LoRaWan en France était seulement évoqué par les opérateurs (Orange, Bouygues) et était marginal par rapport à SigFox. Mais l’avantage de LoRa est de pouvoir déployer son réseau privé et de régler des compromis de transmission entre fiabilité - débit - charge utile et de bénéficier de transmissions descendantes de bonne qualité. Nous pensons que de nombreux cas d’usage LoRaWan vont émerger dans les bâtiments, et maîtriser son réseau indoor est un point important pour les projets IoT.

Architecture et technologies retenues

L’architecture, étudiée en collaboration avec Zerfos.Systems qui implémente le bouton, s’appuie sur les matériels de Multitech. Ce choix a été réalisé pour le bon compromis - simplicité de mise en œuvre - performance - coûts. D’autres matériels leader tels que Kerlink nous ont paru trop chers pour l’usage que nous envisagions. A noter que de nombreuses offres matérielles de passerelles existent.

L’étude du cycle de vie du bouton de concert avec le système d’information a abouti à l’architecture suivante :

• Le bouton communique en LoRaWan avec une passerelle Multitech Conduit
• La passerelle communique sur Internet en 4G
• L'application de collecte des événements est réalisée sur Amazon IoT et stocke les événements dans une base DynamoDB
• Un web service permet de récupérer les données et de les analyser

Chaque bouton est identifié lors de la fabrication, puis couplé au compte client lors de la phase de déploiement.

La maquette initiale du "Bouton"

Une interface de démonstration sur AWS a été réalisée pour montrer le fonctionnement à nos clients.

Résultat d’expérience

La bonne collaboration hard-soft a clairement accéléré le projet car tous les éléments (bouton, LoRaWan, SI et le cycle de vie du bouton) ont été intégrés dans la conception de l’architecture du système. Les contraintes matérielles et de communications font partie de la “génétique” du système.

Les technologies LoRa sont assez faciles à mettre en oeuvre pour une démonstration mais plus compliquées pour une utilisation industrielle. Des instruments d’analyse de transmission radio (analyseur de spectre, mesure des niveaux) ont été nécessaires pour réaliser des travaux de debug et de fiabilisation.

Le déploiement d’agent Amazon en multi-objet sur une passerelle Multitech se révèle être une opération assez compliquée pour deux raisons : les particularités techniques de la distribution Linux Multitech et le SDK Amazon non multi-objets. La constitution de la chaîne de développement doit être soignée et bien maîtrisée.

Sur le terrain, on observe une communication en intérieur de bonne qualité, mais une portée limitée à quelques centaines de mètres en extérieur (zone urbaine dense).

Conclusion

Un passage de la théorie de l’IoT à la pratique qui s’est révélé très concluant sur notre bouton. En associant innovation technologique et gestion de la relation client, nous travaillons à toujours mieux satisfaire ceux qui nous font confiance. Nous avons validé LoRa dans un cas d'usage simple et touché du doigt certaines de ses limites. Nos client sont ainsi mieux écoutés et pionniers dans l'usage des technologies d'IoT.