All I Want for Christmas is my Inverter Data

“Without a systematic way to start and keep data clean, bad data will happen.” — Donato Diorio

Dec 21, 2022

Reducing the emissions of your portfolio often means installing on-site solar energy generation. It is not an easy task to determine where the incentives line up, where the regulatory environment provides for the recovery of the CapEx from all who benefit, and just where it makes financial sense, especially in an extensive portfolio. We spend a lot of time figuring out where we should do projects and what the cost and impact of those projects are - but we are missing an important detail.

Installing solar is great, but you have to be able to pull down the data to account for its impact. What did you produce? What did you use on-site? What you see on your utility bill typically does not reflect what you used, just what you sent back to the grid. What about those electrons you produced and used on site? If you are not accounting for this when you benchmark your energy consumption, you are likely understating your electrical usage.

When we install solar on site, the panels collect the solar energy and convert it to Direct Current (DC) Electricity. There is only one slight issue with that; in the United States, our buildings and the electric grid work on Alternating Current (AC) Electricity. DC power electricity is maintained at a constant voltage and in one direction. AC, however, flows in both directions in the circuit as the voltage changes from positive to negative.

This is where the inverter comes into play. The inverter converts solar energy from DC power to AC power. It also does another critical function; it can monitor the system and provide data on the amount of electricity your solar system generates.

This makes the inverter a vital component from an ESG perspective - it is literally the meter that tells us what the solar panels generated - in other words, without the inverter data, you are not accounting for your total electrical consumption.

Here is the issue with that…. how often are you including requirements around the inverter in your solar specification? Suppose you are not explicitly outlining your requirements. In that case, you are leaving yourself to the whims of the installer, and chances are you will lack any consistent inverter communication protocol diminishing your ability to acquire your solar energy generation effectively. The end result is cobbing together a workaround and manual processes to capture the data, such as asking properties to log into the system locally and pull down CSV or Excel files that can be emailed for tracking. Hopefully, they manually enter the data correctly, and hopefully, they remember to send it.

We have a similar issue with building automation systems (BAS). We go into great detail about the HVAC system but spend little thought goes into the BAS that controls the HVAC system. You end up with the BAS system manufactured by whoever has a relationship with your installer. Unless that installer is doing all of your installations, that BAS will be different from city to city, installer to installer.

ASHRAE recognized this issue as multiple systems needed to communicate with the BAS, including heating, ventilating, air-conditioning, lighting, access control, elevators, security, energy management, and fire detection systems. Their solution was the development of a standard communication protocol, launched in 1995, called BACnet. Now, at least when you put in a BAS, you can specify it has BACnet - or even better, that it uses an open protocol.

You might be saying to yourself, wait a second. Does that mean if I buy a BAS system that uses a closed communication protocol, only the manufacturer of that system and components made by that manufacturer can access the data? The short answer is likely yes unless you include a requirement of BACnet in the specification. Even then, the amount of data on BACnet is typically less robust than what is available locally. So why would you spend all of that CapEx on a system and not pay attention to the BAS that operates it? How would you feel if you spent millions on improving the energy efficiency of a building but, in doing so, compartmentalized your data making it more difficult to operate with systems and software not made by your BAS manufacturer? You build in diminished interoperability. A potential issue if you want to pull in data from multiple BAS systems into a portfolio-level energy management system.

We have a similar situation with Solar Inverters. We talk to the developer about the overall project - location, production, cost, and ROI. If we have a good partner in the developer, they may have a discussion about which panels have advantages over others. We likely talk about the roof or where the panes will be mounted. If we are thorough, we might even talk about maintenance and ongoing operations. But the item most likely not discussed is the inverter. If it is discussed, I would suspect it isn’t discussed from the perspective of pulling the data into your portfolio-level energy consumption. The result, similar to the HVAC and BAS, we spend a significant amount of CapEx, but in doing so, we silo and isolate the data in a way that makes it difficult to track the reduction.

In building automation, BACnet provided a common communications protocol, allowing for interoperability by defining messages, formats, and rules for exchanging data, commands, and status information. In 2020, we took a step towards a similar solution for inverters with the publication of IEEE 1547.1-2020, which established a standard communication protocol for Distributed Energy Resources (DER).validatedded validation for the requirements set out in California’s CA Rule 21. clarified the timeframe of CA Rule 21 phase 3 timeline and named the IEEE 2030.5-2018 protocol as the default DER-to-utility communication.

When you are working on your solar specifications, having a common communication protocol across your inverters will provide some consistency in your approach to retrieving data; however, there remains one additional standardization you likely want to consider - the API capability. Building APIs takes both resources and time; once established, it will also require ongoing maintenance. The fewer APIs and the more standard the type of API, the happier your Tech support team will be.

You will want to consult with your tech support team to determine your organization’s API preferences. The critical point here is to be aware that this should be standardized and not left to the solar installer’s preference.

Data collection is not the only benefit communicating to with your inverters can provide. As noted, the inverter provides the system monitoring for your panels. From inverter failures to specific panel performance, the inverter provides insight into the system’s performance. Back to my BAS comparison, the inverter can signal when faults are detected that compromise system performance and provide a mechanism to address issues with the system.

With a bit of upfront coordination and planning, you can position yourself to have the best shot and more quickly obtain your solar generation data for both operational and reporting purposes.

One final sidenote, keep an eye on your Renewable Energy Credits (RECs). If you sell your RECs to another organization as part of your financial model, you will not be able to claim the environmental attributes from your investment. More than one organization has invested in on-site solar and, in doing so, sold their RECs to help with the project economics, only to realize after the transaction that also just lost the ability to claim the environmental attributes from the solar energy production. Be careful what you give away when you set up the deal, and understand the fine print.

You can help reduce the impact of the built environment by sharing this blog with your peers. Together we can impact the 39% of greenhouse gasses attributed to the built environment. It starts with awareness, and we succeed with teamwork.

Stay well!

Thirty Nine

Discussion about this post