User Tools

Site Tools


easy_setup

Easy Setup - Programmer's Guide

Easy Setup is a primitive service layer developed using native platform and IoTivity APIs for making UI-less unboxed devices to be easily connected to the end user's IoTivity network seamlessly, thus enabling the devices to be part of the IoTivity network in a user friendly manner. Specifically, user can transfer a bunch of essential information to the unboxed devices in easy setup phase, which the information includes: WiFi AP connection information needed for the device to connect to Home AP and device configuration like language and country settings. Additionally, user can provide a cloud access information to the devices so that they can register them to an IoTivity cloud server and user can access them via IoTivity cloud even from a distance.


USE CASES

  • A device is unboxed.
  • Mobile connects to the unboxed device.
    • Using a Soft AP network or BT/BLE connection.
  • Mobile transfers Home AP’s information and other information.
    • SSID, password, security type of Home AP.
    • Language, country used in the device.
  • Unboxed device connects to Home AP
  • Mobile transfers a cloud access information to the device via Home AP network.
  • Unboxed device registers to IoTivity Cloud server.


DEVICE ROLES

There are three types of roles defined in Easy Setup for various devices involves in Easy Setup method. These roles are; Enrollee, Mediator and Enroller and their architecture view is depicted with below diagram:

Enrollee

A device that needs to be configured to join user's device network. It typically have limited CPU, memory, and power resources, so- called “constrained devices” often used as sensors/actuators, smart objects, or smart devices) are termed as Enrollee devices. All the constrained devices discussed above may or may not have the user interface to take user input and connect to the user desired networks.

Mediator

The purpose of a Mediator in Easy Setup is to enable Enrollee devices to be easily connected to the target WiFi network and the target IoTivity cloud server if needed. In practice, mobile phone can act as a Mediator, mostly.

Enroller

Enroller is the target network entity to be connected by Enrollee. Mediator provides the target Enroller information to the Enrollee. The Mediator may get the Enroller information either from the application user or dynamically fetch from the Enroller depending on the deployment transport and scenario.


TERMINOLOGY

Ownership Transfer

Ownership Transfer Methods (OTMs) gets ownership of the Enrollee device by the Mediator device and establishes a secure communication channel between them for all subsequence transcations. Ownership Transfer Methods (OTMs) involves credentials transfer, setting up device access policy i.e. ACL on the Enrollee device.

WiFi provisioning

A phase of transferring a WiFi-related information to Enrollee. Mediator can provide a WiFi AP's SSID, password, security type (authentication and encryption type). Upon receiving the information from Mediator, Enrollee is expected to destroy its SoftAP network and try to connect to WiFi AP with the given information.

Device Configuration provisioning

A phase of transferring a device configuration information to Enrollee. Mediator can provide a country, language, and location information to Enrollee. Upon receiving the information from Mediator, Enrollee can configure itself to the given settings.

Cloud Server provisioning

A phase of transferring a cloud access information to Enrollee. Note that, IoTivity cloud server utilizes OAuth 2.0 protocol to authenticate an user and his device. Thus, Mediator should request a new Auth code to one of account server(e.g., github and facebook) and provide it to Enrollee. With the given Auth code, Enrollee tries to sign up to IoTivity cloud server. For that, there would be multiple IoTivity cloud servers depending on its deployment, so Mediator should provide a cloud interface server URI of which the enrollee is expected to be registered.


FEATURES

This section describes the features of Easy Setup Service:

  • Provide a security mechanism to secure a communication channel for transferring a sensitive information like WiFi AP's SSID and password.
  • Able to deliver a WiFi connection information to out-of-box device in a given network (i.e. Soft AP network)
  • Able to deliver a device configuration to out-of-box device like language and location.
  • Able to deliver a cloud access information to out-of-box device like auth code and cloud server address.
  • Compatible to OCF Specification

RESOURCE MODEL

There are 4 OCF resources for Easy Setup Service: Provisioning, WiFi, DevConf, and CloudServer resources. Note that, Provisioning resource is a collection resource and the other resources are binded to Provisioning resource as child resources.


Provisioning Resource

Provisioning resource stores an useful information including a current status of unboxing device and last error code which are produced in a process of easy setup. The information includes:

  1. A current status in easy setup process
  2. A last error code describing a reason of some failures occured at the last time.

As mentioned before, Provisioning resource is a type of collection resource, which has WiFi, CloudData, and DevConf resources as its child resources. That is, through Provisioning resource, Mediator can retrieve all properties of WiFi, DevConf, CloudServer resources and update some of them by help of BATCH interface.

The detailed information of this resource is described below:


WiFi Resource

WiFi resource stores an essential information to help an unboxing device to connect to an existing WiFi AP. The information includes :

  1. WiFi SSID and password
  2. WiFi Security type (i.e. auth type and encription type)
  3. WiFi hardware capability (i.e. supported frequency and mode)

The detailed information of this resource is described below:


DevConf Resource

Device configuration resource stores a preference of device settings like device name, language, country, and etc. Vender-specfic information can be added to the resource. The information includes :

  1. Device name (human-friendly)
  2. Model Number (defined by manufacturer)
  3. Lanugage (Follow IETF laungage tag using ISO 639X)
  4. Country (ISO 3166-1 Alpha-2 encoded)
  5. Location (GPS in json)

The detailed information of this resource is described below:


CloudServer Resource

Cloud server resource stores all information for an unboxing device to register to cloud server. We assume that OAuth 2.0 protocol is used for authencating an user account by the cloud server. The information includes :

  1. Auth code
  2. Authentication provider ID
  3. Cloud interface server URL

The detailed information of this resource is described below:


OVERALL WORKFLOW



ARCHITECTURE


Mediator Architecture

Enrollee Architecture


CLASS DIAGRAM


Mediator C++ Class Diagram


API USAGES


Multi-PHY Setup Service SDK consists of two parts :

  • Mediator SDK (C++, Android)
  • Enrollee SDK (C)

Mediator SDK


Mediator SDK provides several APIs to communicate with Enrollee device. What Mediator should do for Enrollee is:

  1. Enable security configuration of Enrollee (i.e. Ownership transfer and DTLS setup)
  2. Transfer WiFi-related information (i.e. WiFi SSID, Password, and Security Type)
  3. Transfer device configuration to be set (i.e. language, country, and location)
  4. Transfer cloud access information (i.e. auth code, auth provider, and CI server URL)

Besides, Mediator can retrieve several pre-configured information from Enrollee:

  1. Supported WiFi frequency(i.e. 2.4G and 5G) and mode (e.g., 802.11g and 802.11n)
  2. Device name and model number given by manufacturer

Additionally, Mediator can know a status of Enrollee in easy setup process and last error code used for clarify a failure reason happened in Enrollee.


Class diagrams of Mediator C++ SDK

A role of each class can be described as follows:

  1. EasySetup class
    1. Create an instance of RemoteEnrollee object with a discovered resource which is represented as Provisioning resource in Enrollee.
  2. RemoteEnrollee class
    1. Represented as the corresponding Enrollee and provides all necessary APIs for communicating with the Enrollee
  3. EnrolleeSecurity class
    1. Provide a functionality related to security provisioning
    2. Perform an Ownership transfer, ACL provisioning, and Cert provisioning to Enrollee
  4. EnrolleeResource class
    1. Perform a functionality to handle request/response related to WiFi and DevConf resource's properties
  5. CloudResource class
    1. Perform a functionality to handle request/response related to CloudServer resource's properties

API usages of Mediator C++ SDK

This section is going to describe how to use Mediator C++ APIs to do easy-setup with Enrollee. It is assumed that there is an out-of-box Enrollee in a network and no security provisioning by other entity has been performed before.

  • Preliminary, you have to configure Iotivity stack to be operated as secured mode. From Mediator side, you should initiate “Provisioning Manager” functionality by calling OCSecure::provisionInit API as well as specifying SVR DB path.
static FILE* client_open(const char *UNUSED_PARAM, const char *mode)
{
    (void)UNUSED_PARAM;
    return fopen("./oic_svr_db_client.json", mode);
}
 
int main()
{
    OCPersistentStorage ps {client_open, fread, fwrite, fclose, unlink };
 
    PlatformConfig config
    {
        OC::ServiceType::InProc, ModeType::Both, "0.0.0.0", 0, OC::QualityOfService::LowQos, &ps
    };
 
    OCPlatform::Configure(config);
 
    try
    {
    #ifdef __WITH_DTLS__
        //Initializing the provisioning client stack using the db path provided by the application.
        OCStackResult result = OCSecure::provisionInit("");
 
        if (result != OC_STACK_OK)
        {
            return -1;
        } 
    #endif
  • First, discovery a Provisioning resource which corresponds to Enrollee in a network by calling OCPlatform.findResource API. Note that the resource has a standardized resource type, “ocf.wk.prov”, so user can discover the resource with the resource type.
std::ostringstream requestURI;
requestURI << OC_RSRVD_WELL_KNOWN_URI << "?rt=ocf.wk.prov";
 
OCPlatform::findResource("", requestURI.str(), CT_DEFAULT, &foundResource);
std::cout<< "Finding Resource... " <<std::endl;

If an Enrollee exists in a network, a corresponding OCResource object would be passed in its callback function, foundResource in the above example.

  • With the discoverd resource, you, first, create RemoteEnrollee object. To do this, EasySetup class provides createRemoteEnrollee API as below:
// Callback to found resources
void foundResource(std::shared_ptr<OC::OCResource> resource)
{
    ...
    remoteEnrollee = EasySetup::getInstance()->createRemoteEnrollee(resource);
    if(!remoteEnrollee)
    {
        std::cout << "RemoteEnrollee object is failed for some reasons!" << std::endl;
    }
    ...
  • The first required operation with RemoteEnrollee object is a security provisioning. As mentioned below, security provisioning at this stage will perform ownership transfer which makes DTLS channel establishment enabled between Mediator and Enrollee. To do security provisioning, you can call provisionSecurity API of RemoteEnrollee object. The result of the API will be returned in specified callback.
void provisionSecurity()
{
    try
    {
        remoteEnrollee->provisionSecurity(provisionSecurityStatusCallback);
    }
    catch (OCException &e)
    {
        std::cout << "Exception during getConfiguration call" << e.reason();
        return;
    }
}
 
void provisionSecurityStatusCallback(std::shared_ptr<SecProvisioningStatus> secProvisioningStatus)
{
    if(secProvisioningStatus->getESResult() != ES_OK)
    {
      cout << "provisionSecurity is failed." << endl;
      return;
    }
    else
    {
      cout << "provisionSecurity is success." << endl;
      cout << "uuid : " << secProvisioningStatus->getDeviceUUID()<< endl;
    }
}

Even if security provisioning fails or succeeds, the registered callback is always called in bounded time with one parameter, SecProvisioningStatus object. With this object, you can know a result of security provisioning(i.e. by getESResult API) and UUID of the target Enrollee (i.e. by getDeviceUUID API) if it succeeds.

  • After security provisioning, Mediator can communicate to Enrollee in a secure channel (through DTLS). For example, before delivering WiFi-related information to Enrollee, you may want to know pre-configuration of Enrollee. To retrieve the configuration from Enrollee, you can call getConfiguration API of RemoteEnrollee object. The result of the API will be returned in specified callback.
void getConfiguration()
{   
    try
    {
        remoteEnrollee->getConfiguration(getConfigurationCallback);
    }
    catch (OCException &e)
    {
        std::cout << "Exception during getConfiguration call" << e.reason();
        return;
    }
}
 
void getConfigurationCallback(std::shared_ptr< GetConfigurationStatus > getConfigurationStatus)
{
    if(getConfigurationStatus->getESResult() != ES_OK)
    {
      cout << "GetConfigurationStatus is failed." << endl;
      return;
    }
    else
    {
      cout << "GetConfigurationStatus is success." << endl;
 
      EnrolleeConf conf = getConfigurationStatus->getEnrolleeConf();
      cout << "===========================================" << endl;
      cout << "\tDevice Name : " << conf.getDeviceName() << endl;
      cout << "\tModel Number : " << conf.getModelNumber() << endl;
 
      for(auto it : conf.getWiFiModes())
      {
          cout << "\tSupported WiFi modes : " << it << endl;
      }
 
      cout << "\tSupported WiFi freq : " << static_cast<int>(conf.getWiFiFreq()) << endl;
      cout << "\tCloud accessibility: " << conf.isCloudAccessible() << endl;
      cout << "===========================================" << endl;      
    }
}

If a response of this request is successfully received, the registered callback is called with one parameter, GetConfigurationStatus object. With this object, you can know a result of the retrieval request(i.e. by getESResult API) and several properties describing Enrollee's configuration(i.e. by getEnrolleeConf API). You can easily notice how to extract a wanted property from the GetConfigurationStatus object from the above example.

  • After the Enrollee's configuration is known, you can know a WiFi capability like supported WiFi frequency. With this information, you can choose one of Home WiFi APs which Enrollee is able to connect to. After choosing, you can write the WiFi AP information(i.e. SSID, password, and security type) and device configuration(i.e. language, country, and location) in DeviceProp object and transfer it to Enrollee by calling provisionDeviceProperties API of RemoteEnrollee object (We called this tranfer to “Device provisioning”). How to write the information in DeviceProp object and call provisionDeviceProperties API is described in below.
void provisionDeviceProperty()
{
    DeviceProp devProp;
    devProp.setWiFiProp("Iotivity_SSID", "Iotivity_PWD", WPA2_PSK, TKIP_AES);
    devProp.setDevConfProp("korean", "Korea", "Location");
 
    try
    {       
        remoteEnrollee->provisionDeviceProperties(devProp, deviceProvisioningStatusCallback);
    }
    catch (OCException &e)
    {
        std::cout << "Exception during provisionDeviceProperties call" << e.reason();
        return;
    }
}
 
void deviceProvisioningStatusCallback(std::shared_ptr< DevicePropProvisioningStatus > provStatus)
{
    if(provStatus->getESResult() != ES_OK)
    {
      cout << "Device Provisioning is failed." << endl;
    }
    else
    {
      cout << "Device Provisioning is success." << endl;
    }
}

After receiving a result of the device provisioning from Enrollee, a registered callback is called with one parameter, DevicePropProvisioningStatus object, which you can know a result by calling getESResult API of it.

  • After WiFi information as well as device configuration are transfered to Enrollee, it is expected that Enrollee would attempt to connect to Home AP by utilizing the transfered information. That is, Enrollee would destroy its Soft AP network, if it is used, and then Mediator would suffer a disconnection with Enrollee, as well. Thus, Mediator should follow Enrollee by connecting to the Home AP where Enrollee is going to be connected.
  • When connecting to Home AP, Mediaitor can additionally provide a cloud access information to Enrollee if it is needed. A target cloud server is one of IoTivity Cloud server, which uses OAuth2.0-based authentication of users.
  • Before the cloud (information) provisioning, Mediator needs to sign up to the IoTivity cloud server, which means Mediator knows the cloud server's URL, UUID, and certificate used for TLS channel with the cloud server.
  • If Mediator already knows the above information(i.e. the cloud server's URL, UUID, and certificate), it needs to get an authentication code (Auth code, for short) from one of account servers like like github and facebook, which will be delivered to Enrollee. Note that, how to get Auth code from those account server is out-of-scope from IoTivity easy setup.
  • Once Auth code is issued, Mediator fills all information related to cloud access in CloudProp object as the below example, and calls provisionCloudProperties API of RemoteEnrollee object to deliver it to Enrollee.
void provisionCloudProperty()
{
    CloudProp cloudProp;
    cloudProp.setCloudProp("authCode", "authProvider", "ciServer");
    cloudProp.setCloudID("f002ae8b-c42c-40d3-8b8d-1927c17bd1b3");
 
    try
    {
        remoteEnrollee->provisionCloudProperties(cloudProp, cloudProvisioningStatusCallback);
    }
    catch (OCException &e)
    {
        std::cout << "Exception during provisionCloudProperties call" << e.reason();
        return;
    }
}
 
void cloudProvisioningStatusCallback(std::shared_ptr< CloudPropProvisioningStatus > provStatus)
{
    switch (provStatus->getESResult())
    {
        case ES_OK:
            cout << "Cloud Provisioning is success." << endl;
            break;
        case ES_FOUND_ENROLLEE:
            cout << "Enrollee is found in a given network." << endl;
            break;
        case ES_NOT_FOUND_ENROLLEE:
            cout << "Enrollee is not found in a given network." << endl;
            break;
        default:
            cout << "Cloud Provisioning is failed." << endl;
            break;
    }
}

Inside the provisionCloudProperties API, discovery for Enrollee in a given network is performed, again, before all the information are transfered, because Enrollee is likely to connect to Home AP. Due to this discovery, Mediator can get additional result in registered callback function if Enrollee with a known device ID(i.e. UUID) is discovered in given network.

And if the discovery succeeds, then Mediator tries to transfer the cloud information to Enrollee. A result of it can be returned in the registered callback, as well. The above example explains how to know the above results during the cloud provisioning. (by using getESResult API of CloudPropProvisioningStatus object.)


Enrollee SDK


Enrollee, basically, plays as a role of OCF resource server so its SDK provides a set of simple APIs for resource registration and resource property update. The APIs includes:

  1. Initialize Enrollee with resources' creation
  2. Set pre-configured properties in the resources (like supported WiFi frequency and device name)
  3. Set provisioning status and last error code in Provisioning resource, which will let Mediator know by GET request
  4. Terminate Enrollee with resources' destruction

API usages of Enrollee C SDK

This section is going to describe how to use Enrollee C APIs to be ready to communicate with Mediator.

  • First, Enrollee's resources should be initialized by calling ESInitEnrollee API. As parameters in this API, you can choose if the resources are registered as secure resources and which resources are created among WiFi, CloudServer, DevConf resources. And lastly, you can register a set of callback functions as a last parameter of the API, which will called when data properties related to wifi, cloud and device configuration provisioning are delivered.
void StartEasySetup()
{
    printf("StartEasySetup IN\n");
 
    if (OCInit(NULL, 0, OC_SERVER) != OC_STACK_OK)
    {
        printf("OCStack init error!!\n");
        return;
    }
 
    ESResourceMask resourcemMask = ES_WIFI_RESOURCE | ES_CLOUD_RESOURCE | ES_DEVCONF_RESOURCE;
    ESProvisioningCallbacks gCallbacks = {
    .WiFiProvCb = &WiFiProvCbInApp,
    .DevConfProvCb = &DevConfProvCbInApp,
    .CloudDataProvCb = &CloudDataProvCbInApp
     };
 
    if(ESInitEnrollee(gIsSecured, resourcemMask, gCallbacks) != ES_OK)
    {
        printf("OCStack init error!!\n");
        return;
    }
    printf("ESInitEnrollee Success\n");
    ...
}
  • If you successfully called the ESInitEnrollee API, it means that Enrollee is ready to communicate with Mediator by OCF procotol. For example, when Mediator sends a WiFi information, Enrollee can receive and pass it to one of registered callback functions, i.e. WiFiProvCbInApp function in the above example. The received data is represented in a form of ESWiFiProvData data structure, and you can extract all the data as be
void WiFiProvCbInApp(ESWiFiProvData *eventData)
{
    printf("WiFiProvCbInApp IN\n");
 
    if(eventData == NULL)
    {
        printf("ESWiFiProvData is NULL\n");
        return ;
    }
 
    printf("SSID : %s\n", eventData->ssid);
    printf("Password : %s\n", eventData->pwd);
    printf("AuthType : %d\n", eventData->authtype);
    printf("EncType : %d\n", eventData->enctype);
 
    printf("WiFiProvCbInApp OUT\n");
}
  • You can configure Enrollee's pre-configuration like supported WiFi frequency or device name. To do this, Enrollee provide an API, ESSetDeviceProperty, to set several properties to the resource. The properties are filled in ESDeviceProperty data structure and call the API as below:
void SetDeviceInfo()
{
    printf("SetDeviceInfo IN\n");
 
    ESDeviceProperty deviceProperty = {
        {{WIFI_11G, WIFI_11N, WIFI_11AC, WiFi_EOF}, WIFI_5G}, 
        {"Test Device", "Test Model Number"}
    };
 
    if(ESSetDeviceProperty(&deviceProperty) == ES_ERROR)
    {
        printf("ESSetDeviceProperty Error\n");
    }
 
    printf("SetDeviceInfo OUT\n");
}
  • Additionally, you can set a provisioning status or error code if needed. The provisioning status can indicates if Enrollee is successfully connected to Home AP or registered to IoTivity Cloud server. Note that you should carefully set this property in a right way because it may cause Mediator to misunderstand the status during easy setup if Mediator is continuously monitoring it.
  • The error code property is used to indicate a reason of last error event during easy setup if an error occurs. For example, Enrollee attempted to connect to Home AP with a given WiFi information from Mediator but it fails, then Enrollee can set an error code like ES_ERRCODE_SSID_NOT_FOUND or ES_ERRCODE_PW_WRONG, and then Mediator can know the reason after re-connecting with Enrollee, later. Below describes how to use APIs for these two usages in Enrollee sample application for Tizen platform.
WiFiConnErrCode ret = WIFI_NO_ERROR;
ret = TizenWiFiScanStart();
 
if(ret != WIFI_NO_ERROR){
    ESSetState(ES_STATE_CONNECTED_FAIL_TO_ENROLLER);
    ESSetErrorCode(ES_ERRCODE_UNKNOWN);
    cout << "WiFi Scan Error" << endl;
    return;
}
else{
    cout << "WiFi Scan Succss" << endl;
}

SAMPLE APPLICATION


In IoTivity 1.2 release, sample applications for Mediator and Enrollee are provided as below:

  • Mediator Sample Applications for Linux and Android
  • Enrollee Sample Applications for Linux and Tizen

This section introduces sampple applications of Mediator for Android, and of Enrollee for Linux, which includes how to build the sample applications and use them.


Mediator Android Application - How to build

You can run scons build with the following options:

~/<iotivity> $ scons TARGET_OS=android TARGET_ARCH=armeabi TARGET_TRANSPORT=IP WITH_TCP=1 WITH_CLOUD=1 SECURED=1

If the build succeeds, an APK, i.e. app-debug.apk, for Android sample application is generated as follows:

~/<iotivity>/service/easy-setup/sampleapp/mediator/android/EasySetup/app/build/outputs/apk $ ls
app-debug.apk  app-debug-unaligned.apk  app-release-unsigned.apk

Mediator Android Application - How to use

  • Sign-up and sign-in for Mediator itself
    • When you first execute the sample application, you can see a login page of github, which is for Mediator to get Auth code from github and register itself to IoTivity cloud server. (See the first screenshot)
    • If an Auth code is successfully received, the application automatically tries to sign up and in to a predefined Iotivity cloud server at Amazon server. (See the second screenshot)

  • Discover an Enrollee in a given network, i.e Provisioning resource. Push the botton, discover, in the upper left
    • When any Enrollee is found, you can see the button to be changed to found as below
    • Note that, Mediator and Enrollee should be in a same network.

  • Initiate Security provisioning to Enrollee. Select SecurityProvisioning option and push the start botton in the bottom right. (See the first screenshot)
    • If ownership transfer between Mediator and Enrollee succeeds, you can see Success message and Enrollee's UUID in the screen. (See the second screenshot)
    • However, if it fails due to various reasons, you can see Failed message. (See the third screenshot)

  • Get pre-configured properties of Enrollee. Select GetConfiguration option and push the start botton in the bottom right. (See the first screenshot)
    • If the retrieval request succeeds, you can see Success message and various pre-configured properties of Enrollee like device name and supported WiFi mode. (See the second screenshot)

  • Transfer WiFi and DevConf properties to Enrollee. Select ProvisionDeviceConfig option and push the start botton in the bottom right. (See the first and second screenshot)
    • If the update request succeeds, you can see Success message in the screen. (See the third screenshot). And you can also see that Enrollee sample application shows the corresponding log messages in the screen. (Refer to the next section, Enrollee Linux Application - How to use.)

  • Transfer CloudServer properteis to Enrollee. If you select CloudProvisioning option, the application automatically sends a request to get an additional Auth code with your account information you registered at the first stage and automatically fill cloud access information including the received Auth code, in boxes. (See the first screenshot)
    • If the update request succeeds, you can see Success message in the screen. (See the second screenshot). And you can also see that Enrollee sample application shows the corresponding log messages in the screen. (Refer to the next section, Enrollee Linux Application - How to use.)


Enrollee Linux Application - How to build

You can run scons builds with the following options:

~/<iotivity> $ scons service/easy-setup/ SECURED=1 WITH_CLOUD=1 WITH_TCP=1

If the build succeeds, an excutable file, i.e. enrollee, of Linux sample application is generated as follows:

~/<iotivity>/out/linux/x86_64/release/service/easy-setup/sampleapp/enrollee/linux $ ls
easysetup_x.o  enrollee  enrolleewifi.o  oic_svr_db_server.dat

To execute the sample application, you, first, includes a library path in your environment:

  • export LD_LIBRARY_PATH=~/<iotivity>/out/linux/x86_64/release/
  • NOTE that, apply your compile options like x86_64/x86 or release/debug from the above path

Then, you can run the application as follows:

~/<iotivity>/out/linux/x86_64/release/service/easy-setup/sampleapp/enrollee/linux $ ./enrollee
#########################
EasySetup Enrollee SAMPLE
#########################
============
S: Enabled Security
I: Init & Start EasySetup
D: Set DeviceInfo
T: Terminate
U: set Callback for userdata
Q: Quit
============

Enrollee Linux Application - How to Use

The main options you SHOULD execute are :

  • Enable security feature in Enrollee (S)
    • This option sets a path of SVR DB file which stores all security information in Enrollee.
    • Note that, this option can be skipped in unsecured test
  • Initialize Enrollee with resource creation (I)
    • Enrollee registers Provisioning/WiFi/DevConf/CloudServer resources and acts as a OCF resource server.
    • From this time, all requests from Mediator to Enrollee will be handled. For example, If WiFi-releted properties are delivered, they are passed into registered callback, i.e. WiFiProvCbInApp function in the sample application.
  • Configure a pre-defined information of Enrollee like a device name (D)
    • You can set several pre-configured information with this option. WiFi supported frequency, mode, a device name, a model number can be set.
  • When Enrollee receives WiFi and DevConf properties from Mediator, you can see the property's values:
============
S: Enabled Security
I: Init & Start EasySetup
D: Set DeviceInfo
T: Terminate
U: set Callback for userdata
Q: Quit
============
WiFiProvCbInApp IN
SSID : Iotivity_SSID
Password : Iotivity_PWD
AuthType : 3 (WPA2_PSK)
EncType : 5 (TKIP_AES)
WiFiProvCbInApp OUT
DevConfProvCbInApp IN
Language : korean
Country : Korea
Location : location
DevConfProvCbInApp OUT
  • When Enrollee receives CloudServer properties from Mediator, you can see the property's values:
============
S: Enabled Security
I: Init & Start EasySetup
D: Set DeviceInfo
T: Terminate
U: set Callback for userdata
Q: Quit
============
CloudDataProvCbInApp IN
AuthCode : authCode
AuthProvider : authProvider
CI Server : ciServer
CloudDataProvCbInApp OUT
easy_setup.txt · Last modified: 2016/11/08 22:40 by Phil Coval