8.8.1 Overview
This function set provides an interface for capturing responses from all events, including demand response and load control (DRLC), distributed energy resources (DERs), pricing, and messaging. Client devices of this function set include smart thermostats, in-premises displays, energy management systems, and devices that support load control, pricing, or text events.
The originating event will indicate if a response is required.
8.8.2 List ordering
Table 26 —Response list ordering
Resource name | Primary key | Secondary key | Tertiary key |
ResponseSet | mRID (descending) | N/A | N/A |
Response | createdDateTime (descending) | endDeviceLFDI (ascending) | N/A |
8.8.3 Application guidelines/behavior
8.8.3.1 Introduction
Clients of any function set that can utilize the Response function set (e.g., DRLC, DER, Price, Messaging, Flow Reservation) SHALL implement a Response function set client.
The typical use for this function set is that end devices will POST their responses to a Response resource identified in events. It is not expected that devices will use discovery to locate these resources.
It is up to the implementer to decide whether to have all responses in a single list or to have multiple lists. The destination of the Responses is controlled by the replyTo attribute of the originating event.
If a response is desired to an event, then the event SHALL provide, in the replyTo field, a URI indicating the location of where the responses are to be posted.
The client SHALL POST the responses to the indicated URI based on the rules indicated by the responseRequired bitfield of the event.
If a server hosts events that specify a response is required, then that server is NOT REQUIRED to host the response server.
The response server identified in the replyTo field of the event SHOULD be available on the network.
Several function sets use the responseRequired attribute, which indicates whether or not this particular event requires a response from the client. Table 27 indicates the valid Response.status values supported by each function set.
Table 27 —Response types by function set
Enumeration value | Description | Why sent | When sent | response Required bit position | DRLC and DER | Pricing | Messaging |
0 | Reserved | ||||||
1 | Event received | To notify response server that client has initially received event | When the device first receives the event, either via a GET or a Notification | 0 | X | X | X |
2 | Event started | To notify response server that client has begun event | At EffectiveStartTime (see 10.2.3.2) | 1 | X | X | X |
3 | Event completed | To notify response server that the event fully and successfully completed | At EffectiveEndTime (see 10.2.3.2) | 1 | X | X | X |
4 | User has chosen to opt-out | To notify response server that user has chosen to opt out of the event. Can occur before event begins | At time user actively chose to opt out or when device automatically opts out due to user preference | 1 | X | ||
5 | User has chosen to opt-in | To notify response server that user has chosen to opt in to the event (after a previous opt-out). Can occur before event begins | At time user actively chose to opt in or when device automatically opts in due to user preference | 1 | X | ||
6 | The event has been cancelled | To notify response server that client has initially received cancellation | When the device first receives the cancellation, either via a GET or a Notification, even if the event has not yet begun execution | 1 | X | X | X |
7 | The event has been superseded | To notify response server that client has learned of an event that supersedes this event | When the device first learns of an event that supersedes this event, even if the event has not yet begun execution | 1 | X | X | X |
8 | Event partially completed with user opt-out | To notify response server that some participation in the event occurred, but not complete participation, due to one or more user opt-outs | At EffectiveEndTime (see 10.2.3.2) | 1 | X | ||
9 | Event partially completed due to user opt-in | To notify response server that some participation in the event occurred, but not complete participation, due to one or more user opt-ins (after a previous opt-out) | At EffectiveEndTime (see 10.2.3.2) | 1 | X |
Table 27—Response types by function set (continued)
Enumeration value | Description | Why sent | When sent | response Required bit position | DRLC and DER | Pricing | Messaging |
10 | Event completed, no user participatio n (previous opt-out) | To notify response server that no participation in the event occurred | At EffectiveEndTime (see 10.2.3.2) | 1 | X | ||
11 | User has acknowledg ed the event | To notify response server that the client displayed the event and a human user actively acknowledged it | At time user actively chose to acknowledge the event | 2 | X | X | X |
12 | Cannot be displayed | To notify response server that the client is unable to display the message | When the device first receives the event, either via a GET or a Notification | 1 | X | ||
13 | Event aborted due to alternate server event | To notify response server that the client has chosen to stop execution of the event and instead execute an event from a different function set instance on a different server | At time the original event was ceased | 1 | X | X | X |
14 | Event aborted due to alternate program event | To notify response server that the client has chosen to stop execution of the event and instead execute an event from a different function set instance on the same server | At time the original event was ceased | 1 | X | X | X |
15 to 251 | Reserved | ||||||
252 | Rejected: control parameter not applicable | To notify response server that client is unable to execute the event due to the controls being inapplicable to the device (e.g., a temperature offset was sent to a pool pump) | When the device first receives the event, either via a GET or a Notification | 1 | X | ||
253 | Rejected: invalid event | To notify response server that client is unable to execute the event due to the controls (e.g., duty cycle, offset, setpoint) being out of range or not possible for the device (e.g., settings already at a maximum or minimum) | When the device first receives the event, either via a GET or a Notification | 1 | X | ||
254 | Rejected: event was received after it expired | To notify response server that client has initially received event, but that the event was received after SpecifiedEndTime | When the device first receives the event, either via a GET or a Notification | 1 | X | X | X |
255 | Reserved |
8.8.3.2 Response storage
It is expected that the server provides some mechanism that allows the service provider to obtain the responses, even in the presence of outages. Details of storage are vendor specific.
Implementers SHOULD have enough storage and bandwidth to support responses for the number of devices they plan to support as a server for each function set that requires a response.
If the server supports the GET method for the Response function set, the server SHALL minimally support one response for each function set for which it accepts responses.
8.8.4 LogEvents
Table 28 —Response LogEvents
LogEvent name | LogEvent code | LogEvent description |
RESPONSE_LIST_OVERFLOW | 0x00 | Should be issued by a server anytime their response list has exceeded maximum storage |
RESPONSES_REPORTED_UPSTREAM | 0x01 | Should be issued by a server when responses are sent upstream |