DIY: “OK Google, ouvre le portail !”

1. Le projet

Depuis que j’ai fait installer un portier connecté à l’entrée de ma maison, j’ai envie de pouvoir le contrôler avec l’enceinte intelligente qui est dans mon entrée. En effet, pour le moment je n’ai pas encore complètement finalisé mon installation et je dois soit utiliser le bip de mes clés, ou l’application de mon téléphone portable, pour ouvrir/fermer le portail. Ce n’est pas toujours hyper pratique alors qu’un simple “OK Google, ouvre le portail !” serait tellement plus sympa.

Bref, le portier connecté ayant une API, voici une excellente occasion de faire un petit “DIY” pour intégrer tout ce petit monde. Et par la même occasion c’est également l’opportunité de faire une petite série d’articles pour partager avec vous mon expérience.

Au programme :

• Un peu de méthode et d’architecture.
  On ne se refait pas.
• Découvrir quelques technos, solutions et frameworks.
  Apprendre des trucs de geeks et se faire plaisir.
• Mettre en oeuvre tout ça avec des bonnes pratiques, en se (re)mettant à la page.
  Nous sommes en 2019, pas en 2009.
• Documenter tout ça sous forme de journal de bord.
  Pour démystifier un peu la complexité et pourquoi pas donner envie à d’autres de se lancer.
• Et bien sûr, réussir à faire s’ouvrir ce portail !

2. L’environnement

Je compte réutiliser au maximum ce dont je dispose déjà chez moi pour éviter d’en rajouter.
Voici donc les composants qui vont entrer en jeu :

Quelques explications

La programmation d’un Google Mini, ou d’ailleurs de toute enceinte intelligente, se fait grâce à un agent. Dans le cas des assistants Google, les traitements associés à une action ne s’exécutent pas localement, mais dans le Cloud. Il faudra donc que je configure, ou programme, via Dialogflow pour actionner l’ouverture de mon portail lorsque je prononcerai la bonne phrase. Je ne connais pas Dialogflow, donc je ne sais pas quels type de traitements je pourrais exécuter. Du coup je prévois d’utiliser Google App Engine en cas de trop fortes limitations.

Mon portail est actionnable via une API locale, mais je ne compte pas exposer celle-ci sur Internet. Cependant, il faut bien qu’elle soit accessible d’une manière ou d’une autre en dehors de mon réseau local pour que les services Cloud puissent déclencher l’ouverture. Je vais avoir besoin d’un petit web service, accessible d’Internet, qui va se charger de contrôler la légitimité des requêtes entrantes et d’appeler ensuite l’API du portail. Cela me permet d’avoir une rupture protocolaire, la main sur ce que je rend accessible par Internet et également comment.

J’ai un Raspberry Pi chez moi qui devrait être idéal pour héberger mes traitements locaux : le web service et Let’s Encrypt pour générer un certificat HTTPS valide et le renouveler automatiquement. A voir si je dockerise tout ça, ou pas. C’est une bonne occasion de mesurer le surcoût en terme de performance lié à l’utilisation de Docker sur une aussi petite configuration.

3. Le plan

Maintenant que la cible “grosses mailles” est à peu prêt claire, on peut subdiviser le travail en 3 grands points clés à traiter le plus indépendamment possible :

1. Construire un web service en surcouche de l’API native de mon portail et l’exposer en HTTP sur mon réseau local.
   En clair : permettre d’ouvrir le portail via le navigateur web de mon PC.
2. Mettre en place du HTTPS, automatiser le renouvellement du certificat généré via Let’s Encrypt, et dockeriser le tout (si l’impact sur les performances est faible). Exécuter le container et ouvrir les flux permettant d’y accéder en dehors de mon réseau local.
   En clair : permettre d’ouvrir le portail via n’importe quel navigateur web en dehors de mon réseau local via une connexion sécurisée.
3. Configurer Dialogflow pour qu’il réagisse à la phrase “OK Google, ouvre le portail !” et exécute un appel à un web service. Celui d’ouverture de mon portail idéalement.
   Ça me semble à peu prêt clair.

Si j’avais à confier l’implémentation à différentes personnes, je pourrais subdiviser le travail de cette manière. Je pourrais également répartir les tâches selon les compétences de chacun, il y en a pour tous les goûts : développement, sys. admin et assistant personnel. Mais vu qu’ici je serais seul à la réalisation, disons plutôt qu’il s’agit de la liste d’articles que je prévois d’écrire.

Pour ceux qui se posent la question, je prévois de travailler sous Ubuntu et les développements se feront en Python 3. Pour le reste, je verrais au cas par cas, en fonction des besoins et de mes recherches.

Let’s go.