HawaCommand: Delhi Already Owns the Machines. We Gave Them a Brain.

By Team Straw Hat Pirates, built for the WeMakeDevs AWS Environment Hackathon (Track 01: Air) Live demo: http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000/

Mayank Yadav

Published Oct 11, 2026

Last modified Oct 11, 2026

The problemDelhi has 376 anti-smog guns, 266 water sprinklers and 91 road sweepers. That is 733 machines. The city already paid for them.
The trouble is how they are used:
They follow fixed schedules. They do not follow the pollution or the people.
Nobody can say if a spray run lowered PM2.5, or if the wind did it.
Citizens can see smoke and dust, but they have no way to turn that into action.
Contractors can skip routes. There is no proof that a machine actually worked.
So we did not build another air quality dashboard. We built the decision layer on top of the fleet Delhi already has.
What we builtHawaCommand is a closed loop: Sense, Map, Attribute, Forecast, Decide, Act, Verify. What worked in the last loop feeds the next plan.
﻿
The last stage loops back: what the verifier proves works shapes the next plan.
Sense: live air stations, vehicle trackers (we call them HawaTags) and citizen photo reports.
Map: a digital twin of the city. It uses Gaussian process kriging over 10,600 cells of 500 m. Each cell has PM2.5, PM10 and a confidence score.
Attribute: simple fingerprint rules label each hotspot as road dust, traffic, burning, regional smoke or industry.
Forecast: 21 LightGBM quantile models predict 1 to 72 hours ahead, with P10, P50 and P90 bands. The output includes the CPCB AQI and the CAQM GRAP stage.
Decide: hotspots are ranked by people exposed (population, schools, hospitals), not by raw AQI. A Planner agent drafts a dispatch plan that matches the cause. An Auditor agent challenges it, for example "a sprinkler near a CPCB station will distort the reading".
Act: an officer approves the plan in one click. Drivers get a Hindi-first route in the Flutter app. SNS alerts go out.
Verify: synthetic control with placebo tests gives the effect of each intervention with a 95% interval.
﻿
﻿
The stackAI/ML: Python 3.11, scikit-learn, LightGBM, SciPy, LLM agents (Groq or Amazon Bedrock)
Backend: FastAPI, Pydantic v2, boto3, redis-py, managed with uv. 50 API operations plus a WebSocket.
Web console: Next.js 15, React 19, TypeScript, Tailwind, MapLibre GL
Mobile: Flutter, Riverpod, drift (SQLite) for offline storage. English and Hindi.
Data: WAQI, OpenAQ, CPCB, Open-Meteo, NASA FIRMS, OpenStreetMap, WorldPop
How AWS fitsWe integrated 22 AWS services. Nine are live on the deployment, four more are wired in code and switched on with one variable, and nine are in the infrastructure-as-code path (CloudFormation, ECS Fargate, ALB and others). We say this plainly because we do not want to oversell it.
The nine live services, and the job each one does:
EC2 (ap-south-1, Mumbai): runs the backend, the AI-ML engine and the web console.
IAM: an instance role with a least-privilege policy. There are no access keys on the server.
IoT Core: receives MQTT messages from HawaTag trackers on  hawa/vehicles/+/telemetry . A rule forwards each message to Kinesis.
Kinesis: the telemetry bus. A consumer reads it and keeps its place with Redis checkpoints.
DynamoDB: stores citizen grievances and fleet telemetry. Telemetry has a 7-day TTL, so old data cleans itself up.
ElastiCache (Valkey/Redis): the live fleet geo index, the twin snapshot, plans, alerts and the WebSocket fan-out. This is why a vehicle ping reaches the app in milliseconds.
S3: stores citizen photo evidence. Uploads use pre-signed POST with type, size and SHA-256 pinned, so the phone uploads straight to S3 and our server never touches the file.
SNS: sends alert broadcasts with ward filter policies, so people only get alerts for their area.
KMS: encrypts the Kinesis stream and the cache at rest.
The path of one vehicle ping:
A HawaTag sends an MQTT message to IoT Core.
A rule pushes it into Kinesis.
The consumer writes it to DynamoDB and updates the geo index in ElastiCache.
A WebSocket sends it to the officer console and the citizen app.
﻿
The ping lands in the app within milliseconds because ElastiCache pushes it out over a WebSocket.
What fought backThis is the part that took the most work. These are the real design problems we had to solve.
﻿
2. Real trackers do not exist yet. We did not have physical HawaTags on real vehicles. So we built a fleet simulator that sends data through the real IoT Core to Kinesis path, not a fake shortcut. When real trackers arrive, they use the same topic. Anything simulated carries  simulated: true  and a badge in the UI. We did not want the demo to pretend.
3. A demo cannot die because one service fails. Every AWS service in the app is optional and has a fallback. AI-ML runs over HTTP, then in-process, then on fixtures. AWS and Redis fall back to memory. A failing service breaks one feature, not the whole app. We built  hawa aws-check  to test each configured service with one live call, so we always know what is really running.
4. The people using it are on the street, not at a desk. Drivers need large tap targets, a high-contrast outdoor theme and Hindi first.
﻿
5. Trust. A "missed machine" report from a citizen is checked against the vehicle's real GPS and pump telemetry. If there was no work on site, it counts as an SLA breach. That is the "no ghost workers" rule.
[ADD HERE: 2 or 3 real bugs or surprises from your build. Examples to cover: an IAM permission that failed, a Kinesis or IoT rule problem, a WebSocket or deployment issue on EC2, a model that did not train well. Write what broke, how you found it, and what fixed it. This is what readers and judges remember most.]
What we would do nextAdd sign-in for officers and citizens with Amazon Cognito. Today the prototype uses a shared API key.
Add OR-Tools route optimisation on top of our greedy dispatcher.
Put physical HawaTag trackers on the fleet, using the same IoT Core topic.
Try itLive demo:  http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000/ 
Backend API docs:  http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:8000/docs 
Which AWS services are live:  http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:8000/readyz 
Code: [ADD GITHUB LINK]
HawaCommand is a fully developed prototype, deployed on AWS. Every flow runs end to end, from a vehicle ping to a verified impact. Delhi does not need more machines. It needs to know where to send the ones it has, and whether it worked.