The thing program starts with the main() function which initializes the program and onboards the thing.

Processes at Start of the Program

First, the function gets the program arguments and initializes the mutex used for the exclusive processing of the state handler.

static pthread_mutex_t m_mutex;

int main(int argc, char** argv)

  char *vendorThingID, *thingPassword;

  if (argc != 3) {
    printf("hellothingif {vendor thing id} {thing password}\n");

  vendorThingID = argv[1];
  thingPassword = argv[2];

  if (pthread_mutex_init(&m_mutex, NULL) != 0) {
    printf("Failed to get mutex.\n");

As seen in Running Sample Apps, the thing program starts with command line parameters as below.

$ ./hellothingif 1111 DEF456

Specify the command name, vendorThingID, and the thing password.

argc and argv count the command name. Therefore, argv[1] stores vendorThingID and argv[2] stores the thing password.

Next, the mutex of Pthreads is initialized for exclusive processing. pthread_mutex_init(), which is one of the Pthreads APIs, initializes the static variable m_mutex.

Initializing the Thing-IF SDK

Next, the Thing-IF SDK is initialized.

The Thing-IF SDK does not dynamically reserve memory with malloc or anything. Therefore, the user program needs to prepare buffers for communication processing. Also, as seen in Source Code Structure, it needs to pass the action and state handlers to the Thing-IF SDK.

Processes for the above tasks are implemented with the code below.

int main(int argc, char** argv)
  kii_bool_t result;
  kii_thing_if_command_handler_resource_t command_handler_resource;
  kii_thing_if_state_updater_resource_t state_updater_resource;
  char command_handler_buff[EX_COMMAND_HANDLER_BUFF_SIZE];
  char state_updater_buff[EX_STATE_UPDATER_BUFF_SIZE];
  char mqtt_buff[EX_MQTT_BUFF_SIZE];
  kii_thing_if_t kii_thing_if;


  /* prepare for the command handler */
  memset(&command_handler_resource, 0x00, sizeof(command_handler_resource));
  command_handler_resource.buffer = command_handler_buff;
  command_handler_resource.buffer_size =
      sizeof(command_handler_buff) / sizeof(command_handler_buff[0]);
  command_handler_resource.mqtt_buffer = mqtt_buff;
  command_handler_resource.mqtt_buffer_size =
      sizeof(mqtt_buff) / sizeof(mqtt_buff[0]);
  command_handler_resource.action_handler = action_handler;
  command_handler_resource.state_handler = state_handler;

  /* prepare for the state updater */
  memset(&state_updater_resource, 0x00, sizeof(state_updater_resource));
  state_updater_resource.buffer = state_updater_buff;
  state_updater_resource.buffer_size =
      sizeof(state_updater_buff) / sizeof(state_updater_buff[0]);
  state_updater_resource.period = EX_STATE_UPDATE_PERIOD;
  state_updater_resource.state_handler = state_handler;

  /* initialize */
  result = init_kii_thing_if(&kii_thing_if, EX_APP_ID, EX_APP_KEY, EX_APP_SITE,
          &command_handler_resource, &state_updater_resource, NULL);
  if (result == KII_FALSE) {
    printf("Failed to initialize the SDK.\n");


The above code sets the buffers and handlers in command_handler_resource and state_updater_resource and calls init_kii_thing_if(). The code might look complicated, but you can see it is quite simple from the below figure. Also, it sets the interval to update state information in seconds in state_updater_resource.period. EX_STATE_UPDATE_PERIOD is set to 60 (one minute) in the sample program.

init_kii_thing_if() identifies the target application on Kii Cloud with the AppID, AppKey and server location. As seen in Application Class Implementation, the mobile app and the thing program work together by accesing the same application.

As a result of initialization, the kii_thing_if_t structure, the first argument of init_kii_thing_if(), is initialized and the main() function gets control. From now, subsequent APIs are called with this kii_thing_if_t structure.

You need to reserve enough size of buffers in order to process received actions and register state information. If the buffers are smaller than data to send or receive, such processes will fail.

Onboarding the Thing

Next, the thing gets onboarded. In this tutorial, onboarding from the Android mobile app aims to associate the owner with the thing, but onboarding from the thing program just registers the thing to Kii Cloud. You can start onboarding from either the mobile app or the thing program; the execution sequence does not matter.

int main(int argc, char** argv)
  result = onboard_with_vendor_thing_id(&kii_thing_if, vendorThingID, thingPassword, THING_TYPE, THING_PROPERTIES);
  if (result == KII_FALSE) {
    printf("Failed to onboard the thing.");

The onboard_with_vendor_thing_id() of the Thing-IF SDK onboards the thing. The arguments include the initialized kii_thing_if_t structure, vendorThingID, and the thing password.

The remaining arguments, THING_TYPE and THING_PROPERTY are declared as below. The values specified in onboarding from the mobile app must be specified.

const char THING_TYPE[] = "HelloThingIF-SmartLED";
const char THING_PROPERTIES[] = "{}";

You can get the detailed root cause of errors in onboarding, in any. By changing the code as below, you can get the HTTP response code and body returned by the REST API of Thing Interaction Framework for debugging purposes.

printf("Failed to onboard the thing. %d, %s\n",


The last part of main() keeps the program waiting for commands by entering in the loop with the while statement.

int main(int argc, char** argv)
  printf("Waiting for commands\n");

  while(1){}; /* run forever. */

The initialization of the Thing-IF SDK has internally created threads to process actions and state information. These threads call the action and state handlers to control the thing.

What's Next?

Let us walk through the process of receiving commands.

Go to Receiving Commands.

If you want to learn more...