Solar panels generate power when the sun is out, but household routines don’t always line up with that generation. A washing machine or water heater may run when the home is drawing more electricity from the grid.
SolarSync is my attempt to help households plan flexible appliance use around their rooftop solar. It takes a home’s energy profile and daily tasks, then suggests when those tasks could run based on expected solar generation, household demand, and each task’s time window and priority.
The idea is to make solar planning practical. A user should be able to say what needs to run and by when, then see a schedule they can act on. SolarSync suggests a plan; it doesn’t control appliances.
How it works
The user sets up a home profile with details such as location, solar panel capacity and orientation, household demand, and grid settings. SolarSync uses the location and panel details to request a solar forecast from Open-Meteo.
Users add tasks with their power use, duration, allowed time window, and priority. The backend uses Google OR-Tools CP-SAT to find a schedule that respects those constraints and the home’s load limit. It also calculates an energy summary so users can compare the proposed schedule’s expected solar use and grid import.
The stack
The frontend is React and TypeScript. The API is built with FastAPI, and Supabase provides authentication and PostgreSQL storage. The scheduler uses OR-Tools, and solar forecast data comes from Open-Meteo.
I also used the AWS SAM CLI to describe the backend as a Lambda function with API routes and build it locally in Docker. The template includes a Mangum adapter for FastAPI. I haven’t deployed SolarSync to AWS.
Getting the local SAM setup working surfaced an issue I had to diagnose: the Lambda handler needs its Supabase settings passed into the runtime environment. My first API request failed because those values weren’t available inside the container. That’s a reminder that a local run needs its own environment configuration, even when the app works through a regular development server.
What I learned
Building SolarSync made me think beyond “find a good time” and consider the constraints that shape a useful household schedule: deadlines, priority, power limits, and changing solar forecasts. It also showed me that deployment tooling is part of the project, not an afterthought. Packaging a FastAPI app for Lambda meant understanding how the handler, dependencies, Docker, and environment settings fit together.
SolarSync is still a suggested schedule rather than an automated device controller. My next step is to verify the full local SAM request path with the environment configured, then keep improving how clearly the schedule explains its recommendations.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article