Spisu treści:

IDC2018IOT: Snitcher w sali konferencyjnej: 6 kroków
IDC2018IOT: Snitcher w sali konferencyjnej: 6 kroków

Wideo: IDC2018IOT: Snitcher w sali konferencyjnej: 6 kroków

Wideo: IDC2018IOT: Snitcher w sali konferencyjnej: 6 kroków
Wideo: Jak zaprojektować stronę? #1: Zbieranie wymagań 2024, Listopad
Anonim
IDC2018IOT: Snitcher w sali konferencyjnej
IDC2018IOT: Snitcher w sali konferencyjnej

PROBLEM

Jak wiemy, trend na przestrzenie coworkingowe przybiera na sile w ostatnich latach, wraz z najnowocześniejszą technologią określającą wybór konkretnej przestrzeni coworkingowej, która odpowiada Twoim potrzebom.

Jedną z głównych oferowanych funkcji są współdzielone sale konferencyjne oferowane członkom przestrzeni coworkingowej, zarządzane przez (zwykle) prostą platformę kalendarzową.

Problem pojawia się ponownie, ponieważ harmonogramy ludzi są zwykle dynamiczne.

Można zarezerwować pokój, myśląc, że może go potrzebować i nie chcieć przegapić przedziału czasowego.

Nawet jeśli ktoś w końcu nie skorzysta z tego przedziału czasowego, nie zada sobie trudu, aby go powiadomić i odwołać ze względu na innych, ponieważ niestety taka jest ludzka natura.

JAK TO ROZWIĄZUJEMY?

Wykorzystując technologię IoT - sprawdzając dźwięk i ruch w wyznaczonej sali konferencyjnej, sprawdzamy co określony czas, czy sala jest zarezerwowana i faktycznie zajęta, czy nie:

1. Jeśli nie jest zarezerwowany, nie rób nic.

2. Jeśli jest zarezerwowany, sprawdź, czy wykryto ruch lub dźwięk;

Jeśli jest, nie rób nic.

Jeśli nic nie zostanie wykryte, wyślij wiadomość ostrzegawczą (poprzez e-mail) do użytkownika, który zarezerwował pokój, z pytaniem, czy pokój jest nadal używany. chyba że użytkownik zadeklaruje, że nadal korzysta z pokoju, status pokoju zmieni się na „Dostępny”.

* Tutaj zintegrowaliśmy nasz projekt z Kalendarzem Google, aby jak najbardziej go uogólnić.

Krok 1: Potrzebny sprzęt i protokoły

Potrzebny sprzęt i protokoły
Potrzebny sprzęt i protokoły

1. Użyliśmy NOSEMCU, abyśmy mogli aktualizować rzeczy dynamicznie za pomocą połączenia WIFI.

2. Czujnik mikrofonu, który „odczyta” hałas w pomieszczeniu.

3. Czujnik PIR, który sprawdzi, czy jest jakiś ruch.

Do użytku oprogramowania i serwera, oprócz kodu w Arduino, użyliśmy Google Script i Zapier do obsługi naszego systemu online. Możesz zobaczyć przepływ na dodanym obrazku (i PDF).

Wykorzystaliśmy Zapier do połączenia aplikacji i zautomatyzowania naszych przepływów pracy (takich jak IFTTT) i użyliśmy Google Script, aby pomóc nam komunikować się z Kalendarzem Google. Skrypt, który napisaliśmy, tworzy e-mail twórcy wydarzenia, abyśmy mogli go wysłać wrzucając Zapiera i sprawdzając, czy użytkownik poprosił o zatrzymanie pokoju (zapisując niektóre informacje w Arkuszach Google) przed usunięciem wydarzenia.

Krok 2: Podłącz mikrofon i czujnik PIR

Podłącz mikrofon i czujnik PIR
Podłącz mikrofon i czujnik PIR
Podłącz mikrofon i czujnik PIR
Podłącz mikrofon i czujnik PIR

Chcieliśmy sprawdzić średnie wartości, jakie mikrofon wysyła do NODEMCU, gdy ludzie rozmawiają (oczywiście, w każdym pokoju były różne odgłosy tła). Zrobiliśmy kilka testów i zdaliśmy sobie sprawę, że średni poziom hałasu w pomieszczeniu, w którym pracowaliśmy, wynosi gdzieś powyżej 50.

Czujnik PIR podaje tylko wartości HIGH lub LOW, więc sprawdziliśmy tylko poziom czułości, który jest najdokładniejszy dla sprawdzanego pomieszczenia. Ten przewodnik był bardzo pomocny.

NASZE POŁĄCZENIA:

Mikrofon - jak na obrazku czujnik PIR: GND > GND, OUT > D7, VCC > VN (5V)

Krok 3: Utwórz przepływ pracy w Zapier

Utwórz przepływ pracy w Zapier
Utwórz przepływ pracy w Zapier
Utwórz przepływ pracy w Zapier
Utwórz przepływ pracy w Zapier
Utwórz przepływ pracy w Zapier
Utwórz przepływ pracy w Zapier

Aby wiedzieć, czy pomieszczenie jest rzeczywiście puste, czy nadal jest w użyciu (na przykład użytkownicy mają przerwę), chcielibyśmy stworzyć przepływ, który to zapewni, zaraz po tym, jak NodeMCU odpali webhooka do Zapier, który powiadomi, że pokój jest pusty:

(1) TRIGGER - CATCH HOOKZapier łapie webhooka (który zostanie wysłany przez NODEMCU)

(2) AKCJA - GETZapier wysyła kolejny Webhook w celu pobrania danych zdarzenia;> Wywołuje (uruchamia) GoogleScript - GetCurrentEmailEventID (wyjaśnienie w następnym kroku), aby uzyskać aktualne dane zdarzenia - nazwę zdarzenia, identyfikator zdarzenia, adres e-mail użytkownika.

(3) FILTR - KONTYNUUJ TYLKO JEŚLI

Przejdź do następnego kroku tylko wtedy, gdy w kalendarzu aktualnie odbywa się jakieś wydarzenie (dowolne wydarzenie) (POKÓJ JEST ZAJĘTY), w przeciwnym razie zatrzyma się, gdy pomieszczenie jest wolne.

(4) DZIAŁANIE - GMAILZapier wysyła wiadomość e-mail za pośrednictwem Gmaila do użytkownika, który zarezerwował pokój (otrzymał tę informację w kroku 2)

(5) DZIAŁANIE – OPÓŹNIENIE ZAPEWNIJ użytkownikowi czas na odpowiedź na wiadomość e-mail. – Jeśli użytkownik kliknie link: wywołaj (uruchom) GoogleScript – ApproveCurrentEvent(Stąd pokój zostanie usunięty z listy „Pokoje do usunięcia”, a pokój jest nadal oznaczony jako zajęty.)

(6) AKCJA - GET Po 5 minutach Zapier wywołuje (uruchamia) GoogleScript - DeleteCurrentEvent - Jeśli użytkownik nie kliknął linku

Sprawdza, czy numer pokoju znajduje się na liście „Pokoje do usunięcia”

po prostu usuwa wydarzenie.

Krok 4: Skrypty Google

Skrypty Google
Skrypty Google
Skrypty Google
Skrypty Google
Skrypty Google
Skrypty Google

Ponieważ zintegrowaliśmy cały system, GoogleScripts był trywialnym wyborem IDE, dlatego skorzystaliśmy z odpowiednich Bibliotek Google. Zmieni się zgodnie z platformą rezerwacji pokoi.

(1) GetCurrentEmailEventID

Działa przez wywołanie webhooka.

Korzystanie z pewnego przesunięcia w celu wyeliminowania możliwej błędnej anulacji, uzyskanie aktualnych danych o zdarzeniu.

(2) Zatwierdź bieżące wydarzenie

Działa przez kliknięcie użytkownika.

W przypadku zatwierdzenia przez użytkownika, że sala jest nadal używana, usuwa identyfikator wydarzenia z „Pokoje do usunięcia”. Użyliśmy arkusza Google, każda inna forma listy może być tutaj odpowiednia.

(3) Usuńbieżące zdarzenie

Działa przez wywołanie webhooka.

Wyszukuje odpowiedni identyfikator wydarzenia na liście (arkusz Google) i usuwa to wydarzenie z kalendarza.

Krok 5: Połącz przepływ z kodem Arduino

Załączony kod łączy czujniki, które sprawdziliśmy kilka kroków temu, z systemem online (w naszym przypadku kalendarz Google). Sprawdza, czy pokój jest zajęty, a jeśli nie, wysyła żądanie HTTP (Webhook), które uruchamia żądanie usunięcia zdarzenia na Zapier.

Krok 6: Przegląd, wnioski i przyszłe skalowanie

Image
Image

Głównym wyzwaniem, z którym musieliśmy się zmierzyć, jest uwzględnienie wszystkich skrajnych przypadków przy podejmowaniu decyzji o zwolnieniu sali konferencyjnej. Następnie musieliśmy stworzyć maszynę stanów uwzględniającą każdy możliwy przypadek, tak aby błąd nie wystąpił, a pomieszczenie zostanie ustawione jako dostępne tylko wtedy, gdy powinno.

Na przykład, jeśli pokój jest zarezerwowany dla jakiejś grupy, której aktualnie nie ma (na przykład ma przerwę), ale nadal go potrzebuje, NODEMCU wykryje, że pokój jest wolny > PROBLEM.

Następnie naszym rozwiązaniem było wysłanie e-maila do użytkownika, który zarezerwował pokój (co nie było łatwe do rozszyfrowania) wiadomości, która zapewnia opcję dalszego trzymania pokoju.

Jeśli użytkownik nie odpowiedział w określonym czasie (ustawiliśmy go na 5 minut, ale można to łatwo zmienić), usuwamy wydarzenie z kalendarza (i zwalniamy salę).

W ten sposób w końcu udało nam się obsłużyć wszystkie możliwe scenariusze i stworzyć działający system.

NASZE OGRANICZENIA SYSTEMOWE:

1. Używane czujniki muszą być bardzo dokładne i czułe.

2. Wielkość pomieszczenia jest ograniczona do promienia/zasięgu czujnika.

3. Będziemy musieli polegać na reakcji użytkownika.

4. Nasz system jest zbudowany na kilku platformach (kalendarz Google, Gmail, Zapier itp.) i będzie musiał korzystać z ich usług.

5. Skalowanie tej usługi dla wielu sal (zamiast powielania całego systemu) będzie wymagało dodatkowej obsługi identyfikatorem sali.

6. System działa tylko automatycznie i nie ma możliwości ręcznego anulowania rezerwacji pokoju.

PRZYSZŁY ROZWÓJ:

Zdecydowanie rozbudowalibyśmy system na dwa sposoby:

1. Możliwość współpracy z dowolnymi innymi platformami kalendarzowymi (tak, aby każda firma coworkingowa mogła z niej korzystać).

2. Możliwość obsługi wielu pomieszczeń, pięter i witryn.

Wierzymy, że taka skala zajmie 2-3 miesiące, aby uogólnić, przetestować i dodać funkcję wielu pomieszczeń (pięter itp.).

Dodatkowo, wykorzystując nieograniczoną ilość pieniędzy i zasobów, wykorzystalibyśmy lepsze czujniki o większym zasięgu, wraz z dostosowaniem ich do wyznaczonego pomieszczenia – biorąc pod uwagę zasięg, promień, ilość czujników itp. Krok, który wydłużyłby montaż każdego systemu, oczywiście.

Zalecana: