Étiquette : IOT

Publié le

Home Assistant vers PubSub vers BigQuery vers Datastudio

Tout un programme !

Connaissez-vous Home Assistant ? C’est un chouette logiciel de domotique, compatible avec une multitude d’objets, de protocoles…. Vous pourrez facilement faire des tableaux de bord, et avoir des interactions assez poussées avec vos objets à condition d’accepter d’écrire un peu de YAML. Sa communauté est vraiment dynamique, les plugins sont nombreux et on trouve à peu prêt ce que l’on veut.

Par défaut, Home Assistant va utiliser un stockage SQLite. C’est pratique, ça ne réclame pas de dépendance particulière, et ça fait le job. Mais par défaut, et je ne comprends franchement pas l’idée, nous n’avons qu’un historique de 24h sur nos différents capteurs. Dans mon cas j’ai un dongle ZWave, avec un capteur de température Fibaro:

L’oeil de Sauron… Ceux qui savent, savent.

Et ça me frustre. Avant j’utilisais Domotizc et je n’avais pas ce soucis. On avait un véritable historique, et ça me permettait d’analyser un peu l’effort énergétique que je devais mettre dans ma maison pour maintenir une certaine température.

Fort heureusement, beaucoup de plugins existent pour arranger ça.

rien que ça…

Pour votre utilisation personnelle, toutes ces solutions peuvent convenir en fonction de vos connaissances ou vos affinités.

Quand j’ai vu la présence de Google Pub/Sub, j’ai réalisé que je pourrais très vite réaliser des tableaux de bord grâce à la suite Google à un cout proche de 0€. (OK, tout service a un prix. Mais je ne souhaitais pas consacrer de réel budget à ce service).

Quelle est l’idée ?

Pousser les données Home Assistant dans Pub/Sub

Pub/Sub, c’est un message broker. L’idée est donc de recueillir tous les événements Home Assistant grâce à ce plugin : https://www.home-assistant.io/integrations/google_pubsub/
Ce plugin est préinstallé dans Home Assistant. Vous n’aurez donc qu’à modifier le fichier configuration.yaml selon la documentation du plugin. Chez moi, cela ressemble à ça :

google_pubsub:
project_id: <GCP_PROJECT_ID>
topic_name: <GCP_PUBSUB_TOPIC>
credentials_json: <CREDENTIALS>.json
filter:
include_entities:
- sensor.salon_temperature
- sensor.salon_humidity
- sensor.fgms001_motion_sensor_air_temperature

Cela me permet de pousser dans pubsub uniquement les évènements relatifs à mon fibaro, et à mon thermostat Nest.

OK, des messages arrivent dans Pub/Sub, qu’est ce que j’en fais maintenant ?

Déjà, vérifions si des messages arrivent. Les messages sont publiés dans un « topic » ou « sujet » en français.

Bonne nouvelle en ce qui me concerne, on voit quelques messages passer. Home Assistant parle, et assez peu (ce qui est aussi une bonne nouvelle, les filtres configurés ont l’air de fonctionner).

Plusieurs options s’offrent maintenant à vous pour faire quelque chose de ces messages. Pub/Sub vous propose deux options pré-construites : « Exporter vers BigQuery » ou « Exporter vers Cloud Storage ». Ces tâches, qui vont en effet fonctionner, sont basées sur Dataflow. C’est une solution basée sur Apache Beam qui permet d’exécuter du code sur de volumineux flux de données avec différents patterns (agrégation, filtre, transformation…).
Je ne vous conseille pas son utilisation pour ce cas précis, juste parce que vous allez le payer cher (€) pour pas grand chose.

Une autre option m’intéresse un peu plus. En haut de l’écran, on peut lire une option « Déclencher une cloud function ». Qu’est ce donc ? C’est la possibilité d’exécuter un bout de code, simple et unitaire, pour chaque message qui arrive. Et c’est exactement ce que nous souhaitons vu l’objectif : lire les messages et les stocker quelque part. La volumétrie impliquera un coût proche de 0.

Pré-requis : Création du dataset BigQuery

Avant de s’occuper de la Cloud Function, allons préparer la base de données. Pour cela, rien de plus simple, on se connecte à la console d’administration de BigQuery pour y créer un dataset. Vous pourrez choisir l’emplacement des données. Dans l’exemple de code que je vais vous donner, j’ai choisi de ne garder que 3 simples informations :
– Le device id
– La date de l’évènement
– La valeur associée
C’est la définition d’une Time Série…

Un dataset, une table et son schéma.

Création de la Cloud Function

Maintenant que BigQuery est prêt à accueillir nos données, allons les déverser.
Sur l’écran de votre sujet Pub/Sub, cliquez sur « Déclencher une cloud function ». Cela vous amènera à un écran pré-rempli où vous pourrez mettre un nom à votre cloud function, une région d’exécution (par habitude je prends local, Europe-West1 😉 ). Et si vous voulez utiliser un bout de code pré-écrit, il y aura 3 variables d’environnement d’exécution à fournir dans les paramètres avancés :

Paramètres avancés pour la Cloud function

Etape suivante, le code.
Je vous propose ce dépot : https://github.com/lborie/home-assistant-to-big-query

Soit vous essayez de lier ce dépot que vous aurez forké à votre compte GCP, soit vous copiez coller le contenu dans l’éditeur intégré. Le code est en golang 1.13, le point d’entrée étant une fonction Main

function.go, go.mod et go.sum

Et plus qu’à déployer.

Si tout va bien, une fois déployée, vous devriez voir votre fonction se déclencher à chaque nouveau message dans Pub/Sub ! Sur l’écran d’administration de la cloud function, vous trouverez un onglet pour accéder aux logs générés.

La fonction est lancée, le message qui provient de Home Assistant est loggé et doit être sauvé dans BigQuery

Et normalement, votre table BigQuery devrait aussi s’alimenter…

De la donnée ! Victoire !

Comment en faire un graphique ? Direction Datastudio

Datastudio permet de faire des tableaux de bord en se connectant à plein de sources de données différentes, dont BigQuery. Lors de la création d’un nouveau rapport, vous allez pouvoir ajouter des données au rapport.

BigQuery parmi les centaines de connecteurs disponibles…

Vous allez pouvoir pointer vers la table Data du bon dataset. Une fois que la source de données est ajoutée, vous allez pouvoir éditer le rapport. En haut à droite, différents types de graphiques seront disponibles, dont un qui me parait pertinent : « Graphique de série temporelle lissée ». Comme on parle de température, un lissage me parait approprié.

Une date, un type et une valeur : on est bien dans la timeserie

Et magie…

La température dans mon bureau… On voit quand les moniteurs sont allumés, pas besoin de chauffage.

Conclusion

Tout ça pour ça me direz-vous ?
BigQuery est un outil extrèmement puissant. Pour une volumétrie Domotique, vous n’aurez jamais à vous soucier de quoi que ce soit, à condition de ne pas réclamer une réactivité trop grande. La puissance est illimitée, les couts de stockage ridicules. Intéressez-vous à cet outil.
Datastudio possède une grande variété de données, et vous serez capable de croiser les informations, peut-être avec une autre source de données que vous avez quelque part ?
On aura aussi vu du PubSub, de la Cloud Function, bref une chaine de traitement complète autour de l’IOT ! Et le tout sera scalable… Amusez-vous en jouant avec les filtres de configuration Home Assistant par exemple !

L.B.

Publié le

L’aventure Karnott, 2 ans déjà !

L’an dernier, j’avais déjà écrit un premier article racontant mes 12 premiers mois chez Karnott. Cette année, je voulais réitérer l’expérience, histoire de faire le point sur ce qui a été accompli, nos réussites et nos échecs. J’ai beaucoup cogité, ne sachant par où commencer, et je suis tombé sur ce tweet :

https://twitter.com/omartineau/status/1164192417937076225

L’article pointé apparait comme une évidence aujourd’hui, mais ça ne l’était pas il y a un an.

Remise dans le contexte

Juin 2018. Equipe constituée de 3 développeurs, dont moi. Nous avions commencé à prendre le virage de « la data », ce qui voulait dire être capable de la stocker, la traiter, la partager. Autant dire que les 3 sujets sont très propices à l’over-engineering. En août et septembre 2018, nous nous sommes renforcés avec 2 personnes de plus, expérimentées. Plutôt Backend et Devops, avec l’objectif de sécuriser notre plateforme.

Techniquement, où en étions-nous ?
Une API redéveloppée en Golang, de l’intégration continue qui produit des JARs, du Ruby, du Go, du JS, et des scripts bash de déploiement sur des VMs plus que fragiles. Pour notre Devops, le premier chantier tombait sous le sens : rationaliser notre déploiement continu, et plus globalement, notre hébergement.

Choix technique, scalabilité et résilience…

A J+500 dans ma vie de CTO chez Karnott, Il était temps de faire l’un de ces fameux choix critique qui impacterait notre façon de travailler, mais aussi notre SRE, le cout de notre infra (et donc le modèle économique de l’entreprise), et qui restera surement plusieurs années : passer sous Kubernetes et Google Cloud Platform.

J’entends d’ici les critiques classiques : « c’est pour la hype, vous n’en n’aviez pas vraiment besoin, vous avez introduit plus de problèmes que vous en avez résolu… ». Reprenons le cahier des charges que nous nous étions fixés :

  • Avoir un DSL décrivant nos services et notre infrastructure (même si bon sang, le YAML…)
  • Uniformiser la façon dont nous déployons tous nos services
  • Gérer du 0 downtime pendant nos montées de version
  • Avoir une façon simple de monitorer et gérer la montée en charge
  • Ne pas avoir à se soucier de la captation de logs, et être capables d’en générer des métriques simples (ai-je des erreurs sur l’un de mes services ?)
  • Pouvoir profiter de services managés si besoin, et ne rien s’interdire techniquement (capacité à faire un POC rapidement dans une nouvelle techno)

Et franchement, la stack choisie a répondu à toutes nos attentes. La mise en place a été très rapide (moins d’un mois à mettre en place, avec la dockerisation de nos services), même si, avec le recul, trois éléments ont facilité la migration :

  1. La base de données n’est pas « Kubernetisée », mais gérée à côtée.
  2. Nous n’avons aucune problématique réseau compliquée, tous nos messages internes transitant à travers Google Cloud PubSub
  3. La personne de l’équipe qui a mis tout ça en place, David, avait l’expérience pour le faire

La conception produit et les interrogations

D’un point de vue technique, le reste de l’année a été consacré en grande partie à l’amélioration de notre scalabilité dans la gestion de la flotte de Karnott. Cela revient à améliorer notre capacité à stocker, transformer, visualiser la donnée, mais aussi améliorer notre gestion du support pour fournir les bons outils à l’entreprise pour diagnostiquer au plus vite le moindre soucis. Ces problématiques seront toujours un fil rouge chez Karnott, et mériteraient pas mal d’articles pour parler de la vente d’objet physique à l’échelle d’une startup… (Coucou Amaury, Guillaume et Georges !)

ça commence à avoir de la gueule non ?

Et la création produit dans tout ça ?

Revenons-en au développement de l’application Karnott, que nos clients utilisent tous les jours.
Lors de la première année, nous avons développé une application.
Lors de cette seconde année, nous avons essayé de développer la bonne application.
Mais encore ? C’est maintenant que je vous renvoie à l’article cité premier paragraphe. Nous n’insisterons jamais assez sur le fait que pour construire le bon produit, le développeur en startup doit être pragmatique, ne pas avoir peur de s’approprier le métier, et faire parfois des concessions sur la technique pour satisfaire un besoin urgent, que l’on ne comprend pas toujours, ou que nous aurions souhaité différer pour X raisons. Oui nous introduisons tous les jours de la dette et je suis persuadé qu’il est important de le faire. Finalement, nous ne faisons que caler notre modèle sur celui de la startup. Ce n’est pas de la dette, mais de l’investissement, qui nous permet d’avancer.

Mais est-ce vraiment le BON produit ?

C’est la grande question. Comment éviter la surcharge featurale ? L’empilage de fonctionnalités en espérant que cela convienne ? Cette seconde année, nous avons pris le parti de prendre un maximum d’initiatives. Concrètement, chaque développeur a travaillé main dans la main avec nos différentes équipes : Customer Success et support ( <3 ), l’équipe commerciale, l’équipe marketing, le Design, et bien entendu nos fondateurs pour garder la vision d’un produit utile et simple, profondément ancrée dans l’ADN de l’entreprise. Cela passe aussi par une réflexion UX de tous les instants. Un résultat simple implique toujours une conception compliquée.

Quelques choix forts de l’année : nous avions absolument besoin d’une présence sur les stores Android et iOs, ce qui a amené une nouvelle stack technique chez nous ( React Native). Autre exemple qui peut paraitre anecdotique, un client, ça n’aime pas le CSV. Quand on lui fait télécharger un export, c’est du format excel obligatoirement ! Nous avons aussi fait de la dataviz autour de la Geodata et expérimenté des choses rigolotes…

D3js, leaflet, de la donnée sympa, et on peut faire de belles choses !

Bilan

Le bilan de cette seconde année, c’est que nous sommes fiers du travail accompli. Maintenant pour passer un cap, et continuer à construire le bon produit avec toute la connaissance métier et client accumulée, nous savons que nous avons besoin de nous structurer différemment. Cela passe par le recrutement obligatoire d’un Product Owner / Product Manager (poste ouvert!) qui sera le pivot de l’entreprise, le carrefour entre toutes les approches clientes différentes. Mettre sur papier les persona, les obstacles et les opportunités, prioriser, analyser plus profondément les besoins et la pertinence de chacun, c’est notre limite d’aujourd’hui. Les besoins en UX sont aussi très présents. Comme je l’ai évoqué, nous attachons beaucoup d’importance à la simplicité du produit. Cela passera aussi par le recrutement d’un UX à temps plein.

J’en profite pour mettre un petit lien vers notre page WelcomeToTheJungle, cette page donne un bon aperçu de nos différents corps de métier, et de la bonne humeur générale 🙂

Un dernier mot pour les développeurs qui auront travaillé chez Karnott cette année. François, Georges, David, Guillaume, Paul et Amaury. Développeur en startup, ce n’est pas jouer au ping pong et rigoler toute la journée… Cette année, il y avait de la solidarité, de l’envie, de la compétence et c’était vraiment chouette. Merci à eux.

A l’an prochain !
LB.

Publié le

Un an en tant que CTO, retour d’expérience

Il y a tout pile un an, le 1er juin 2017, j’ai rejoint Karnott en tant que CTO.  Durant cette année passée, on m’a souvent posé la question suivante : « Mais finalement, un CTO dans une startup, ça fait quoi ? » J’avoue que je n’en savais pas grand chose, ayant travaillé pendant 10 ans principalement pour des grands comptes, et d’ailleurs je ne sais pas si il y a une unique réponse à cette question. Je vais juste essayer de faire un petit retour d’expérience, et raconter ce qu’il s’est passé durant cette année.

Mais revenons encore un an en arrière. En 2016, Antoine Dequidt et Alexandre Cuvelier, les deux fondateurs de Karnott, ont confié la concrétisation de leur idée à des développeurs de leur connaissance. Le truc quand on a une idée, c’est qu’on est très loin d’imaginer du premier coup le produit parfait. On ajoute à ça une pincée de développement au forfait, des spécifications fonctionnelles imprécises, et des technologies pas toujours adaptées, et on arrive à un projet qui fonctionnait tout de même, sans répondre totalement au besoin initial.

Je suis donc arrivé dans ce contexte. Mon premier job a été de m’approprier le projet, le fonctionnel, le code, et d’y mettre ma patte. Fiabiliser le bousin, mettre des tests, de l’intégration continue… Ce qui a toujours été super chez Karnott, c’est que dès le premier jour, j’ai eu la contrainte de devoir être au petit soin avec la prod’. En effet, nous avions déjà des utilisateurs, et même si certains jours cela démangeait de tout défaire pour repartir de zéro, il fallait se réfreiner, planifier, réfléchir, et prévoir des plans de migration. Avec le recul, je me dis que cette contrainte de la prod’ m’a aidé à concevoir un système plus solide et pragmatique.

Sur certaines parties, j’ai aussi compris que j’avais besoin d’aide. Typiquement je suis un très mauvais intégrateur web… Et j’en ai tiré la première leçon primordiale :

En tant que CTO, je n’ai pas la science infuse

Alors on s’est entouré. Tout d’abord avec de la prestation, des partenaires en qui nous avions confiance (Coucou Sfeir et Tymate <3 ), avec en parallèle la volonté d’embaucher une équipe de développeurs à embarquer dans l’aventure… Fin aout puis début octobre 2017 nous ont donc rejoint François, dev Front React, et Georges, Fullstack Ruby. 3 développeurs, avec 3 profils complètement différents. Il a fallu apprendre à se connaitre, et cela fit apparaitre la composante la plus importante de mon boulot de ces 12 derniers mois :

En tant que CTO, je m’assure de la cohérence de l’équipe et du projet

Je considère la cohérence humaine et technique comme intimement liée. La technique doit répondre à un besoin fonctionnelle et des contraintes (IOT, scalabilité…), mais dès le premier jour, nous étions tous d’accord sur le fait que tout le monde travaillerait sur l’intégralité de la stack. Il a fallu se mettre d’accord sur des technos que nous avions tous envie d’apprendre, avec lesquelles nous serions productifs. Le choix le plus significatif a été de refondre l’api en Golang. On pense ce que l’on veut du langage (à titre personnel j’aime beaucoup cet article de Sylvain Wallez qui résume bien ma pensée), mais il a eu le mérite de nous permettre de refondre une API complète en quelques mois, de résoudre nos soucis de performances et surtout d’être « facilement » maitrisée par toute l’équipe.

La mise en place d’une équipe, c’est aussi mettre sa casquette d’agiliste, et proposer tous les rituels qui nous permettent de partager et collaborer tous les jours. Daily Meetings, Rétro, Pull Requests systématiques, Sessions de Code Reviews… Si l’on veut travailler sur l’intégralité de la stack et ne pas risquer l’isolement de la compétence, ces étapes sont juste indispensables.

En parlant d’isolement, un autre risque est que l’équipe de devs s’isole du reste de l’entreprise. Chez Karnott, toute l’équipe commerciale est issue du monde agricole. La connaissance métier, c’est eux qui l’ont, et nous ne devons jamais l’oublier. Il est tellement facile de développer des fonctionnalités techniquement sympa, mais complètement à côté de la plaque… Alors voilà :

En tant que CTO, je m’implique dans la réflexion autour du produit

Si l’équipe commerciale vient du monde agricole, je ne leur ferai pas offense en disant qu’ils découvrent tous l’univers du développement d’une application Web. Alors toute cette année il a fallu apprendre à communiquer, qu’ils m’expliquent leur métier, et que nous leur expliquions le notre, et nos contraintes de développeurs. « Tout est possible, tout n’est qu’une question de délai et de priorités » a sans doute été la phrase que j’ai le plus répétée. Mais dev ou commerciaux, nous avons tous fait de notre mieux pour nous impliquer dans la construction du produit Karnott, et être au plus prêt de ce que nos utilisateurs réclamaient. L’arrivée prochaine d’un Product Owner devrait nous faire franchir une étape de plus en ce sens…

Et puis avec le temps et le succès commercial, les priorités et les contraintes changent. Très naïvement, je n’avais pas du tout anticipé cette partie là, mais Karnott est à une période charnière dans sa structuration et nous devons construire un SI d’entreprise. Automatiser la logistique, le monitoring, les prises de parole, la facturation, bref, tout ce qui fait que nous pourrons accueillir sereinement beaucoup plus de clients. C’est techniquement pas mal de travail, ce qui force à ralentir les évolutions du produit Karnott lui-même, mais c’est indispensable.

Un easter-egg se cache sur cette photo. Sauras-tu le retrouver ?

Tout ça pour dire que j’attendais du challenge, et je n’ai pas été déçu ! Je pourrais encore parler du monde agricole que je découvre tous les jours et que je trouve passionnant, de l’équipe géniale et enthousiaste, des raisons pour laquelle nous venons d’annoncer une deuxième levée de fonds, ou encore vous encourager à venir nous découvrir sur WelcomeToTheJungle. Mais là tout de suite, j’ai juste envie de savourer une année riche en émotions (ah oui, je suis papa aussi ! <3 ), et d’attendre avec impatience l’année prochaine !

L.B.

Publié le

2017, l’année du changement

Cela fait dix ans que je fais de la prestation de service en informatique. Dix ans que je fais du forfait, de la régie, des réponses à appel d’offre, que je rencontre des clients avec des besoins divers et variés.

En dix ans, j’aurais cotoyé le monde pharmaceutique, l’industrie aéronautique, automobile, le monde bancaire, l’univers de la grande distribution, associatif, de la startup au grand groupe, de Bâle à Lille en passant par Toulouse ou Paris. Cette variété de métiers et de façon de faire du développement est l’une des raisons qui m’avait poussé en sortant d’école, à entrer dans le monde du service et des mal-aimées « SSII ».

Alors, 10 ans plus tard, est-ce que j’ai vraiment appris des choses ?

Déjà, j’aurais appris à aimer mon métier. J’ai eu la chance de croiser des développeurs passionnés, et il est clair que c’est contagieux! Merci aux JUGs de Toulouse, Paris ou Lille, aux GDGs de France, et à l’ensemble des Sfeiriens qui ont tous été plus qu’inspirants.
Mais la principale leçon de ces 10 ans, c’est que la technique n’est qu’une petite composante d’un projet informatique. Prenons le métier, l’humain, les compétences à disposition, le temps disponible, la conjoncture, la pleine lune ou la météo, mettons tout ça dans un panier, et on en sort les vrais défis à surmonter. La technique est une composante essentielle, mais non suffisante.

Si je parlais à mon moi d’il y a 10 ans, lui conseillerais-je de faire du service ?

Sans hésiter.
Je ne sais pas si j’aurais été meilleur développeur autrement, mais je suis heureux de ne pas avoir été enfermé dans ma bulle, et heureux de toutes ces rencontres.

Et maintenant alors ?

Et maintenant, le grand changement. J’ai décidé de rejoindre le 1er juin l’équipe de Karnott en tant que CTO. Un terme pompeux pour un challenge bien réel. Le projet est chouette, l’un des deux fondateurs est agriculteur et connait parfaitement son métier (chouette, un nouveau domaine fonctionnel!). Plusieurs choses me plaisent dans ce challenge :
– Chaque pierre posée le sera pour mon employeur direct. La SSII a ce côté frustrant de n’être toujours que de passage…
– Je ne pourrai pas être plus proche de l’utilisateur final! C’est quelque chose que j’avais souvent reproché à mes différents projets par le passé…
– L’un de mes objectifs est de fonder une équipe technique complète. Rassembler des personnes compétentes qui partagent les mêmes valeurs que moi, j’y ai participé avec Sfeir Lille, et humainement c’est génial. (D’ailleurs, si vous êtes dans le Nord, que vous en avez marre du retail et que vous voulez faire de l’IOT, on recrute 😉 )
– Techniquement, il y a carte blanche. Et comme on vit une époque formidable, je crois qu’il y a de quoi bien s’amuser.
– Pas un jour qui passe sans qu’on entende parler de startup. Je crois qu’il ne faut pas mourir idiot et vivre ça de l’intérieur au moins une fois…

Bref, c’est stressant, angoissant, et encore un saut dans l’inconnu… Mais après tout, qu’est ce qu’on risque ?

LB.