Smart Plant Doctor, an ESP32 sensor stream feeding a React and FastAPI app
Smart Plant Doctor is an AI + IoT plant health platform that streams realtime ESP32 sensor data to a Streamlit dashboard and uses a MobileNetV2-based model for plant disease detection with treatment recommendations.
At a glance
- What is it?
- Smart Plant Doctor is a plant health platform that combines ESP32 sensors reporting temperature, humidity, light and soil moisture with a MobileNetV2 disease detection model and a Gemma 4 care assistant. It suits students and hobbyists building an IoT plus machine learning project, and its deployment assumes three hosted services rather than a single box.
- Who is it for?
- Adopt Smart Plant Doctor as a reference for a full stack IoT and machine learning project, since it shows the whole path from device token to FastAPI ingest to WebSocket dashboard in one repository, along with a trained MobileNetV2 model with its class mapping. Do not adopt it as a product to run, since the model covers six species and 29 disease classes, the chat assistant needs a Gemini API key, and the deployment assumes Vercel, Railway or Render plus Supabase.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 91 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
From a Streamlit prototype to a three tier application
Smart Plant Doctor is described as an AI plus IoT plant health platform, and the README documents a rewrite rather than a first release. The original was a Streamlit prototype kept at app.py, and the current version is a full stack React plus FastAPI application with Supabase authentication, live WebSocket dashboards and a production-ready API.
The table in the README that compares v1 with v2 is the clearest summary of the scope. The frontend moved from Streamlit to React with TypeScript and a Vite PWA. The backend moved from a single ingest.py to FastAPI with modular routers. Authentication went from none to Supabase with email and Google OAuth. The database went from SQLite only to PostgreSQL on Supabase, or SQLite for local development. The dashboard went from basic charts to live metrics, charts, care recommendations and a demo mode. Disease detection went from a Streamlit upload to a drag-and-drop interface with treatment cards and history. The chat feature is new, a Gemma 4 assistant with optional plant context. The encyclopedia is new, covering six species. Device management gained onboarding, multi-pot support and WebSockets. And a community disease map was added, with anonymised geohash reports.
The project is by Priyanshu, the homepage is smart-plant-dr.vercel.app, and the repository has no GitHub releases, with the last push on 2026-07-24.
The data path from an ESP32 to a browser chart
The architecture diagram in the README is short enough to hold in your head, and it is worth reading because it shows where the boundaries are.
Sensor readings go from the ESP32 devices to POST /api/v1/ingest with a device token, then to the FastAPI backend, then to PostgreSQL or SQLite, and out over a WebSocket to the React dashboard. The live feed endpoint is a WebSocket route at /api/v1/ws/plants/{id}, so each plant has its own channel.
The dashboard metrics are the ones you would expect from a potted plant: temperature, humidity, light, soil moisture and a computed plant health score.
Two other flows run in parallel. A leaf image upload goes to POST /api/v1/diagnose, hits the MobileNetV2 model in ai/inference.py, and returns a disease with a confidence and treatment recommendations. A plant care question goes to POST /api/v1/chat, hits Gemma 4 through Google AI, and comes back as contextual advice built from the sensor and diagnosis data.
The rest of the API surface is conventional: GET and POST on /api/v1/plants for listing and adding plants, GET on /api/v1/diagnose/history, GET on /api/v1/encyclopedia for species care guides, and POST on /api/v1/ingest for the devices.
The firmware side is PlatformIO, in the firmware/ directory, with NVS token storage and multi-pot sensor support. You set WIFI_SSID and WIFI_PASSWORD in platformio.ini or in src/main.cpp, flash with pio run -t upload, then register the device in the app UI and claim it with the device token.
A MobileNetV2 model with 29 classes across six species
The disease detection model is a MobileNetV2 backbone in PyTorch, with the inference wrapper called SmartPlantDoctor living in ai/inference.py. Input size is 224 by 224, and the output is 29 plant disease and healthy classes, with a validation accuracy of around 92.37%.
The class breakdown per plant is in the README, and it is the number to look at before you trust the output: Rose has 8 disease classes, Hibiscus 4, Aloe Vera 5, Money Plant 4, Chrysanthemum 3 and Turmeric 5. Six species, 29 classes in total. A model that only recognises those six plants will still return a confident label for something that is none of them, so the health score and the confidence percentage matter more here than they would for a model with broader coverage.
The exported artefacts are committed, which is what makes the project runnable without a training pipeline: ai/exports/smart_plant_doctor_model.pth and ai/exports/class_mapping.json. The MODEL_PATH environment variable points at that checkpoint, and the Dockerfile copies the whole ai directory into the image with AI_ROOT set to /app/ai.
The chat assistant is a different model entirely. Gemma 4 is reached through the Gemini API, so it needs GEMINI_API_KEY, and it is described as taking live sensor context as optional input, which is what makes its advice specific to your plant rather than generic.
The other features are unglamorous and useful: a care journal for logging watering, fertilising and repotting, and a disease map built from anonymised geohash reports.
Running the backend, the frontend and the firmware
The prerequisites are Python 3.11 or newer, Node.js 18 or newer, and a Supabase project for auth, with the setup guide for that in docs/SUPABASE_SETUP.md.
The clone is straightforward:
git clone https://github.com/GitHpriyanshu23/Smart-Plant-Doctor.git
cd Smart-Plant-DoctorThe backend is a virtual environment, a requirements install, a copied environment file and uvicorn:
cd backend
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp ../.env.example .env # configure DATABASE_URL, SUPABASE_*, GEMINI_API_KEY
uvicorn app.main:app --reload --port 8000The frontend is the same shape:
cd frontend
cp .env.example .env # add VITE_SUPABASE_URL + VITE_SUPABASE_ANON_KEY
npm install
npm run devThen you open http://localhost:5173, and the README describes the path as landing page, sign in, dashboard.
The backend environment file needs DATABASE_URL, which can be a PostgreSQL connection string or the local fallback sqlite:////tmp/smart_plant_doctor.db, plus SUPABASE_URL, SUPABASE_JWT_SECRET, GEMINI_API_KEY and MODEL_PATH. The frontend needs VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY.
The root requirements.txt is the union of both worlds, which is worth knowing: torch, torchvision, torchaudio, numpy, pandas, scikit-learn, matplotlib, pillow, tqdm, pyyaml, tensorboard, torchmetrics and jupyter, alongside streamlit and streamlit-autorefresh for the legacy prototype, plotly, requests, fastapi, uvicorn and pyserial. Installing that file pulls in the machine learning stack even for a run that only needs the API.
Deployment across three platforms, and a Compose file for local work
The deployment table splits the application across three hosted services: the frontend on Vercel, the backend on Railway or Render, and the database and auth on Supabase. The repository backs that up with railway.toml and render.yaml at the root, plus vercel.json for the frontend.
For local work there is a Docker Compose file with three services. A postgres:16-alpine database with a named volume for the data, a backend built from./backend on port 8000, and a frontend running on node:20-alpine with npm install and npm run dev on port 5173, mounting the frontend directory so the code is live. The backend service sets DATABASE_URL to the internal Postgres host, passes a CORS_ORIGINS list covering localhost:5173 and localhost:3000, sets MODEL_PATH to /ai/exports/smart_plant_doctor_model.pth, and mounts the ai directory and the uploads directory.
The backend Dockerfile is built for a small image on Railway. It starts from python:3.11-slim, installs libpq-dev and gcc, and deliberately installs a CPU-only PyTorch build from the CPU wheel index, with a comment in the file explaining that this keeps the image small by avoiding multi-gigabyte CUDA downloads. The runtime then copies the backend app, the Alembic migration directory and alembic.ini, sets PYTHONPATH to include both the app and the ai directory, exposes port 8000 and starts uvicorn on 0.0.0.0.
That CPU-only decision has a consequence worth stating plainly. A CPU inference of a MobileNetV2 at 224 by 224 is entirely workable for a single uploaded image, but it is a different proposition from a camera feed running continuously.
Editorial conclusion
Adopt Smart Plant Doctor as a reference for a full stack IoT and machine learning project, since it shows the whole path from device token to FastAPI ingest to WebSocket dashboard in one repository, along with a trained MobileNetV2 model with its class mapping. Do not adopt it as a product to run, since the model covers six species and 29 disease classes, the chat assistant needs a Gemini API key, and the deployment assumes Vercel, Railway or Render plus Supabase. Before you build on it, read the environment variable tables for the backend and the frontend, keep MODEL_PATH pointing at the exported checkpoint, and note the licence field is one GitHub cannot classify even though the README states MIT.
Frequently asked questions
What does Smart Plant Doctor actually do?
It combines real-time environmental sensing from ESP32 devices with image-based disease detection and an AI plant care assistant. Sensors post readings to the ingest endpoint, the FastAPI backend stores them, and the React dashboard receives them over a WebSocket, while a MobileNetV2 model diagnoses uploaded leaf images.
Which plants and diseases does the Smart Plant Doctor model cover?
The MobileNetV2 model outputs 29 plant disease and healthy classes across six species: Rose with 8 disease classes, Hibiscus 4, Aloe Vera 5, Money Plant 4, Chrysanthemum 3 and Turmeric 5, with a validation accuracy of around 92.37% at a 224 by 224 input size.
How do I run the Smart Plant Doctor backend and frontend locally?
Clone the repository, then in backend create a virtual environment, install requirements.txt, copy .env.example to .env and run uvicorn app.main:app --reload --port 8000. In frontend copy .env.example to .env, run npm install and npm run dev, then open http://localhost:5173 and sign in.
Which environment variables does Smart Plant Doctor need?
The backend needs DATABASE_URL, SUPABASE_URL, SUPABASE_JWT_SECRET, GEMINI_API_KEY and MODEL_PATH. The frontend needs VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. The example file also lists PUBLIC_API_URL, CORS_ORIGINS, CONFIDENCE_THRESHOLD and the Blynk IoT token and server.
How is Smart Plant Doctor deployed?
The frontend goes to Vercel, the backend to Railway or Render, and the database and authentication to Supabase. A Dockerfile builds a CPU-only PyTorch image for the backend, and a docker-compose file brings up Postgres, the backend and the frontend together for local work.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/githpriyanshu23-smart-plant-doctor)Was this useful?