VENTILASJON
Sensorene som kostet mer svette enn penger: Våre beste tips fra feltet
Hvordan kan vi spare energi i bygninger uten å ofre luftkvaliteten vi puster inn? Dette er hovedspørsmålet i forskningsprosjektet RecirculateIT, som undersøker hvordan smart styring av ventilasjon og omluft kan bidra til både lavere energibruk og bedre inneklima. For å lykkes må vi forstå hvilke forurensninger som faktisk følger med når vi bruker omluft.
Prosjektleder Maria Justo Alonso bygger videre på arbeidet fra sin doktorgrad, der hun brukte en Raspberry Pi i kombinasjon med lavkostnadssensorer for datainnsamling. Raspberry Pi ble valgt fordi den gir fleksibilitet og er godt egnet til utvikling og testing i forskningssammenheng.
I RecirculateIT ønsket vi imidlertid å teste en mer kompakt og energieffektiv løsning, og valgte derfor ESP32-mikrokontrollere. Sensorene kobles til mikrokontrolleren, som sender data via Wi-Fi til en lokal MQTT-broker og videre til vår SQLite-server.
Seks pilotprosjekter i reelle bygg
Prosjektet har testet denne løsningen for lavkostnadssensorer i kombinasjon med Airthings og laboratoriesensorer i seks pilotprosjekter, fra kontorbygg til kulturhus, for å samle inn data under reelle driftsforhold. På papiret fremstod vår lavkostnadsløsning som en enkel og elegant løsning, men i praksis støtte vi på flere utfordringer.
Underveis har vi møtt både tekniske og praktiske utfordringer, funnet løsninger som fungerer og opparbeidet kunnskap som kan være nyttig for andre. Her deler vi våre erfaringer, slik at andre kan unngå de samme fallgruvene.
– Lavkostsensorer for å måle luftkvalitet åpner for rimelige og fleksible målinger, men krever grundige forberedelser i praksis og ikke minst kalibrering, sier Maria Justo Alonso.
1. Wi-Fi og frekvensutfordringer
I mange av pilotbyggene var det flere trådløse nettverk, noe som kunne føre til forstyrrelser i rekkevidde og signalstyrke. En mulig feilkilde er at nettverkene overlapper og påvirker hverandre, særlig når kanalbånd velges eller endres.
Våre IoT-enheter var avhengige av 2.4 GHz-båndet, mens de fleste bygg i dag primært benytter 5 GHz. Vi måtte derfor verifisere at det fantes tilgjengelige 2.4 GHz nettverk på målelokalitetene. En annen mulig feilkilde er støy fra andre enheter som også opererer på 2.4 GHz-båndet. For IoT målinger er det derfor avgjørende å sikre stabil dekning på dette frekvensområdet. En gjennomgang og justering av ruterinnstillinger kan dessuten bidra til bedre ytelse.
2. Valg av mikrokontroller og strømbruk
Mikrokontrollere har lavt strømforbruk, men det kan gå på bekostning av rekkevidden. Det er derfor viktig å velge en modell med god Wi-Fi-funksjonalitet, gjerne med støtte for ekstern antenne for bedre signalmottak. Det finnes mange leverandører av utviklingskort med innebygde mikrokontrollere. Formfaktor spiller ofte en rolle når man ønsker å redusere størrelsen på enheten. Selv plassering av komponenter på kretskortet kan påvirke ytelsen og bør vurderes nøye.
– Med god planlegging av nettverk, gjennomtenkt utstyrsvalg, robust kode og effektive sikkerhetsmekanismer kan man oppnå en stabil og driftssikker løsning, sier Thomas E. Lassen.
3. Robust programkode
I feltet oppstår det alltid uforutsette problemer. Koden må derfor være robust, og i stand til å håndtere feil uten å stoppe systemet. Dersom MQTT-brokeren eller databasen er utilgjengelig, bør sensoren ha bufferkapasitet for midlertidig lagring av data. På serversiden bør det være mulig å sende varsler via e-post eller pushmeldinger. En innebygd restart-funksjon er nyttig, slik at sensoren automatisk starter på nytt ved feil.
Det er upraktisk å ha behov for å måtte trykke på en fysisk knapp når man befinner seg 600 km unna et pilotbygg. Det må også være håndtert på riktig måte i koden. I vårt tilfelle laget vi en “fix on the fly” som trigget en maskinell omstart dersom koden stoppet. Dette aktiverte en funksjon i firmwaren på kortet. Vi oppdaget imidlertid at dette ikke fungerte godt med en av sensorpakkene vi hadde koblet til i 2c-bussen på kortet. Spenning ble ikke droppet lenge nok på bussen, noe som førte til at sensorpakken ikke koblet ned og dermed kom opp igjen med feil.
4. Automatisk feildeteksjon
Det er ikke nok å bare overvåke om sensoren sender data – kvaliteten på dataene må også kontrolleres. En funksjon for automatisk feildeteksjon, inkludert lagringsovervåkning, er en stor fordel. Dette bidrar til å identifisere avvik tidlig og sikrer at systemet fungerer som forventet.
5. Buffering og lokal lagring
Serverfeil kan oppstå plutselig, og da er det viktig at data ikke går tapt. Lokal buffering mellom sensorene og skyen er en effektiv løsning. Formatet dataene lagres i har stor betydning for hvor lenge bufferen kan holde på informasjonen før den overskrives. Dette avhenger både av valg av utviklingskort og kompleksitet i programkoden. Dataen lagres midlertidig og sendes videre når forbindelsen er gjenopprettet.
6. Alternativ til Wi-Fi
Dersom Wi-Fi-dekningen ikke kan garanteres, bør man vurdere egne 4G- eller 5G-modems. Et alternativ er å bruke Raspberry Pi med 4G-modul (HAT), som kan være en mer pålitelig back-up ved manglende Wi-Fi tilgang.
Videre læring
Heldigvis hadde vi i datainnsamlingsfasen overlappende sensorer, og i tillegg til Sensirion-sensorene målte vi også med Airthings. Deres sensorer viste seg å være mer robuste, og i flere av pilotene kom mesteparten av dataene våre fra Airthings-enhetene.
Dette kan forklares med to forhold:
1. Airthings-enheter benytter sub-1 GHz frekvenser (IEEE 802.15.4) mellom enheter og hub, og unngår dermed problemer med 2.4 GHz sameksistens. Huben har videre cellular 2G/CATM1.
2. Bruken av en proprietær protokoll, slik Airthings har utviklet, bidrar til lang batterilevetid og økt driftssikkerhet. Dette var en positiv erfaring – selv om vi dermed ikke fikk inn målinger av formaldehyd.
