IDC2018IOT: Találkozóterem Snitcher: 6 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:42

A PROBLÉMA

Mint tudjuk, az együttműködési terek trendje az elmúlt években felgyorsult, a legmodernebb technológiával együtt, amely meghatározza az Ön igényeinek megfelelő együttműködési tér kiválasztását.

Az egyik fő szolgáltatás a közös tárgyalótermek, amelyeket a közös munkaterület tagjainak kínálnak, és amelyeket egy (általában) egyszerű naptárplatform kezel.

A probléma ismétlődik, mivel az emberek ütemezése általában dinamikus.

Lefoglalhat egy szobát, és azt gondolhatja, hogy szüksége lehet rá, és nem akar lemaradni az időrésről.

Még ha az ember végül nem is használná ezt az időrést, nem törődik azzal, hogy mások érdekében értesítse és törölje, mivel sajnos ez az emberi természet.

HOGYAN MEGOLDJUK?

Az IoT technológia segítségével - a hang és a mozgás ellenőrzése egy kijelölt tárgyalóteremben - bizonyos időközönként ellenőrizzük, hogy egy szoba le van -e foglalva és ténylegesen foglalt -e:

1. Ha nincs lefoglalva, ne tegyen semmit.

2. Ha le van foglalva, ellenőrizze, hogy nem észlel -e mozgást vagy hangot;

Ha van, ne tegyen semmit.

Ha nem észlel semmit, küldjön figyelmeztető üzenetet (e -mailben) annak a felhasználónak, aki lefoglalta a szobát, és megkérdezi, hogy a szoba még használatban van -e. hacsak a felhasználó nem nyilatkozik arról, hogy továbbra is használja a szobát, a szoba állapota „Elérhető” -re változik.

* Itt integráltuk a projektünket a Google Naptárba, hogy a lehető legnagyobb mértékben általánosítsuk.

1. lépés: Szükséges hardver és protokollok

1. A NOSEMCU -t használtuk, hogy a WIFI kapcsolat használatával dinamikusan frissíthessük a dolgokat.

2. Mikrofon érzékelő, amely "leolvassa" a helyiség zaját.

3. PIR érzékelő, amely ellenőrzi, hogy nincs -e mozgás.

A szoftver és a szerver használatához az Arduino kódon kívül a Google Scriptet és a Zapier -t használtuk rendszerünk online támogatására. A folyamatot a hozzáadott képen (és PDF -ben) láthatja.

A Zapier -t használtuk az alkalmazások összekapcsolására és a munkafolyamatok automatizálására (például IFTTT), és a Google Scriptet használtuk a Google Naptárral való kommunikációhoz. Az általunk írt szkript az esemény készítőjének e -mailjét állítja elő, így elküldhetjük Zapier -nek, és ellenőrzi, hogy a felhasználó kérte -e a szoba megtartását (néhány információ mentésével a Google Táblázatokban) az esemény törlése előtt.

2. lépés: Csatlakoztassa a mikrofont és a PIR érzékelőt

Szerettük volna ellenőrizni a mikrofon által a NODEMCU -hoz küldött átlagos értékeket, amikor az emberek beszélnek (egyértelmű, hogy minden szobában más és más háttérzaj volt). Végeztünk néhány tesztet, és rájöttünk, hogy az átlagos zajszint az a helyiség, ahol dolgoztunk, valahol 50 felett van.

A PIR érzékelő csak HIGH vagy LOW értékeket ad meg, ezért csak azt az érzékenységi szintet ellenőriztük, amely a legpontosabb a helyiséghez, amelyet ellenőriztünk. Ez az útmutató nagyon hasznos volt.

CSATLAKOZÁSAINK:

Mikrofon - mint a képen PIR érzékelő: GND> GND, OUT> D7, VCC> VN (5V)

3. lépés: Hozza létre a munkafolyamatot a Zapier alkalmazásban

Annak érdekében, hogy megtudjuk, hogy a szoba valóban üres vagy még mindig használatban van (és például a felhasználók szünetben vannak), szeretnénk létrehozni egy folyamatot, amely biztosítja ezt, közvetlenül azután, hogy a NodeMCU elindítja a Webhook -ot a Zapier -hez, amely értesíti, hogy a a szoba üres:

(1) TRIGGER - CATCH HOOKZapier elkapja a Webhook -ot (amelyet a NODEMCU küld)

(2) ACTION - A GETZapier egy másik Webhook -ot küld az eseményadatok lekéréséhez;> Meghívja (futtatja) a GoogleScriptet - GetCurrentEmailEventID (magyarázat a következő lépésben), hogy megkapja az aktuális eseményadatokat - esemény nevét, eseményazonosítóját, felhasználói e -mail címét.

(3) SZŰRŐ - CSAK FOLYTATJA HA

Csak akkor folytassa a következő lépéssel, ha éppen van esemény (bármilyen esemény) a naptárban (SZOBA EL foglalt), ellenkező esetben leáll, mivel a szoba üres.

(4) AKCIÓ - A GMAILZapier e -mailt küld a Gmailben a szobát lefoglaló felhasználónak (ezeket az információkat a 2. lépésben kapta meg)

(5) AKCIÓ - KÉSLELTETÉS Hagyja a felhasználónak, hogy válaszoljon az e -mailre. - Ha a felhasználó rákattint a linkre: hívja (futtassa) a GoogleScriptet - ApproveCurrentEvent (Ezért a szobát eltávolítjuk a „Törlendő szobák” listából, és a szoba továbbra is foglaltnak van jelölve.)

(6) ACTION - GET 5 perc elteltével Zapier hívja (futtatja) a GoogleScriptet - DeleteCurrentEvent- Ha a felhasználó nem kattintott a linkre

Ellenőrzi, hogy a szobaazonosító szerepel -e a „Törlendő szobák” listában

csak eltávolítja az eseményt.

4. lépés: Google Scripts

Miközben integráltuk a teljes rendszert, a GoogleScripts volt az IDE triviális választása, így releváns Google Libraries -t használtunk. A szobafoglalási platformnak megfelelően változna.

(1) GetCurrentEmailEventID

Webhook hívással fut.

Egy bizonyos eltolás használata az esetleges kihagyás megszüntetése érdekében, az aktuális eseményadatok lekérése.

(2) ApproveCurrentEvent

Felhasználói kattintással fut.

Ha a felhasználó jóváhagyja, hogy a helyiség még használatban van, törli az eseményazonosítót a „Törlendő szobák” közül. Google lapot használtunk, a lista bármely más formája releváns lehet itt.

(3) DeleteCurrentEvent

Webhook hívással fut.

Keresi a megfelelő eseményazonosítót a listában (Google lap), és törli az eseményt a naptárból.

Lépés: Csatlakoztassa az áramlást az Arduino kóddal

A mellékelt kód azokhoz az érzékelőkhöz kapcsolódik, amelyeket néhány lépés előtt ellenőriztünk az online rendszerhez (esetünkben a Google naptárához). Ellenőrzi, hogy a szoba foglalt -e, majd ha nem, HTTP -kérést (Webhook) küld, amely elindítja a Zapier eseménykérési kérelmét.

6. lépés: Áttekintés, következtetések és jövőbeli skálázás

A fő kihívás, amellyel szembe kellett néznünk, az, hogy lefedjük az összes életszerű esetet, amikor a tárgyalóterem felszabadításáról döntünk. Ezt követően minden lehetséges esetet figyelembe véve létre kellett hoznunk egy állapotgépet, hogy hiba ne forduljon elő, és a helyiséget csak akkor állítsuk rendelkezésre állónak, amikor kell.

Például, ha a szobát olyan csoport számára foglalják le, amely jelenleg nincs ott (például szünetben), de mégis szüksége van rá, a NODEMCU észleli, hogy a szoba szabad> PROBLÉMA.

A megoldásunk az volt, hogy e -mailben küldtük el a szobát lefoglaló felhasználónak (amit nem volt egyszerű kitalálni) egy üzenetet, amely lehetőséget biztosít a szoba megtartására.

Ha a felhasználó adott időn belül nem válaszolt (5 percre állítottuk be, de könnyen megváltoztatható), akkor töröljük az eseményt a naptárból (és felszabadítjuk a szobát).

Így végül sikerült kezelnünk az összes lehetséges forgatókönyvet, és létre kellett hoznunk egy működő rendszert.

RENDSZERÜNK KORLÁTOZÁSAI:

1. A használt érzékelőknek nagyon pontosaknak és érzékenyeknek kell lenniük.

2. A helyiség mérete az érzékelő sugarára/tartományára korlátozódik.

3. Bíznunk kell a felhasználók válaszkészségében.

4. Rendszerünket több platform (Google naptár, Gmail, Zapier stb.) Felhasználásával építettük fel, és a szolgáltatásukat igénybe kell venniük.

5. Ennek a szolgáltatásnak a skálázása több helyiségre (a duplikálás helyett az egész rendszer) további kezelést igényel a szobazonosítóval.

6. A rendszer csak automatikus, és nincs manuális lehetőség a szobafoglalás visszavonására.

JÖVŐBENI FEJLESZTÉSEK:

Határozottan kétféleképpen bővítenénk a rendszert:

1. Képesség bármely más naptári platformmal való együttműködésre (így bármelyik közös munkaterületet használó cég használhatja).

2. Több szoba, emelet és helyszín kezelésének képessége.

Úgy véljük, hogy egy ilyen skála 2-3 hónapot vesz igénybe az általánosításhoz, teszteléshez és több helyiség (emelet stb.) Funkció hozzáadásához.

Ezenkívül korlátlan mennyiségű pénz és erőforrás felhasználásával jobb érzékelőket használnánk, nagyobb hatótávolsággal, valamint a kijelölt helyiséghez való testreszabással - figyelembe véve a hatótávolságot, a sugarat, az érzékelők mennyiségét stb. magától értetődően.