Degree Days
Weather Data for Energy Saving
These frequently asked questions relate specifically to the Degree Days.net API. For FAQ about the website and degree days in general, please see here.
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 temperature records (typically hourly or better). 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?
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 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).
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.
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 all the stations in the area of your target geographic location. It 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.
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.
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. For analysis of energy data from individual buildings, we recommend you get our system to choose a weather station to represent each individual building location. But regional degree-day figures can still be useful for some sorts of applications.
There are two common ways to get degree days for a region:
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 + ...) Where: p1, p2, p3 are the populations of cities 1, 2, 3 etc. dd1, dd2, dd3 are the degree days for 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.
The degree days, for any given day, for any given weather 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 degree days for a day available once the station has reported its first temperature reading on the following day (in the station's local time zone). The best stations (with top star ratings) report the temperature hourly or more frequently, and their degree days are typically available within an hour or so of the day ending.
Some 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 degree days at midday in the local time zone of each location you are dealing with. Or you could wait until midday in the latest time zone (the one that reaches midday last), 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 is 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 for 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 data a couple of hours after midnight in each station's local time zone. If it's available, then great; if not, try again once each hour until you get it. That's a good, robust, automated approach that should work well for all stations.
By default, hourly temperature data (available on API Standard, Plus, and Premium plans) for a day becomes available at the same time as the degree days for that day. But there is an allowPartialLatest option that you can specify to get the API to return such data for days that aren't complete yet. This partial-latest data can be a little volatile, as weather stations sometimes send multiple reports for the same time, some delayed, and some marked as corrections for reports they sent earlier. Our system generates time-series data using all the relevant reports that each weather station has sent, but the generated figures may change if delayed or corrected reports come through later. If you are storing partial-latest time-series data we suggest you overwrite it later with figures generated after the day has completed and any delayed/corrected reports have had time to filter through.
Customers with an API Standard, Plus, or Premium account (see API account options) can fetch hourly temperature data directly from our API. The technical docs for Java / .NET / Python / JSON / XML etc. explain how. This is the simplest and best approach in most cases.
If you can't quite stretch to an API Standard account, and you don't need the detail of hourly temperature data, you can also reverse-engineer daily mean temperatures 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 reverse-engineering approach will give you accurate, time-weighted daily mean temperatures. However, a word of warning: when customers ask for daily mean temperatures 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 best way to get accurate degree days in multiple base temperatures is to fetch degree days out of our system in multiple base temperatures. Our system makes this easy to do, you can fetch up to 120 sets of data in a single request (e.g. HDD and CDD in 60 base temperatures each).
You can also calculate degree days yourself by applying the integration method to hourly temperature data from our system. This will be a lot more accurate than estimating degree days using daily mean temperatures or daily max/min temperatures. Though it won't usually be quite as accurate as getting degree days directly from our system. We calculate degree days using the full detail of the temperature data each weather station reports, and many stations report more frequently than hourly. Also, stations that do report hourly rarely report exactly on the hour every hour, so there is almost always some interpolation required to calculate the neat/regular hourly temperature data that our system provides. This translates to a small loss of detail that can't then be captured in subsequent degree-day calculations. These are minor points however, and degree days calculated correctly from hourly temperature data are still very good.
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.
We've always preferred email, but in our early days we often scheduled calls if requested. As our API grew in popularity (a lot!), we realized this was taking too much time away from development, and we would either have to raise prices drastically to cover the cost of a dedicated sales team, or focus on quality email-only support and making our website as helpful and comprehensive as possible. We chose the latter as it fitted much better with our philosophy of maximizing energy saving through widespread usage of our API (including by smaller players as well as the enterprise market).
We have found that email enables us to answer questions much quicker and better than we can on a call. We can point to resources on our website (invaluable for difficult-to-explain concepts like base temperature and regression), and pause to consider harder questions carefully, pulling in the expertise of colleagues if we need to. You can read our responses at your leisure and have a full record to refer back to. That record is useful for us too if you have follow-up questions further down the line.
We think you'll be impressed with how helpful we are by email. Please feel free to email us at info@degreedays.net to discuss whatever you need.
© 2008–2024 BizEE Software – About | Contact | Privacy | Free Website | API | Integration Guide | API FAQ | API Sign-Up