8.5.1 Overview
The End Device function set provides interfaces to exchange information related to particular client device(s). This may include both general information about a client (e.g., SFDI, software version numbers) and information specific to the relationship between a client and the server where the EndDevice resource is hosted (e.g., subscriptions, Function Set Assignments, registration). The major resources are listed below:
EndDeviceList
EndDevice
EndDeviceList provides the list of all EndDevice resources hosted by the given server. Each EndDevice resource corresponds to a particular client device for which the server is maintaining persistent information. On an End Device function set server, an EndDevice resource may be created as part of an out-of-band registration process. EndDevice resources may also be created on a POST to the End Device List.
8.5.2 List ordering
Table 21 —EndDevice list ordering
Resource name | Primary key | Secondary key | Tertiary key |
EndDevice | changedTime (descending) | SFDI (ascending) | href (ascending) |
8.5.3 Application guidelines/behavior
Servers MAY present the EndDeviceList differently based on the credentials of the requesting client. For example, even if a server contains the EndDevice resources for five registered clients, any one registered client that GETs the EndDeviceList may receive a list resource containing only the one EndDevice resource corresponding to that client. Similarly, an unregistered client that GETs the EndDeviceList may receive an empty EndDeviceList list resource. However, clients SHALL NOT rely on this filtering behavior, as it is not mandatory server behavior; therefore, clients SHALL support the normal paging mechanism for List- type resources.
If a server hosts resources pointed to from an EndDevice instance (e.g., DeviceInformation, PowerStatus) that allow PUT, POST, or DELETE access, those HTTP methods SHOULD be restricted to the client device represented by the given EndDevice.
Clients MAY update their EndDevice and related status resources at regular intervals, or when the relevant information changes, to the appropriate sub-resources of an EndDevice instance that corresponds to the client.
Clients SHALL NOT POST a new EndDevice instance to a server’s EndDeviceList if that EndDeviceList already contains an EndDevice instance for the client.
Servers MAY remove records after 72 hours of no interaction from the corresponding client. It is RECOMMENDED that clients interact with the server at least once every 48 hours.
Servers SHOULD delete or prevent duplicate EndDevice instances for the same client from appearing in its EndDeviceList. For instance, certificate information transmitted as part of TLS may be used to uniquely identify a particular client and prevent it from POSTing multiple EndDevice instances.
Servers MAY remove EndDevice instances and/or their subordinate resources at any time, for any reason. Servers SHALL NOT remove EndDevice instances before marking them as disabled (using the enabled attribute) and allowing time for clients to query this change. Clients that have cached URIs for their EndDevice instance and/or subordinate resources, but are no longer able to access those resources, SHOULD attempt to rediscover the new locations of those resources, recognizing that they MAY have been permanently deleted by the server (e.g., as part of an out-of-band de-registration process).
When a Server receives an EndDevice resource via a POST to its EndDeviceList, the Server SHOULD NOT modify any of the Link attributes inherited from AbstractDevice if the Link contains a fully qualified URI. If a POSTed Link does not contain a fully qualified URI, the Server MAY allocate local storage for that subordinate resource and populate the EndDevice resource with a Link pointing to the allocated resource, or the Server MAY choose not to support that particular subordinate resource, if allowed by the IEEE 2030.5 schema, in which case that particular Link attribute would not appear in the newly created EndDevice resource.
Clients that POST EndDevice resources to the EndDeviceList of a Server SHOULD NOT populate Link attributes in that EndDevice resource with fully qualified URIs that point to resources on the Server itself. Servers would typically allocate storage and URIs themselves.
8.5.4 LogEvents
Table 22 —EndDevice LogEvents
LogEvent name | LogEvent code | LogEvent description |
LE_UNAUTHORIZED_WRITE_TO_END_DEVICE | 0x00 | MAY be generated in response to PUT, POST, and DELETE attempts by an unauthorized device on an EndDevice instance or any of its protected sub- resources. |