IDC2018IOT: Vergaderkamer Snitcher: 6 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:27

DIE PROBLEEM

Soos ons weet, het die neiging van samewerkingsruimtes die afgelope paar jaar versnel, tesame met die nuutste tegnologie wat die keuse van die spesifieke samewerkingsruimte wat by u behoeftes pas, bepaal.

Een van die belangrikste kenmerke wat aangebied word, is gedeelde vergaderruimtes wat aan die lede van die medewerkingsruimte aangebied word, wat bestuur word deur 'n (gewoonlik) eenvoudige kalenderplatform.

'N Probleem kom weer voor namate mense skeduleer, is dit geneig om dinamies te wees.

'N Mens kan 'n kamer bespreek deur te dink dat hy dit dalk nodig het en die tydgleuf nie wil misloop nie.

Selfs as iemand uiteindelik nie die tydgleuf gebruik nie, sal hy dit nie ter wille van ander in kennis stel en kanselleer nie, want dit is ongelukkig die menslike natuur.

HOE los ons dit op?

Met behulp van IoT -tegnologie - om klank en beweging in 'n aangewese vergaderlokaal na te gaan, kontroleer ons elke sekere tydsperiode of 'n kamer bespreek is of nie;

1. As dit nie bespreek is nie, moet niks doen nie.

2. As dit bespreek is, kyk of daar beweging of klank is;

As daar is, doen niks.

As niks opgespoor is nie, stuur 'n waarskuwingsboodskap (via e -pos) na die gebruiker wat die kamer bespreek het, wat vra of die kamer nog gebruik word. tensy die gebruiker sal verklaar dat hy steeds die kamer gebruik, word die kamerstatus verander na "Beskikbaar".

* Hier het ons ons projek met Google Kalender geïntegreer om dit soveel as moontlik te veralgemeen.

Stap 1: hardeware en protokolle benodig

1. Ons het NOSEMCU gebruik sodat ons dinge dinamies kon opdateer met behulp van die WIFI -verbinding.

2. Mikrofoonsensor wat die geraas in die kamer sal "lees".

3. PIR -sensor wat sal kyk of daar beweging is.

Benewens die kode in Arduino, het ons Google Script en Zapier gebruik om ons stelsel aanlyn te ondersteun, behalwe die kode in Arduino. U kan die vloei in die bygevoegde prentjie (en PDF) sien.

Ons het Zapier gebruik om programme aan te sluit en ons werkstrome te outomatiseer (soos IFTTT) en ons het Google Script gebruik om ons te help om met die Google Kalender te kommunikeer. Die draaiboek wat ons geskryf het, produseer die e -pos van die skepper van die gebeurtenis, sodat ons dit met Zapier kan stuur en kyk of die gebruiker gevra het om die kamer te hou (deur inligting in Google Sheets op te slaan) voordat hy die geleentheid uitvee.

Stap 2: Koppel die mikrofoon en die PIR -sensor

Ons wou die gemiddelde waardes nagaan wat die mikrofoon na die NODEMCU plaas wanneer mense praat (daar was duidelik verskillende agtergrondgeluide in elke kamer). Ons het getoets en besef dat die gemiddelde geraasvlak in die kamer waarin ons gewerk het, iewers bo 50 is.

Die PIR -sensor gee slegs HOOG of LAAG waardes, sodat ons slegs die sensitiwiteitsvlak wat die akkuraatste is vir die kamer wat ons nagegaan het, nagegaan het. Hierdie gids was redelik behulpsaam.

ONS VERBINDINGS:

Mikrofoon - soos op die foto PIR -sensor: GND> GND, OUT> D7, VCC> VN (5V)

Stap 3: Skep die werkstroom in Zapier

Om te weet of die kamer eintlik leeg is of nog in gebruik is (en die gebruikers is byvoorbeeld op pouse), wil ons 'n vloei skep wat dit verseker, net nadat die NodeMCU 'n Webhook na Zapier afgevuur het, wat in kennis stel dat die kamer is leeg:

(1) TRIGGER - CATCH HOOKZapier vang die Webhook (wat deur die NODEMCU gestuur sal word)

(2) AKSIE - GETZapier stuur 'n ander Webhook om die gebeurtenisdata te kry;> Dit noem 'n GoogleScript - GetCurrentEmailEventID (verduideliking in die volgende stap) om die huidige gebeurtenisdata te kry - gebeurtenisnaam, gebeurtenis -ID, gebruikers -e -pos.

(3) FILTER - GAAN SLEGS VOORT AS

Gaan slegs na die volgende stap as daar tans 'n geleentheid (enige gebeurtenis) op die kalender plaasvind (KAMER IS BESIG), anders stop as die kamer leeg is.

(4) AKSIE - GMAILZapier stuur 'n e -pos, via Gmail, na die gebruiker wat die kamer bespreek het (het hierdie inligting in stap 2 gekry)

(5) AKSIE - VERTRAGING Laat die gebruiker tyd om op die e -pos te antwoord. - As die gebruiker op die skakel klik: bel (hardloop) die GoogleScript - ApproveCurrentEvent (vandaar dat die kamer uit die 'Kamers om te verwyder' -lys verwyder word, en die kamer is steeds gemerk as beset.)

(6) AKSIE - KRY Na 5 minute bel (loop) Zapier GoogleScript - DeleteCurrentEvent- As die gebruiker nie op die skakel geklik het nie

Kontroleer of die kamer -ID in die lys 'Kamers om te verwyder' is

dit verwyder die gebeurtenis net.

Stap 4: Google Scripts

Terwyl ons die hele stelsel geïntegreer het, was GoogleScripts die triviale keuse van 'n IDE. Daarom het ons relevante Google Libraries gebruik. Sal verander volgens die kamerbesprekingsplatform.

(1) GetCurrentEmailEventID

Loop deur 'n Webhook -oproep.

Gebruik 'n sekere verrekening om moontlike kanselleer-kansellasie uit te skakel, om die huidige gebeurtenisdata te kry.

(2) ApproveCurrentEvent

Word uitgevoer deur 'n klik van 'n gebruiker.

As 'n gebruiker goedkeur dat die kamer nog in gebruik is, verwyder die gebeurtenis -ID uit die 'Kamers om te verwyder'. Ons het 'n Google -blad gebruik; enige ander vorm van 'n lys kan hier relevant wees.

(3) DeleteCurrentEvent

Loop deur 'n Webhook -oproep.

Soek na die relevante gebeurtenis -ID in die lys (Google -blad) en verwyder die gebeurtenis uit die kalender.

Stap 5: Koppel die stroom met die Arduino -kode

Die aangehegte kode sluit aan by die sensors wat ons 'n paar stappe gelede nagegaan het, met die aanlynstelsel (in ons geval Google -kalender). Dit kontroleer of die kamer besig is, en as dit nie die geval is nie, stuur dit 'n HTTP -versoek ('n Webhook) wat die verwydering van die versoek op Zapier begin.

Stap 6: Oorsig, gevolgtrekkings en toekomstige skaal

Die grootste uitdaging waarmee ons te doen gehad het, is om die belangrikste sake te dek wanneer ons besluit om 'n vergaderlokaal te bevry. Ons moes dan 'n staatsmasjien maak wat alle moontlike gevalle oorweeg, sodat daar nie 'n fout sal voorkom nie en die kamer slegs beskikbaar sal wees as dit moet.

As die kamer byvoorbeeld bespreek is vir 'n groep wat tans nie daar is nie (dit is byvoorbeeld 'n pouse), maar dit steeds nodig het, sal NODEMCU agterkom dat die kamer gratis is> PROBLEEM.

Ons oplossing was om 'n boodskap aan die gebruiker wat die kamer bespreek het, te e -pos (wat nie maklik was om uit te vind nie), wat die opsie bied om die kamer aan te hou.

As die gebruiker nie binne 'n gegewe tyd geantwoord het nie (ons stel dit op 5 minute, maar dit kan maklik verander word), verwyder ons die gebeurtenis uit die kalender (en maak die kamer vry).

Op die manier kon ons uiteindelik alle moontlike scenario's hanteer en 'n werkende stelsel skep.

ONS STELSELBEPERKINGS:

1. Die gebruikte sensors moet baie akkuraat en sensitief wees.

2. Die kamergrootte is beperk tot die sensor se radius/reikwydte.

3. Ons moet staatmaak op die reaksie van die gebruiker.

4. Ons stelsel is gebou op verskillende platforms (Google -kalender, Gmail, Zapier, ens.) En sal hul diens moet gebruik om te presteer.

5. Om hierdie diens vir verskeie kamers te vergroot (in plaas van duplisering van die hele stelsel), sal 'n ekstra hantering met kamer -ID vereis word.

6. Die stelsel is slegs outomaties en daar is geen handmatige opsie om 'n kamerbespreking te kanselleer nie.

TOEKOMSTIGE ONTWIKKELINGE:

Ons sou die stelsel beslis op twee maniere opskaal:

1. Die vermoë om met enige ander kalenderplatform te werk (sodat enige medewerkende onderneming dit kan gebruik).

2. Die vermoë om verskeie kamers, vloere en persele te hanteer.

Ons glo dat hierdie soort skaal 2-3 maande sal neem om te veralgemeen, te toets en om meer kamers (vloere, ens.) By te voeg.

Boonop sou ons met behulp van 'n onbeperkte hoeveelheid geld en hulpbronne beter sensors met 'n groter omvang gebruik, sowel as om dit aan te pas by die aangewese kamer - met inagneming van reikafstand, radius, hoeveelheid sensors, ens. 'N Stap wat elke stelsel langer laat installeer, duidelik.