Gridspy Development

Most startups seem to embrace 60-80 hour weeks, you keep reading about them and begin to believe that this is normal. After 12 hour marathon coding sessions ‘typical entrepreneurs’ walk 10 metres from desk to bed and collapse in their shared accommodations. Living in such lean conditions makes those crucial first months of business far cheaper. This work ethic and minimial living costs maximises the runway before the seed money runs out.

Paul Graham is one of my favourite bloggers, and his essay entitled The Other Road Ahead he paints a clear picture of how lean a start-up can be, stating “You can literally launch your product as three guys sitting in the living room of an apartment, and a server collocated at an ISP. We did.”

No matter how much I’d love to take the lean ramen noodle approach it’s simply not practical for me. I’m a father of two, a husband of one, and an employee. I’ve got a beautiful family with young children, a modest house with a mortgage, and a full-time job to pay the bills. In short, I have a standard existence that I imagine many of my readers share. Living off noodles in a cheap apartment with my co-founders is not the only way that start-ups are built. I’ve taken an alternative route that involves just as much hard graft (harder maybe?) and allows me to remain employed full-time. The food sure is better!

I simply have to fit Gridspy into the gaps between the hours at work outside of the home and the start-up and the time put into fatherhood and being an available partner. It is a compromise position that I have had to maintain for the last year until Gridspy was ready. Along with the mandatory overtime, maintaining a full-time job limits my flexibility. I cannot travel to meet potential clients as easily or pick up the phone to talk to them. It markedly slows down progress. However, without the job there would possibly be no Gridspy, or less so than there is now, as there would be no base to develop from.

Despite my full-time commitments I still consistently work on Gridspy. As I mentioned in Selling the Dream I spend four evenings a week working on Gridspy (3-4 hours each one) plus all of Sunday and manage to make a lot of progress. Sometimes I spend my four hours on a blog entry, sometimes on some firmware or a little bit of Django code. Lately I have been creating the setup process for new users. There is a ton of documentation to do on our website - it all takes so much time.

Since my baseline existence is ‘family-man’ and a full-time job, I have had to pace myself with Gridspy. If I am not careful I will burn myself or my loved ones out (and trust me, we’ve been close at times) so I have to be the tortoise rather than the hare. At least doing a small chunk every night gives me a lot of time to think through technology decisions and plan my development.

Of course Gridspy is all that I want to work on and all that I can think about. This creates constant tension/wishful thinking in wanting to jump in both feet first and get everything up and running now, yesterday! It doesn’t help that this fully dedicated full-time start-up founder is also a widely published expectation.

But there are no savings to live off, and even though the almost three year old in my life would like to live on noodles for a bit, I don’t think I could for long. Being employed isn’t as simple as just turning up to my ‘day job’ and punching keys so I can pay the bills. I want, need, to be a ‘good employee.’ It takes conscious effort to honour my commitment to my employer. I remind myself everyday to focus on the work I do for them and to leave Gridspy at home. I’m sure you can see how after a long day at the office and after the chaos of the early evening with the kids, it can take a while to get down to the business of Gridspy. Sometimes all I want to do is grab a beer and turn on the TV.

I like my job, it has loads of benefits. Not least that I can afford to buy beer and have nice dinners and provide my wife and children with all the comforts of home. I have been given some great introductions to potential business partners through my well connected colleagues. I’ve had a group of fellow engineers to discuss my ideas with and sound out my features. Plus I’ve had lots of free coffee and idle banter around the water cooler to enjoy. The benefits of a stable routine and a reliable injection of cash into our bank account each month are not to be frittered away lightly.

But when it comes to developing my own gig, it is a chicken and egg problem. The sooner I take the leap and go fulltime with Gridspy, the sooner we can complete the features that are preventing us from doing a large scale release. But the moment I take that leap, the clock (and the bank account) starts ticking down. I have an extremely short runway and I worry that I could scuttle this opportunity before it has had a chance to take off.

Reading entrepreneurial blogs such as Paul Graham’s can make you think that you have to go fulltime or give up. I am taking an alternative route. By creating Gridspy part-time I have been able to give it the time and breathing room required to succeed. I’m starting to think that this path is the most courageous since it requires serious commitment to devote all your free time to your startup. In the end, I am sure that my compromises will pay off.

Please let me know in the comments what your own situation is like.

• Have you taken the leap yet, or is it not a viable option?
• When is the right time to do it?
• Are you also battling to keep it part-time even though you really want to take it fulltime?

Further reading:

• Selling the Dream, putting Sales before Software
• Introducing the Nexus

It is difficult to admit, but Gridspy is not yet complete. The physical prototypes of our new Radio device are not yet manufactured and much of the software is yet to be written. That has not stopped me from putting on my sales-person hat and describing Gridspy as a complete system. We know that everything will be finished running and ready for deployment in January or February next year, but it is not ready today.

Sitting down to develop new features for Gridspy is a real pleasure, but it has recently become a rare one. Marketing has quickly become essential to gather feedback from our clients and secure pre-orders. Trust me, there is no time-sink like marketing. Hours flash by as careful email dialogue takes place, meetings are arranged and executed, and promotional materials created. I started to forget how great it is to sit down and code for hours straight and my late hours quickly caught up with me.

Of course the marketing is a requirement and has had may benefits, not least the continuing refining of the product upon hearing client feedback. However, all of this takes time and our to-do list is now longer than our features list. Like any great product, there will always be something new to add. The pragmatic thing to do is to get out there and sell what we have now with an eye to the future. What we do have is our wired device (we call it Nexus) which is already installed and running in a couple of locations. But of course we want to have more, and we want to have it now!

Unfortunately we are not sitting on piles of cash just yet that would fund long uninterrupted hours of development. Without angel funding or a huge savings account to raid, I’ve continued my full-time programming job and am moonlighting for Gridspy. An average evening for me runs like this: cycle home after a long day as an employee, put the kids to sleep, talk to the wife and cram some dinner down, and then put in around 4 hours of work on Gridspy before crashing into bed. In that 4 hours I have to housekeep general operations, publicise, secure sales, and oh-yeah, develop the product! I also work as much of the day and night as I can on Sunday, leaving only Saturday for time-out with the family. Stephen isn’t moonlighting right now, but will probably have too soon. Here’s hoping that we can begin securing regular sales and devote all our time to development for some old fashioned bootstrapping.

When you are a software developer in a large organisation you remain isolated from the sales reality. The day that your new product hits the market a lot of work has already been done by other departments to build buzz and a ready clientèle. Programmers tend to moan about clients being promised features that are not yet complete, but that is simply the reality of sales. As a founder wearing many hats I have had to confront this reality and the early feedback gathered really helps to inform the design, and to assure me we are doing the right thing.

I’ve realised that striking a balance between publicity and features is essential. Your start-up can die either from incomplete solutions or from lack of exposure. However marketing efforts can quickly become very time consuming, slowing down feature development. The hard work is paying off and word is slowly and surely getting out there, be sure to tell your friends about Gridspy! It is now time to turn my attention back to features. Next on my list is the ability to push software updates out to our installed devices. That is an interesting problem involving flash drivers, firmware downloading and in system programming of our microcontrollers.

We are confident that we will hit our targets on the back of decades of hardware and software development, so no issues there. As hard as it is, selling our system while still in development is the only way to go. To my fellow entrepreneurs - If you haven’t tried to secure a pre-sale, why not? Are you secretly afraid that you product won’t sell? Better to test your business model now than after months of development time.

Talking to clients and selling early lines up really well with releasing early and often, creating something people want and validating your market. As you can see we already have our core features working and our wired solution (Nexus) is already deployed.

The word is out, Gridspy is coming and I can code late into the night in peace, just after I have finished this last email.

After deciding to cut down our power usage, we know exactly where to start. A quick trip around the home or office to turn off standby devices, shut down computers and set the Air Conditioning to less comfortable levels is all it takes - right?

So after doing all those things, you wait and wait and wait some more. Finally the power bill arrives and with luck, it is lower than the previous month. Usually it isn’t that simple. The bill is complicated by a change in the seasons, new appliances or computers or changes in energy usage patterns. It might turn out that you were using the electric oven more this month, or you spent more evenings out of town with everything turned off.

The obvious next step is to spend a lot of time looking at your power meter and determining how much it has changed since the last time you looked. Another option is to purchase a power monitor that sits on the counter top and tells you how much you are using right now. With Gridspy you can go one better and split your usage into separate channels and view the results on-line. Configure one channel to cover your lighting, another for heating and yet another for hot water.

By narrowing down which particular parts of your house consume energy and when, Gridspy helps you concentrate on the real power hogs. If you lower the thermostat on the water heating, the measurements on that channel will clearly show a saving. Put the appliances in your house on their own channel and hunt down those parasitic loads like cellphone chargers or the TV on standby.

With Gridspy, when you decide to shut down those computers at night you have real numbers to back up your efforts. Gridspy tells you exactly how much power the computers were using before, so you just study the graphs to see the dip in usage overnight. Hey presto! You’ve just saved power and cut your power bill. Best of all, you know exactly how much you saved - you can clearly see if that extra effort was worth it. It becomes possible to focus your efforts on those areas that have most effect on your power bill.

Most homes have two key power hogs : hot water and space heating. With Gridspy, you quickly get a clear picture of how much money you are spending on each. There are great power saving alternatives such as solar hot water systems and heat pumps. Once you know what you are spending on hot water, you can calculate how long it will take for the solar hot water investment to pay for itself. If you lead the rural life, you might even install a wet-back around your fireplace so you can heat water by simply lighting a fire. At the barrier house, we have a solar hot water system with a wet-back for the inevitable cloudy day.

In the office, power usage can be slashed by reducing Air Conditioning load, installing smart lighting and turning computers of while not in use. The challenge lies in backing these decisions up with hard data to get buy-in throughout the organisation. Gridspy can give you the data you need, and make power saving fun and interesting. When every single staff member can see the live data feed for their lights and plugs, they understand the impact of turning off the lights they don’t need and leaving computers off overnight.

When the time comes to renovate or build anew choosing the right building materials and methods will lower the lifetime costs of the new building. The New Zealand research consortium Beacon Pathway is currently performing extensive research into the means of building environmentally friendly houses. Beacon understands the importance of constant measurement to prove the performance of their designs, but collecting that much data without Gridspy is not easy.

Could you like to cut the power bills in your business? Gridspy can help you determine exactly how, and help to motivate your colleagues to take the necessary steps.

To me, ‘web 2.0’ is fresh, fast and fun. Gridspy is all about making power monitoring fascinating and accessible - that’s the goal. We’re talking numbers you can understand, graphs you can read and systems that you can intuit as you change the amount of power you use. Read on to learn how we deliver on our live data vision all the way from the Nexus to the browser.

Naturally like any sensor system, the data flow starts at the sensor. We have two sensor solutions - the wired Nexus and the wireless Gridspy. Both of these have several sensors that can clip onto the live mains cables in your house and the Nexus also connects to your home / office Ethernet. Every second each sensor takes 64 readings and uploads an accurate measurement of your power usage. Because home power uses the alternating current system to ease the transmission of power from generators to your house, power readings move up and down over time. The Gridspy system takes readings over several up and down cycles of your power and uses sophisticated mathematics to compensate for the alternating current to get nice smooth power readings.

Once plugged into a home or office Ethernet, the Nexus automatically detects the network configuration and establishes an outgoing connection to our servers. Once the connection is established, the nexus begins streaming live power data. What is really great about this scheme is that outgoing connections ensure that on most networks absolutely no configuration is necessary - our users do not have to expose the Nexus or any other device on the network to the general public to view their data on-line.

The nexus then collects those sensor samples from the nearby Gridspies, bundles it up with its own data and uploads it to our central servers. To collect the data we use a custom application written using the excellent Twisted framework. Every single reading gets instant attention: it is evaluated for real-time events, queued to be stored in the database and finally forwarded to watching dashboard users. Processing the data stream live on the server opens up many exciting possible features that I look forward to discussing in future blog posts. By the time that the sample reaches the server, it is about 0.2 seconds old.

Each time someone opens up a browser and starts viewing the data dashboard for a Gridspy (live power demo!), the dashboard makes a connection back to our server using a technology called Orbited. Orbited gives us a two way event-driven communication channel so our users can send messages to the server such as switching lights on and off while receiving those precious data samples back in real time. Through Orbited, our users subscribe to a “message queue” which efficiently sends power updates and other messages to all watching web browsers. We are currently using MorbidQ as our message queue for ease of deployment. If you want to set up a similar system, I thoroughly recommend this tutorial on Orbited, MorbidQ and Twisted.

So, the total time from taking a sample to seeing the result in the dashboard? It takes as much time as the power message takes to travel from your network to our server and the reading takes to travel back. For most people, this is a 0.2 to 0.4 second delay or less - it sure beats the old “poll the database every 5 minutes for latest readings” mechanism that I used in our early prototypes. The result? Power monitoring is fun and intuitive. If you hear the washing machine speeding up into a spin cycle, you will instantly see that reflected in your dashboard online. When you turn off those lights, you get instant feedback showing you exactly how much your power usage has dropped. This is the sort of feedback that motivates experimentation and power saving.

Power monitoring, meet web 2.0!

If you want more technical detail on any part of my system, please do drop me a note in the comments below. You can also follow me on Twitter.

If there is one thing that trying to make my own product has tought me, it is that the old sages are right. The key to success is to choose the very smallest possible subset of your features and focus with razor vision on that and only that. I have spent the last six months doing nothing else, discarding distracting feature after seemingly important improvement until only the key feature remained.

Over the last few months, my mantra has been "All I need is web-based graphs of power usage."

Well, I am proud to say that it has paid off. I have now got a system that can send live power data from our very own custom hardware to our twisted server, and have graphs rendered. It has been a hard slog, but now we have something that we might be able to sell... to one or two clients. I am fairly certian that even with promises of upcoming features we will not sell very many units until our system can do the other impressive things that we have planned.

Fortunately from here things only get easier. With all this key technology in place there are no new peices of the puzzle to add, just nice incremental improvements.

Okay, so who am I kidding? I have to master JQuery to get the live data working the way that I would like to... I have online billing and subscriptions to set up, Restful apis to develop, all manner of ideas and features that I would like to add. There are important features yet to add to the firmware. But we now have a system that we could install and it is enough to delight at least a few alpha testers. What they have to say about it will ultimately be what guides our decision of the very next thing to implement.

I like to think that a year from now I will look back on this blog entry and smile. Considering how far I have come already, by then our system will be very exciting.

When I look at the power monitoring market now, I see many companies providing cheap meters that do not tap into the power of the internet. There are meters that offer clunky online interfaces and cost the earth. The demand for internet savvy power meters is so strong that many do-it-yourselfers have forged a path with modified off the shelf hardware and garnered quite a following.

We are ready, and the market is waiting.

I have been programming in C++ for ages, so it would come as no surprise that I am comfortable with it. That however, does not make me god’s gift to database programming. I have tinkered with these mysterious beasts several times and always come away impressed at how much I could do with so little effort. With just a little SQL, an amazing amount of data just leaps from the hard disk into a handy table. So, with a little trepidation, I set out to design a database schema for the Gridspy power-monitoring system.

Of course, back then it hardly had a name. I personally called it ActiveCore, because it was the active core of your house. I think that Dad called it something cute, like 5301. He has a tendency to pick names like that.

So… have you heard of the Second System Effect?

If you have been lucky enough to work on a first system and found it enough of a hack - god help you if someone asks you to make a second system from scratch. It always turns into a huge heap of over engineering. This was true from the database schema to the code in C++ and it quickly turned what should have been a simple program into a nightmare. As it turns out, knowing about the fallacy does nothing to prevent you from committing it. There was a table for each idea, and expensive joins left, right and centre. You needed to join about 5 tables to determine which inputs to monitor!

It doesn’t help that I was up against a challenging problem. I wanted to monitor many sensors for a long time, at a high resolution. There are 86,400 seconds in the day - this multiplies quickly if you have 10 sensors and 365 days of history. Of course, this data should not be lost of the user decides to move or upgrade the sensor. The finished data table had indexes on all the fields I used (date, value, id, sensor id, and more!). At one point 5mb of data (for a single building no less) had over 100mb of extra data just to (in theory) accelerate lookups.

So, we have an over-engineered schema and C++ deamon. Now we just need to throw some real time demands into the mix. Naturally the design calls for a way to see how much power you are using this minute. On paper it looked great to put the database between the deamon and the website. In reality this led to the (relatively underpowered) computer maxing out the CPU.

We also have the ability to control outputs and switch lights. This was done by writing the new output state into a row in the database. However, I knew we had a problem when the deamon was taking ten seconds at a time to turn on outputs in response to inputs. At one point Dad turned on a light to go up the stairs and waited a little. He soon set off up the dark stairs and returned from his errand in time to see the light switch on. Trust me, this is totally sorted out now.

In retrospect it is so obvious. Instead of putting the database at the middle of the system it has now been relegated to its proper location - a permanent data store. While preferences and historical data is stored in the DB, live data and communications with our sensors are done directly with a custom server written on the Twisted framework, rather than having our sensors send many individual Django page requests. Each sensor establishes an ongoing connection with Twisted and streams data and other info. Twisted can then send back commands to the sensors, including setting outputs.

Because Twisted has an ongoing connection with the sensor, it handily punches straight through firewalls and NATs. I knew I had made the right decision about using Twisted when I controlled my first output. My http request went to Django, who passed a XML request to Twisted, which sent a custom message to the Nexus. The Nexus had instructed the output to turn on so fast that it seemed totally instant. No Database could do it quite that fast, not even with triggers.

I couldn’t recommend a language and framework more highly than Twisted Python. Now that I am feeling the power of Python, writing C++ is a total bore by comparison. Of course, as soon as something needs to execute super- fast I’ll be back into C++ for that little bit, but no need yet!

I now have a solution that can scale into thousands of sensors. Lets just hope I am onto the third system now.

Further reading:

My replacement for the database : Live power monitoring

Since the beginning of last year, my Dad and I have been hard at work on our own power monitoring system. It wasn't always for power monitoring, originally it was more about controlling the cool automated house on great barrier. It didn't take long to realise that just measuring power usage is a pretty cool feature in and of itself, one with minimal hardware costs.

A quick search around showed that there were not many people creating devices to monitor power. Those that were had features missing that we consider important, such as easy and open access to live data and web connectivity. Also, Dad and I love making things together so it quickly became a fun project. We have a great working relationship since I have been writing software for Dad's custom hardware since I was 13, usually for entrepreneurs under the guise of our company Technman.

The natural first step was to buy a power monitor provided by someone else (we choose a wattnode with a pulsed output) and connect it to Technman's range of IO modules. I wrote a Linux daemon that runs in the house and reads the power into a postgres database. A separate website reads the database and displays power usage as nice graphs. While this system works fine, it requires a PC running in the house all the time and it also requires each house to contain quite expensive hardware. The natural next step was to reduce the cost with some custom hardware.

Our first device - the "nexus" is planned to become the hub of our finished system. It is the master of an in-house or in-business radio network that links several of our devices together. The nexus then transmits live data from the house back to our server for logging, analysis and user interface. We chose to do it this way because we want to move the power hungry PC out of our customer's house and instead have the analysis (and data storage) in a central data centre. Moving the UI to the data centre also avoids problems with firewalls and will make it easier for us to iterate quickly on our features.

On the Nexus, we wanted low power, wired Ethernet connectivity and power monitoring. We are big fans of the 8051 micro controllers created by Silicon Labs. Along with their off the shelf Ethernet chips and oodles of technical design expertise creating a power monitoring system was not a problem. It has been a busy couple of months but as I write our first prototypes are being assembled for testing. We have already written most of the firmware using development kits provided by silicon labs, and have working code proving all the major subsystems.

One thing that makes us pretty unique is our live, on-line power data. Each nexus has an ongoing connection to our central server and streams sensor samples as they are taken. When someone is logged in to our website, we send them updates via JavaScript on a very regular basis. Well, this is the plan - but the Javascript bit is not implemented as of this writing. Because our power usage is totally live, it is practical for you to wander around turning things on and off with your iPod in your hand or your laptop. As you switch loads, you will immediately see the changes reflected on your on-line dashboard. The graphs are also updated often, so it is intuitive how they work (Update: have a look at a live example).

The high resolution graphs make it easy to understand the nature of your power usage. Some things use a lot of power while switching on but for a short time, such as toasters or kettles. When you bring home shopping and load it in the fridge, it uses more power. The washing machine uses different amounts of power depending on its current stage in the wash cycle. The dishwasher uses far less power in eco mode, and the hot water cylinder has to reheat the hot water for either of these appliances. These curves are easy to pick out. High resolution graph rendering is another feature I am looking forward to completing.

It is easy to see the patterns of your day in high resolution graphs, you will be able to see when you have a shower and use hot water, when you run the heater or when you make tea. You can see when you turn the computer on and the effect of the computer's power saving modes on your power consumption.

The Nexus can also control the Technman IO modules - you can turn your lights on and off from our website, or anything else you care to switch. If you decide to control something in your house (if you have control) then the Nexus will act on your instructions instantly. You will not perceive a delay unless you have a slow web connection. This really is cool, but you can't enjoy the effect from across the web!

Creating all this firmware and getting the systems to talk together has raised some interesting design challenges. I plan to write more about those in later blog entries. I have also put a lot of thought into how I will make a system that relies on lots of devices communicating with a central server scale over time.

To read about the challenges of streaming live data, see Database, meet realtime data logging

Have you ever been stuck in that horrible guess and check routine? You know the one - the page layout is just wrong and Firefox isn't quite reading your mind. You keep making small changes to the css but nothing seems to change. Suddenly you make the wrong change and everything is a mess. Trust me, I've been there too. I've also seen my fair share of inscrutable JavaScript bugs. As a C++ Veteran coming to all this fancy web stuff is fun but can quickly become frustrating when all you see is that nice opaque view that browsers tend to give our users.

The more information you can get about what is going on under the hood, the faster you are likely to find the problem that is causing you to spin your wheels. I love information and there is nothing more satisfying than seeing the bytes, words and requests that you created with your code flowing beautifully from client to server and back again. The modern web tools allow single stepping JavaScript, css changes on the fly and fully transparent HTTP request debugging.

Many of my favourite tools are plugins to Firefox, which just makes sense. You are using Firefox, right? Of course I understand if you are using anything else, as long as it isn't Internet Explorer. If you are Firefox-adverse, you might consider installing it just for these plugins.

First up - HttpFox. This plugin will show you the flow of requests between your computer and the server. Every time you hit a page or load an image in a page, every time you click in a form, even when your browser auto-completes a Google search you will see a request in HttpFox. You can see all the headers that were sent and the headers that were received and gain some insight into what is going on under the hood. I found this really useful when I was first learning how to send data to the server inside of a post request. If you want even more low-level insight into the traffic between you and the web server, I suggest WireShark. This is a standalone GNU tool that will expose all the communications between your computer and the outside world - dns resolutions and all!

Okay, so your web server has sent you a page... If only you could quickly change something on the page, or debug your javascript that should be modifying that paragraph. You can very easily do this with FireBug. With Firebug, you can see the current html, javascript and css files. You can also edit these files and view the in-memory version that javascript has modified. The Javascript windows feature breakpoints and other powerful debugging tools - at least more powerful that lots of alert("hey, I got here") statements!

For getting your css looking just right, I recommend Stylizer - it makes it possible to play with css, rather than getting frustrated. As as programmer who is always in a hurry, I don't have time to do css unless I can get a lot done quickly. Its interface shows the current webpage and immediately reflects any updates that I decide to make to the styling. It treats simultaneously treats the css like a text file, while providing a very rich interface to interact with it.

Overall, having the right tools can turn web development from being a totally frustrating experience to the wonderful, interactive and rewarding activity that you expect.

Far off the beaten trail, you will find the Barrier house. A perfect retreat from city living, it is nestled among trees high on a hill overlooking a bay on Great Barrier Island. Like most houses on the barrier, it is completely off the grid and has no access to the power grid, or council provided water and sewerage services. These are all facilities that have to be provided on site. There is no road access to the property, the only access is by boat and by foot. The construction process required a barge and a helicopter!

This home was designed with the goal of being environmentally sound. It is shaped and oriented to maximise the winter sun while avoiding the heat of summer, and most of the time you can choose the temperature by just opening or closing windows. To keep the house warm during the night and cool during the day, the house surrounds a slab of concrete that absorbs the heat of the day and releases it at night. The house is nestled among the trees and rises up just enough to afford spectacular views down on to the nearby bay.

Power is provided by a roof mounted solar grid supported by a generator for occasional use. Usually total consumption is the same as two continually running towel rails. Also on the roof is a solar hot water system. If the sun is behind a cloud, you can light a fire for more hot water and heat in the pot-belly stove that you can also cook on. The power system also has to support the rainwater and sewerage pumps - a challenging load since these pumps are most active when weather is bad and solar power is not available. Without a way to start the generator remotely the house could run out of power if left unattended.

From the start, the barrier house has driven the nexus’s design. The most important requirement is to be able to check power and rainwater status from town. Also important is minimising power use and predicting how long the house can run on solar alone before the generator will have to be used again. The $2 per kWh that it costs in fuel to run the generator far exceeds the 20c per kWh available in town so careful power management pays dividends here. Subsystems such as the satellite based internet connection are switched off when not in use.

From conception, the house was wired for control. Every light switch is individually addressable and every light is under computer control 24/7, accessible via any mobile phone or internet connection. We can monitor power usage, solar power collection and temperatures and will soon add information about water heating and usage. We already know that the fridge, computer, washing machine and vacuum all use the lions share of the power. Over time and with the nexus’s live feedback we learn more and more.

We can choose the level of access we give to our friends via the internet. They can look at our power usage but can’t control the lights, and if they are strangers they can only see time-delayed, low resolution data for privacy. We have complete control over how public or how private we are online and who is able to do what. When we come back from town we know that the batteries are full, the lights are on and everything is ready to go!