IDC2018IOT: Susitikimų kambarys „Snitcher“: 6 žingsniai

2024 Autorius: John Day | [email protected]. Paskutinį kartą keistas: 2024-01-30 10:48

PROBLEMA

Kaip žinome, per pastaruosius kelerius metus bendrų darbo vietų tendencija spartėjo, o pažangiausios technologijos apibrėžia konkrečios jūsų poreikius atitinkančios bendro darbo erdvės pasirinkimą.

Viena iš pagrindinių siūlomų funkcijų yra bendros darbo erdvės nariams siūlomos bendros posėdžių salės, kurias valdo (paprastai) paprasta kalendoriaus platforma.

Problema kartojasi, nes žmonių tvarkaraštis paprastai būna dinamiškas.

Galima užsisakyti kambarį manant, kad jam to gali prireikti ir nenorėti praleisti laiko tarpo.

Net jei žmogus to laiko tarpo nesinaudotų, jis nesivargins apie tai pranešti ir atšaukti kitų labui, nes, deja, tai yra žmogaus prigimtis.

KAIP TAI SPRENDAME?

Naudodamiesi daiktų interneto technologija - tikrindami garsą ir judesį tam skirtoje posėdžių salėje, mes kiekvieną tam tikrą laiko tarpą tikriname, ar kambarys yra rezervuotas ir iš tikrųjų užimtas, ar ne:

1. Jei jis nėra užsakytas, nieko nedarykite.

2. Jei jis užsakytas, patikrinkite, ar nėra aptiktų judesių ar garso;

Jei yra, nieko nedaryk.

Jei nieko neaptiko, išsiųskite įspėjamąjį pranešimą (el. Paštu) kambarį užsisakiusiam vartotojui ir klauskite, ar kambarys vis dar naudojamas. nebent vartotojas pareikš, kad vis dar naudojasi kambariu, kambario būsena bus pakeista į „Galima“.

* Čia mes integravome savo projektą su „Google“kalendoriumi, kad kuo labiau jį apibendrintume.

1 veiksmas: reikalinga aparatūra ir protokolai

1. Mes naudojome NOSEMCU, kad galėtume dinamiškai atnaujinti dalykus naudodami WIFI ryšį.

2. Mikrofono jutiklis, kuris „perskaitys“triukšmą patalpoje.

3. PIR jutiklis, kuris patikrins, ar nėra judesių.

Naudodami programinę įrangą ir serverį, be „Arduino“kodo, mes naudojome „Google Script“ir „Zapier“, kad palaikytume savo sistemą internete. Srautą galite pamatyti pridėtame paveikslėlyje (ir PDF).

Mes naudojome „Zapier“, kad sujungtume programas ir automatizuotume darbo eigą (pvz., IFTTT), o „Google Script“padėjome mums bendrauti su „Google“kalendoriumi. Mūsų parašytas scenarijus sukuria įvykio kūrėjo el. Laišką, kad galėtume jį išsiųsti, nusiųsdamas „Zapier“ir patikrins, ar naudotojas paprašė sulaikyti kambarį (išsaugodamas tam tikrą informaciją „Google“skaičiuoklėse) prieš ištrindamas įvykį.

2 veiksmas: prijunkite mikrofoną ir PIR jutiklį

Mes norėjome patikrinti vidutines vertes, kurias mikrofonas skelbia NODEMCU, kai žmonės kalba (aišku, kiekviename kambaryje buvo skirtingi foniniai garsai). Mes atlikome keletą bandymų ir supratome, kad vidutinis triukšmo lygis yra tas, kuriame mes dirbome, kažkur virš 50.

PIR jutiklis pateikia tik HIGH arba LOW reikšmes, todėl tikrinome tik tą jautrumo lygį, kuris yra tiksliausias mūsų patikrintam kambariui. Šis vadovas buvo gana naudingas.

MŪSŲ JUNGTYS:

Mikrofonas - kaip paveikslėlyje PIR jutiklis: GND> GND, OUT> D7, VCC> VN (5V)

3 veiksmas: sukurkite darbo eigą „Zapier“

Norėdami sužinoti, ar patalpa iš tikrųjų tuščia, ar vis dar naudojama (ir, pavyzdžiui, vartotojai yra pertraukoje), norėtume sukurti tai užtikrinantį srautą iškart po to, kai „NodeMCU“suaktyvina „Webhook“į „Zapier“ir praneša, kad kambarys tuščias:

(1) TRIGGER - CATCH HOOK „Zapier“sugauna „Webhook“(kurį atsiųs NODEMCU)

(2) VEIKSMAS - „GETZapier“siunčia kitą „Webhook“, kad gautų įvykio duomenis;

(3) FILTRAS - TIK TĘSTI, JEI

Tęskite kitą veiksmą tik tuo atveju, jei kalendoriuje šiuo metu įvyksta įvykis (bet koks įvykis) (KAMBARIS UŽIMTAS), kitaip sustoja, nes kambarys yra laisvas.

(4) VEIKSMAS - „GMAILZapier“siunčia el. Laišką per „Gmail“kambarį užsisakiusiam vartotojui (šią informaciją gavo 2 veiksme)

(5) VEIKSMAS - LAIKYMAS Leiskite vartotojui atsakyti į el. Laišką. - Jei naudotojas spustelės nuorodą: paskambinkite (paleiskite) „GoogleScript“- ApproveCurrentEvent (Taigi kambarys pašalinamas iš sąrašo „Patalpos, kurias reikia ištrinti“, ir kambarys vis dar pažymėtas kaip užimtas.)

(6) VEIKSMAS - GET Po 5 minučių Zapier skambina (paleidžia) „GoogleScript“- DeleteCurrentEvent- Jei naudotojas nepaspaudė nuorodos

Patikrina, ar kambario ID yra sąraše „Patalpos, kurias reikia ištrinti“

tai tik pašalina įvykį.

4 veiksmas: „Google“scenarijai

Integruodami visą sistemą, „GoogleScripts“buvo nereikšmingas IDE pasirinkimas, todėl naudojome atitinkamas „Google“bibliotekas. Pakeistų pagal kambarių rezervavimo platformą.

(1) „GetCurrentEmailEventID“

Veikia pagal „Webhook“skambutį.

Naudojant tam tikrą poslinkį, kad būtų išvengta galimo atšaukimo atšaukimo, gaunami dabartinių įvykių duomenys.

(2) „ApproveCurrentEvent“

Veikia naudotojo paspaudimu.

Jei vartotojas patvirtina, kad patalpa vis dar naudojama, ištrina įvykio ID iš „Ištrinamų kambarių“. Mes naudojome „Google“lapą, bet kokia kita sąrašo forma čia gali būti aktuali.

(3) DeleteCurrentEvent

Veikia „Webhook“skambučiu.

Sąraše („Google“lape) ieško atitinkamo įvykio ID ir ištrina tą įvykį iš kalendoriaus.

5 veiksmas: prijunkite srautą naudodami „Arduino“kodą

Pridėtas kodas prisijungia prie jutiklių, kuriuos prieš keletą žingsnių patikrinome prie internetinės sistemos (mūsų atveju „Google“kalendorius). Jis patikrina, ar kambarys yra užimtas, o jei ne, siunčia HTTP užklausą („Webhook“), kuri paleidžia „Zapier“įvykio ištrynimo užklausą.

6 žingsnis: peržiūra, išvados ir būsimas mastelio keitimas

Pagrindinis iššūkis, su kuriuo teko susidurti, yra visų svarbiausių atvejų sprendimas, kai nusprendžiama atlaisvinti posėdžių salę. Tada turėjome sukurti būsenos mašiną, atsižvelgdami į visus galimus atvejus, kad klaida neįvyktų ir patalpa būtų nustatyta kaip prieinama tik tada, kai turėtų.

Pvz., Jei kambarys užsakytas grupei, kurios šiuo metu nėra (pavyzdžiui, pertraukoje), bet vis tiek to reikia, NODEMCU aptiks, kad kambarys yra laisvas> PROBLEMA.

Tada mūsų sprendimas buvo išsiųsti kambarį užsisakiusiam vartotojui el. Laišką (o tai buvo ne taip paprasta išsiaiškinti).

Jei vartotojas per tam tikrą laiką neatsakė (nustatėme, kad tai yra 5 minutės, tačiau jį galima lengvai pakeisti), įvykį ištriname iš kalendoriaus (ir atlaisviname kambarį).

Tokiu būdu mums galiausiai pavyko išspręsti visus galimus scenarijus ir sukurti veikiančią sistemą.

MŪSŲ SISTEMOS APRIBOJIMAI:

1. Naudojami jutikliai turi būti labai tikslūs ir jautrūs.

2. Kambario dydis apribotas jutiklio spinduliu/diapazonu.

3. Turėsime pasikliauti vartotojo atsaku.

4. Mūsų sistema sukurta naudojant kelias platformas („Google“kalendorių, „Gmail“, „Zapier“ir kt.) Ir turės atlikti savo paslaugas.

5. Šios paslaugos mastelio keitimui keliuose kambariuose (vietoj visos sistemos dubliavimo) reikės papildomai tvarkyti nurodant kambario ID.

6. Sistema yra tik automatinė ir nėra rankinio varianto atšaukti kambario užsakymą.

ATEITIES PLĖTRA:

Mes tikrai padidintume sistemą dviem būdais:

1. Galimybė dirbti su bet kuriomis kitomis kalendorinėmis platformomis (taigi bet kuri bendradarbiaujančių erdvių įmonė galėtų ja naudotis).

2. Gebėjimas tvarkyti kelis kambarius, aukštus ir svetaines.

Manome, kad tokio masto apibendrinimas, išbandymas ir kelių kambarių (aukštų ir pan.) Funkcijos užtruks 2-3 mėnesius.

Be to, naudodami neribotą pinigų sumą ir išteklius, mes naudojame geresnius jutiklius, turinčius didesnį diapazoną, ir pritaikome juos pagal paskirtį - atsižvelgiant į diapazoną, spindulį, jutiklių kiekį ir tt. aišku.