Õpperuumide sisekliima jälgimise seade koos andmelehega

Probleemi ja lähteülesande kujunemine

Rühm valis projektiks Digitehnoloogia instituudi õpperuumide õhutemperatuuri ja õhuniiskuse jälgimise lahenduse. Esmase arutelu järel jõuti arusaamani, et teema on praktiline, sest ruumide sisekliima mõjutab õppetegevust, tehnika töökeskkonda ja haldusotsuseid. Alguses oli küsimus üsna üldine: kuidas mõõta temperatuuri ja niiskust ning kas andmed võiksid jõuda internetti.

Kasutajauuring täpsustas probleemi. Õpperuumide eest vastutaval töötajal puudub automaatne ja keskne ülevaade ruumide temperatuurist ja õhuniiskusest. Praegune lahendus põhineb käsitsi mõõtmisel, näitude üleskirjutamisel ja vajaduse korral haldusele edastamisel. See on ajamahukas ega võimalda märgata probleeme ajal, mil keegi ruume füüsiliselt ei kontrolli.

Eesmärgiks seati lahendus, mis mõõdab sisekliima näitajaid automaatselt, salvestab need koos ruumi, kuupäeva ja kellaajaga ning teeb andmed kasutajale kaugelt kättesaadavaks. Projekti mõte ei olnud ainult Arduino ja anduri ühendamine, vaid disainiprotsess, kus tehnilised valikud tulenevad kasutaja vajadustest, piirangutest ja testimisel kogutud tagasisidest.

Kasutajauuring ja andmete kogumine

Rühm viis läbi poolstruktureeritud intervjuu õpperuumide sisekliima eest vastutava kasutajaga. Intervjuu toimus 24. veebruaril 2026 Zoomi vahendusel ning kõik rühma liikmed tegid märkmeid. Küsimused puudutasid kasutaja rolli, praegust tööprotsessi, ebamugavaid sisekliimaolukordi, andmete vajadust, tehnilisi piiranguid, seadme välimust ja võimalikke riske.

Intervjuu kavandamisel lähtuti oletustest, mis võisid osutuda valeks. Näiteks eeldati, et kasutaja tahab eeskätt reaalajas häiret, kuid intervjuu põhjal osutus väga oluliseks ka püsiv ajalooline andmestik. Kasutaja vajab usaldusväärset ülevaadet, mida saab kasutada nii jooksva olukorra jälgimiseks kui ka tulevaste remondi- ja planeerimisotsuste toetamiseks.

Rühm kogus andmeid intervjuu märkmetest, otsestest tsitaatidest, hilisemast klasterdamisest ja analoogsete toodete uurimisest. Vaadeldi lahendusi nagu Monnit, T&D TR72A, Dragino LHT65N, Shelly H&T, Govee, SensorPush ja Netatmo. Analoogid aitasid mõista erinevaid arhitektuure: otse WiFi kaudu pilve, sensor koos gateway-seadmega, Bluetoothi ja WiFi värava kombinatsioon või LoRaWAN.

Analüüs, süntees ja disaininõuded

Intervjuu põhjal moodustati klastrid. Esile tulid süsteemse ja pideva ülevaate puudumine, pikaajalise analüüsi võimatus, ekstreemsete tingimuste võimalik mõju õppetööle ja varale, seadme füüsilise kohalolu häiringud, toite ja hoolduse riskid ning süsteemi usaldusväärsuse, laiendatavuse ja kulu küsimused.

Klastritest tuletati mustrid. Käsitsi andmekogumine viib hilinenud reageerimiseni, sest vastutaja peab ruumides kohal käima. Töövälisel ajal tekkivad probleemid võivad süveneda enne, kui keegi neid märkab. Ilma püsiva ajaloota ei saa probleeme tõenduspõhiselt esitada. Silmatorkav või püsivalt kinnitatud seade võib klassiruumi sobimatuks osutuda.

Nõuetena sõnastati, et süsteem peab mõõtma temperatuuri ja õhuniiskust, salvestama mõõtmised koos ruumi identifikaatori, kuupäeva ja kellaajaga ning saatma andmed kesksesse süsteemi. Süsteem peab toetama mitut ruumi, visuaalselt eristama piirväärtuse ületusi ning võimaluse korral saatma teavitusi. Seade peab olema tagasihoidlik, mittevilkuv, ilma liigse ekraanita ja paigutatav lauale, riiulile või aknalauale ilma kruvimise või liimimiseta.

Disainibrief ja lahenduse kontseptsioon

Disainibriefis määratleti sihtrühmana ülikooli õpperuumide, arvutiklasside ja laborite eest vastutav isik. Tegemist on tehnilise taustaga kasutajaga, kellel ei ole aega ruume pidevalt käsitsi kontrollida. Briefis kirjeldati funktsionaalsed, kasutatavuse, jõudluse, ohutuse ja hooldatavuse nõuded.

Lahenduse kontseptsioonina kavandati akutoitel või vajaduse korral seinatoitel töötav mõõteseade, mis kasutab Arduino UNO R4 WiFi arendusplaati ja DHT22 temperatuuri- ning õhuniiskuse andurit. Mõõdetud andmed saadetakse WiFi kaudu Google Sheetsi. Tabelis salvestatakse aeg, temperatuur, niiskus ja ruumi identifikaator, näiteks A-406, T-302 või M-543.

Piirväärtuse ületamisel värvub vastav lahter punaseks ning süsteem saadab e-posti hoiatuse. Korpuse ülesanne oli kaitsta komponente, teha seade ruumis tagasihoidlikuks ja võimaldada anduril mõõta ruumi õhku. Esialgse mudeli puhul arvestati avadega, et andur saaks mõõta ning arendusplaadi või aku soojus ei jääks korpusesse kinni.

Prototüüpimine ja testimine

Esimese testimise eesmärk oli kontrollida põhiloogikat: kas seade mõõdab temperatuuri ja õhuniiskust ning kas andmed jõuavad Google Sheetsi. Testiti lihtsat stsenaariumi, kus kasutaja ühendas seadme arvutiga ja jälgis, kas mõõteandmed ilmuvad tabelisse. Põhifunktsioonid hakkasid tööle, kuid selgus, et kasutajale tuleb paremini selgitada, millal mõõdetud väärtus on probleemne ja kuidas andmeedastus toimub.

Teises testimises täiustati prototüüpi. Seade töötas patarei pealt, ruumi identifikaator lisati andmepäringusse, probleemsed temperatuurid ja niiskused värvusid tabelis punaseks ning süsteem saatis e-posti hoiatuse. Test näitas, et kasutaja suutis tuvastada probleemsed väärtused ja aru saada, millises ruumis need esinesid. Samas jäi selgusetuks, milline tegevus peaks kasutajal järgnema hoiatussignaalile.

Pikem kasutajatest algas 16. aprillil 2026, kui andur paigaldati Tallinna Ülikooli klassiruumi seinale. Seade mõõtis temperatuuri ja õhuniiskust iga tunni tagant ning töötas seitsmepäevase testperioodi jooksul stabiilselt. Andmed jõudsid Google Sheetsi regulaarselt, ruumipõhine eristus toimis ning väärtused tundusid usutavad. Kasutaja tagasiside oli väga positiivne: seade töötas probleemideta, juhend oli arusaadav ja seade ei tõmmanud arvutiklassis liigset tähelepanu.

Refleksioon

Protsessi käigus õpiti, et tehniliselt töötav mõõteseade ei ole veel terviklik lahendus. Kasutaja väärtus tekib siis, kui andmed on õigel kujul, õigel ajal ja õige ruumiga seotud. Google Sheetsi kasutamine oli prototüübi jaoks sobiv, sest võimaldas kiiresti kontrollida andmeedastust, tingimusvormingut ja e-posti teavitusi.

Samas ilmnes, et pikema kasutuse puhul vajab andmevaade paremat visuaalset kokkuvõtet, näiteks graafikuid või eraldi ülevaatelehte. Toitelahendus osutus samuti oluliseks piiranguks. Patarei pealt töötamine näitas, et ilma energiasäästurežiimita ei ole pikaajaline akutoide lihtne.

Korpuse puhul õpiti, et esialgne mudel võib olla liiga väike ning komponentide tegelik paigutus selgub alles füüsilise proovimise käigus. Järgmises arendustsüklis tuleks alustada varem energiasäästu ja andmevisualiseerimise küsimustest, sest need määravad, kas prototüüp on kasutatav ka pikema aja jooksul.