IDC2018IOT: Sanāksmju zāle Snitcher: 6 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:57

PROBLĒMA

Kā mēs zinām, kopdarbības telpu tendence pēdējos gados ir paātrinājusies, līdz ar progresīvām tehnoloģijām, kas nosaka jūsu vajadzībām atbilstošas kopstrādes telpas izvēli.

Viena no galvenajām piedāvātajām funkcijām ir koplietošanas sanāksmju telpas, kas tiek piedāvātas sadarbības telpas dalībniekiem, un to pārvalda (parasti) vienkārša kalendāra platforma.

Problēma atkārtojas, jo cilvēku grafiks mēdz būt dinamisks.

Varētu rezervēt istabu, domājot, ka viņam tas varētu būt vajadzīgs, un viņš nevēlas palaist garām laika nišu.

Pat ja kāds galu galā neizmantotu šo laika nišu, viņš neuztraucas to paziņot un atcelt citu dēļ, jo diemžēl tā ir cilvēka daba.

KĀ MĒS TO RISINĀM?

Izmantojot IoT tehnoloģiju - pārbaudot skaņu un kustību noteiktā sanāksmju telpā, mēs katrā noteiktā laika intervālā pārbaudām, vai telpa ir rezervēta un faktiski aizņemta:

1. Ja tas nav rezervēts, nedariet neko.

2. Ja tas ir rezervēts, pārbaudiet, vai nav konstatēta kustība vai skaņa;

Ja ir, nedariet neko.

Ja nekas netika atklāts, nosūtiet brīdinājuma ziņojumu (pa e -pastu) lietotājam, kurš rezervēja istabu, un jautā, vai istaba joprojām tiek izmantota. ja vien lietotājs nepaziņos, ka joprojām izmanto telpu, telpas statuss tiks mainīts uz “Pieejams”.

* Šeit mēs integrējām savu projektu ar Google kalendāru, lai to pēc iespējas vispārinātu.

1. darbība. Nepieciešama aparatūra un protokoli

1. Mēs izmantojām NOSEMCU, lai mēs varētu dinamiski atjaunināt lietas, izmantojot WIFI savienojumu.

2. Mikrofona sensors, kas "nolasīs" troksni telpā.

3. PIR sensors, kas pārbaudīs, vai nav kustību.

Programmatūras un servera lietošanai papildus kodam Arduino mēs izmantojām Google Script un Zapier, lai atbalstītu mūsu sistēmu tiešsaistē. Plūsmu varat redzēt pievienotajā attēlā (un PDF).

Mēs izmantojām Zapier, lai savienotu lietotnes un automatizētu mūsu darbplūsmas (piemēram, IFTTT), un mēs izmantojām Google skriptu, lai palīdzētu mums sazināties ar Google kalendāru. Mūsu rakstītais skripts veido notikuma veidotāja e -pastu, lai mēs varētu to nosūtīt, iemeta Zapjē un pirms notikuma dzēšanas pārbauda, vai lietotājs lūdza aizturēt telpu (saglabājot informāciju Google izklājlapās).

2. darbība: pievienojiet mikrofonu un PIR sensoru

Mēs vēlējāmies pārbaudīt vidējās vērtības, ko mikrofons ievieto NODEMCU, kad cilvēki runā (skaidri redzams, ka katrā telpā bija dažādi fona trokšņi). Mēs veicām dažus testus un sapratām, ka vidējais trokšņa līmenis telpā, kurā strādājām, ir kaut kur virs 50.

PIR sensors sniedz tikai HIGH vai LOW vērtības, tāpēc mēs pārbaudījām tikai to jutīguma līmeni, kas ir visprecīzākais pārbaudītajai telpai. Šī rokasgrāmata bija diezgan noderīga.

MŪSU SAVIENOJUMI:

Mikrofons - kā attēlā PIR sensors: GND> GND, OUT> D7, VCC> VN (5V)

3. darbība: izveidojiet darbplūsmu programmā Zapier

Lai uzzinātu, vai telpa patiešām ir tukša vai joprojām tiek izmantota (un, piemēram, lietotāji ir pārtraukumā), mēs vēlētos izveidot plūsmu, kas to nodrošina, tūlīt pēc tam, kad NodeMCU aktivizē Webhook uz Zapier, kas paziņo, ka istaba ir tukša:

(1) TRIGGER - CATCH HOOKZapier noķer Webhook (to nosūtīs NODEMCU)

(2) DARBĪBA - GETZapier nosūta citu Webhook, lai iegūtu notikuma datus;> Tas izsauc (palaiž) GoogleScript - GetCurrentEmailEventID (skaidrojums nākamajā solī), lai iegūtu pašreizējā notikuma datus - notikuma nosaukumu, notikuma ID, lietotāja e -pastu.

(3) FILTRS - TIKAI TURPINĀT, JA

Turpiniet nākamo darbību tikai tad, ja kalendārā pašlaik notiek kāds notikums (jebkurš notikums) (ISTABA IR aizņemta), pretējā gadījumā apstājas, jo istaba ir brīva.

(4) DARBĪBA - GMAILZapier nosūta e -pastu, izmantojot Gmail, lietotājam, kurš rezervējis istabu (šo informāciju ieguva 2. darbībā)

(5) DARBĪBA - AIZLIKŠANA Ļaujiet lietotājam laiku atbildēt uz e -pastu. - Ja lietotājs noklikšķina uz saites: zvaniet (palaidiet) GoogleScript - ApproveCurrentEvent (Līdz ar to istaba tiek noņemta no saraksta “Dzēšamās telpas” un istaba joprojām ir atzīmēta kā aizņemta.)

(6) DARBĪBA - GET Pēc 5 minūtēm Zapjers izsauc (palaiž) GoogleScript - DeleteCurrentEvent- Ja lietotājs nav noklikšķinājis uz saites

Pārbauda, vai istabas ID ir sarakstā “Dzēšamās telpas”

tas tikai noņem notikumu.

4. darbība. Google skripti

Integrējot visu sistēmu, GoogleScripts bija nenozīmīga IDE izvēle, tāpēc mēs izmantojām atbilstošas Google bibliotēkas. Mainītos atbilstoši numuru rezervēšanas platformai.

(1) GetCurrentEmailEventID

Darbojas ar Webhook zvanu.

Izmantojot noteiktu nobīdi, lai novērstu iespējamo atcelšanu, tiek iegūti pašreizējo notikumu dati.

(2) Apstiprināt pašreizējo notikumu

Darbojas ar lietotāja klikšķi.

Ja lietotājs apstiprina, ka telpa joprojām tiek izmantota, tā izdzēš notikuma ID no “Dzēšamās telpas”. Mēs izmantojām Google lapu, jebkurš cits saraksta veids šeit varētu būt atbilstošs.

(3) DeleteCurrentEvent

Darbojas ar Webhook zvanu.

Sarakstā (Google lapā) meklē attiecīgo notikuma ID un dzēš šo notikumu no kalendāra.

5. solis: savienojiet plūsmu ar Arduino kodu

Pievienotais kods savienojas ar sensoriem, kurus pirms dažām darbībām pārbaudījām, ar tiešsaistes sistēmu (mūsu gadījumā Google kalendārs). Tā pārbauda, vai telpa ir aizņemta, un pēc tam, ja tā nav, tā nosūta HTTP pieprasījumu (Webhook), kas sāk dzēšanas notikuma pieprasījumu vietnē Zapier.

6. darbība. Pārskatīšana, secinājumi un mērogošana nākotnē

Galvenais izaicinājums, ar kuru mums bija jārisina, ir aptvert visas galvenās lietas, pieņemot lēmumu atbrīvot sanāksmju telpu. Pēc tam mums bija jāizveido valsts mašīna, ņemot vērā visus iespējamos gadījumus, lai kļūda nenotiktu un telpa tiktu iestatīta kā pieejama tikai tad, kad tai vajadzētu būt.

Piemēram, ja istaba ir rezervēta kādai grupai, kura pašlaik nav (piemēram, pārtraukumā), bet tai joprojām ir nepieciešama, NODEMCU noteiks, ka telpa ir brīva> PROBLĒMA.

Pēc tam mūsu risinājums bija nosūtīt e -pasta ziņojumu lietotājam, kurš rezervēja istabu (ko nebija vienkārši izdomāt), ar ziņojumu, kas nodrošina iespēju turpināt turēt istabu.

Ja lietotājs noteiktā laikā neatbildēja (mēs iestatījām 5 minūtes, bet to var viegli mainīt), mēs izdzēšam notikumu no kalendāra (un atbrīvojam telpu).

Tādā veidā mums galu galā izdevās tikt galā ar visiem iespējamiem scenārijiem un izveidot funkcionējošu sistēmu.

MŪSU SISTĒMAS IEROBEŽOJUMI:

1. Izmantotajiem sensoriem jābūt ļoti precīziem un jutīgiem.

2. Telpas izmēri ir ierobežoti līdz sensora rādiusam/diapazonam.

3. Mums būs jāpaļaujas uz lietotāju atsaucību.

4. Mūsu sistēma ir veidota, izmantojot vairākas platformas (Google kalendārs, Gmail, Zapier uc), un tās darbībai būs jāizmanto viņu pakalpojums.

5. Šī pakalpojuma mērogošanai vairākās telpās (dublēšanās vietā visai sistēmai) būs nepieciešama papildu apstrāde ar telpas ID.

6. Sistēma ir tikai automātiska, un nav manuālas iespējas rezervācijas atcelšanai.

TURPMĀKĀ ATTĪSTĪBA:

Mēs noteikti palielinātu sistēmu divos veidos:

1. Spēja strādāt ar citām kalendāra platformām (lai to varētu izmantot jebkurš sadarbības telpu uzņēmums).

2. Spēja apstrādāt vairākas telpas, stāvus un vietnes.

Mēs uzskatām, ka šāda mēroga mērīšana prasīs 2-3 mēnešus, lai vispārinātu, pārbaudītu un pievienotu vairāku telpu (stāvu utt.) Funkciju.

Turklāt, izmantojot neierobežotu naudas summu un resursus, mēs izmantotu labākus sensorus ar lielāku diapazonu, kā arī pielāgotu tos norādītajai telpai - ņemot vērā diapazonu, rādiusu, sensoru daudzumu utt. acīmredzot.