In quest'ultima puntata della nostra serie di blog sull'IoT, inizieremo a parlare di una pipeline più estesa che abbiamo installato qui al quartier generale di SnapLogic (come promesso nell'ultimo post). Lo spazio ci impedisce di mostrare tutti i dettagli del suo funzionamento, ma in questo e nel prossimo post ne illustreremo i punti salienti.
A un certo punto della vostra carriera vi sarà capitato di partecipare a una riunione che è andata in overtime. (Forse lo state facendo proprio ora). Probabilmente avrete desiderato che qualcosa interrompesse la riunione. Ebbene, l'Internet degli oggetti è qui per esaudire il vostro desiderio.
Creeremo una pipeline per attivare un segnale di riunione in sala conferenze, l'Apparato Evanescente Luminescente per gli Impegni Vuoti.
La pipeline interroga l'API FreeBusy di Google Calendar per sapere quando le riunioni dovrebbero terminare per una determinata sala conferenze; la pipeline elabora quindi queste informazioni in una variabile "time-until-finished" e calcola un hash unico per la riunione. Se rimangono 5 minuti o meno per una riunione, il filtro consente di passare questa informazione all'endpoint. Questo può essere un POST al microcontrollore o, per maggiore generalità, un push a un meccanismo di coda generale (ad esempio, RabbitMQ). Quest'ultimo approccio è simile al livello di astrazione aggiuntivo offerto da un servizio hub IoT. In questo caso, includeremo nel nostro documento anche l'id della sala conferenze a cui vogliamo inviare il messaggio.
Utilizziamo un particle.io Photon come microcontrollore. I Photon sono (per lo più) compatibili con Arduino, ma hanno una notevole funzionalità nativa di cloud . In particolare, possiamo esporre le funzioni del firmware come endpoint REST. Ciò significa che possiamo scrivere il firmware (in un sottoinsieme di C++) che fa accadere le cose nel mondo reale e poi possiamo invocare quella funzionalità con un semplice POST.
Questa pipeline viene eseguita come attività programmata una volta al minuto. Questo è il motivo del calcolo dell'hash: possiamo passare più messaggi a Photon (o al broker) sulla stessa riunione, ma il dispositivo sa che deve ignorare i messaggi il cui hash è uguale a quello del messaggio precedente. Questo è un modello di progettazione che può essere utile: può essere più facile tenere traccia dello stato in un endpoint che in una pipeline. (Eseguire ogni minuto e cercare un delta inferiore a cinque minuti significa aspettarsi di generare il messaggio meeting-is-over 5 volte, e forse anche 6 in un caso limite).
L'aspetto più complicato di questa pipeline è la corretta richiesta GET a Google Calendar. È necessario assicurarsi di avere i permessi corretti sull'account Google che si sta utilizzando e assicurarsi di passare i parametri giusti nella richiesta GET e anche nell'autorizzazione. Il risultato finale sarà simile a questo:
Convertiamo l'output dell'API FreeBusy in "delta-times", ovvero la differenza tra l'ora corrente e l'ora di fine riunione. Infine, generiamo un "hash" - in realtà solo un'operazione di codifica - sull'orario di fine riunione. Il tempo che manca alla fine della riunione e l'hash vengono passati attraverso il filtro all'endpoint se la riunione termina in meno di cinque minuti. Questi sono gli unici due dati di cui il microcontrollore ha bisogno.
Il prossimo post parlerà del dispositivo IoT e del suo software. Nel frattempo, date un'occhiata al resto della serie di blog sull'IoT o contattateci per una dimostrazione.
