Gridspy Development

Out of 'the Garage' and into an Office

2010-07-06T00:38:03Z

I’ve moved office again. When I first left full-time employment for a company I had just begun my exciting new life as a self-employed programmer working in the comfort of my own home. The commute was excellent, the environment comfortable and the space affordable. For the months up until that move I had been a part time entrepreneur working 60 to 70 hour weeks (plus father time) and it had taken its toll. I was mentally exhausted, unavailable for the kids and my wife, and stressed out.

When ‘working from home’ I bounced back to normal 40 hour weeks, with time spent either contracting to pay the bills or working on Gridspy. The change in environment and focus improved my mental state and allowed a lot of progress. But then the honeymoon ended. I have discovered that home is an environment rife with distractions, unfortunately all from people I love. We settled into a routine of the toddlers and their mum going out each morning and then returning at lunchtime to spend the afternoon at home. Towards about 3pm the household becomes progressively louder as the toddlers become more tired and amp up their behavior. When this happened, it became extremely hard to resist lending a helping hand.

]]> The morning should have been a peaceful working haven, and to some degree it was. However, as discussed by Paul Graham in the makers schedule it is hard to program towards a fixed point in time - and in my case the toddlers return was not completely certain. When my little 3 year old walks through the door the last thing I want to do is to ice him out, I want him to know how special he is to me. As my office is in the major shared living space (that’s right - no doors or walls to shut out distractions) the kids can always see me. In general they are good at understanding that I am working in ‘the office,’ and leave me alone. But boy can they be loud. The afternoon would be too loud to call people on the phone, and having my co-founder over to discuss Gridspy was both a lot of traveling and was difficult since the kids wanted to get involved.

To help with the afternoon noise I purchased noise canceling headphones, which substantially reduced the kids racket. They didn’t cancel out the direct requests when the kids climbed into my makeshift office in the middle of the lounge. When my stress levels would rise my wife reminded me that I was still getting a lot done despite the short working days. However, I ran into another roadblock. When faced with a particularly big new programming challenge I found it hard to get started on my working day. I’d avoid the work at hand with simple home chores and comfortable distractions such as making a nice espresso coffee. On hard days I would find it difficult to separate work and home and would mooch around not getting much of anything done. Not being available for the family (because ‘I’m working’) but not applying myself either.

The challenge that finally defeated me was implementing the Automatic Reprogramming of our devices in the field - a sophisticated and complex system required before we can sell widely. As big tasks can do, it simply felt too big. I found myself unable to approach the problem from a manageable angle. I needed to talk it through with my co-founder Stephen in a regular fashion whilst completing the task. It was this, along with hungering after an office with fewer distractions, that prompted a move.

Realizing my roadblock and envisioning all the benefits of working in our own office together I spent an hour on the phone talking it through with Stephen. We decided that a quiet shared working space would afford us many benefits, to name a few:

Communication would be simple and natural, meaning we would stay in sync
More motivation to continue working, since the constant reinforcement of demonstrating progress to our partners would keep us excited about our current tasks.
No distractions from the work at hand, an entire day of concentrated working for us to split up as we choose.
Make Gridspy feel more like a real entity
Simpler to maintain relationships with clients, since we would have a quiet talking environment and could easily collaborate on each customer’s unique situation.

And hopefully: - An address we would be willing to publish, expecting guests to just drop in - Some conveniences of an office - Better work / life separation

It looked like a serviced office would suit our needs well. Since there are only two of us all we need was space for a couple of desks and access to facilities such as phones, Internet, a kitchen and bathrooms. We considered incubators but we didn’t like the idea of the distractions and financial issues that might arise, plus we want to try it ‘on our own’ for a little while before we pay the steep equity cost of such arrangements. We also considered renting an apartment or renting a spare room but that would lead to distractions at certain times of day and wouldn’t give us a location that we would want other people to visit.

Once we had decided that we wanted a serviced office, I had to arrange one that instant. I’m one of those people who constantly toggles from ‘sure, whatever’ to ‘hell yes, right NOW,’ in a short space of time. Stephen and I chatted about offices on Monday, visited my shortlist on Tuesday, signed contracts on Wednesday and moved in on Thursday for our first working afternoon.

I feel we lucked out with our new serviced office. They had a high vacancy rate due to a successful client recently “graduating” and vacating several offices, so there was a generous discount. They were flexible, courteous and professional and had a lovely space for us with plenty of natural light. They even provided us with enough furniture to make the move easy. Our other shareholders (that’d be the wives) have both voiced their approval of our office choice.

It has only been a fortnight but our office already feels like a lovely home away from home. We have settled into a nice routine of planning in the morning, coding until 3pm and then an afternoon of troubleshooting or client calls. We love all the little office comforts, from a great shared receptionist to instant boiling hot water on tap. Working together has been even better than we hoped, with several long-term unresolved issues handled in the first couple of days. It is now much easier to pass software and hardware to each other and to draw on each other’s strengths.

One unfortunate side effect of moving out of home has been the lack of a spare computer in the evenings and weekends. Since I primarily use desktop computers, bringing the computer home at night would be a huge pain. The absence of my computer at home has led to the an unexpected benefit of no guilt about taking the night off. I have had the most relaxing evenings over the past week as I arrive home happy after a good day knowing that I cannot, and considering the full workday I’ve had, should not be working after work. I guess that work-life separation really is important.

Stephen and I have enjoyed the best working week that we have had since we started working on Gridspy together. Concentration has been easy, meetings natural and productive, and goals both set and met. I’m proud to say that I have made solid progress on the auto-updating. I know my hourly worth based on my contracting rate and it only takes half an hour or so saved each day for the office to pay for itself handsomely. I’m confident that the mental health benefits and the way it has allowed me to work solidly has been worth the cost. My toddlers vehemently disagree, with several calls containing pleas for “daddy come home now” . It breaks my heart but it must be done, honestly it is bliss to be able to hang up the phone and work in silence.

I still have to grapple with some of the issues I raised when I mentioned my move to Full-Time Entrepreneur - especially my illogical expectation that we can move a mountain in just one day. Gridspy has a frustrating amount of plumbing required to create a complete solution and it feels like it has already taken forever. In only a month now we will be ready to launch our shop and sell Nexus internationally, I’ve got the merchant account and paperwork to prove it. All we need to do now is to make the Nexus hardware rock solid and then we can open the store. Profitability and the associated independence feels so close now that I can taste it.

Firmware Auto-Updates for GridSpy

2010-07-01T03:30:05Z

I’d like to dive into some technical detail today about those automatic updates that everyone takes for granted.

If you are a web developer, I wouldn’t blame you for thinking that deploying updated software is (mostly) painless and simple. Once the latest version of our code is live on the server, all our customers are essentially updated. Because a web developer can control the set-up of the web server it is very easy to deploy quickly and predictably.

Even the desktop folks have it pretty easy. There are lots of automated ways to check for new versions of code, and just as many ways to install the latest version onto the client’s PC. If things go wrong, as things often do due to both human and hardware issues, there is a human involved who can interact with the computer to fix things.

]]> Then there are hardware devices, each with their own custom communications system. Although hardware vendors completely control the design of the hardware, there are very few standard tools and these devices range from hard to access to impossible.

Since GridSpy is a hardware solution combined with a web service, we live at both extremes. On one side we have a web server that is easy for us to update, so keeping all our clients on the bleeding edge is a snap. On the other side we have our custom hardware devices that are to be installed in homes and businesses around the world. Most of these devices will be rarely accessed by humans, they are out of sight and out of mind in a locked cabinet somewhere.

Now that would be just fine if we didn’t want to continually add new features to our products. For example, we’d like to add info on the GridSpy dashboard showing glitches such as surges and transients in your power supply. To support this new feature we’d need new code in our Nexus to detect, log and upload these transients. It is a rare feature that does not require any changes at all to the firmware, and a lot of our competitive advantage comes from having a completely flexible smart device installed in our customer’s office. Without a remote update we would either have to ship new Nexuses to all our clients whenever we performed a firmware update leave or our early adopters behind as our solution evolves. A remote update gives us the agility we need.

There are also selfish reasons to keep all our deployed devices up to date. Each of our devices calls home and interacts with our server code 24/7. Our ongoing communication channel allows us to instantly “Push” instructions to the Nexus. This lets us deploy a wide range of interactive features from instantly switching loads, opening windows to setting the temperature in your building, all from our web interface. If we didn’t upgrade all our devices then the server would need to work with every version of our code that we ever release. So deploying firmware updates in a timely manner saves us effort as we only need to worry about support for the most recent few versions.

The microcontroller at the heart of our devices stores its instructions in 64kb of flash. This web page alone takes up more than double the size of our compiled code. The instructions are like any other file on your computer, just a lump of data that has to be copied into the microcontroller exactly right. There is no operating system on there so every instruction on that chip is our responsibility. On the lab bench, or in the factory, we use a debugging interface called JTAG to load the code into the chip. But we can’t use JTAG in the field since we’d need physical access to every Nexus any time we wanted to deploy an update.

Fortunately for us there is a mechanism inside the microcontroller where we can ask it to reprogram one of the flash bytes and store a new value. We have to erase the surrounding ‘page’ of 512 bytes before we write new data. Since the microcontroller reads instructions directly out of flash, we must ensure that we do not erase the code that is currently running. With this facility it is possible to install a new code version into the chip, but first we must handle all the detail of getting the code into the chip and creating the reprogramming process.

So how do we load new code into a microcontroller? The trick to a self-reprogramming microcontroller is to separate the reprogramming instructions from the actual application, kind of like storing two files side by side. These instructions become two separate programs that share the flash - the main program and a bootloader that faithfully takes care of it. Most of the time the bootloader stays out of the way. Occasionally the main code asks the bootloader to load new code.

At GridSpy we ensure that there is plenty of memory space external to the microcontroller to store lots of your power samples and other data. Before the bootloader is invoked we transfer fresh code from the server to the Nexus and save into our memory space ready to load. The bootloader finds this code and checks to ensure that it is valid. It then writes a note to itself at the end of the memory used for code so that it remembers the version of both the new and old programs. It then begins copying the code itself. When finished the bootloader crosses its digital fingers and starts the new code.

It is crucial that no matter what happens the Nexus successfully wakes up and reconnects to our servers. The worst possible situation would be to permanently “brick” a Nexus in the field, especially if that Nexus is hard for our customers to access.

We have several mechanisms to prevent bricking a Nexus

When the Nexus turns on, the bootloader always gets a chance to check the main program before it starts. It quickly checks its own notes to see if there is a complete copy of code loaded or it was half way through a reprogram. If the main program is incomplete the bootloader will continue copying the flash code into memory. Once the bootloader is convinced that the code on the micro matches the image sent to the Nexus by our servers it will start running the new code.

But what if the new code is bad? There is always the possibility that we accidentally send out code for updating that is not ready for prime time. It is a human mistake that can happen all too easily in the heat of the moment. Should we get this wrong, hundreds of Nexuses across the world could upgrade to this new version and then fail to call back to the server. The reasons could be subtle and this may only occur on certain devices, say those manufactured at a certain time or with features that were disabled in the factory. We would like our Auto-Update system to detect ‘bad code’ and automatically downgrade to the previous working version.

But how do we know that the code is good? To us, ‘Good code’ is code that can call back to our server, code which we can upgrade later over the wire

So, after a reprogram the Nexus must call into the server and once it is happy that the nexus is functioning correctly the server gives its seal of approval. We can add as many checks on the server side as we like before we ‘okay’ the upgrade. If the Nexus reboots several times without getting a seal of approval, the bootloader then downgrades the firmware to the latest working version. Combined with a “watchdog” which reboots the Nexus when it crashes, we can be fairly sure that a Nexus with bad firmware will spring back to life some time later.

Finally, the rollout of new firmware is carefully monitored server-side. The first nexuses to be upgraded are those that are physically easy for us to visit - those at our beta tester’s homes, our own homes and at clients here in Auckland, New Zealand. From there we ensure that we roll out the new version gradually. If too many Nexuses fail to upgrade correctly we will halt the rollout until we have checked the situation ourselves. This ensures that it will be hard to brick a great number of Nexuses in one go.

As I publish this blog entry I am hard at work on our Firmware Auto-Updating system, which as you now know is a subtle and complex beast. It remains one of the few hurdles that we must cross before we can offer our devices for sale across the world or in large volume.

If you would like to learn more you could read how GridSpy has up to the second data, why we manufacture custom sensors or just check out the GridSpy homepage.

Also, did you notice that the images above are clickable?

Breaking Away From 'The Man'

2010-06-01T03:13:49Z

Life got very interesting one and a half months ago. I had a meeting with my employer where he sat me down and asked me if GridSpy was ready to survive without my salary. Essentially he asked me if I was ready to leave and take GridSpy full-time. Being an VC funded entrepreneur himself he knew how hard it is to make that initial leap into full-time start-up and gave me a gentle nudge “out of the nest.”

After that meeting my mind was racing. My wife and I agreed that taking GridSpy full-time was absolutely exciting but equally frightening. We’ve been tightening our belts for some time to get ready for bootstrapping but even we don’t know how soon GridSpy will transition from a ‘sure thing’ to a trading business. I assured her that I could land on my feet with a contracting job should the money run out.

]]> So with much trepidation I decided that it indeed was the time to leave.

With a month’s notice given, I served out the notice period with tense anticipation, mostly worrying about the money. It turned out that the money problem soon solved itself. A friend of the family runs a stealth start-up which now had need of a contract programmer, and it was suggested to him that I would fill the role..

So the plan was to serve out my notice and start the contract after a well deserved full-time month on GridSpy. It soon came to be that my new client had an urgent need for my services - arguably more urgent than our own start-up for at least a couple of weeks. As a founder, it was a real heart wrenching experience. With complete control over my time I have decided that cash in the hand now to build initial stock is worth delaying our product just that little bit longer. I’ve also had a nice little splurge, for instance getting the required noise cancelling headphones.

It has been four weeks now since my last day as a salaried employee and I’ve had a great time. For the first time in ages overtime has been optional, working conditions are in my control, and opportunities are endless. However, the opportunities being endless thing has taken me away a little, well a lot, from GridSpy. These last four weeks have been great for my client but not so great for GridSpy. I have really enjoyed the programming challenges of the contract work, but I really haven’t spent any more time on GridSpy than I would have before. I seem to have exchanged one full-time job for another. Again I appear to be working for ‘the man.’

However, my working conditions now are much better. I’m working from home on my favourite sort of problems with my four screens. After a 5 step commute from the kitchen table to my office in the morning I work solid until lunchtime. The afternoon starts late after lunch and a play with the kids and is occasionally interrupted by one of my gorgeous children demanding a cuddle. Dinner is at 5pm and since that tends to work out as a 6.5 hour day I often work an odd evening too. Even though it seems like a short day I have found my output is huge. I am really able to totally concentrate and complete tasks in a way I enjoy. I’m much happier and I’m spending much more time with my wife and kids - that’s great!

Back when I was a Part time entrepreneur I constantly dreamed of the day that I went full-time. How much easier it would be when I could work on GridSpy and not have to stop. When looking at schedules of when the next feature would be ready I could wistfully say “well, it will take a long time but only because I can’t work on it full-time.” Although it was true, it was also a very convenient excuse.

Now I have exactly the opposite problem. With complete control of my time comes an equal amount of guilt when progress on GridSpy doesn’t suddenly take off. Since late last year I have been eternally thinking that we are only two months away from a product that is worth selling, and today I would make the same claim. What we do have today is a fantastic product and a handful of very happy clients. Today our Minimum Viable Product is pretty refined. It is focusing all my energies into those two months, or what it takes to get GridSpy out there, I am now struggling with. This has been a surprise for me.

Each week I can choose how much to work - somewhere on the slider from “Instant Cash Today” to “Successful business tomorrow.” It doesn’t help that I love my contracting job. I had better set the slider back to “Successful Business” before we run out of time. To do that requires the ability to say “No.” No to fun contracting tasks, No to quick cash, No to partnerships that require a lot of time on our part, and No to distracting marketing. But how do I break away from ‘the man’ when I actually really enjoy the work (and the cash too.)

Reflecting on what I have written I can see that I need to reduce the contracting work to the point where it pays some bills only, and spend as much time as possible putting GridSpy as a finished product into the marketplace. Well, after this particular contracting task is over that is.

A PC in Every Power Cabinet - aaahhhh......No.

2010-02-21T09:12:18Z

Currently Gridspy has a centralised server where each user gets a dashboard online to read their power usage. Originally we planned to have these dashboards hosted inside each building on simple servers. Our first prototype simply used a small PC, our IO range and simple sensors. The PC logged the data and also hosted the dashboard.

It seemed sensible at the time. It seemed easier to have one device both logging data and providing a website. A locally hosted dashboard would ensure a nice fast connection between the user and the dashboard. We found ourselves a nice cheap low power PC and created a nice blend of custom software and great open-source technology. The custom part was a sensor-polling database stuffing daemon. This plan let us develop rapidly and we planned to take it to market.

]]> These cheap PCs each need a power supply, case and hard disk drive. Once the hardware is in place we then spend hours setting up a reliable software configuration and installing it onto each PC. But it soon became apparent that this was going to get annoying, fast. With this system we open ourselves up to the possibility of 3rd party reliability issues. Most cheap PC owners expect to reboot often, but we wanted uptime measured in weeks. I shudder to think how difficult it would be to maintain 1000 PCs in the field. Think of all the failing hard drives.

Also it turns out low power computers are not as green as we thought. These little power hogs would sit there 24/7 chewing up the very power we are trying to save. We also had a performance problem. Our clients expect a very fast response in their web browser, but they use that interface extremely infrequently. In that 0.1% of the time they are waiting for their dashboard to load they want the very best performance. Computers that excel in bringing so much data together in a short time require expensive, power hungry hardware. Our compromise between good performance, low cost, low power and high reliability was not going to end well.

To get performance we need a fast box. That immediately ruled out cheap and low power.

So we centralised the data processing and dashboard aspects of Gridspy into http://your.gridspy.co.nz. Now the Nexus takes the place of the PC in each house. The Nexus is a little box that streams sensor readings live from your house to your dashboard. The Nexus has much lower power hardware than the web server because it doesn’t have to do processing “on demand”. Each Nexus draws around 1-2W, a normal PC 150-400W and a powerful web server 500W or more. Since the dashboard sits outside of the users’ premises on a shared web server its real power use per user is minimal.

Our little box has a lot of advantages over the in house PC/dashboard combo. It is easy for us to assemble and program without the complexities of shifting consumer hardware and 3rd party software installs. It has a comparatively low cost, especially as we move into mass manufacture (I look forward to passing that saving on). As there are no moving parts or major heat sources it could be installed in a sealed box inside a hostile, vibrating environment and survive. It integrates the entire system onto a single board, it is silent, it’s easy to install, and it is discreet (especially compared to a locally hosted PC!). An online dashboard is a huge win for both our customers and for us.

There are lots of advantages to us when we serve our dashboard to clients online. Chief among them is the lack of an installation step. We totally control the hardware that serves the site. We can poke, prod and customise the data collected, and we can analyse it in great depth. This also means that we can roll out a dashboard improvement or bug-fix to all our customers nearly instantly.

A central server also lets us centralise all that expensive hardware so that every individual request is served quickly but the server doesn’t spend all day standing idle. I have to admit that I get quite excited when I imagine a server performing well under load - requests flying in, processing going on and insightful data flowing out.

For the client monitoring power use it is much easier for the novice to turn a Nexus on and then visit http://your.gridspy.co.nz than it is to type in something like http://192.168.5.1. This is especially so if you bookmarked the dashboard when you purchased your Nexus. Only the ‘most hardcore’ computer geek (yes: you, me and all our friends) could successfully route an internal IP address to the wider world so it could be accessed from your mobile phone. By comparison the online dashboard is easy to find and access on any device.

So, Gridspy is the power monitoring solution that just works. It’s just plug (and get online) and go.

Part time Entrepreneur, fulltime Employee

2010-02-09T09:01:39Z

Update - we are now now working full-time, in our own office!

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 in 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?

Selling the Dream, putting Sales before Software

2009-12-09T07:06:09Z

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.

Cutting your power bills with Gridspy

2009-11-18T06:19:07Z

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. There are all sorts of reasons why it might not be what you expect. 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 hours outside, staring at your power meter and determining how much it has changed since the last time you looked. With Gridspy you can save yourself the time and hassle. We can 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.

Real-time data from sensors to browsers

2009-10-23T08:19:26Z

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.

Where does all the power go?

2009-10-06T09:29:51Z

Our Gt Barrier offgrid house uses 2 towel rails worth of power each day (4Kwh), but in our apartment in the city we use 13Kwh. That is 3 times more…. Is it the hot water, or the fridge, or the cooking? I just don’t know and that it annoys me. A friend of mine has tells me his power bill for a single parent and child is between $300 and $500 per month. They wonder if someone is stealing the power somehow.

]]> On Gt Barrier we are running one of the first versions of the Gridspy which monitors and graphs total power, refrigerator power and the power used by our satellite system. But here in town I have not got such a system.

Why no monitoring system in the city? Well I will blame one of our distributors. He said the system on the Gt Barrier would be too expensive for many city people. So we sat and scratched our respective heads. Lots of data to store equals a PC in the house. But no, these days as we have the web. Hey we could dump the PC and put the data directly onto a high speed server online. This means low cost power monitoring. From this version 2 is being born. This has been named the Nexus.

Soon the prototype Nexus will be monitoring the power in the city apartment. There will be extensive testing by many critical friends and family. So many people have put their hands up for testing they will have to be rationed out. It is an exciting time to have a product that so many people want to get their hands on, and finally I will have the tools to answer the question “Where does all the power go?

Gridspy Alpha is up!

2009-10-01T06:03:02Z

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.

Database, meet realtime data logging.

2009-09-15T03:22:51Z

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

Introducing the Nexus

2009-09-09T09:35:58Z

Update : You can now purchase the Nexus (now called the GridHub)

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

Essential Firefox Tools

2009-08-26T09:47:42Z

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.

The Barrier house

2009-08-19T08:24:43Z

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!