Table des matières:

IDC2018IOT : Snitcher de salle de réunion : 6 étapes
IDC2018IOT : Snitcher de salle de réunion : 6 étapes

Vidéo: IDC2018IOT : Snitcher de salle de réunion : 6 étapes

Vidéo: IDC2018IOT : Snitcher de salle de réunion : 6 étapes
Vidéo: История климата и ее влияние на общество 2024, Novembre
Anonim
IDC2018IOT: Snitcher de salle de réunion
IDC2018IOT: Snitcher de salle de réunion

LE PROBLÈME

Comme nous le savons, la tendance des espaces de coworking s'est accélérée au cours des dernières années, avec une technologie de pointe définissant le choix de l'espace de coworking spécifique qui correspond à vos besoins.

L'une des principales fonctionnalités proposées est les salles de réunion partagées proposées aux membres de l'espace de co-working, qui sont gérées par une plate-forme de calendrier (généralement) simple.

Un problème se reproduit car l'emploi du temps des gens a tendance à être dynamique.

On pourrait réserver une chambre en pensant qu'il pourrait en avoir besoin et ne voudrait pas manquer le créneau horaire.

Même si quelqu'un n'utiliserait pas ce créneau horaire, il ne prendra pas la peine de le notifier et de l'annuler pour le bien des autres, car, malheureusement, c'est la nature humaine.

COMMENT LE RÉSOUDRE ?

En utilisant la technologie IoT - en vérifiant le son et le mouvement dans une salle de réunion désignée, nous vérifions, à chaque intervalle de temps, si une salle est réservée et effectivement occupée ou non:

1. S'il n'est pas réservé, ne faites rien.

2. S'il est réservé, vérifiez s'il y a un mouvement ou un son détecté;

Si c'est le cas, ne faites rien.

Si rien n'a été détecté, envoyez un message d'avertissement (par e-mail) à l'utilisateur qui a réservé la chambre pour lui demander si la chambre est toujours utilisée. à moins que l'utilisateur ne déclare qu'il utilise toujours la chambre, le statut de la chambre passera à « Disponible ».

* Ici, nous avons intégré notre projet avec Google Calendar afin de le généraliser au maximum.

Étape 1: Matériel et protocoles nécessaires

Matériel et protocoles nécessaires
Matériel et protocoles nécessaires

1. Nous avons utilisé NOSEMCU pour pouvoir mettre à jour les choses de manière dynamique à l'aide de la connexion WIFI.

2. Capteur de microphone qui "lira" le bruit dans la pièce.

3. Capteur PIR qui vérifiera s'il y a un mouvement.

Pour l'utilisation du logiciel et du serveur, outre le code dans Arduino, nous avons utilisé Google Script et Zapier pour prendre en charge notre système en ligne. Vous pouvez voir le flux dans l'image ajoutée (et PDF).

Nous avons utilisé Zapier pour connecter des applications et automatiser nos flux de travail (comme IFTTT) et nous avons utilisé Google Script pour nous aider à communiquer avec Google Calendar. Le script que nous avons écrit produit l'e-mail du créateur de l'événement afin que nous puissions l'envoyer à Zapier et vérifie si l'utilisateur a demandé à conserver la salle (en enregistrant certaines informations dans Google Sheets) avant de supprimer l'événement.

Étape 2: connectez le microphone et le capteur PIR

Connectez le microphone et le capteur PIR
Connectez le microphone et le capteur PIR
Connectez le microphone et le capteur PIR
Connectez le microphone et le capteur PIR

Nous voulions vérifier les valeurs moyennes que le microphone envoie au NODEMCU lorsque les gens parlent (clairement, dans chaque pièce il y avait des bruits de fond différents). Nous avons fait quelques tests et nous nous sommes rendu compte que le niveau de bruit moyen dans la pièce dans laquelle nous travaillions est supérieur à 50.

Le capteur PIR ne donne que des valeurs HIGH ou LOW, nous n'avons donc vérifié que le niveau de sensibilité le plus précis pour la pièce que nous avons vérifiée. Ce guide a été assez utile.

NOS CONNEXIONS:

Microphone - comme sur l'image Capteur PIR: GND > GND, OUT > D7, VCC > VN (5V)

Étape 3: Créer le workflow dans Zapier

Créer le workflow dans Zapier
Créer le workflow dans Zapier
Créer le workflow dans Zapier
Créer le workflow dans Zapier
Créer le workflow dans Zapier
Créer le workflow dans Zapier

Afin de savoir si la salle est réellement vide ou encore en cours d'utilisation (et les utilisateurs sont en pause par exemple), nous souhaitons créer un flux qui l'assure, juste après que le NodeMCU ait déclenché un Webhook vers Zapier qui notifie que le la salle est vide:

(1) DÉCLENCHEUR - CATCH HOOKZapier attrape le Webhook (qui sera envoyé par le NODEMCU)

(2) ACTION - GETZapier envoie un autre Webhook pour obtenir les données de l'événement;> Il appelle (exécute) un GoogleScript - GetCurrentEmailEventID (explication à l'étape suivante), pour obtenir les données de l'événement actuel - nom de l'événement, ID de l'événement, e-mail de l'utilisateur.

(3) FILTRE - CONTINUER UNIQUEMENT SI

Passez à l'étape suivante uniquement s'il y a un événement (n'importe quel événement) en cours sur le calendrier (ROOM IS BUSY), sinon, s'arrête car la salle est vacante.

(4) ACTION - GMAILZapier envoie un e-mail, via Gmail, à l'utilisateur qui a réservé la chambre (obtenu cette information à l'étape 2)

(5) ACTION - RETARD POURLaissez à l'utilisateur le temps de répondre à l'e-mail.- Si l'utilisateur clique sur le lien: appelez (exécutez) le GoogleScript - ApproveCurrentEvent (par conséquent, la salle est supprimée de la liste "Pièces à supprimer", et le la pièce est toujours marquée comme occupée.)

(6) ACTION - GET Après 5 minutes, Zapier appelle (exécute) GoogleScript - DeleteCurrentEvent- Si l'utilisateur n'a pas cliqué sur le lien

Vérifie si l'identifiant de la salle est dans la liste 'Pièces à supprimer'

il supprime simplement l'événement.

Étape 4: Scripts Google

Scripts Google
Scripts Google
Scripts Google
Scripts Google
Scripts Google
Scripts Google

Comme nous avons intégré l'ensemble du système, GoogleScripts était le choix trivial d'un IDE. Ainsi, nous avons utilisé les bibliothèques Google pertinentes. Changerait en fonction de la plateforme de réservation de chambres.

(1) GetCurrentEmailEventID

Fonctionne par un appel Webhook.

Utilisation d'un certain décalage afin d'éliminer une éventuelle annulation manquée, obtenir les données d'événement en cours.

(2) ApprouverCurrentEvent

Fonctionne par un clic de l'utilisateur.

En cas d'approbation par un utilisateur que la salle est toujours utilisée, supprime l'ID d'événement des « Pièces à supprimer ». Nous avons utilisé une feuille Google, toute autre forme de liste pourrait être pertinente ici.

(3) Supprimer l'événement en cours

Fonctionne par un appel Webhook.

Recherche l'ID d'événement pertinent dans la liste (feuille Google) et supprime cet événement du calendrier.

Étape 5: Connectez le flux avec le code Arduino

Le code joint se connecte aux capteurs que nous avons vérifiés il y a quelques étapes au système en ligne (calendrier Google dans notre cas). Il vérifie si la salle est occupée et si ce n'est pas le cas, il envoie une requête HTTP (un Webhook) qui lance la requête de suppression d'événement sur Zapier.

Étape 6: Examen, conclusions et mise à l'échelle future

Image
Image

Le principal défi auquel nous avons dû faire face est de couvrir tous les cas limites lorsque nous décidons de libérer une salle de réunion. Nous avons ensuite dû créer une machine à états considérant tous les cas possibles, de telle sorte qu'aucune erreur ne se produise et que la salle ne soit définie comme disponible que lorsqu'elle le devrait.

Par exemple, si la salle est réservée pour un groupe qui n'est actuellement pas là (c'est-à-dire en pause, par exemple), mais en a encore besoin, NODEMCU détectera que la salle est libre > PROBLÈME.

Ensuite, notre solution consistait à envoyer par e-mail à l'utilisateur qui avait réservé la chambre (ce qui n'était pas simple à comprendre) un message lui offrant la possibilité de conserver la chambre.

Si l'utilisateur n'a pas répondu dans un délai donné (nous le fixons à 5 minutes, mais cela peut être modifié facilement), nous supprimons l'événement du calendrier (et libérons la salle).

De cette façon, nous avons finalement réussi à gérer tous les scénarios possibles et à créer un système fonctionnel.

LES LIMITES DE NOTRE SYSTÈME:

1. Les capteurs utilisés doivent être très précis et sensibles.

2. La taille de la pièce est limitée au rayon/à la plage du capteur.

3. Nous devrons compter sur la réactivité de l'utilisateur.

4. Notre système est construit à l'aide de plusieurs plateformes (agenda Google, Gmail, Zapier etc.) et devra utiliser leur service pour fonctionner.

5. La mise à l'échelle de ce service pour plusieurs salles (au lieu de dupliquer l'ensemble du système) nécessitera une gestion supplémentaire avec l'ID de la salle.

6. Le système est uniquement automatique et il n'y a pas d'option manuelle pour annuler une réservation de chambre.

DÉVELOPPEMENTS FUTURS:

Nous augmenterions certainement le système de deux manières:

1. Capacité à travailler avec n'importe quelle autre plate-forme de calendrier (ainsi toute entreprise d'espaces de co-working pourrait l'utiliser).

2. Capacité à gérer plusieurs pièces, étages et sites.

Nous pensons que ce type d'échelle prendra 2-3 mois pour généraliser, tester et ajouter plusieurs pièces (étages, etc.).

De plus, en utilisant une quantité illimitée d'argent et de ressources, nous utiliserions de meilleurs capteurs avec une plus grande portée, tout en les personnalisant en fonction de la pièce désignée - en tenant compte de la portée, du rayon, de la quantité de capteurs, etc. Une étape qui rendrait chaque système plus long à installer, évidemment.

Conseillé: