Dans ce dernier épisode de notre série de blogs sur l‘IdO, nous allons commencer à discuter d‘un pipeline plus étendu que nous avons installé ici au siège de SnapLogic (comme promis dans le dernier article). L‘espace nous empêche de montrer tous les détails de son fonctionnement, mais nous en aborderons les grandes lignes dans ce billet et le suivant.
À un moment ou à un autre de votre carrière, vous avez peut-être participé à une réunion qui s‘est prolongée. (Vous y êtes peut-être en ce moment même). Vous avez probablement souhaité que quelque chose mette fin à la réunion. L ‘internet des objets est là pour exaucer votre souhait.
Nous allons créer un pipeline pour activer un signal de réunion dans la salle de conférence, le Luminescent Evanescent Apparatus for Voiding Engagements.
Le pipeline interroge l‘API Google Calendar FreeBusy pour savoir quand les réunions doivent se terminer pour une salle de conférence donnée ; le pipeline traite ensuite ces informations dans une variable "time-until-finished" et calcule un hash unique pour la réunion. S‘il reste 5 minutes ou moins pour une réunion, le filtre permet de transmettre cette information au point de terminaison. Il peut s‘agir d‘un POST vers le microcontrôleur ou, pour plus de généralité, d‘un push vers un mécanisme général de file d‘attente (par exemple, RabbitMQ). Cette dernière approche est similaire à la couche d‘abstraction supplémentaire que vous offrirait un service de hub IoT. Dans ce cas, nous inclurions également dans notre document l‘identifiant de la salle de conférence à laquelle le message est destiné.
Nous utilisons un Photon de particle.io comme microcontrôleur. Les Photons sont (pour la plupart) compatibles avec Arduino, mais disposent d‘une fonctionnalité native substantielle sur cloud . En particulier, nous pouvons exposer les fonctions du micrologiciel en tant que points de terminaison REST. Cela signifie que nous pouvons écrire le firmware (dans un sous-ensemble de C++) qui provoque des choses dans le monde réel, et nous pouvons ensuite invoquer cette fonctionnalité avec un simple POST.
Nous exécutons ce pipeline en tant que tâche programmée une fois par minute. C‘est la raison pour laquelle nous calculons le hachage - nous pouvons transmettre plusieurs messages au Photon (ou au courtier) concernant la même réunion, mais le dispositif sait qu‘il doit ignorer les messages dont le hachage est le même que le message précédent. C‘est un modèle de conception que vous pouvez trouver utile - il peut être plus facile de garder une trace de l‘état sur un point final que dans un pipeline. (L‘exécution toutes les minutes et la recherche d‘un delta inférieur à cinq minutes signifient que nous nous attendons à générer le message meeting-is-over 5 fois, et peut-être même 6 dans un cas particulier).
L‘aspect le plus délicat de ce pipeline est de faire en sorte que la requête GET vers Google Agenda soit correcte. Vous devez vous assurer que vous disposez des autorisations nécessaires sur le compte Google que vous utilisez, et que vous passez les bons paramètres dans la requête GET et dans l‘autorisation. Le résultat final ressemblera à ceci :
Nous convertissons la sortie de l‘API FreeBusy en "delta-times" - la différence entre l‘heure actuelle et l‘heure de fin de réunion. Enfin, nous générons un "hash" - qui n‘est en fait qu‘une opération d‘encodage - sur l‘heure de fin de la réunion. L‘heure de fin de la réunion et le hachage sont transmis par le filtre au point de terminaison si la réunion se termine dans moins de cinq minutes. Ce sont les deux seules données dont notre microcontrôleur a besoin.
Le prochain article traitera de l‘appareil IoT et de son logiciel. En attendant, consultez le reste de la série de blogs sur l‘IdO ou contactez-nous pour une démonstration.
