IDC2018IOT: Snitcher u sobi za sastanke: 6 koraka

2024 Autor: John Day | [email protected]. Zadnja izmjena: 2024-01-30 08:08

PROBLEM

Kao što znamo, trend prostora za zajednički rad ubrzava se u posljednjih nekoliko godina, zajedno s najnovijom tehnologijom koja definira odabir specifičnog prostora za rad koji odgovara vašim potrebama.

Jedna od glavnih značajki koje se nude su zajedničke prostorije za sastanke koje se nude članovima prostora za zajednički rad, a kojima upravlja (obično) jednostavna kalendarska platforma.

Problem se ponavlja kako raspored ljudi ima tendenciju da bude dinamičan.

Netko bi mogao rezervirati sobu misleći da bi mu mogla zatrebati i ne bi želio propustiti vrijeme.

Čak i ako neko na kraju ne bi iskoristio taj vremenski period, neće se potruditi da ga obavijesti i otkaže zbog drugih, jer je to, nažalost, ljudska priroda.

KAKO RJEŠIMO?

Koristeći IoT tehnologiju - provjeravajući zvuk i kretanje u određenoj prostoriji za sastanke, provjeravamo, u svakom određenom vremenskom intervalu, je li soba rezervirana i zauzeta ili nije:

1. Ako nije rezervirano, nemojte ništa učiniti.

2. Ako je rezervirano, provjerite ima li otkrivenih pokreta ili zvukova;

Ako postoji, nemojte ništa učiniti.

Ako ništa nije otkriveno, pošaljite poruku upozorenja (putem e -pošte) korisniku koji je rezervirao sobu s pitanjem je li soba još uvijek u upotrebi. osim ako korisnik izjavi da još uvijek koristi sobu, status sobe će se promijeniti u "Dostupno".

* Ovdje smo integrirali naš projekt s Google kalendarom kako bismo ga što više generalizirali.

Korak 1: Potrebni hardver i protokoli

1. Koristili smo NOSEMCU kako bismo mogli dinamički ažurirati stvari putem WIFI veze.

2. Senzor mikrofona koji će "čitati" buku u prostoriji.

3. PIR senzor koji će provjeriti ima li pomaka.

Za upotrebu softvera i servera, osim koda u Arduinu, koristili smo Google Script i Zapier za podršku našem sistemu na mreži. Tok možete vidjeti na dodanoj slici (i PDF -u).

Koristili smo Zapier za povezivanje aplikacija i automatizaciju naših tokova rada (poput IFTTT -a), a koristili smo i Google Script za komunikaciju s Google kalendarom. Skripta koju smo napisali proizvodi e -poruku kreatora događaja kako bismo je mogli poslati, bacio je Zapier i provjerava je li korisnik tražio da zadrži sobu (spremanjem nekih podataka u Google tablice) prije brisanja događaja.

Korak 2: Povežite mikrofon i PIR senzor

Htjeli smo provjeriti prosječne vrijednosti koje mikrofon šalje NODEMCU -u dok ljudi pričaju (jasno je da su u svakoj prostoriji postojali različiti pozadinski zvukovi). Napravili smo neka testiranja i shvatili da je prosječna razina buke u prostoriji u kojoj smo radili negdje iznad 50.

PIR senzor daje samo VISE ili NISKE vrijednosti, pa smo provjerili samo nivo osjetljivosti koji je najprecizniji za prostoriju koju smo provjerili. Ovaj vodič je bio od velike pomoći.

NAŠE VEZE:

Mikrofon - kao na slici PIR senzor: GND> GND, OUT> D7, VCC> VN (5V)

Korak 3: Kreirajte tijek rada u Zapieru

Kako bismo znali je li soba zaista prazna ili je još uvijek u upotrebi (a korisnici su na primjer na pauzi), htjeli bismo stvoriti tok koji to osigurava, odmah nakon što NodeMCU pokrene Webhook na Zapier koji obavještava da soba je prazna:

(1) TRIGGER - COTCH HOOKZapier hvata Webhook (koji će poslati NODEMCU)

(2) AKCIJA - GETZapier šalje drugi Webhook radi dobivanja podataka o događaju;> Poziva (pokreće) GoogleScript - GetCurrentEmailEventID (objašnjenje u sljedećem koraku), kako bi dobio podatke o trenutnom događaju - naziv događaja, ID događaja, korisničku e -poštu.

(3) FILTER - NASTAVI SE SAMO AKO

Pređite na sljedeći korak samo ako se na kalendaru trenutno događa neki događaj (bilo koji događaj) (SOBA JE ZAPOSLENA), u suprotnom, prestaje jer je soba prazna.

(4) AKCIJA - GMAILZapier šalje e -poštu, putem Gmaila, korisniku koji je rezervirao sobu (ove je informacije dobio u 2. koraku)

(5) AKCIJA - ODLAGANJE FOR Ostavite korisniku vrijeme da odgovori na e -poruku.- Ako korisnik klikne na vezu: pozovite (pokrenite) GoogleScript - ApproveCurrentEvent (Stoga je soba uklonjena sa liste 'Sobe za brisanje', a soba je i dalje označena kao zauzeta.)

(6) AKCIJA - DOBIJI Nakon 5 minuta, Zapier poziva (pokreće) GoogleScript - DeleteCurrentEvent- Ako korisnik nije kliknuo na vezu

Provjerava je li ID sobe na listi 'Sobe za brisanje'

samo uklanja događaj.

Korak 4: Google skripte

Kako smo integrirali cijeli sistem, GoogleScripts je bio trivijalni izbor IDE -a, pa smo koristili relevantne Google biblioteke. Promijenilo bi se prema Platformi za rezervaciju soba.

(1) GetCurrentEmailEventID

Pokreće se pomoću Webhook poziva.

Korištenje određenog pomaka radi uklanjanja mogućeg otkazivanja, dobivanje podataka o trenutnom događaju.

(2) OdobriCurrentEvent

Pokreće se klikom korisnika.

U slučaju korisničkog odobrenja da se soba još uvijek koristi, briše ID događaja iz 'Sobe za brisanje'. Koristili smo Google tablicu, ovdje bi mogao biti relevantan bilo koji drugi oblik liste.

(3) DeleteCurrentEvent

Pokreće se pomoću Webhook poziva.

Traži odgovarajući ID događaja na popisu (Google tablica) i briše taj događaj iz kalendara.

Korak 5: Povežite protok s Arduino kodom

Priloženi kôd povezuje se sa senzorima koje smo prije nekoliko koraka provjerili na mrežni sistem (Google kalendar u našem slučaju). Provjerava je li soba zauzeta, a ako nije, šalje HTTP zahtjev (Webhook) koji pokreće zahtjev za brisanje događaja na Zapieru.

Korak 6: Pregled, zaključci i skaliranje budućnosti

Glavni izazov s kojim smo se morali nositi je pokriti sve rubne slučajeve pri odlučivanju o oslobađanju sobe za sastanke. Zatim smo morali stvoriti državnu mašinu uzimajući u obzir svaki mogući slučaj, tako da neće doći do greške i da će soba biti postavljena kao dostupna samo kada bi trebala.

Na primjer, ako je soba rezervirana za neku grupu koja se trenutno ne nalazi (na primjer, na pauzi), ali joj je ipak potrebna, NODEMCU će otkriti da je soba slobodna> PROBLEM.

Zatim je naše rješenje bilo poslati korisniku koji je rezervirao sobu (što nije jednostavno shvatiti) poslati poruku koja pruža mogućnost da zadrži sobu.

Ako korisnik nije odgovorio u datom vremenu (postavili smo ga na 5 minuta, ali ga je moguće lako promijeniti), brišemo događaj iz kalendara (i oslobađamo sobu).

Na taj način smo na kraju uspjeli obraditi sve moguće scenarije i stvoriti radni sistem.

NAŠA OGRANIČENJA SISTEMA:

1. Korišteni senzori moraju biti vrlo precizni i osjetljivi.

2. Veličina sobe je ograničena na radijus/raspon senzora.

3. Morat ćemo se osloniti na reakciju korisnika.

4. Naš sistem je izgrađen pomoću nekoliko platformi (Google kalendar, Gmail, Zapier itd.) I morat će koristiti njihovu uslugu za izvođenje.

5. Skaliranje ove usluge za više prostorija (umjesto dupliciranja cijelog sistema) zahtijevat će dodatno rukovanje s ID -om sobe.

6. Sustav je samo automatski i ne postoji ručna opcija za otkazivanje rezervacije sobe.

BUDUĆI RAZVOJ:

Definitivno bismo povećali sistem na dva načina:

1. Sposobnost rada sa bilo kojim drugim kalendarskim platformama (tako da ga može koristiti bilo koja kompanija za radne prostore).

2. Sposobnost rukovanja s više soba, podova i lokacija.

Vjerujemo da će ovoj vrsti ljestvice trebati 2-3 mjeseca za generalizaciju, testiranje i dodavanje više prostorija (spratova itd.).

Osim toga, koristeći neograničenu količinu novca i resursa, koristili bismo bolje senzore s većim rasponom, zajedno s prilagođavanjem prema određenoj prostoriji - uzimajući u obzir domet, radijus, količinu senzora itd. Korak koji bi svaki instalacijski sustav produžio, očigledno.