IDC2018IOT: koosolekuruum Snitcher: 6 sammu

2024 Autor: John Day | [email protected]. Viimati modifitseeritud: 2024-01-30 08:49

PROBLEEM

Nagu me teame, on ühistööruumide suundumus viimastel aastatel kiirenenud ning tipptasemel tehnoloogia määrab teie vajadustele vastava konkreetse koostööruumi valiku.

Üks peamisi pakutavaid funktsioone on jagatud koosolekuruumid, mida pakutakse koostööruumi liikmetele, mida haldab (tavaliselt) lihtne kalendriplatvorm.

Probleem kordub, kuna inimeste ajakava kipub olema dünaamiline.

Võiks broneerida toa, arvates, et tal võib seda vaja minna ja ta ei tahaks ajavahemikust ilma jääda.

Isegi kui keegi seda ajavahemikku lõpuks ei kasutaks, ei viitsi ta seda teiste huvides teavitada ja tühistada, kuna see on kahjuks inimloomus.

KUIDAS ME seda lahendame?

Kasutades asjade Interneti -tehnoloogiat - kontrollides heli ja liikumist määratud koosolekuruumis, kontrollime iga teatud ajavahemiku järel, kas ruum on broneeritud ja tegelikult hõivatud või mitte:

1. Kui see pole broneeritud, ära tee midagi.

2. Kui see on broneeritud, kontrollige, kas on tuvastatud liikumist või heli;

Kui on, siis ära tee midagi.

Kui midagi ei tuvastatud, saatke ruumi broneerinud kasutajale hoiatusteade (e -posti teel), kus küsitakse, kas tuba on endiselt kasutusel. välja arvatud juhul, kui kasutaja teatab, et kasutab ruumi endiselt, muudetakse ruumi olekuks „Saadaval”.

* Siin lõime oma projekti Google'i kalendriga, et seda võimalikult üldistada.

Samm: vajalik riistvara ja protokollid

1. Kasutasime NOSEMCU -d, et saaksime WIFI -ühendust kasutades asju dünaamiliselt värskendada.

2. Mikrofoni andur, mis "loeb" ruumis müra.

3. PIR -andur, mis kontrollib liikumist.

Tarkvara ja serveri kasutamiseks kasutasime lisaks Arduino koodile ka meie süsteemi veebis toetamiseks Google Scripti ja Zapieri. Näete voogu lisatud pildil (ja PDF -is).

Rakenduste ühendamiseks ja töövoogude automatiseerimiseks (nt IFTTT) kasutasime Zapieri ja Google'i kalendriga suhtlemiseks Google Scripti. Meie kirjutatud skript toodab sündmuse looja e -kirja, et saaksime selle saata, saatis Zapieri ja kontrollis, kas kasutaja palus enne sündmuse kustutamist ruumi hoida (salvestades teatud teabe Google'i arvutustabelitesse).

Samm: ühendage mikrofon ja PIR -andur

Tahtsime kontrollida keskmisi väärtusi, mida mikrofon postitab NODEMCU -le, kui inimesed räägivad (selgelt oli igas toas erinev taustamüra). Tegime mõningaid katseid ja saime aru, et keskmine müratase on ruum, kus me töötasime, kuskil üle 50.

PIR -andur annab ainult HIGH või LOW väärtusi, nii et kontrollisime ainult seda tundlikkuse taset, mis on meie kontrollitud ruumi suhtes kõige täpsem. See juhend oli üsna kasulik.

MEIE ÜHENDUSED:

Mikrofon - nagu pildil PIR -andur: GND> GND, OUT> D7, VCC> VN (5V)

Samm: looge Zapieris töövoog

Et teada saada, kas ruum on tegelikult tühi või on endiselt kasutusel (ja kasutajad on näiteks puhkepausil), soovime luua selle tagava voo kohe pärast seda, kui NodeMCU käivitab Zapieri Webhooki, mis teatab, et tuba on tühi:

(1) TRIGGER - CATCH HOOKZapier püüab veebihaaki (mille saadab NODEMCU)

(2) ACTION - GETZapier saadab sündmuse andmete saamiseks teise Webhooki;> See kutsub (käivitab) GoogleScripti - GetCurrentEmailEventID (selgitus järgmises etapis), et saada praeguste sündmuste andmed - sündmuse nimi, sündmuse ID, kasutaja e -post.

(3) FILTER - JÄTKAKSE AINULT KUI

Jätkake järgmise sammuga ainult siis, kui kalendris on praegu mõni sündmus (mis tahes sündmus) (ROOM IS BUSY), vastasel juhul peatub, kuna ruum on vaba.

(4) TOIMING - GMAILZapier saadab toa broneerinud kasutajale Gmaili kaudu e -kirja (selle teabe sai 2. juhises)

(5) TEGEVUS - VIIVITAMINE Lase kasutajal meilile vastamiseks aega. - Kui kasutaja klõpsab lingil: helistage (käivitage) GoogleScript - ApproveCurrentEvent (Seega ruum eemaldatakse loendist „Kustutatavad ruumid” ja tuba on endiselt hõivatud.)

(6) ACTION - GET 5 minuti pärast Zapier helistab (käivitab) GoogleScripti - DeleteCurrentEvent- Kui kasutaja ei klõpsanud lingil

Kontrollib, kas ruumi ID on loendis „Kustutatavad ruumid”

see lihtsalt eemaldab sündmuse.

Samm: Google'i skriptid

Kogu süsteemi integreerimisel oli GoogleScripts IDE triviaalne valik, seega kasutasime asjakohaseid Google'i teeke. Muutuks vastavalt tubade broneerimise platvormile.

(1) GetCurrentEmailEventID

Käivitab Webhooki kõne.

Teatud nihke kasutamine võimalike tühistamiste kõrvaldamiseks, praeguste sündmuste andmete hankimine.

(2) ApproveCurrentEvent

Töötab kasutaja klõpsuga.

Kui kasutaja kinnitab, et ruum on endiselt kasutusel, kustutab sündmuse ID väljast „Kustutatavad ruumid”. Kasutasime Google'i lehte, mis tahes muu loendi vorm võib siin asjakohane olla.

(3) DeleteCurrentEvent

Käivitab Webhooki kõne.

Otsib loendist (Google'i leht) asjakohase sündmuse ID ja kustutab selle sündmuse kalendrist.

Samm: ühendage voog Arduino koodiga

Lisatud kood ühendub anduritega, mida paar sammu tagasi kontrollisime võrgusüsteemiga (meie puhul Google'i kalender). See kontrollib, kas ruum on hõivatud, ja kui see pole nii, saadab see HTTP -päringu (Webhook), mis käivitab Zapieri kustutussündmuse taotluse.

6. samm: ülevaade, järeldused ja edasine skaleerimine

Peamine väljakutse, millega pidime tegelema, on koosolekuruumi vabastamise otsustamisel kõigi eelisjuhtumite katmine. Seejärel pidime looma olekumasina, arvestades kõiki võimalikke juhtumeid, nii et viga ei teki ja ruum seatakse kättesaadavaks ainult siis, kui peaks.

Näiteks kui ruum on broneeritud mõnele grupile, kes pole hetkel kohal (näiteks puhkepausil), kuid vajab seda siiski, tuvastab NODEMCU, et ruum on vaba> PROBLEEM.

Seejärel oli meie lahendus e -postiga ruumi broneerinud kasutajale (mida polnud lihtne välja selgitada) saata meili, mis annab võimaluse ruumi hoida.

Kui kasutaja ei vastanud teatud aja jooksul (seadsime selle 5 minutiks, kuid seda saab hõlpsasti muuta), kustutame sündmuse kalendrist (ja vabastame ruumi).

Nii õnnestus meil lõpuks käsitleda kõiki võimalikke stsenaariume ja luua toimiv süsteem.

MEIE SÜSTEEMI PIIRANGUD:

1. Kasutatavad andurid peavad olema väga täpsed ja tundlikud.

2. Ruumi suurus on piiratud anduri raadiusega/vahemikuga.

3. Peame lootma kasutajate reageerimisvõimele.

4. Meie süsteem on üles ehitatud mitut platvormi kasutades (Google'i kalender, Gmail, Zapier jne) ja peab selle toimimiseks kasutama nende teenust.

5. Selle teenuse skaleerimine mitme ruumi jaoks (kogu süsteemi dubleerimise asemel) nõuab ruumi ID -ga täiendavat käsitsemist.

6. Süsteem on ainult automaatne ja toa broneerimise tühistamiseks pole käsitsi valikut.

TULEVASED ARENGUD:

Kindlasti suurendaksime süsteemi kahel viisil:

1. Võimalus töötada mis tahes muude kalendriplatvormidega (nii et iga kaastööruumide ettevõte saaks seda kasutada).

2. Võimalus käsitleda mitut tuba, korrust ja saiti.

Usume, et sellise mõõtkava üldistamiseks, testimiseks ja mitme ruumi (korruse jne) funktsiooni lisamiseks kulub 2-3 kuud.

Lisaks kasutaksime piiramatul hulgal raha ja ressursse paremaid ja suurema ulatusega andureid ning kohandaksime need vastavalt määratud ruumile - võttes arvesse ulatust, raadiust, andurite kogust jne. Samm, mis pikendaks iga süsteemi paigaldamist, ilmselgelt.