What We've Been Building

Launching out of Beta this week

In advance of bringing WattCarbon out of beta this week, we wanted to share a bit more about what we’ve been building, why we’re excited about the future of decarbonization, and where we plan on going from here. To start, we’d like to thank the hundreds of volunteers who helped us over the past few months with everything from testing complicated use cases, to feedback on our UX and design, to offering ideas for features and functionality that we could develop. It’s been a community effort thus far and we hope to continue to grow the community that contributes to this important work.

This week, we’ll announce that WattCarbon can provide hourly carbon emissions for any building in the United States, on-demand. 

It’s worth unpacking this claim a little bit. When we say hourly carbon emissions, we mean that we’ve been able to connect to real-time grid dispatch data that tells us all of the different types of fuels that are being used to provide electricity for each balancing authority in the U.S. Most of the country is served by a handful of large balancing authorities, but there are also dozens of smaller (mainly municipal) balancing authorities that manage their own power dispatch. Each of these relies on different combinations of power plants. For example, in California, most of the state is served by the California Independent System Operator and relies heavily on wind, solar, and gas, but Sacramento and Los Angeles operate their own balancing authorities. L.A. relies much more heavily on coal-fired power plants than the rest of the state, so its emissions are much higher.

The “hourly” part is important too because the sun shines and the wind blows at fairly consistent times of day, but not all day. Most emissions reporting today relies on an annual average (you can find this number at the EPA’s eGRID website). The eGRID number assumes that emissions are constant over the course of the day and the year. If you use power at noon, or at midnight, you get the same eGRID emissions factor. This is categorically wrong when solar is part of the mix. Recent research by NREL shows that you can err by 30% or more using annual averages.

The composition of the grid is also changing rapidly. Solar and wind are coming online at astonishing rates. If you use current emissions data, rather than last year’s or (more commonly) data from 5-10 years ago, your carbon measurement will reflect current reality. If you are trying to shift your consumption from high-carbon times of day to low-carbon times of day, you want to be measuring against what’s happening now and not what conditions were like during the Obama Administration.

Of course, the grid is only half of the equation. The other side is the built environment. It does no good to use hourly grid values if you only have daily, monthly, or annual energy consumption data. Sometimes, you don’t have any energy data at all! Consider the case of the property owner being asked to measure Scope 2 emissions when the tenant owns the energy bill. Or a tenant who leases space in a building that lacks submetering. How do we calculate emissions in states that entirely lack smart metering? 

We solve the hourly energy data problem by first recognizing that different use cases require different levels of accuracy. Some use cases require revenue-grade meter data, but in other situations, it might be enough to get fairly close estimations. For surveys and benchmarking, close-enough estimations will be fine - and far more accurate than using the annual average. When procuring renewable energy to meet 24/7 carbon-free energy goals, highly accurate meter data might be desired.

WattCarbon supports all of these use cases by providing several different ways of calculating hourly energy use in a building. For situations where actual meter data isn’t needed (or isn’t available), our software provides estimates of hourly energy use using synthetic data. What this means is that for a given building, we can estimate both annual energy consumption and its hourly energy distribution with just a few basic pieces of information about the building. If daily, monthly, or annual energy totals are available, we can calibrate these models to fit the actual total consumption. 

Where accuracy counts, actual hourly energy consumption is important. We’re excited to be partnering with UtilityAPI, Verdigris, Infisense, and other data providers to support direct connections to ongoing data feeds. These integrations allow us to provide up-to-date carbon emissions data on any connected building. Simply dropping in an API key will result in automatic emissions calculations for the building and enable advanced analytics like optimization scoring, savings calculations, and scenario planning.

Just as important as getting the right input data is making sure that the data can be used once the calculations have been made. One of our most delightful learnings over the past several months has been understanding how deeply embedded carbon reporting is becoming within organizational workflows. We saw how organizations were combining this data with mission critical KPIs to reinvent how they measured their own success. More and more we realized that we needed to prioritize API access so that measurements coming from the WattCarbon platform could be embedded into the tools that they already use. Our API docs are now available at

https://docs.wattcarbon.com.

For instance, we’re excited to be using our API to facilitate carbon emissions reporting as part of commercial real estate transactions. When commercial buildings are acquired, the buyers will need information related to the potential for toxic chemicals onsite, stormwater issues, etc. Increasingly, buyers are asking about carbon emissions. This had basically been impossible to do in a timely fashion because of the amount of work required to collect utility data and look up an emissions factor (which of course would likely be very outdated). Now, a report can be provided on demand, with details about the hourly load profile of the building, the hourly carbon emissions of the local grid, benchmarking, and forecasts of future carbon emissions. The best part is that we can provide this information through an existing provider of environmental reports, so that buyers and sellers have a seamless experience with existing reports that they already order.

We’ve also made some decisions about what we are not doing. In the world of carbon accounting, there is a distinction made between attributional and consequential accounting; the latter category is associated with so-called marginal emissions. The tribalism emerging between proponents of “emissionality” and “24/7 Carbon Free Energy” is probably a sign of healthy growing pains in our community, but it is not our battle. Our goal is to provide data infrastructure that joins what is actually happening on the grid to what is actually happening in the built environment. Strategies for reducing carbon emissions can involve many different approaches, but at the end of the day, the only thing that will matter is whether or not we are reducing emissions from our energy supply. To the extent that we track carbon reductions, we will do so in a transparent, auditable manner, with all accounting decisions (such as how to account for renewable energy generation) fully specified.

To that end, we will continue our commitment to better data, more transparency, and open-source through our work with LF Energy. Alongside our partners at Google, with whom we are co-chairing the Strategy Committee of the Carbon Data Specification Consortium, we will continue to work to provide better access to and standardize grid carbon emissions data, as well as customer data.

Finally, we are releasing a guide to hourly emissions accounting. We’ve spent nearly a year trying to establish a set of rules that we can implement within our software for handling the myriad edge conditions that show up when using real-world data. What happens, for example, when data is missing? How does one create a portfolio-level aggregation when assets are spread across multiple time zones? We expect to open-source some of our codebase as well. We don’t want to hide our methods behind a proprietary firewall. If we are serious about decarbonizing the built environment, it will take everyone pulling together to make it work.

If you are interested in incorporating carbon emissions into your products or services, please reach out. Our platform is primarily designed to sit behind the scenes and support good work that is already being done. We’re ready to dig in with you to help drive systemic changes in the production and consumption of energy on this planet.