IDC2018IOT: Snitcher de sala de reunião: 6 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:38

O PROBLEMA

Como sabemos, a tendência de espaços de co-working tem se acelerado nos últimos anos, junto com a tecnologia de ponta que define a escolha do espaço de co-working específico que se adapta às suas necessidades.

Uma das principais características oferecidas são as salas de reunião compartilhadas oferecidas aos membros do espaço de co-working, que é gerenciado por uma plataforma de calendário (geralmente) simples.

Um problema reaparece à medida que a programação das pessoas tende a ser dinâmica.

Alguém pode reservar um quarto pensando que pode precisar dele e não quer perder o horário.

Mesmo que alguém não use esse intervalo de tempo eventualmente, ele não se preocupará em notificar e cancelar para o bem dos outros, pois, infelizmente, essa é a natureza humana.

COMO RESOLVEMOS ISSO?

Usando a tecnologia IoT - verificando o som e o movimento em uma sala de reunião designada, estamos verificando, a cada intervalo de tempo determinado, se uma sala está reservada e realmente ocupada ou não:

1. Se não estiver reservado, não faça nada.

2. Caso esteja agendado, verifique se há algum movimento ou som detectado;

Se houver, não faça nada.

Se nada for detectado, envie uma mensagem de aviso (por e-mail) ao usuário que reservou o quarto, perguntando se o quarto ainda está em uso. a menos que o usuário declare que ainda está usando a sala, o status da sala será alterado para “Disponível”.

* Aqui, integramos nosso projeto ao Google Calendar para generalizá-lo o máximo possível.

Etapa 1: Hardware e protocolos necessários

1. Usamos o NOSEMCU para que pudéssemos atualizar as coisas dinamicamente usando a conexão WIFI.

2. Sensor de microfone que "lerá" o ruído na sala.

3. Sensor PIR que verificará se há algum movimento.

Para uso de software e servidor, além do código em Arduino, utilizamos Google Script e Zapier para dar suporte ao nosso sistema online. Você pode ver o fluxo na imagem adicionada (e PDF).

Usamos o Zapier para conectar aplicativos e automatizar nossos fluxos de trabalho (como IFTTT) e usamos o Google Script para nos ajudar a nos comunicar com o Google Calendar. O script que escrevemos está produzindo o e-mail do criador do evento para que possamos enviá-lo para Zapier e verificar se o usuário pediu para manter a sala (salvando algumas informações no Planilhas Google) antes de excluir o evento.

Etapa 2: conectar o microfone e o sensor PIR

Queríamos verificar os valores médios que o microfone envia para o NODEMCU quando as pessoas estão falando (obviamente, em cada sala havia ruídos de fundo diferentes). Fizemos alguns testes e percebemos que o nível de ruído médio na sala em que trabalhamos está acima de 50.

O sensor PIR fornece apenas valores ALTOS ou BAIXOS, portanto, verificamos apenas o nível de sensibilidade mais preciso para a sala que verificamos. Este guia foi muito útil.

NOSSAS CONEXÕES:

Microfone - como no sensor picturePIR: GND> GND, OUT> D7, VCC> VN (5V)

Etapa 3: Crie o fluxo de trabalho no Zapier

Para saber se a sala está realmente vazia ou em uso (e os usuários estão em pausa, por exemplo), gostaríamos de criar um fluxo que o assegure, logo após o NodeMCU disparar um Webhook para Zapier que avisa que o sala está vazia:

(1) TRIGGER - CATCH HOOKZapier captura o Webhook (que será enviado pelo NODEMCU)

(2) AÇÃO - GETZapier envia outro Webhook para obter os dados do evento;> Chama (executa) um GoogleScript - GetCurrentEmailEventID (explicação na etapa seguinte), para obter os dados do evento atual - nome do evento, ID do evento, e-mail do usuário.

(3) FILTRO - SOMENTE CONTINUAR SE

Continue para a próxima etapa apenas se houver um evento (qualquer evento) acontecendo no momento no calendário (QUARTO ESTÁ OCUPADO), caso contrário, para quando o quarto estiver vago.

(4) AÇÃO - GMAILZapier envia um e-mail, através do Gmail, para o usuário que reservou a sala (obteve essa informação na etapa 2)

(5) AÇÃO - ATRASO PARA DEIXAR o usuário responder ao e-mail.- Se o usuário clicar no link: chame (execute) o GoogleScript - ApproveCurrentEvent (portanto, a sala é removida da lista 'Salas a serem excluídas', e a a sala ainda está marcada como ocupada.)

(6) AÇÃO - OBTER Após 5 minutos, Zapier chama (executa) GoogleScript - DeleteCurrentEvent- Se o usuário não clicar no link

Verifica se o ID da sala está na lista 'Salas a serem excluídas'

apenas remove o evento.

Etapa 4: Scripts do Google

Como integramos todo o sistema, GoogleScripts foi a escolha trivial de um IDE, portanto, utilizamos Bibliotecas Google relevantes. Mudaria de acordo com a plataforma de reserva de quartos.

(1) GetCurrentEmailEventID

É executado por uma chamada de Webhook.

Usar um certo deslocamento para eliminar possíveis erros de cancelamento, obtendo os dados do evento atual.

(2) ApproveCurrentEvent

É executado por um clique do usuário.

No caso de aprovação do usuário de que a sala ainda está em uso, exclui o ID do evento de 'Salas a serem excluídas'. Usamos uma planilha do Google, qualquer outra forma de lista pode ser relevante aqui.

(3) DeleteCurrentEvent

É executado por uma chamada de Webhook.

Procura o ID do evento relevante na lista (planilha do Google) e exclui o evento do calendário.

Etapa 5: conectar o fluxo com o código do Arduino

O código anexado se conecta aos sensores que verificamos algumas etapas atrás para o sistema online (calendário do Google em nosso caso). Ele verifica se a sala está ocupada e, em caso negativo, envia uma solicitação HTTP (um Webhook) que inicia a exclusão da solicitação de evento no Zapier.

Etapa 6: Revisão, Conclusões e Escalonamento Futuro

O principal desafio com o qual tivemos de lidar foi cobrir todos os casos extremos ao decidir liberar uma sala de reuniões. Em seguida, tivemos que criar uma máquina de estado considerando todos os casos possíveis, de forma que um erro não ocorresse e a sala fosse definida como disponível apenas quando deveria.

Por exemplo, se a sala está reservada para algum grupo que não está lá (ou seja, em um intervalo, por exemplo), mas ainda precisa, NODEMCU detectará que a sala está livre> PROBLEMA.

Em seguida, nossa solução foi enviar um e-mail ao usuário que reservou o quarto (o que não foi fácil de descobrir) uma mensagem que fornece a opção de manter o quarto reservado.

Se o usuário não respondeu em um determinado tempo (configuramos para 5 minutos, mas pode ser alterado facilmente), excluímos o evento do calendário (e liberamos a sala).

Dessa forma, conseguimos lidar com todos os cenários possíveis e criar um sistema funcional.

NOSSAS LIMITAÇÕES DE SISTEMA:

1. Os sensores usados devem ser muito precisos e sensíveis.

2. O tamanho da sala é limitado ao raio / alcance do sensor.

3. Teremos que contar com a capacidade de resposta do usuário.

4. Nosso sistema é construído usando várias plataformas (Google calendar, Gmail, Zapier etc.) e terá que usar seu serviço para funcionar.

5. O dimensionamento deste serviço para vários quartos (em vez de duplicar todo o sistema) exigirá um tratamento adicional com a identificação do quarto.

6. O sistema é apenas automático e não existe a opção manual de cancelamento da reserva de um quarto.

DESENVOLVIMENTOS FUTUROS:

Definitivamente, expandiríamos o sistema de duas maneiras:

1. Capacidade de trabalhar com qualquer outra plataforma de calendário (para que qualquer empresa de espaços de co-working possa usá-la).

2. Capacidade de lidar com vários quartos, andares e sites.

Acreditamos que esse tipo de escala levará de 2 a 3 meses para generalizar, testar e adicionar o recurso de várias salas (andares, etc.).

Além disso, usando uma quantidade ilimitada de dinheiro e recursos, usaríamos sensores melhores com um alcance maior, junto com personalizá-los para a sala designada - considerando alcance, raio, quantidade de sensores etc. Uma etapa que tornaria a instalação de cada sistema mais longa, obviamente.