The Alert at the College Gate: Building Aervia Around a Real Campus Capture

How our team connected a campus sensor, timestamped warnings, and schedule-aware follow-up using AWS IoT Core.

Rakshit Chaturvedi

Published Oct 11, 2026

Last modified Oct 11, 2026

At 3:55 p.m., the PM2.5 reading at our VNR VJIET College Gate node climbed to 201.5 µg/m³.
That number mattered to us because it came from a sensor we had deployed on our own campus. We had collected nearly 100 minutes of field data, and the record showed four detected episodes. One severe episode began at 3:40 p.m.; the next reached the end of our recording while readings were still elevated.
A high number on a chart is easy to display. The harder question is what a college team should do with it.
That question shaped Aervia: a local air-quality monitoring prototype that connects readings to timestamped episodes, warnings, and practical follow-up for campus staff. It is designed to help teams review what a sensor recorded and decide what to check next, while being clear about what one node cannot tell them.
﻿
From a sensor reading to a useful follow-up
﻿
﻿
Regional air-quality data can provide important context, but it does not describe every location on a campus. A sensor near a college gate can capture changes at that specific point. On its own, though, a reading does not tell an administrator which event it belongs to, whether it crossed a configured warning threshold, or what a security or transport team should review.
Aervia brings those steps together:
The node measures particulate matter and environmental parameters.
The system organizes readings into a time series and identifies candidate PM2.5 episodes.
A warning queue links each warning to its event window and evidence.
An operator can acknowledge a warning and generate a report for the local node.
Schedule-aware advisories suggest checks for relevant campus teams.
For the advisory, we hardcoded the VNR schedule as context. For example, an event near first-year dismissal and bus dispatch can prompt security to review gate activity and transport staff to check bus staging records. That overlap helps staff decide what to investigate; it does not identify a pollution source or establish that the schedule caused the reading.
﻿
We took the prototype to our own campusOur field capture ran from 2:24 p.m. to 4:02 p.m. IST on October 9, 2026. It contains 99 one-minute bins and four detected PM2.5 episodes.
﻿
Two of those episodes show why timestamps matter. E-0003 ran from 3:40 to 3:43 p.m., reaching 116.9 µg/m³. E-0004 began at 3:55 p.m. and reached 201.5 µg/m³, with a peak excess of 167.6 µg/m³ over the estimated baseline. The recording ended during E-0004, so we cannot say from this capture whether the event continued or cleared afterward.
The dashboard presents the sensor trace alongside the event windows and warning queue. That lets a reviewer move from “there was a spike” to “this is the interval, this is the measured peak, and this is the follow-up we recommend.” A local node report summarizes the capture, observed parameters, episodes, and warnings.
The distinction between a measured value and an interpretation is deliberate. Our warning levels are prototype triage categories. They are not official AQI ratings or medical guidance.
﻿
How the telemetry reaches the application
﻿
The field node is built around an ESP32-S3 and three sensor modules:
A Sensirion SPS30 measures PM1, PM2.5, PM4, PM10, and particle-count ranges.
A Bosch BME280 measures temperature, relative humidity, and pressure.
A Sensirion SGP41 provides VOC and NOx indices. These are relative indices, not calibrated gas concentrations.
The ESP32 publishes telemetry to an AWS IoT Core MQTT topic over TLS, using QoS 1. The backend also connects to AWS IoT Core to receive messages. It uses the AWS IoT Device SDK for Python v2, MQTT over a SigV4-signed WebSocket connection, and the AWS Common Runtime. The backend normalizes incoming readings and exposes them to the dashboard through its API.
Plain text
SPS30 + BME280 + SGP41
          │
       ESP32-S3
          │ MQTT over TLS · QoS 1
          ▼
     AWS IoT Core
          │ MQTT over SigV4 WebSockets
          ▼
   FastAPI ingestion service
          │
   Local persistence + API
          │
   Aervia dashboard and reports
In this prototype, the application stores its telemetry locally. We also wrote a Boto3 setup script for an AWS IoT rule and DynamoDB/S3 destinations, but those resources are a separate provisioning path; they are not required for the local dashboard flow described here. An IoT Core broker acknowledgment confirms receipt by the broker, not permanent historical storage.
﻿
What the schedule adds—and what it doesn’tThe schedule-aware advisory is meant to make a warning easier to act on. Instead of repeating sensor values in a block of text, it gives Security, Transport, and Administration concise next steps tied to the event time.
For an event near dismissal, those steps might include checking gate logs, reviewing bus staging records, and confirming a fresh sensor reading. If the recording ends during an event, the advisory says that its current state is unknown and asks for a new measurement.
This feature uses schedule overlap as operational context. It cannot prove that buses, traffic, or any other activity caused an episode. A single node also cannot represent air quality across the whole campus. Those limits are part of the report and advisory experience, rather than a footnote hidden behind a chart.
﻿
What the field test taught usThe campus capture changed how we thought about the product. A warning is only useful if someone can inspect the evidence behind it. A graph needs clear event boundaries. A report needs the capture window and data coverage, so a partial recording is not mistaken for a full-day assessment. And an advisory should tell the right team what to check without pretending to know the cause.
We also learned to treat the end of a recording as a meaningful data boundary. When E-0004 reached the capture boundary, the correct message was “current state unknown,” not “still active” or “resolved.”
Our next step is to test the workflow across more capture sessions and locations, validate the event criteria, and make the telemetry history more robust. The current prototype gives campus teams a way to connect a local measurement to a reviewable event and a practical follow-up. More deployments will be needed before drawing broader conclusions.
﻿
Authors: Powerpuff Girls