From Algae to AWS: Building a Connected Air-Treatment Prototype
Our team is developing a hardware-and-software system that combines an experimental algae-based treatment unit with environmental monitoring and community water contributions. Here is how the design, AWS backend, and reward workflow fit together.
Pre-Final Year AIML Student at SRM IST Trichy | AI/ML, AWS, Python, UI/UX & Full-Stack Enthusiast
Where our project started
Our project began with the hardware: a unit that draws in air, circulates water through an algae-based system, and reports its operating conditions. As we worked through the design, we realised that the software would matter just as much as the machine itself.
If we placed several units around a campus, we would need to know which ones were online, which needed water, and what their sensors were reporting. We also wanted people nearby to be able to take part in maintaining them.
For Environmental Hacks 2026, part of the Bharat Builds Tour with AWS and WeMakeDevs, we're bringing these ideas together in one hardware-and-software project. It combines an experimental air-treatment unit, a connected sensor network, and a website where users can contribute water and receive points after verification.
The complete system is still under development. This is the story of our design, the software foundation we've established, and the problems we're working through.
Inside the hardware design
Our concept illustration shows an intake fan and fine mesh at the front, an algae-water reservoir at the bottom, a pump and hose, an inclined surface over which water flows, and an outlet above the treatment chamber. A BME680 environmental sensor and LoRa antenna sit at the top.
The proposed fan draws air into the enclosure through the mesh. This first stage is intended to intercept some particles; its actual performance will depend on the filter and airflow.
Inside the unit, the pump lifts water from the reservoir through a hose. The water is released over the inclined surface and returns to the reservoir. This recirculating arrangement is part of our plan for maintaining the wet treatment area.
Algae are central to the biological side of the project. Under suitable light and growing conditions, they use carbon dioxide during photosynthesis and release oxygen. Our wider design also explores moss as a treatment material, although its placement and contribution still need testing.
We're treating this as an experiment. We haven't measured carbon capture, oxygen output, or a pollution-removal percentage. The outlet in the illustration represents the proposed exit path for air; it should not be read as a claim that the machine produces pure oxygen.
What the sensors can tell us
The BME680 in our design provides temperature, humidity, pressure, and gas-resistance measurements. These will help us record conditions around the device and look at changes over time. The measurement types are described in Bosch's BME680 documentation .
We won't treat a gas-resistance value as a direct CO₂ or PM2.5 reading. Assessing treatment performance will require suitable sensors, calibration, and measurements before and after treatment.
We're also planning water-level monitoring and a separate flow sensor for refill measurements. Knowing that a machine needs water and knowing how much a person added are different jobs, so the software needs to handle them separately.
Connecting one machine to a network
Each unit will have a unique node ID. An ESP32 will collect its readings and send them over LoRa to a Raspberry Pi gateway. The gateway will forward those readings to the Python backend over an internet connection.
This design lets several machines share a gateway. The backend can then associate incoming data with the correct node and store it for later viewing.
Our telemetry format includes the node ID, reading ID, temperature, humidity, pressure, gas resistance, sequence number, and device uptime. Giving each message context is useful when we need to trace where a reading came from or investigate a communication problem.
The planned dashboard will bring together recent readings, water levels, refill activity, and connectivity status. For example, a long gap since the last message could flag a node for investigation.
Building the backend on AWS
We've created an Amazon RDS PostgreSQL instance in the Mumbai region,
ap-south-1 . The database is intended to hold user profiles, machine records, sensor readings, refill sessions, verification results, and reward transactions.We've also created an Amazon Cognito User Pool for registration and login. Cognito will handle authentication and email verification, while our backend will connect each authenticated identity to its application record in PostgreSQL. Contribution history and rewards will stay with that user record, without duplicating passwords in our database.
Our first backend used Node.js and Express. We're now rebuilding it in Python with FastAPI, giving authentication, machine management, telemetry, refill verification, and rewards their own parts of the application.
The same backend will serve the hardware gateway and our React, Vite, and TypeScript frontend. We're evaluating AWS App Runner for deployment; hosting the complete application and configuring its database connection remain part of the development work.
Giving people a way to participate
Each machine will have a permanent QR sticker. Scanning it with a phone camera will open that machine's page on the website.
The intended experience is simple:
- Scan the QR code and open the machine page.
- Register or log in.
- Start a refill session.
- Add water through the refill system.
- Wait for automatic verification.
- View the contribution and earned points in the account.
Users won't need to enter a quantity such as one or two litres. In the physical version, a flow sensor will measure what was added and associate it with the active session.
This was a change from our earlier design, which relied on a claimed quantity and manual approval. We wanted a simpler user experience and a measurement the backend could verify. The revised workflow has no operator approval step.
Water quality, reservoir capacity, and the biological system's needs will also have to guide how refills work in practice.
Developing verification with a simulator
We haven't completed physical flow-sensor integration yet. To work on the application in the meantime, we're building a server-side simulator.
It will create a refill session, generate demo measurements over a short period, move the session through verification, and record the corresponding reward. Simulated values will be identified as demo data rather than physical contributions.
Our proposed reward rule is 10 points per verified litre, rounded down to a whole number. A 1.25-litre contribution would therefore earn 12 points.
The backend must also prevent the same session from earning points twice. Refreshing the page or repeating a request should leave the recorded reward unchanged.
We're keeping measurement collection separate from the account and rewards code. When the flow sensor is ready, its readings can replace the simulator's input while the rest of the workflow stays in place.
Keeping contributions and rewards traceable
We're designing each account to show its refill history, verified water total, points balance, and reward redemptions. A transaction ledger will record why points were added or deducted.
That history matters when a user comes back later or when we need to investigate a missing reward. It also gives us a clearer way to check the system than relying on a single balance that changes without explanation.
Where the project stands
Area | Current progress |
|---|---|
Hardware design | Concept and network architecture defined; physical integration and performance testing remain |
AWS foundation | RDS PostgreSQL instance and Cognito User Pool created |
Initial software | Node.js/Express backend and initial React login and registration screens developed |
Authentication | Cognito integration and linking identities to RDS user records in progress |
Python backend | FastAPI rewrite in progress |
Contributions | QR workflow defined; refill simulation and duplicate-credit protection in development |
Device network | ESP32, BME680, LoRa, and Raspberry Pi integration planned |
Deployment | App Runner under consideration; complete application deployment still pending |
What we've learned so far
Database connectivity took more attention than we expected. We encountered issues with endpoints, SSL certificates, network access, and credentials. Those problems made us look more carefully at the connection between our local backend and the cloud database.
Authentication also required more than a working login screen. We need each Cognito identity to resolve to the correct application account, so contributions and rewards remain attached to the right person.
The refill design taught us to think beyond the happy path. A user may refresh the page, a request may be repeated, or a device may stop sending data. Session state and reward records need to remain consistent through those situations.
The hardware brings a separate challenge: proving that the treatment process is useful. Sensor data will help us investigate, but we'll need controlled tests of airflow, pollutant levels, energy use, and biological conditions before making environmental-performance claims.
Our next milestone
Our immediate focus is to complete the Python backend and test the full QR-to-reward journey with simulated measurements. Then we'll connect the gateway, bring in physical flow-sensor readings, and test the treatment unit itself.
We want to reach a point where we can follow one complete interaction: a particular machine reports its condition, a user starts a refill, the contribution is verified, and the account shows the correct result.
Getting that sequence reliable, alongside evidence from the hardware tests, will give us a sound basis for deciding how the project should grow.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article