IDC2018IOT: Sekač v sejni sobi: 6 korakov

2024 Avtor: John Day | [email protected]. Nazadnje spremenjeno: 2024-01-30 12:07

TEŽAVA

Kot vemo, se trend sodelovalnih prostorov v zadnjih nekaj letih pospešuje, skupaj z najsodobnejšo tehnologijo, ki opredeljuje izbiro posebnega delovnega prostora, ki ustreza vašim potrebam.

Ena glavnih ponujenih funkcij so skupne sejne sobe, ki so na voljo članom prostora za sodelovanje, ki jih upravlja (običajno) preprosta koledarska platforma.

Težava se znova pojavi, saj je urnik ljudi dinamičen.

Lahko bi rezervirali sobo, misleč, da jo bo potreboval, in ne bi želel zamuditi časovnega razporeda.

Tudi če sčasoma tega časovnega razporeda ne bi uporabili, se ne bo potrudil, da ga obvesti in prekliče zaradi drugih, saj je to žal človeška narava.

KAKO TO REŠIMO?

S tehnologijo IoT - preverjanje zvoka in gibanja v določeni sejni sobi, v vsakem določenem časovnem intervalu preverjamo, ali je soba rezervirana in dejansko zasedena ali ne:

1. Če ni rezervirano, ne storite ničesar.

2. Če je rezervirano, preverite, ali je zaznano gibanje ali zvok;

Če obstaja, ne storite ničesar.

Če ni bilo zaznanega ničesar, pošljite opozorilo (po e -pošti) uporabniku, ki je rezerviral sobo, da vpraša, ali je soba še v uporabi. razen če uporabnik izjavi, da še vedno uporablja sobo, se bo stanje sobe spremenilo v »Na voljo«.

* Tu smo svoj projekt integrirali z Google Koledarjem, da bi ga čim bolj posplošili.

1. korak: potrebna strojna oprema in protokoli

1. Uporabili smo NOSEMCU, da smo lahko s povezavo WIFI dinamično posodabljali stvari.

2. Senzor mikrofona, ki bo "prebral" hrup v prostoru.

3. PIR senzor, ki bo preveril, ali se premika.

Za uporabo programske opreme in strežnika smo poleg kode v Arduinu uporabljali Google Script in Zapier za podporo našega sistema na spletu. Tok lahko vidite na dodani sliki (in PDF).

Za povezovanje aplikacij in avtomatizacijo delovnih tokov (na primer IFTTT) smo uporabili Zapier, za komunikacijo z Google Koledarjem pa Google Script. Scenarij, ki smo ga napisali, ustvarja e -poštno sporočilo ustvarjalca dogodka, da ga lahko pošljemo. Zapier je vrgel in preveri, ali je uporabnik pred brisanjem dogodka prosil, naj zadrži sobo (tako, da shrani nekaj podatkov v Google Preglednicah).

Korak: Priključite mikrofon in senzor PIR

Želeli smo preveriti povprečne vrednosti, ki jih mikrofon posreduje NODEMCU, ko se ljudje pogovarjajo (očitno je bilo v vsaki sobi drugačen zvok v ozadju). Nekaj smo testirali in ugotovili, da je povprečna raven hrupa v prostoru, v katerem smo delali, nekje nad 50.

Senzor PIR podaja le vrednosti VISI ali NIZKI, zato smo preverili samo raven občutljivosti, ki je najbolj natančna za prostor, ki smo ga preverili. Ta priročnik je bil zelo v pomoč.

NAŠE VEZE:

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

3. korak: Ustvarite potek dela v Zapierju

Da bi vedeli, ali je soba dejansko prazna ali je še vedno v uporabi (uporabniki so na primer na odmoru), bi radi ustvarili tok, ki to zagotavlja, takoj po tem, ko NodeMCU sproži Webhook v Zapier, ki obvesti, da soba je prazna:

(1) TRIGGER - COTCH HOOK Zapier ujame Webhook (ki ga bo poslal NODEMCU)

(2) DELOVANJE - GETZapier pošlje drug Webhook, da pridobi podatke o dogodku;> Pokliče (zažene) GoogleScript - GetCurrentEmailEventID (razlaga v naslednjem koraku), da dobi podatke o trenutnem dogodku - ime dogodka, ID dogodka, e -poštni naslov uporabnika.

(3) FILTER - NADALJUJTE SAMO ČE

Nadaljujte z naslednjim korakom le, če se na koledarju trenutno dogaja dogodek (kateri koli dogodek) (ROOM IS BUSY), sicer se ustavi, ko je soba prazna.

(4) UKREP - GMAILZapier preko Gmaila pošlje e -pošto uporabniku, ki je rezerviral sobo (te podatke je dobil v 2. koraku)

(5) UKREP - ZAKASNITEV FOR Pustite uporabniku čas, da odgovori na e -poštno sporočilo. - Če uporabnik klikne povezavo: pokličite (zaženite) GoogleScript - ApproveCurrentEvent (zato je soba odstranjena s seznama 'Sobe za brisanje' in soba je še vedno označena kot zasedena.)

(6) AKCIJA - DOBI Po 5 minutah Zapier pokliče (zažene) GoogleScript - DeleteCurrentEvent- Če uporabnik ni kliknil na povezavo

Preveri, če je ID sobe na seznamu 'Sobe za brisanje'

samo odstrani dogodek.

4. korak: Google Scripts

Ker smo integrirali celoten sistem, je bil GoogleScripts nepomembna izbira IDE, zato smo uporabili ustrezne Googlove knjižnice. Spremenilo bi se v skladu s platformo za rezervacijo sob.

(1) GetCurrentEmailEventID

Deluje s klicem Webhook.

Uporaba določenega odmika za odpravo morebitnega preklica napake in pridobivanje podatkov o trenutnem dogodku.

(2) OdobriCurrentEvent

Deluje s klikom uporabnika.

Če uporabnik odobri, da je soba še vedno v uporabi, izbriše ID dogodka iz »Sobe za brisanje«. Uporabili smo Googlov list, tukaj bi lahko bila pomembna katera koli druga oblika seznama.

(3) DeleteCurrentEvent

Deluje s klicem Webhook.

Na seznamu (Googlov list) poišče ustrezen ID dogodka in ga izbriše iz koledarja.

5. korak: Povežite tok s kodo Arduino

Priložena koda se poveže s senzorji, ki smo jih pred nekaj koraki preverili, v spletni sistem (v našem primeru Googlov koledar). Preveri, ali je soba zasedena, nato pa, če ni, pošlje zahtevo HTTP (Webhook), ki zažene zahtevo za izbris dogodka na Zapierju.

6. korak: Pregled, zaključki in prilagajanje prihodnosti

Glavni izziv, s katerim smo se morali spopasti, je pokriti vse robne primere, ko smo se odločali za sprostitev sejne sobe. Nato smo morali ustvariti državni stroj, ki je upošteval vse možne primere, tako da ne bo prišlo do napake in bo soba nastavljena kot razpoložljiva le takrat, ko bi morala.

Na primer, če je soba rezervirana za neko skupino, ki je trenutno ni (na primer na odmoru), a jo še vedno potrebuje, bo NODEMCU zaznal, da je soba prosta> PROBLEM.

Potem je bila naša rešitev, da uporabniku, ki je rezerviral sobo (kar ni bilo enostavno ugotoviti), pošljemo e -poštno sporočilo, ki ponuja možnost, da še naprej zadržuje sobo.

Če uporabnik v določenem času ni odgovoril (nastavili smo ga na 5 minut, vendar ga je mogoče enostavno spremeniti), dogodek izbrišemo iz koledarja (in osvobodimo sobo).

Tako smo na koncu uspeli obvladati vse možne scenarije in ustvariti delujoč sistem.

NAŠE OMEJITVE SISTEMA:

1. Uporabljeni senzorji morajo biti zelo natančni in občutljivi.

2. Velikost sobe je omejena na polmer/območje tipala.

3. Zanašati se bomo morali na odzivnost uporabnikov.

4. Naš sistem je zgrajen na več platformah (Googlov koledar, Gmail, Zapier itd.) In bo za izvajanje moral uporabiti njihovo storitev.

5. Za povečanje obsega te storitve za več sob (namesto podvajanja celotnega sistema) bo potrebno dodatno ravnanje z ID -jem sobe.

6. Sistem je samo samodejen in ni možnosti ročnega preklica rezervacije sobe.

PRIHODNI RAZVOJ:

Vsekakor bi sistem povečali na dva načina:

1. Sposobnost dela s katero koli drugo koledarsko platformo (tako bi jo lahko uporabljalo katero koli podjetje za delovne prostore).

2. Sposobnost upravljanja več sob, nadstropij in mest.

Verjamemo, da bodo takšne lestvice potrebovale 2-3 mesece za posplošitev, preizkus in dodajanje več prostorov (nadstropij itd.).

Poleg tega bi z neomejeno količino denarja in virov uporabili boljše senzorje z večjim razponom, skupaj s prilagoditvijo za določeno sobo - glede na doseg, polmer, količino senzorjev itd. očitno.