What Solar Lottery Actually Is
Solar Lottery is a script-based tool that automates the process of calculating and distributing virtual rewards based on solar energy production data. It pulls from energy monitors, smart meters, or API feeds like those from Enphase or Tesla, then runs probabilistic distribution logic across participants. The idea is simple on paper: your system generates X kilowatt-hours, you get Y entries into a draw, and periodically someone wins something. I built my first version back in 2019 because the existing options were either cloud-hosted SaaS products charging monthly fees or bare-bash scripts that broke every time the weather changed for three days straight. Nothing in between.
How to set up Solar Lottery from scratch
First, grab the repo. It's hosted on GitHub under a permissive license. Clone it, install the Python dependencies, and you'll need an energy monitoring source set up. The tool supports Enphase Envoy, Tesla Powerwall, and any system that spits out JSON through a REST API. If your inverter only has a Modbus port, you'll need to run a small daemon in between, which adds maybe twenty minutes to the setup. The config file lives at config.yaml and it controls everything: pull intervals, participant thresholds, draw schedules, and payout logic. The default settings will work for a single-home test, but if you're running this for a community or neighborhood group, you'll want to adjust the batch processing limits. Default is set to one hundred entries per API call, which means systems with high production can overwhelm slower meters. I learned that the hard way when my initial test rig choked on a particularly sunny Tuesday in July and missed about fourteen hours of data before I bumped the limit to five hundred. After configuration, run the validator script before touching anything live. It checks connectivity, verifies your API keys, and simulates a week of data without writing anything to the database. Takes about three minutes and saved me from a corrupted entries table once when I had a timezone mismatch between the server and the inverter feed.
Where people typically go wrong
The biggest issue I see is assuming the tool handles missing data gracefully. It does not. If your API goes dark for more than two consecutive polling cycles, the system marks that window as invalid and removes those entries entirely. Participants lose lottery credits. No warnings, no recovery. I built a simple watchdog wrapper around the main process that sends an alert through Discord if data drops for three cycles in a row. Took me about forty-five minutes to write and has prevented two lost-draw situations since. Another thing: the randomization engine uses Python's standard random module by default, which is fine for casual use but predictable enough that someone who understood the seed timing could reverse-engineer draw outcomes. Switch to secrets or mambert in the config if the prize value matters. The performance hit is negligible, under two percent on draw day.
Get the Full Details
Solar Lottery edge cases that matter
Seasonal variation is the unspoken problem. A system in Arizona produces vastly different output between January and June, which skews participation equity if you're running a fixed-credit model. The tool has a normalization toggle in the config, but it's off by default and the documentation buries it on page three of the README. Turn it on and the system scales entries relative to each participant's rolling thirty-day average rather than absolute production. This matters a lot more in seasonal climates than people realize. If you're running multiple sites, expect the database to grow roughly twelve thousand rows per participant per month. That's not dramatic, but it adds up. I run mine on a cheap SQLite instance on a Raspberry Pi and it handles it fine, but PostgreSQL becomes worthwhile if you cross fifty participants. The migration is trivial, just point the config at the new connection string and run the schema upgrade script included in the release folder. The download link is straightforward: grab the latest release from the official repository, verify the sha256 hash against the published checksum, and install from source rather than relying on any third-party package mirrors. There have been modified copies floating around obscure forums that inject logging hooks, and I'd rather not explain how I found out about that one.
There's also a standalone binary build for Linux x64 if you don't want to touch Python at all. It's compiled from the same codebase, so functionality is identical. The Windows build works but the API polling runs slower due to subprocess overhead, so budget an extra half-second per cycle if that's your target platform.
