@@ -99,9 +99,9 @@ This clause describes a use case which helps to understand the devices abstracti
This guide is based on the following use case: an application on a Gateway, Cloud/Server, or Smartphone wants to monitor and control lightbulbs. Due to the abstraction layer provided by oneM2M, the monitoring and controlling processes can be performed independently from underlying connectivity technologies. This tutorial is based on the example of Philips Hue lightbulbs (these lightbulbs require dedicated bridge for connection with Gateway). Figure 5.1-1 presents the general architecture of the use case.
NOTE: The terms of use of Philips Hue API are available at https://developers.meethue.com/documentation/terms-use.
NOTE: The terms of use of Philips Hue API are available at https://developers.meethue.com/documentation/terms-use.<mark>Editor note: check this URL</mark>
**Figure 5.1-1: Overview of the lightbulbs use case**
...
...
@@ -113,7 +113,7 @@ The main components are introduced as follows:
- The Smartphone hosts an application used to remotely control and monitor the lightbulbs in the home and supports the following capabilities:
- Discovery of the lightbulbs deployed in the home.
- Sending commands to change light state i.e. switch on/off and change colour.
- Receive state of a lightbulb.
- Receive state of a lightbulb.<!---->
# 6 Introduction to IPE and SDT
...
...
@@ -130,7 +130,7 @@ The SDT (Smart Device Template) is a reference template to model most home appli
The SDT approach is to define re-usable basic functions (or services) (labelled "ModuleClass" in Figure 6.2-1) which can represent the typical functions found, for example, in many home automation systems, such as "on/off", "dim a lamp", "receive events from binary sensor", "read data from sensor", etc.
**Figure 6.2.1-1: SmartHome Device Template for a generic device**
...
...
@@ -225,7 +225,7 @@ In reference to oneM2M terminology, when a new device is discovered the CSE shou
To allow current non-oneM2M devices ("NoDN", Non-oneM2M Device Node) to connect to the oneM2M system the specification provides "Interworking/Integration of non-oneM2M solutions and protocols" section (Annex F of oneM2M TS-0023 <ahref="#_ref_i.2">[i.2]</a>). Figure 6.3-1 shows SDT in oneM2M architecture.
**Figure 6.3-1: Translation of non-oneM2M Data Model to SDT Data Model via the IPE**
...
...
@@ -234,7 +234,7 @@ To allow current non-oneM2M devices ("NoDN", Non-oneM2M Device Node) to connect
Clause 7 describes how the elements of this use case are represented by corresponding oneM2M architectural entities. Figure 7-1 presents the functional architecture of this use case.
**Figure 8.2.1-1: AE registration with CSE request**
...
...
@@ -286,7 +286,7 @@ The procedure to create resource tree for particular SDT Device (deviceLight in
- Device adapter (IPE-AE) sends a CREATE request to gateway (MN-CSE) to create _<flexContainer>_ for a single Action. The _<flexContainer>_ which represents Action is set as a child of _<flexContainer>_ which represents Module.
- Gateway (MN-CSE) responds with URI for created Action.
**Figure 8.3.1-1: AE registration with CSE request**
...
...
@@ -312,7 +312,7 @@ The procedure to discover SDT Device is as follows:
- Utility application (ADN-AE-1) sends a RETRIEVE request to server (IN-CSE) including filter criteria conditions, especially it could be a _containerDefinition_ attribute (e.g. org.onem2m.home.devices.deviceLight).
- Server (IN-CSE) responds with list of URIs of the discovered resources, if any (especially URI for deviceLight which represents a bulb).
@@ -351,7 +351,7 @@ The procedure to change DataPoint value is as follows:
- Utility application (ADN-AE-1) sends an UPDATE request to server (IN-CSE) with _<flexContainer>_ which contains the new value of the DataPoint. There is also a possibility to change more than one DataPoint of particular ModuleClass in a single request (in this case the <flexContainer> contains new values of all needed DataPoints.
- Server (IN-CSE) responds with status of DataPoint's UPDATE operation.
