A little light on details. Seems like a a script that alters the site's DNS A records to point to the server with the greatest electrical input from solar panels.
> Solar Protocol is an art project exploring the poetics of internet infrastructure; as well as an education and research platform for exploring energy efficient and energy aware web design; and ecologically responsive internet protocols, among many other things.
It's one thing to consider energy use of a webpage (I'm guessing a lot of "slide show" functions chew up gigawatt-hours of electricity every year) but it's another to implement infrastructure which consumes power to save power.
One also needs to be wary of lost opportunity cost for equipment. Frankly, just put the money into funding for utility-scale solar installations where everything is more efficient.
utility scale anything is more efficient. That's why micro-farms will never take off commercially - the money and climate costs of transport are smaller than the savings from being a big farm rather than 20 cabbages on someone's roof.
Interesting illustration of the notion that the sun comes out reliably and that intermittency is a very local and seasonal effect. The aggregate power is reliable and predictable enough to host stuff and survive a little attention from Hacker News. It would be interesting to track the aggregate KWH used and correlate it with traffic.
Of course as practical thing this is not that important. Most big cloud providers are pretty far done transitioning to data centers that are powered sustainably. It will take another few years to complete this globally. E.g. Amazon is looking to use 100% renewable power by 2025.
I absolutely love this. It would be fascinating for a CDN to figure out the exact battery-size/latency-hit arbitrage points so that you could have a "follow the sun edge computing" model. People using your internet service mid-day get the full local low-latency performance as usual. Late-day/early-evening business similarly get full local performance from the battery for a few hours. Then evening hours the latency hit grows as the sun and therefore the pop you're hitting tracks further west. If you're the kind of person who goes to bed early, or maybe just watches streaming video when its late anyway, you'll never even notice the latency hit (I figure 50-100ms most of the time). The ability to geographically route/control your traffic and shift which pops are active is already an innate capability of a CDN. The vertical integration from solar panels to high-margin-saas would be economically fascinating. And the "green tax" would be negligible.
I am in the mix for doing this over the next week or so. Totally love the hardware documentation and after tearing down a 900w solar array experiment, and having most if not all the materials (in Buffalo no less) we have a new shed w/ the materials to get online and on it.
Pergola lighting, internet web server, and plant hydroponics .. fun fun! (sorry, really love this particular type of stuff, so nerding out like - go home right now from the day job and just get after it).
The charge controller is surprisingly large (to me) relative to the rest of the system. I don’t have much experience - is there a reason it needs to be, or is the charge controller significantly overspec’d for this 50W panel?
MPPT controller has a better communication set of commands and you'll notice the ethernet port that can send TX/RX out to a monitor or connect to a network. That's where the general $15-100 charge controller falls off the map - think Horror Freight.
Mind you there are some spectacular Chinese PCB designs / implementations out there for cheap, but off the shelf this is a fairly inexpensive / future proof / expandable unit should more power come off that.
I use something similar and have a wifi module that reports out to a dashboard in the house and can take remote commands from a phone if within bluetooth range.
very cool project. is it straight DNS (with very short TTL and the preference based on energy), or is it something like anycast (with preference based on energy rather than latency?
