Column definitions and time zone information for real-time prices API

  • 86 Views
  • Last post 28 May 2019
Dave Shea posted this 25 May 2019

Hi,

I am just starting out experimenting with the EMI Real Time Prices API and I have two questions:

1) Where can I find a definition of each of the columns returned by a call to the Real Time Prices API ? I get the following columns returned but it would be useful to know whether my assumptions about them are correct:

interval - What time zone is this in, is it UTC See 2) below ?
interval_datetime - What time zone is this in , is it UTC See 2) below ?
five_min_period - What does this mean, is it the 5-minute segment of the hour (ie there are values 1 to 12 ) ?
isDayLightSavingHR - What does the HR indicate ? As at 25May2019 (ie Daylight Savings is NOT in force) every row shows a value of <zero>. I would expect to see value of 1 when New Zealand is in Daylight Savings, but I notice that data returned for mid-Jan 2019 still shows a value of <zero>
pnode - This looks to be the power node. Is this correct ?
load - What scale is this / Megawatts, Gigawatts ?
generation - ??????
price - I assume that this is NZD, but again, $ per what ? (No pun intended)

2) What is the timezone being used for interval and interval_datetime?
When I ran the following query against the Real Time Prices API at 2019-05-25 15:30:
https://emi.azure-api.net/rtp/?$filter=interval_datetime gt datetime'2019-05-24T00:45' and interval_datetime lt datetime'2019-05-25T15:15'

the latest value I see returned for interval_datetime is '2019-05-25T01:25:00'. Is this simply a delay in making prices available or is the value offset by 14 hours for some reason ?

Any help or guideance would be appreciated.

Thanks.

Dave.

Order by: Standard | Newest | Votes
Phil Bishop posted this 27 May 2019

Hi Dave

The column definitions are as follows:

interval and interval_datetime are both New Zealand time, with interval being a textual representation of interval_datetime. interval_datetime is an ISO 8601 format. An interval in the SPD model refers to a time interval, in this case a 5-minute time period because real-time prices are calculated every five minutes, even though final prices are calculated ex post by trading period, a 30-minute interval. The interval_datetime represents the start of the five-minute interval. See also the post here.

five_min_period is an integer from 1 to 6, i.e. there are six five-minute periods per trading period (ordinarily we would show trading period number and 5-min interval number - not sure why that wasn't done in this case but in any event it can be gleaned from interval_datetime.

isDayLightSavingHR is a 0/1 indicator of the 2am-3am hour which occurs twice on the one day per year that daylight savings end, i.e. it is zero for all hours of the year except one.

pnode in the SPD jargon is pricing node. You can interpret it as the point on the grid at which the reported price is determined. Currently there are 243 pricing nodes (I think).

load is megawatts (you could divide by 12 I suppose to approximate the energy injected or taken off the grid in the five minute interval).

generation is also megawatts (ditto the divide by 12 comment).

price is dollars per megawatt hour (although technically you might say it is dollars per MW for five minutes).

Hope this helps.

All that said, the real-time API stopped pumping out data on Saturday evening because the data feed from the system operator to the Authority stopped working. The relevant folk are sorting that out as we speak. But even when it is working, you can expect the data to be about 15 minutes behind real time - you'll have to wait possibly until next year before the WITS system is pushing out prices in real time via an API. 

Cheers

Phil

 

  • Liked by
  • Dave Shea
Dave Shea posted this 28 May 2019

Hi Phil,

Thank you so much for a timely and very comprehensive reply to my post. It all makes a lot more sense now, especially your pointing out that the data feed had stopped working over the period I was first scratching around trying to use this API. I thought I was being very thick, but now I can see (Monday evening) that the API is returning nice, up to date, data.

I am pretty sure I would have got to my grave before I guessed what column [isDayLightSavingHR] actually represented !

I appreciate your effort in supplying the info, but was I actually missing some big button on the screen that said [Get Your Column Information Here], is there actually a document that I should have been using ?

As to the [five_min_period] column, I am happy that I can drop that and determine it and the corresponding trading period by just playing with the interval_datetime once I have got the data from the API.

Finally, when I compare the output of the Real Time Prices with the Real Time Dispatch APIs I notice that RTD offers an additional column, [Runtime]. Is this the load time of the external feed into the database from which the API extracts ?

Many thanks,

Dave.

Close