Carbon tracking and offsetting is a trending topic at the moment. It is another part of the quantified self and helping towards a peace of mind state. We have started our venture as a team of eight data enthusiasts where about half of them is very interested in reducing the footprint we have on this planet. Thus, also our company vision is “Increasing life-quality, decreasing footprint”. And how do you do that? Yes, you need to measure it. So, as one of our actions, we have decided to use carbon tracking (and later buying certificates for our produced emissions). However, there are lots of different apps and tools in the market. We have evaluated (among others) in more detail:
These apps are easy to use and somehow intuitive. However, we have missed essential features for us. Among these, there is the option to compare tracked emissions with offsetted/saved/prevented emissions. Yes, this is, of course, speculative, because it is very difficult to measure exactly how much emissions you have saved. Nevertheless, we wanted to have an option to enter such information.
In addition, many of the existing apps, do not allow you to get your data of it. As we have previously defined many different products, we know how important it is to have a good API to get the data you want to have.
Third, we did not want to have full-fledged ESG- and CSR solution, as it comes with high costs, needs a lot of maintenance and support and we are a small team. We also wanted to make sure, we can automate every possible step, such as parsing invoices or travel receipts, such that emissions like these are entered automagically into the application.
Fourth, we wanted to make the required input by users as small as possible and allow to e.g. template emissions, such that you only have to confirm that you did have the same amount of emissions like yesterday, which for example includes:
I could add much more, but let us go to the design now, because that is what we are interested in, right?
None of the existing solutions persuaded us. Thus, we decided to build our own application. And just because we are IT guys and want to learn a lot, it is one of our pet projects, where we test and try out things. Hence, we started with the most obvious thing to do at an IT company: Measuring the power consumed of our work stations.
Therefore, we have bought ourselves some Shelly plugs. We have installed these and now they are sending data to our Azure cloud. We analyze the data and there and aggregate the different values over the day and write them aggregated by day into our Azure SQL database. This is already showing us some obvious things:
In addition to the input of the shellys we also want to parse data from our invoices, travel expenses etc. as they probably make up a large part of our emissions. Technically, emissions from e.g. invoices fall into category 3 of emissions, but still we think, that we are responsible for them by buying these products. These, expenses we parse from our storage solution via stream analytics and Azure Functions and directly ingest them with average emissions based on our desk research.
Our SQL database forms the main entry point for everything we do. Thus, we decided to build an API around it. Again, we want to learn things, so we decided to build a containerized Spring Boot App. Of course it is based on Kotlin, as none of us tried Kotlin before. So again something new to learn.
The API also feeds our frontend, which is based on a next.js App getting the best of React for development.
//TODO image of the architecture
In following blog posts we will describe the setup of the different components and how we have integrated all of them into a working solution.
