IDC2018IOT: Snitcher u sobi za sastanke: 6 koraka

2024 Autor: John Day | [email protected]. Zadnja promjena: 2024-01-30 09:36

PROBLEM

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

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

Problem se ponovno javlja jer raspored ljudi ima tendenciju biti dinamičan.

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

Čak i ako netko na kraju ne bi iskoristio taj vremenski okvir, neće se potruditi obavijestiti i otkazati ga 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 stvarno zauzeta ili nije:

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

2. Ako je rezervirano, provjerite postoje li pokreti ili zvuk;

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 bit će promijenjen 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 korištenje softvera i poslužitelja, osim koda u Arduinu, koristili smo Google Script i Zapier za podršku našem sustavu na mreži. Tok možete vidjeti na dodanoj slici (i PDF -u).

Koristili smo Zapier za povezivanje aplikacija i automatiziranje svojih tijekova rada (poput IFTTT -a), a za komunikaciju s Google kalendarom koristili smo Google Script. Skripta koju smo napisali proizvodi e -poruku tvorca događaja kako bismo je mogli poslati. Zapier je provjerio je li korisnik tražio da zadrži sobu (spremanjem nekih podataka u Google tablice) prije brisanja događaja.

Korak 2: Spojite mikrofon i PIR senzor

Željeli 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 ispitivanja 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 najtočniju razinu osjetljivosti u prostoriji 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: Stvorite tijek rada u Zapieru

Kako bismo znali je li soba doista 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 aktivira 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 SAMO AKO

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

(4) RADNJA - GMAILZapier šalje e -poruku putem Gmaila korisniku koji je rezervirao sobu (ove je informacije dobio u 2. koraku)

(5) RADNJA - ODLAGANJE Omogućite korisniku vrijeme da odgovori na e -poruku.- Ako korisnik klikne na vezu: nazovite (pokrenite) GoogleScript - ApproveCurrentEvent (Stoga je soba uklonjena s popisa 'Sobe za brisanje', a soba je još uvijek 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 popisu 'Sobe za brisanje'

samo uklanja događaj.

Korak 4: Google skripte

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

(1) GetCurrentEmailEventID

Pokreće se Webhook pozivom.

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

(2) OdobriCurrentEvent

Pokreće se klikom korisnika.

U slučaju korisnikova 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 popisa.

(3) DeleteCurrentEvent

Pokreće se Webhook pozivom.

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 sustav (u našem slučaju Google kalendar). 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žavni stroj uzimajući u obzir svaki mogući slučaj, tako da se neće dogoditi pogreška, a soba će biti postavljena kao dostupna samo kad 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 bilo jednostavno shvatiti) poslati poruku koja pruža mogućnost da zadrži sobu.

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

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

NAŠA OGRANIČENJA SUSTAVA:

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š sustav izgrađen je pomoću nekoliko platformi (Google kalendar, Gmail, Zapier itd.) I za rad će morati koristiti njihovu uslugu.

5. Skaliranje ove usluge za više soba (umjesto dupliciranja cijelog sustava) 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:

Sigurno bismo povećali sustav na dva načina:

1. Sposobnost rada s bilo kojim drugim kalendarskim platformama (tako da ga može koristiti svaka tvrtka za suradničke prostore).

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

Vjerujemo da će ovoj vrsti ljestvice trebati 2-3 mjeseca da se generalizira, testira i doda više značajki prostorija (katova itd.).

Osim toga, korištenjem neograničene količine novca i resursa koristili bismo bolje senzore s većim rasponom, zajedno s prilagođavanjem prema određenoj prostoriji - uzimajući u obzir raspon, radijus, količinu senzora itd. Korak koji bi svaki instalacijski sustav učinio duljim, očito.