GSE is the newest service in the LoopLink® family and it is one we are very excited to have available. If you aren't familiar with LoopLink GSE, it is a web service for companies in the residential geothermal market that estimates the how much a homeowner could save if they switched to geothermal.
Since this is the first GSE update article, you should note the majority of updates and news we report about GSE will be written more for web-developers than our typical audience of geothermal system designers. We will do our best to keep the nerd lingo to a minimum and include information that is of universal interest.
With the basics out of the way, lets talk about what we have been up to.
Units of Energy
You can now access the total number of units of fuel consumed in an operating mode (heating, cooling, hot water) both annually and monthly. In other words, you can report the number of kWh the heat pump consumes in a year for heating as compared to the number of ccf of natural gas the conventional furnace would use. This is handy if you want to apply your own methods for estimating energy rates after you receive your response. Of course, you could always pass that information to us and we will return your cost and savings.
Monthly Outputs
In the first iteration GSE was built to simply provide annual savings, cost and carbon emissions estimates. In our latest update we added the ability to access that information for every month of the year. This is really useful for generating graphs and charts that can really help in making your interface look professional and approachable.
Carbon Reduction
We added a 'reduction' object to the 'carbon' objects (annual and monthly). This is just a convenience addition that offers direct access to the change in carbon emissions from the conventional system to GSHP rather than requiring client side processing.
Backwards Compatible
We haven't discussed versioning since GSE is so new to us but we wanted to make a note that minor versions of the software will always be built to be backwards compatible. It is how we define our major vs minor versions. Simply put, in minor versions, we won't break your existing interface by dropping support for or changing the name of a key etc. We only expand on the existing response. Major versions may not be backwards compatible with your interfaces but when we get to that point, we establish a sunset policy for legacy version support.