- OCF API object
- OCF Client API to access remote resources
- OCF Server API to implement local resources
- The OcfDevice dictionary
- The OcfPlatform dictionary
- The OcfError interface
- Web IDL
- Examples
This document presents a JavaScript API for the OCF Core Specification version 1.1.0.
The OCF provides
-
the specification for the Core Framework for OCF core architecture, interfaces, protocols and services to enable the implementation of OCF profiles for IoT usages
-
Application Profiles Specification documents for the OCF profiles to enable IoT usages for different market segments such as home, industrial, healthcare, and automotive.
In OCF terminology, multiple providers and solutions can share a physical hardware platform. A platform may host multiple physical or virtual devices. Devices are addressable endpoints of communication, and run the OCF software stack. A device may host multiple physical or virtual resources. A resource represents sensors and actuators.
A given sensor or actuator is represented by resource properties. A read-only resource property represents a sensorial input, whereas a read-write property represents the state of an actuator.
Resources can be accessed remotely, and can notify subscribers with data and state changes. The resources act as servers, and communication may involve different protocols like CoAP or HTTP. Resources may also be represented by devices that translate between resource-specific and standard protocols. These devices are called gateways, or OCF intermediary devices.
The devices support installable software modules called applications. This API is exposed on an OCF device and enables writing applications that implement resources and related business logic.
This version of the API supports OCF Resource, Device, and Platform related functionality. OCF Collections, Links and Scenes are not yet supported.
Since implementations may run on constrained hardware, examples use ECMAScript 5.1.
The API object represents an OCF stack (device) and is exposed in a platform-specific manner. As an example, on Node.js it can be obtained by requiring the package that implements this API. On other platforms, it can be exposed as a property of a global object.
let module = 'ocf'; // use your own implementation's name
var ocf = require(module);
If the functionality is not supported by the platform, require
should throw NotSupportedError
. If there is no permission for using the functionality, require
should throw SecurityError
.
When require
is successful, it MUST return an object with the following properties and methods.
Property | Type | Optional | Default value | Represents |
---|---|---|---|---|
version |
string | no | versions.ocf in package.json |
API version |
Method signature | Description |
---|---|
start(mode, options) |
start the OCF stack |
stop() |
stop the OCF stack |
The version
property is read only and provides the the OCF API specification, as specified in the versions.ocf
property of package.json
.
The start(options)
method initializes the underlying platform and resolves with an API object providing OCF client, or server, or both client-server functionality.
The mode
optional parameter is a string that can be "client-server"
(by default), or "client"
, or "server"
.
The options
optional parameter is an object that may contain the following properties:
Property | Type | Optional | Default value |
---|---|---|---|
device |
OcfDevice object | yes | undefined |
platform |
OcfPlatform object | yes | undefined |
The method runs the following steps:
- Return a
Promise
objectpromise
and continue in parallel. - If the
mode
argument isundefined
, letmode
be"client-server"
. - Otherwise if the
mode
argument is not"client"
, or"server"
, or"client-server"
, rejectpromise
with aTypeError
and abort these steps. - If the
mode
parameter is"client"
, then run the following sub-steps:- If
options
oroptions.device
oroptions.platform
are notundefined
, rejectpromise
withNotSupportedError
and abort these steps. (Client-only device has noplatform
property, and itsdevice
property cannot be configured). - Initialize the underlying OCF stack in client mode.
- If there is an error, reject
promise
withOcfDeviceError
and abort these steps. - Let
result
be an object that implementsOcfClient
. Letresult.device
be anOcfDevice
object initialized from the underlying platform.
- If
- Otherwise if the
mode
parameter is"server"
, then run the following sub-steps.- Initialize the underlying OCF stack in server mode. If
options.device
is defined, use the defined properties for initializing the OCF stack. Ifoptions.platform
is defined, use the defined properties for initializing the OCF stack. - If there is an error, reject
promise
withOcfDeviceError
and abort these steps. - Let
result
be a new object that implementsOcfServer
. Initialize theresult.device
andresult.platform
properties from the underlying OCF stack.
- Initialize the underlying OCF stack in server mode. If
- Otherwise if the
mode
parameter isclient-server
, then run the following sub-steps.- Initialize the underlying OCF stack in client-server mode. If
options.device
is defined, use the defined properties for initializing the OCF stack. Ifoptions.platform
is defined, use the defined properties for initializing the OCF stack. - If there is an error, reject
promise
withOcfDeviceError
and abort these steps. - Let
result
be a new object that implements bothOcfServer
andOcfClient
. - Initialize the
result.device
andresult.platform
properties from the underlying OCF stack.
- Initialize the underlying OCF stack in client-server mode. If
- Resolve
promise
withresult
.
The stop()
method frees resources in the underlying platform, so that a next invocation to start()
is able to start the device from a clean state. After the stop()
method returns, all properties of ocf
should be undefined
.
Exposes information about the OCF device that runs the current OCF stack instance. All properties are read-only. Future versions of this specification will support configuring some of the values.
Property | Type | Optional | Default value | Represents |
---|---|---|---|---|
uuid |
string | no | undefined |
UUID of the device |
name |
string | yes | undefined |
Name of the device |
types |
array of strings | no | [] |
List of supported OCF device types |
dataModels |
array of strings | no | [] |
List of supported OCF data models |
coreSpecVersion |
string | no | undefined |
OCF Core Specification version |
The uuid
property is generated by the underlying OCF stack during the on-boarding process. Applications may provide this property, but it may be changed by the implementation after the device is started.
The name
property represents the device name as provided by the application. Users can also set a free-form device name using the configure() method that updates the oic.wk.con
resource, hence does not alter name
.
The types
property is a list of the OCF Device types that are supported. It comforms to the same syntax constraints as resource types. OCF mandates that every device supports at least the properties defined in the "oic.wk.d"
resource type, that represents a resource for a "basic device". Other specifications, such as the OCF Smart Home Device Specification can define more device types, for instance "oic.d.fan"
, "oic.d.thermostat"
, "oic.d.light"
, "oic.d.airconditioner"
, etc. The properties exposed by these device types are defined in oneiota.org. The values in types
may be used in device discovery filters. For a client-only device types
is an empty array. When a server device registers a new resource with a new resource type, this property SHOULD be updated by the implementation.
Elements of the dataModels
property are in the following format: vertical.major.minor.version
where major
, minor
and version
are numbers and vertical
is a string. For instance, in the OIC 1.1.0 Core Specification the supported data model version is "res.1.1.0"
.
The coreSpecVersion
is "1.1.0"
in this version of the specification.
Exposes information about the OCF platform that hosts the current device.
Property | Type | Optional | Default value | Represents |
---|---|---|---|---|
id |
string | no | undefined |
Platform identifier |
model |
string | yes | undefined |
Model of the hardware |
manufacturerName |
string | no | undefined |
Manufacturer name |
manufacturerLink |
string | yes | undefined |
Manufacturer URI |
manufactureDate |
Date | yes | undefined |
Manufacturing date |
vendorId |
string | yes | undefined |
Vendor ID |
osVersion |
string | yes | undefined |
OS version |
platformVersion |
string | yes | undefined |
Platform version |
firmwareVersion |
string | yes | undefined |
Firmware version |
hardwareVersion |
string | yes | undefined |
Firmware version |
supportURL |
string | yes | undefined |
Product support web page |
datetime |
Date | yes | undefined |
System time of the device |
Errors during OCF network operations are exposed via onerror
events and Promise
rejections.
OCF errors are represented as augmented instances of Error
objects.
The following Error
names are used for signaling OCF issues:
OcfResourceNotFound
used if the resource cannot be located in the OCF network, or when an observed resource is deleted from the network.OcfDeviceNotFound
used if the device id cannot be located in the OCF network.OcfDiscoveryError
for generic discovery related errorsOcfObserveError
for generic observe related errors that are not covered byOcfResourceNotFound
.OcfResourceError
for other resource related errors.OcfDeviceError
for other device related errors.
The OCF error objects MAY contain two additional optional properties.
Property | Type | Optional | Default value | Represents |
---|---|---|---|---|
deviceId |
string | yes | undefined |
UUID of the device |
resourcePath |
string | yes | undefined |
URI path of the resource |
- The
deviceId
property is a string that represents the device UUID causing the error. The valuenull
means the local device, and the valueundefined
means the error source device is not available. - The
resourcePath
property is a string that represents the resource path of the resource causing the error. IfdeviceId
isundefined
, then the value ofresourcePath
should also be set toundefined
. - The
message
property is inherited fromError
.
The constructor of OcfDiscoveryError
and OcfObserveError
takes the following parameters:
- the
message
parameter is a string representing an error message, as withError
- the
deviceId
parameter instantiates thedeviceId
property - the
resourcePath
parameter instantiatesthe resourcePath
.
If deviceId
is defined, and resourcePath
is undefined
or null
, it means the error is device-specific without being specific to the resource (such as errors realted to device presence).
let message = "OCF error";
let deviceId = "0685B960-736F-46F7-BEC0-9E6CBD61ADC1";
let resourcePath = "/myroom/a/light/1";
var err = new OcfObserveError(message, deviceId, resourcePath);
// use `err` in a server response
Implementations SHOULD handle the uncaughtException
event on the process object.
The API uses Promises with these notes.
The API uses Node.js-style events with these notes.
Code using this API is deployed to a device which exposes one or more resources. In this version of the API it is assumed that the execution context of the code is separated for each device.
Device identification is UUID.
Resource identification is URL path, relative to a given device. A URL composed of the oic
scheme, the device ID as host and the resource path can also be used for identifying a resource: oic://<deviceID>/<resourcePath>
. However, this specification uses the device ID and resource ID separately.
Device discovery uses endpoint discovery, that is, a multicast request "GET /oic/res" to "All CoAP nodes" (224.0.1.187
for IPv4 and FF0X::FD
for IPv6, port 5683). The response lists devices and their resources (at least URI, resource type, interfaces, and media types).
OCF defines special resources on each device, for implementing device discovery, resource discovery, platform discovery, presence, etc. API implementations should encapsulate handling these special resources and the hardcoded/fixed URIs.
This version of the API supports the OCF Core Specification version 1.0 (final) and 1.1.0 (draft), except that it does not yet support OCF resource links, scenes, rules and scripts.