Kisan Mausam: A Hindi-First Farm Weather Advisor Running on AWS EC2, with Offline Fallback for Rural India
Kisan Mausam turns open weather and climate data into Hindi-first, crop-aware hazard warnings for Indian farmers. This article covers the three-horizon risk engine, the grounded AI advisor, the offline fallback design, and how the backend runs on AWS EC2 with Docker.
The problem
A farmer in India is usually shown a temperature and a rain icon. What they need to know is what the next few days mean for the crop in their field: whether to irrigate, whether to delay spraying, or whether frost could hit a flowering crop. Many farmers also read little or no English, and rural connectivity comes and goes.
Kisan Mausam is an Android-first, Hindi-first app that connects meteorological data to action. It combines Open-Meteo forecasts, ECMWF seasonal outlooks, NOAA's ENSO index and IMD-inspired warning thresholds into short, practical guidance.
What the app does
- Weather dashboard: current conditions, a 48-hour strip, a 10-day forecast, and soil moisture for the farmer's GPS location.
- Hazard warnings: heavy rain, heat wave, frost and cold wave, hail and squall, and drought, graded from Advisory to Emergency.
- Seasonal context: a live El Niño / La Niña / Neutral status with a plain-language note on what it can mean for the monsoon.
- Crop recommender: ranks the top five crops from a 30-crop database by season, soil, terrain, irrigation and the 30-day rainfall outlook.
- Krishi Sahayak: a voice and text assistant that answers farm questions using the farmer's live weather context.
- Consent and privacy: granular consent flags and an account-deletion route, following India's DPDP Act 2023.
Architecture
The system is a hybrid client-cloud design. A Flutter client talks to a FastAPI backend, and falls back to direct calls to the public weather and AI APIs when the backend can't be reached.
[Insert architecture diagram here]
Client (Flutter, Material 3): a single-language dictionary (Hindi or English) so screens aren't cluttered with both. The theme uses high contrast for sunlight. Voice input and output use on-device speech-to-text and text-to-speech. Forecast and risk snapshots are cached locally, so the last known advice still shows without a signal.
Backend (FastAPI, async SQLAlchemy, Pydantic v2): REST routers for auth, farms, weather, alerts, AI and crops. A weather service wraps Open-Meteo with a short in-memory cache to avoid rate limits. SQLite is used on the edge and in development, and PostgreSQL in production.
How it runs on AWS today
The backend runs on an Amazon EC2 instance provisioned with a setup script and Docker Compose. Nginx sits in front as a reverse proxy, and Uvicorn serves the FastAPI app. A static Flutter Web bundle is served from the same host. The Android app is distributed as an APK through GitHub Releases, and a
version.json file lets installed apps check for updates and offer a one-tap install.This setup is simple, cheap and easy to reproduce. The trade-off is that patching, scaling and backups are managed by hand.
The three-horizon risk engine
The risk engine evaluates weather across three time horizons, using thresholds kept in a JSON config file so they can be reviewed and changed without touching code:
- Days 1 to 3 (high confidence): thresholds for heavy rainfall, heat wave, frost, and hail or strong gusts. Some thresholds are adjusted for crop stage, such as flowering and grain fill, and for crops that lodge easily.
- Days 4 to 10 (medium confidence): cumulative rainfall deficit or surplus and ensemble spread.
- Days 10 to 46 (seasonal outlook): rainfall and temperature anomaly probabilities from seasonal models, combined with the live ENSO phase.
Keeping the thresholds in a config file matters because they are the part that needs agronomic review. The values are modeled on IMD warning criteria and ICAR guidance, and should be checked against current official sources before anyone relies on them.
A grounded AI advisor
The assistant is not a general chatbot. For each question, the backend fetches the farm's live temperature, rain, soil moisture and active hazards, then passes them to the language model along with a system prompt containing safety guardrails and the farmer's crop and location. The reply comes back as short action points with the Krishi Vigyan Kendra helpline attached.
The current implementation uses Google's Gemini 2.0 Flash. The pattern (retrieve live context, constrain the prompt, return structured advice) is model-agnostic.
Designing for bad connectivity
The client tries the backend first. If it can't be reached, the app calls Open-Meteo directly, computes the warning thresholds on the device, and calls the AI API with the same context. Weather and risk snapshots are cached locally. For a farmer in a patchy coverage area, this is the difference between a useful app and a blank screen.
Alerts
When the engine finds a serious hazard, the dispatcher sends a push notification through Firebase Cloud Messaging and an SMS through a DLT-compliant gateway, with a 6-hour deduplication window so a farmer doesn't get the same warning repeatedly.
Lessons learned
- Put thresholds in config, not code. It made review and iteration far easier.
- Fallbacks need their own tests. The offline path is a second implementation of the risk logic, so it can drift from the backend unless both are tested against the same cases.
- Single-language screens work better. Showing Hindi and English together made the interface harder to read at a glance.
- Don't oversell forecasts. Seasonal outlooks have low skill, so the app labels them as outlooks, not predictions.
- Keep keys off the client. Calling SMS and AI services directly from the app is convenient, but it exposes you to abuse and cost. Route them through the backend.
Where managed AWS services could take it next (proposed)
These are not built yet. They are the natural next steps:
Need | AWS service | Why |
|---|---|---|
Database | Amazon RDS for PostgreSQL | Managed backups and failover instead of self-managed storage |
Scheduled hazard evaluation | Amazon EventBridge Scheduler + AWS Lambda | Evaluate every farm on a schedule, without a long-running server |
AI advisor | Amazon Bedrock | Keep the grounded-context pattern and swap the model behind a single interface |
Secrets | AWS Secrets Manager | Move API keys off devices and out of config files |
Static web and APK hosting | Amazon S3 + CloudFront | Faster downloads on slow rural networks |
Notifications | Amazon SNS | Delivery with the same dedup logic (SMS to India still needs DLT registration) |
Observability | Amazon CloudWatch | Logs, metrics and alarms for the API and jobs |
Try it
- Source code: https://github.com/kumarnikki/Kisan-Mausam
- Android APK: available from the project's GitHub Releases page
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article