Inspiration
We were interested in a simple mismatch: one home may have solar energy to spare while a nearby home has demand or a battery that could use it. We wanted to explore how a community could plan around that timing, while making the assumptions behind a proposed match easy to inspect.
What it does
SunShift NEM models a solar producer, a neighbouring buyer and a flexible storage task across 24 hourly intervals. It applies a peer-transfer limit and scenario prices, then compares modeled energy matches, grid imports and costs against a no-peer-match baseline.
This is a planning prototype. It does not trade electricity, control devices, settle payments or verify that energy was delivered.
How we built it
We built a local web app with a Python standard-library server and optimizer, plus a responsive HTML, CSS and JavaScript interface. The optimizer uses a deterministic dispatch heuristic to match modeled solar supply with demand while respecting transfer and storage constraints.
A local SHA-256 hash chain can record a proposed plan and detect edits to that record. It is not a public blockchain transaction. The default household profiles are illustrative; users can also provide a 24-hour CSV, or optionally load weather forecasts.
Challenges we ran into
The biggest challenge was keeping the demo understandable without making its estimates sound like real savings. Weather forecasts are not meter readings, a modeled match does not prove energy delivery, and scenario prices do not account for every network or retailer charge.
We also had to distinguish energy coordination from physical wiring: neighbouring homes remain connected through the existing grid.
Accomplishments that we're proud of
We built an interactive prototype that recalculates a 24-hour plan when its inputs change. It makes the hourly match, transfer constraint, flexible storage schedule and modeled comparisons visible, and can preserve a plan’s identity in a locally verifiable receipt.
We are proud that the prototype explains both what it can demonstrate and what it cannot yet prove.
What we learned
A credible energy-sharing plan needs more than a headline number. It depends on when supply and demand occur, how much energy the network can transfer, how flexible loads are scheduled, and how participants would be credited. We also learned to label modeled outputs clearly and avoid presenting them as measured climate impact.
What's next for SunShift
Next, we would test the planner with consented interval-meter data and validate the tariff, network-loss and settlement assumptions with an energy partner. We would then evaluate the results against a measured baseline and gather feedback from potential community participants.
Only after those steps would we explore device integrations, payments or a deployed smart-contract component.
Log in or sign up for Devpost to join the conversation.