In 2016 I finished my Software Engineering degree at the University of Waikato with my fourth year honours project. The objective of my project was to create a system which would allow the owner of an off-grid house to monitor their energy system and access this information from anywhere.
What resulted is Kauri Energy Monitor, a cloud based system for monitoring a renewable energy system and I’ve recently gotten it to the point where it’s ready to release to the world!
In this post I’ll cover what Kauri can do, how you can start using it and I’ll discuss a few things the process has taught me.
Who would need this?
Some houses are fitted with renewable energy systems - this is a very broad term for various configurations of equipment which allow the occupants to generate their own electricity. Depending on the exact configuration, these may also have a form of energy storage or backup generation.
An off-grid system is a good example of a renewable energy system. These might have solar or wind generation, a bank of batteries for energy storage and a generator as a backup energy supply. On the complete opposite end of the spectrum, grid connected systems usually feed their excess generation back to the grid and consume energy from the grid when required.
A typical offgrid system.
In all of these situations it can be difficult to figure out what your energy system is doing. Is it currently charging? How long will the battery last? How efficient is my generation?
Kauri answers these questions and allows users to do this from any internet connected device.
What can Kauri do?
Users of Kauri setup energy sensors at various points in their energy system. These sensors are hooked up to a computer running a piece of software called Kauri Bridge which sends readings to the Kauri server.
By analysing the energy flow data, Kauri shows an overview of all the energy flowing through the system. This tells the user the amount of energy being generated, consumed by the house or stored in the battery. Kauri also feeds this information into the B42SOC algorithm to calculate the state of charge of the system’s batteries (i.e.: battery level).
The Summary page in Kauri shows current energy flows and battery state.
Kauri determines the future state of the system using battery state information and energy flow patterns developed over time. This lets Kauri answer questions like, when will the battery be fully charged? When will the battery run out? Or what battery level will the system be at in 5 hours?
The Future State page in Kauri shows the state of the system into the future.
How can I use Kauri?
Getting a bridge and some sensors sorted
You’ll need to have some supported sensor devices setup in your energy system (the “What do I need?” page will help you figure out which sensors you’ll need). Once you get these hooked up to a computer which can run Kauri Bridge then you can setup your Kauri server.
A Smart Circuit SC20 device - an AC sensor supported by Kauri Bridge.
Running your own Kauri server
Kauri is open source so you can run it on your own server for free! The getting started guide runs you through the process of setting up Kauri on your own server.
See the getting started guide.
Want a hosted option?
Currently if you want to use Kauri you’ll need to be comfortable with hosting the Kauri server yourself. If you aren’t, then I’d love to offer this as a paid monthly service if there is enough interest.
Express your interest in a hosted option here!
Contributors wanted!
I’ve really enjoyed working on Kauri but I really want to get onto some new projects! If you want to improve the project, please feel free to submit a pull request! I’m happy to provide advice for further development.
Want to learn more?
If you’d like to know more about how it all works, feel free to read my honours project report:
Read "Cloud Based Monitoring of a Renewable Energy System"
Or, watch a video of a slightly younger version of myself presenting my honours project:
What has this project taught me?
This whole project has taught me so much technically and it’s the biggest personal project I’ve ever embarked on, but there are a few specific things that I’ve learned that I want to discuss.
Give your project a name
Kauri didn’t really have a proper name until recently - it was usually just known as ‘my honours project’ or ‘Offgrid Monitoring’. Giving a project a name gets you thinking about the purpose and scope of the project which makes it easier to reason about its features.
For example, by calling it ‘Kauri Energy Monitor’ I decided that I would support as many configurations of renewable energy systems as possible so I shouldn’t prioritise features that only benefit users of off-grid systems.
Ask the question, will I really need that?
While getting Kauri ready for release I listed off loads of features that I thought would be useful. These things would be nice to implement but weren’t driven by any actual user requirement and wouldn’t be the biggest barriers to adoption by users.
The lesson here is to ensure any change you make provides enough value to be worth the cost of implementation. This isn’t easy for projects which you’re passionate about but it means you aren’t wasting time implementing something which no one needs.
Think about project handover
While I was first developing Kauri it had a single production instance that was kept up to date as the system developed. If I needed to play with some real data I just downloaded a database dump and applied it to my local database. I didn’t need documentation at that point because I had all the context in my head and I was the only developer. Some actions could only be completed via the API as it wasn’t worth the time building an interface to add a building if I only needed to add a building once.
However, after spending a few months without working on Kauri I experienced the cold introduction that any new developer would get. How do I get it running on my system? What if I want to get some data running locally without a real renewable energy system to test with?
I realised that I needed to:
-
Improve the configuration interface so that users didn’t need to use the API to configure Kauri.
-
Write some basic documentation - I covered how to setup an enviroment, some of the background to the project and added a getting started guide.
-
Provide a set of mock data to allow users to experiment without needing a renewable energy system.
-
Build tooling to populate Kauri with example data.
Always ask yourself, what would be the biggest pain points for continued development if I had to hand it over to someone else tomorrow?