Degree Days

Degree Days

Weather Data for Energy Saving

Degree API - Frequently Asked Questions

These frequently asked questions relate specifically to the Degree API. For FAQ about the website and degree days in general, please see here.

We're evaluating our options... Why should we choose your API?

First, we don't think you'll find better degree-day data elsewhere. There are good reasons why thousands of energy professionals get their data from us.

Second, using our API is likely to be the fastest, simplest, and cheapest way to reliably integrate accurate degree days into your system. You could custom-build something to approximate degree days using daily mean temperatures from a generalist weather-data provider, but you'd be missing out on the accuracy that comes from proper calculation using detailed raw temperature readings. Even using an approximation method you'd be surprised at how complicated things become if you want to be thorough. We know from bitter experience!

We built our API specifically for energy software systems like yours. And it's taken us years to get our system as robust and feature-complete as it is today. We're popular, affordable, and probably exactly what you need. Why re-invent the wheel?

We want to collect a load of data as a one off... Can we do that?

Yes. Just sign up for one of the monthly plans and cancel once you've collected the data you need. So long as you cancel before the first month is up, you'll only pay for that one month.

Cancellation is really straightforward. Once you're subscribed you'll get an automated email with a link to your billing control panel. Follow that link and you should see an option to cancel your subscription. It's just a couple of clicks; no need to call anyone or fill out any onerous forms.

We like the sound of batch data-collection, but we can't program... Do you have any suggestions?

We recommend our desktop app, which makes it easy for non-programmers to download large quantities of data and export it into a spreadsheet.

Even customers with in-house programmers often find the desktop app to be useful as a starting point. It's a great way to play about with the system and a list of target locations (e.g. your building locations).

What information do we need to collect data for all our buildings (or customer buildings)?

For each building (target location) we recommend you have either:

Either of the above will enable the API to resolve each location without ambiguity (like the ambiguity that arises with city names that are duplicated). Once the API has resolved a location it can select the weather station that will best represent that location.

You can also assign each building a weather station ID manually, by searching on our main website. But that's a chore if you have a lot of buildings. Also, if you do decide to go down that road, make sure to read the question/answer below and the notes on our home page about choosing weather stations, as doing it well is more complicated than it appears on the surface.

How does the API select which weather station to use to represent a given geographic location?

When you ask the API to give you data for a longitude/latitude position or postal/zip code, the API has to select the weather station that will best represent that "geographic location". It has a pretty sophisticated process for doing this:

It starts by finding the stations in the area of your target geographic location. It will only ever use the stations shown with bars and stars on our website (the higher-quality stations for which we use the most accurate calculation method).

The API then ranks those candidate stations according to the following factors:

The API then selects the station that is ranked highest after all the factors above have been considered.

Can we ensure that the auto-selected weather station for a location stays the same when we get data updates in the future?

Yes. Whenever the API gives you data for a geographic location (longitude/latitude position or postal/zip code), it will also give you the ID of the weather station that it selected. If you like, you can use that station ID to fetch future data updates. The desktop app has an in-built option to do this automatically.

This approach does have its pros and cons - see the integration guide for more.

How can we get the degree days for large regions (like US states or European countries)?

The weather varies considerably within most states and countries. So degree days for a large region are rarely an accurate representation of degree days at specific locations within that region. But regional figures can still be useful for some sorts of applications.

There are two common ways to get degree days for a region:

  1. Use the degree days from a single "reference" weather station within the region. For example, you might consider a weather station in the capital city as being approximately representative of the degree days across the region as a whole.
  2. Average the degree days from a selection of weather stations within the region. Such averages are often population weighted such that the degree days from more-populated areas make more of a difference to the overall figures than the degree days from less-populated areas. They can also be weighted using other data instead.

Choosing a reference station is the simplest approach, and needs no further explanation.

Weighted averages are more accurate for many applications requiring regional figures. They can be great for analyzing aggregate totals of energy consumption across large regions. To get a population-weighted average for a region, a good approach is to find a list of the most populous cities in the region. Then find a weather station to represent each city (or specify a longitude/latitude position for each city and let our system find the best weather stations for you). Fetch the degree days for each weather station, and combine them like so:

Population-weighted average = (p1 * dd1) + (p2 * dd2) + (p3 * dd3) + ...
                                         (p1 + p2 + p3 + ...)


p1, p2, p3 are the populations of cities 1, 2, 3 etc.
dd1, dd2, dd3 are the degree days from weather stations in cities 1, 2, 3 etc.

It's pretty straightforward, and can be automated easily enough once you've decided on the process that is best for your project.

When does the most recent data become available?

The data for any given day, from any given station, will only ever become available once the day has finished in the station's local time zone. Though there is a delay, which depends on the station...

Generally the API makes the data for a day available once the first temperature reading on the following day has been reported (in the station's local time zone). The best stations (airport stations with top star ratings) report the temperature hourly or more frequently, which means that their data is typically available within an hour or so of the day ending.

Some of the airport stations report the temperature less frequently. For example, 3-hourly and 6-hourly reporting are both fairly common for stations in more remote areas. So for those stations the degree days for a day won't usually become available until several hours after the day has ended (in the local time zone). Also, some lower-quality stations have a tendency to send temperature reports in late, or miss the odd report completely, which can add further delays.

To be conservative, you could fetch yesterday's data at midday in each location's local time zone. Or you could wait, say, 12 hours after the day has finished in your earliest time zone, and then collect data for all your locations at once. These are both good approaches in many situations, but it's a shame to wait so long if there's business value in having the data sooner, as it will probably be available much sooner for most of your locations on most days.

The majority of locations that customers fetch data for are well represented by high-quality stations that update quickly. You'll probably only end up using lower-quality stations with slower updates if you're explicitly specifying their station IDs or if you're fetching data from more remote locations where there's nothing better around (fairly unusual for most of our customers).

Another approach is to configure your system to have a go at fetching the data a couple of hours after midnight in each station's local time zone. If it's available, then great; if not, try again after an hour or so. That's a good, robust, automated approach that should work well for all stations.

Can we get daily mean temperatures out of your system?

Yes, but first a word of warning: when customers ask for this they often want to use the daily mean temperatures to calculate degree days in multiple base temperatures. That's inherently inaccurate as it uses the Mean Temperature Approximation Method described on our page about calculation methods.

The only way to get accurate degree days in multiple base temperatures is to fetch them out of our system in multiple base temperatures. Don't be afraid to do this... The system makes it easy to fetch HDD and CDD in a wide range of base temperatures, and such figures are a lot easier to store than the huge number of messy/irregular raw temperature readings that they're calculated from.

However, if you still want daily mean temperatures, they're easy to reverse-engineer from daily degree days with an extreme base temperature. You can start by fetching daily HDD with a base temperature that is higher than the outside air temperature would ever get. For example you could use a base temperature of 100°C. Then the mean temperature for any given day, in Celsius, would simply be 100 minus the HDD on that day.

If you wanted daily mean temperatures in Fahrenheit, you could fetch daily HDD with a base temperature of 200°F. Then the mean temperature for any given day, in Fahrenheit, would be 200 minus the HDD on that day.

This approach will give you accurate, time-weighted daily mean temperatures - about as accurate as daily mean temperatures can be.

Any tips on minimizing the number of request units we use?

There are two main ways that we often see customers using more request units than necessary:

First, we often see customers making multiple requests for data from the same location. For example, they'll fetch HDD in one request, and then CDD in another.

You can fetch HDD and CDD together in a single request, and that will invariably require less request units overall. You can also fetch HDD and/or CDD in multiple base temperatures in a single request, which is also invariably more efficient than making multiple requests.

The parallel for users of the desktop app is to specify each location once only. Then, in the "Calculations" column, specify all the data you want (HDD and/or CDD, in however many base temperatures you want). This will make the software fetch the data in a single request for each location.

Second, we often see customers repeatedly fetching data for geographic locations that are very close to each other and are being served by the same weather station. Essentially they are fetching the same data multiple times. This can be avoided with two-stage data fetching.

The desktop app uses two-stage data fetching by default. If you're building your own software, two-stage data fetching will require more development time up front, so you will have to decide whether the scalability and operational efficiency it can bring is worth the extra development cost. Our API integration guide should help you with this decision, and it also has a lot of other useful information on how best to integrate with the API.

Choose your Plan and Start Today!

© 2020 BizEE Software - About | Contact | Privacy | Web Tool | API | Integration Guide | API FAQ | API Sign-Up