Difference between revisions of "Events"
Scott.Radka (talk | contribs) (Created page with "Image ====Event Status's==== Image : All of the event status’s can be seen above in Figure , the meaning of each status are as follows: : '''Ineligible''' '''Withdraw...") |
Scott.Radka (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | + | A DR event represents a request for your organisation to shed load over a specific time period from multiple registered sites capable of shedding load. An event cannot span across multiple days.Every registration of load is sent a separate child event mirroring the parent event parameters, but with a price and target kW amount specific to the site. | |
| − | ====Event | + | ====Event Status’s==== |
| + | From the time that an event is created right up until the payment for said event has been completed the event goes through several status’s: | ||
| − | + | : | |
| + | : | ||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ||'''''Standard Status Progression''''' | ||
| + | |- | ||
| + | ||''Offer Window Open'' | ||
| + | ||Published, offers can be made | ||
| + | |- | ||
| + | ||''Offer Window Closed'' | ||
| + | ||Published, offers can no longer be made | ||
| + | |- | ||
| + | ||''Scheduled'' | ||
| + | ||Event has been scheduled - participants are notified whether or not they have been selected to participate | ||
| + | |- | ||
| + | ||''Active'' | ||
| + | ||Event is in an active state - participants should have shed load at this stage | ||
| + | |- | ||
| + | ||''Completed'' | ||
| + | ||Event is finished - settlement can begin | ||
| + | |- | ||
| + | ||''Meter Data Required'' | ||
| + | ||Event is finished, meter data is required to settle | ||
| + | |- | ||
| + | ||''Meter Data Submitted'' | ||
| + | ||Event is finished, and meter data required for settlement has been detected | ||
| + | |- | ||
| + | ||''Payment Payment'' | ||
| + | ||A payment has been generated for the event | ||
| + | |- | ||
| + | ||''Payment Complete'' | ||
| + | ||An invoice has been uploaded for the payment | ||
| + | |} | ||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ||'''''Potential Event Status’s''''' | ||
| + | |- | ||
| + | ||''Cancelled'' | ||
| + | ||Event was cancelled | ||
| + | |- | ||
| + | ||''Ineligible'' | ||
| + | ||The registration is not eligible to participate in this event (this could be due to the registration being accepted into another event at the same time instead) | ||
| + | |- | ||
| + | ||''Declined'' | ||
| + | ||The child event was declined | ||
| + | |- | ||
| + | ||''Withdrawn'' | ||
| + | ||The child event was withdrawn | ||
| + | |} | ||
| + | ====Event Types==== | ||
| + | Two types of event exist in the DRMS, price response and non-price responsive. | ||
: | : | ||
| + | * Price responsive events progress through an offer window process after they have been submitted. | ||
| + | * Non-price responsive events do not go through an offer window and instead proceed straight to scheduled. | ||
| − | + | : | |
| + | ====Offer Window==== | ||
| + | Before the event is scheduled it goes through an offer window process. During this time participants can agree to make an offer in the DR event.A participant can respond to an offer to participate by opting in or out of the event and optionally decreasing their offered price or kW amount. | ||
| − | + | ''Non price-responsive events skip the offer process.'' | |
| − | ' | + | : '''' |
| + | : | ||
| + | ====Event Notifications==== | ||
| + | The following notifications are sent over the life-span of an event: | ||
| − | + | : | |
| − | + | : | |
| − | + | * Child Event Offer Window Open | |
| − | + | * Child Event Offer Window Closed | |
| − | + | * Child Event Scheduled | |
| − | + | : | |
| − | + | * Child Event Dispatch Reminder | |
| − | + | * Child Event Active | |
| − | + | * Child Event Completed | |
| − | + | * Child Event Meter Data Required | |
| − | + | * Child Event Invoice Created | |
| − | + | * Child Event Cancelled | |
| − | + | * Child Event Declined | |
| − | + | * Child Event Withdrawn | |
| − | + | : | |
| − | + | ===Auto DR Events=== | |
| − | + | These are events that allow participation from Devices and are smart enough to automatically deliver the event details to the accepted devices. This removes the need for human interaction during event time. Load should be shad automatically.AutoDR events are built on top of existing Price Responsive / Non Price Responsive concepts. AutoDR is enabled at the programme level by enabling any of the 3 supported device types and defining mappings between the 3 AutoDR levels and native device signals.Defined AutoDR levels | |
| − | + | * Low | |
| − | + | * Medium | |
| − | + | * High | |
| − | : | + | Supported device types: |
| + | * OpenADR | ||
| + | * Ambi Climate | ||
| + | * Future Point | ||
| + | The lifecycle of the Price Responsive / Non Price Responsive event remains unchanged. The only differences are: | ||
| + | * for Price Responsive events, during the biding process, the participant can decide what devices he/she wants to be signed up for the event and what DR level is willing to accept. This basically allows the participant to change the amount of AutoDR kW offered. The amount of kW delivered by devices will add on top of any manual kW that the participant may deliver. | ||
| + | * for Non Price Responsive events, the market operator has to chose one of the AutoDR levels that apply for the event. This level, together with the programme's AutoDR mapping, dictates what native signal will be sent to each device participating in the event. | ||
| + | * when the event transitions into the scheduled state, the server will automatically send a native event to all devices enrolled in the event informing them of the start of the event, duration of the event and what signal or what level they should switch to during the event. Devices are expected to switch back to the default state once the event has expired. | ||
| + | * when an event transitions into the canceled state, the server will automatically cancel all the events it has previously delivered to enrolled devices. | ||
| + | * Device eligibility for participation into an event is dictated by what type of devices were enabled on the programme. Furthermore, a device has to be fully registered before it is allowed to be part of an event.There is no guarantee that a device will actually be online at the time of the event. The server follows a best effort approach where events are sent to all participating devices regardless of the server's current knowledge about the VEN's online/offline status. However, in order to mitigate this issue, the server will notify the appropriate users as soon as it detects that a device has gone offline. | ||
Revision as of 02:39, 28 May 2019
A DR event represents a request for your organisation to shed load over a specific time period from multiple registered sites capable of shedding load. An event cannot span across multiple days.Every registration of load is sent a separate child event mirroring the parent event parameters, but with a price and target kW amount specific to the site.
Event Status’s
From the time that an event is created right up until the payment for said event has been completed the event goes through several status’s:
| Standard Status Progression | |
| Offer Window Open | Published, offers can be made |
| Offer Window Closed | Published, offers can no longer be made |
| Scheduled | Event has been scheduled - participants are notified whether or not they have been selected to participate |
| Active | Event is in an active state - participants should have shed load at this stage |
| Completed | Event is finished - settlement can begin |
| Meter Data Required | Event is finished, meter data is required to settle |
| Meter Data Submitted | Event is finished, and meter data required for settlement has been detected |
| Payment Payment | A payment has been generated for the event |
| Payment Complete | An invoice has been uploaded for the payment |
| Potential Event Status’s | |
| Cancelled | Event was cancelled |
| Ineligible | The registration is not eligible to participate in this event (this could be due to the registration being accepted into another event at the same time instead) |
| Declined | The child event was declined |
| Withdrawn | The child event was withdrawn |
Event Types
Two types of event exist in the DRMS, price response and non-price responsive.
- Price responsive events progress through an offer window process after they have been submitted.
- Non-price responsive events do not go through an offer window and instead proceed straight to scheduled.
Offer Window
Before the event is scheduled it goes through an offer window process. During this time participants can agree to make an offer in the DR event.A participant can respond to an offer to participate by opting in or out of the event and optionally decreasing their offered price or kW amount.
Non price-responsive events skip the offer process.
- '
Event Notifications
The following notifications are sent over the life-span of an event:
- Child Event Offer Window Open
- Child Event Offer Window Closed
- Child Event Scheduled
- Child Event Dispatch Reminder
- Child Event Active
- Child Event Completed
- Child Event Meter Data Required
- Child Event Invoice Created
- Child Event Cancelled
- Child Event Declined
- Child Event Withdrawn
Auto DR Events
These are events that allow participation from Devices and are smart enough to automatically deliver the event details to the accepted devices. This removes the need for human interaction during event time. Load should be shad automatically.AutoDR events are built on top of existing Price Responsive / Non Price Responsive concepts. AutoDR is enabled at the programme level by enabling any of the 3 supported device types and defining mappings between the 3 AutoDR levels and native device signals.Defined AutoDR levels
- Low
- Medium
- High
Supported device types:
- OpenADR
- Ambi Climate
- Future Point
The lifecycle of the Price Responsive / Non Price Responsive event remains unchanged. The only differences are:
- for Price Responsive events, during the biding process, the participant can decide what devices he/she wants to be signed up for the event and what DR level is willing to accept. This basically allows the participant to change the amount of AutoDR kW offered. The amount of kW delivered by devices will add on top of any manual kW that the participant may deliver.
- for Non Price Responsive events, the market operator has to chose one of the AutoDR levels that apply for the event. This level, together with the programme's AutoDR mapping, dictates what native signal will be sent to each device participating in the event.
- when the event transitions into the scheduled state, the server will automatically send a native event to all devices enrolled in the event informing them of the start of the event, duration of the event and what signal or what level they should switch to during the event. Devices are expected to switch back to the default state once the event has expired.
- when an event transitions into the canceled state, the server will automatically cancel all the events it has previously delivered to enrolled devices.
- Device eligibility for participation into an event is dictated by what type of devices were enabled on the programme. Furthermore, a device has to be fully registered before it is allowed to be part of an event.There is no guarantee that a device will actually be online at the time of the event. The server follows a best effort approach where events are sent to all participating devices regardless of the server's current knowledge about the VEN's online/offline status. However, in order to mitigate this issue, the server will notify the appropriate users as soon as it detects that a device has gone offline.
