Õpperuumide sisekliima jälgimise seade koos andmelehega

Probleemi ja lähteülesande kujunemine

Rühm keskendus õpperuumide sisekliima jälgimise lahendusele. Projekti alguses lähtuti arusaamast, et temperatuur ja õhuniiskus mõjutavad nii õppetingimusi kui ka tehniliste ruumide seisukorda. Intervjuu ja hilisema analüüsi põhjal muutus probleem täpsemaks: ruumivastutaja ei saa õpperuumide temperatuuri ja õhuniiskust järjepidevalt jälgida, sest mõõtmine toimub käsitsi ja ebaregulaarselt ning andmed ei koondu ühte kohta.

Praegune tööviis tähendab, et näitude kontrollimiseks tuleb ruumid füüsiliselt läbi käia, mõõtetulemused üles kirjutada ja vajaduse korral haldusele edastada. Selline lahendus on ajamahukas ning ei anna kindlat ülevaadet sellest, mis toimub ajal, mil ruume parasjagu ei kontrollita.

Keskseks küsimuseks kujunes, kuidas vähendada käsitsi tegutsemist ja luua süsteem, mis kogub mõõteandmeid automaatselt, seob need ruumi ja ajaga ning võimaldab hiljem andmetele toetuda. Lahendus pidi aitama märgata sisekliima muutusi varem, võrrelda ruume ja säilitada ajaloolist andmestikku.

Kasutajauuring ja andmete kogumine

Kasutajauuringu põhimeetod oli poolstruktureeritud intervjuu õpperuumide sisekliima eest vastutava kasutajaga. Intervjuu toimus 24. veebruaril 2026 ning keskendus kasutaja rollile, senisele tööprotsessile, konkreetsetele probleemolukordadele ja ootustele.

Intervjuu tõi välja, et kasutaja vajab eeskätt ülevaadet, mitte pidevat käsitsi kontrollimist. Andmed peavad jõudma ühte tabelisse või süsteemi, olema kaugelt loetavad ning säilima püsivalt. Ajaloolisi andmeid on vaja mitte ainult tagantjärele vaatamiseks, vaid ka tõendamiseks ning suuremate remondi- või ehitusotsuste sisendina.

Samuti selgus, et lahendus ei tohiks olla klassiruumis pilkupüüdev, vilkuv ega püsivalt kinnitatud. Kõigis ruumides ei ole mugavat pistikupesa, mistõttu tuli arvestada akutoite ja selle ohutusega. Uuringu kõrval vaadeldi ka analoogseid temperatuuri ja õhuniiskuse mõõtmise lahendusi, et eristada vältimatuid funktsioone hilisemaks jäävatest lisavõimalustest.

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

Pärast intervjuud koondati tähelepanekud klastriteks ja mustriteks. Eristusid manuaalne ja ebaregulaarne andmekogumine, keskse ülevaate puudumine, ajalooliste andmete vajadus, mõõtmise ja energiakulu tasakaal, seadme diskreetsus ning usaldusväärsus. Probleem ei seisnenud üksnes selles, et näitu on ebamugav lugeda, vaid andmete katkendlikkuses ja otsuste tegemises ilma piisava tõendusmaterjalita.

Süsteem pidi mõõtma automaatselt temperatuuri ja õhuniiskust, lisama igale kirjele ruumi identifikaatori, kuupäeva ja kellaaja ning saatma andmed välisesse andmesüsteemi. Andmevaade pidi võimaldama mitme ruumi koondvaadet, ajaloo säilitamist ja piirväärtustest kõrvalekallete esiletõstmist.

Kasutatavusnõuetes rõhutati, et seade peab olema väike, mittevilkuv, ilma helisignaalideta ja paigutatav ilma püsiva kinnitamiseta. Mõõtmisintervalliks peeti sobivaks ühte kuni kahte tundi, sest tihedam mõõtmine kulutaks rohkem akut, kuid harvem mõõtmine võib jätta muutused märkamata. Arvestati ka 72-tunnise tööaja, aku madala taseme tuvastamise, mõõtetäpsuse ja ohutu korpusega.

Disainibrief ja lahenduse kontseptsioon

Peamiseks sihtrühmaks määratleti õppejõud või ruumivastutaja, kes vajab ülevaadet õpperuumide sisekliimast. Kaudseks sihtrühmaks olid õppijad ja teised ruumikasutajad, kelle töö- ja õpitingimused sõltuvad temperatuurist ja õhuniiskusest. Lahendust ei kavandatud juhuslikule ruumikasutajale, vaid inimesele, kes vastutab ruumi seisundi jälgimise ja vajadusel haldusega suhtlemise eest.

Lahenduse kontseptsioonina valiti kompaktne mõõteseade, mis kasutab temperatuuri- ja niiskusandurit, mikrokontrollerit ning WiFi-ühendust. Seade mõõdab kindla intervalliga sisekliima näitajaid, lisab andmetele ruumi identifikaatori ja ajatempli ning saadab tulemused Google Sheetsi või sarnasesse välisesse süsteemi.

Peamiseks tehniliseks suunaks valiti Heltec WiFi LoRa 32 (V3) arendusplaadil põhinev lahendus koos DHT22/AM2302 anduri ja 18650 Li-ion akuga. Valikut mõjutas soov ühendada mõõtmine, töötlemine ja andmete edastus kompaktsesse vormi. Arduino UNO R4 WiFi jäi varuvariandiks juhuks, kui Heltec osutub kättesaadavuse või toitehalduse tõttu keeruliseks.

Prototüüpimine ja testimine

Prototüüpimise eesmärk oli kontrollida kogu süsteemi põhiloogikat. Esmalt testiti, kas andur mõõdab temperatuuri ja õhuniiskust ning kas mõõteandmed jõuavad Google Sheetsi. Seejärel lisandus 3D-prinditud korpuse arendamine, mille puhul kontrolliti komponentide mahtumist, seadme välimust ja seda, kas korpus vastab tagasihoidliku klassiruumi seadme nõudele.

Esimene prototüüp võimaldas mõõta temperatuuri ja õhuniiskust ning saata andmed tabelisse. See kinnitas lahenduse põhimõtte teostatavust, kuid tõi välja vajaduse parandada korpust ja seadme füüsilist vormi. Teise prototüübi testimisel kontrolliti juba tervikut: anduri stabiilsust, arendusplaadi andmelugemist, WiFi-edastust ja andmete jõudmist Google Sheetsi.

Pikem test toimus ruumis A-406. Prototüüp anti kasutajale 21. aprillil ning järgmistel päevadel kontrolliti, kas mõõteandmed jõuavad süsteemi ja kas tabelis toimib visuaalne eristamine, kui temperatuur või õhuniiskus muutub üle või alla määratud piiri. Kasutaja tagasiside oli positiivne: seade töötas ootuspäraselt, näitas stabiilselt usutavaid tulemusi, saatis e-posti teavitusi ning ei seganud klassiruumi.

Refleksioon

Protsessi käigus sai selgeks, et disainiprobleem muutub nähtavaks alles siis, kui tehniline idee seotakse kasutaja tegeliku tööprotsessiga. Enne intervjuud oli lihtne mõelda temperatuuri ja niiskuse mõõtmise seadmele kui eraldiseisvale tehnilisele objektile. Pärast kasutajauuringut muutus oluliseks andmete järjepidevus, kaugelt loetavus ja võimalus neid otsustamisel kasutada.

Prototüüpimine näitas, et aku kestvus, mõõtmisintervall, korpuse mõõtmed, anduri paigutus ja andmevaate arusaadavus mõjutavad üksteist. Kui mõõta liiga sageli, väheneb tööaeg; kui korpus on liiga väike, ei mahu komponendid; kui andmevaade on liiga keeruline, ei toeta see kasutaja otsustamist.

Järgmises arendustsüklis tuleks varem tegeleda andmevaate kujundamisega ning testida lahendust mitmes ruumis korraga, et hinnata skaleeritavust ja ruumide võrdlemise võimalust.