NOTE:
A device profile can correspond to only one codec plug-in. However, an application can associate with multiple codec plug-ins.
LiteOS SDK consists of device-cloud interconnect components, FOTA, JavaScript engine, and sensor framework.
Device-cloud interconnect components are critical to connect devices with limited resources to OceanConnect in the Huawei IoT solution. Device-cloud interconnect components enable device-cloud synergy and integrate a full set of IoT interconnection protocol stacks, such as Lightweight M2M (LWM2M), Constrained Application Protocol (CoAP), mbed TLS, and lightweight IP (lwIP). Based on LWM2M, device-cloud interconnect components provide packaged open APIs for you to quickly and reliably connect applications to OceanConnect. In addition, they help you improve service development efficiency and quickly build products.
Figure 1 Huawei LiteOS architecture
Device-cloud interconnect components provide the following two types of software architectures.
Figure 1 Architecture for single module or MCU
Figure 2 Architecture for external MCUs + chips/modules
Device-cloud interconnect components are divided into the following three layers:
-
Open API layer: The device-cloud interconnect components provide open APIs for applications. Devices quickly connect OceanConnect, report service data, and process delivered commands by invoking these APIs. In the external MCUs + chips/modules scenario, device-cloud interconnect components also provides the AT instruction adaptation layer for parsing AT instructions.
-
Protocol layer: Device-cloud interconnect components integrate protocols, such as LWM2M, CoAP, Datagram Transport Layer Security (DTLS), TLS, and UDP.
-
Driver and network adapter layer: This layer facilitates device integration and porting. You can adapt to APIs related to the hardware random number, memory management, logs, data storage, and network sockets based on the API list of the adaptation layer provided by SDK and specific hardware platform.
LiteOS basic kernel provides RTOS features for devices.
Device-cloud interconnect components can be easily integrated with various types of communications modules, such as NB-IoT, eMTC, Wi-Fi, GSM, and Ethernet hardware modules without considering the specific chip architecture and network hardware type.
The adapter layer of device-cloud interconnect components provides common hardware and network adapter APIs. Device or module vendors can complete the porting of device-cloud interconnect components after adapting their hardware to these APIs. The following table lists the to-be-ported APIs and related functions.
Table 1 APIs to which the to-be-ported device-cloud interconnect components need adapt
Device-cloud interconnect components can be ported in OS and non-OS modes. The OS mode is recommended.
Device-cloud interconnect components support firmware upgrade. The components need to adapt to the atiny_storage_device_s object.
atiny_storage_device_s *atiny_get_hal_storage_device(void);
struct atiny_storage_device_tag_s;
typedef struct atiny_storage_device_tag_s atiny_storage_device_s;
struct atiny_storage_device_tag_s
{
//Device initialization
int (*init)( storage_device_s *this);
//Begin to write
int (*begin_software_download)( storage_device_s *this);
//Write software, and start from offset. buffer indicates the content, and len indicates the length.
int (*write_software)( storage_device_s *this , uint32_t offset, const char *buffer, uint32_t len);
//Download completed
int (*end_software_download)( storage_device_s *this);
//Activate software
int (*active_software)( storage_device_s *this);
//Activated results are obtained. O indicates successful. 1 indicates failed.
int (*get_active_result)( storage_device_s *this);
//Write update_info, and start from offset. buffer indicates the content, and len indicates the length.
int (*write_update_info)( storage_device_s *this, long offset, const char *buffer, uint32_t len);
//Read update_info, and start from offset. buffer indicates the content, and len indicates the length.
int (*read_update_info)( storage_device_s *this, long offset, char *buffer, uint32_t len);
};
To integrate with device-cloud interconnect components, the following hardware specifications requirements must be met:
-
Modules or chips are supported by physical network hardware and support the UDP protocol stack.
-
Modules or chips provide sufficient Flash and RAM resources to integrate with protocol stacks for device-cloud interconnect components. The following table lists the recommended hardware specifications.
Table 1 Recommended hardware specifications
The recommended hardware specifications are determined based on resources (including open APIs, IoT protocol stacks, security protocols, SDK driver and network adapter layer) used by device-cloud interconnect components and resources (including chip drivers, sensor drivers, and basic service processes) minimally used by user service demos. The preceding specifications are for reference only. The specific hardware specifications need to be evaluated based on user service requirements.
Device-cloud interconnect components support DTLS. Currently, the pre-shared key (PSK) mode is supported. Other modes will be supported.
After the components first complete the handshake process with OceanConnect, the subsequent application data will be encrypted, as shown in the following figure.
Figure 1 DTLS interaction process
Device-cloud interconnect components support the remote firmware upgrade of OceanConnect and feature resumable data transfer and firmware package integrity protection.
The following figure shows the firmware upgrade functions and process.
Figure 1 Firmware upgrade Diagram
This chapter describes the development process of device-cloud interconnect components in detail from the OceanConnect side and the device side to help developers integrate LiteOS SDK device-cloud interconnect components with IoT devices for IoT application development and commissioning. By default, LiteOS SDK device-cloud interconnect components connect OceanConnect through Ethernet, that is, interconnecting the Ethernet port driver, lwIP network protocol stack, LWM2M protocol, and LiteOS SDK device-cloud interconnect components with OceanConnect. In addition, LiteOS SDK device-cloud interconnect components can connect OceanConnect using Wi-Fi, GSM, and NB-IoT.
OceanConnect is a unified and open cloud platform provided for carriers, enterprises, and industry partners. It supports management of connections from devices with or without SIM cards. OceanConnect integrates diverse industry applications upward and connects multiple sensors, devices, and gateways downward through APIs, helping the preceding users quickly access various types of industrial devices and integrate multiple industry applications. In addition, OceanConnect enables industry innovation by providing secure and reliable full-connection management to build an IoT ecosystem.
The information to be obtained before development is as follows:
-
URL, account, and password for logging in to the OceanConnect developer portal.Apply to OceanConnect for them.
-
Device interconnection address and port number
By creating applications, you can select different platform service suites based on application characteristics to make application development easier.
-
Log in to the OceanConnect developer portal.
The URL, account, and password for logging in to the OceanConnect developer portal must be applied to the OceanConnect service provider.
-
In the displayed dialog box where the "Current account has no application！"Please create an app first！" is displayed, click** Create Application**.
Figure 1 Creating an application
-
In the dialog box that is displayed, configure application information and click Confirm.
The following figure shows a configuration example. After you click Confirm, OceanConnect returns the application ID and application key. Keep the application key properly for the application server to connect OceanConnect. If you forget the key, choose docking information > Reset Key to reset the key.
Figure 2 Configuring application information
NOTE:
The preceding configurations are for reference only. The configurations may vary based on the site requirements.
The device profile is used to describe the device type and service capabilities. It defines the device service capabilities and the attributes, commands, and command parameters of each service.
-
Log in to the OceanConnect developer portal.
The URL, account, and password for logging in to the OceanConnect developer portal must be applied to the OceanConnect service provider.
-
Choose Profile Development > Profile Online Development > Custom Product. On the Custom Product page, click Create New Product in the upper right corner.
OceanConnect provides the profile template library. You can select proper templates as required. If a profile you need is not found in the profile template library, define the profile as follows.
NOTE:
The preceding configurations are for reference only. The configurations may vary based on the site requirements. -
Select the created profile, click Create New Service, and configure device service capabilities.
For details about how to configure, see Product Templates in Profile Development > Profile Online Development. For example, create the LightControl service, including an attribute (shows that the indicator is on or off) and a command (sets the indicator to on or off).
-
(Optional) The OceanConnect developer portal supports the export of profile. Choose Profile Development > Profile Online Development > Newly Created Profile File . On the** Newly Created Profile File** page, click Export Profile in the upper right corner to export the profile created online.
IoT devices communicate with OceanConnect based on LWM2M. Data in LWM2M messages is application-layer data, whose format is defined by device vendors. IoT devices have high requirements on power saving. Therefore, application-layer data is generally in the binary format. When parsing the application-layer data, OceanConnect converts the binary format to the JSON format for application servers to use. To convert messages from the binary format to the JSON format, OceanConnect needs to use codec plug-ins.
-
Choose **Plugin Development **> Plugin Development > Start Design. On the Start Design page, click +Creat New Plugin in the upper right corner. In the dialog box that is displayed, select a profile.
OceanConnect provides the profile template library. You can select proper templates as required. If a profile you need is not found in the profile template library, define the profile as follows.
-
Click Add Message and configure the mapping between the binary code stream and the profile attribute, command, or command response.
For details about how to configure, see "Beginner Guide" and "Plugin Template" in "** Plugin Development** " > Plugin Development >** Start Design**.
Figure 2 Creating a plug-in (for creating data reporting messages)
.png "creating-a-plug-in-(for-creating-data-reporting-messages)")
Figure 3 Creating a plug-in (for adding fields)
.png "creating-a-plug-in-(for-adding-fields)")
Figure 4 Creating a plug-in (for creating command delivering messages)
Figure 5 Creating a plug-in (for adding fields)
To create a codec plug-in, define the following contents:
- Define the location of profile attributes or responses at the binary code stream reported by devices for OceanConnect to decode the reported data and command response.
- Define the location of profile commands delivered by OceanConnect at the binary code stream for OceanConnect to decode the delivered commands.
Figure 6 Mapping between the binary code stream and the profile
-
Click** Deploy **in the upper right corner of this page and click Save to save the codec plug-in.
The deployment takes less than 60 seconds.
Figure 7 Saving the codec plug-in
Figure 8 Deploying the codec plug-in
-
(Optional) The OceanConnect developer portal supports the downloading of codec plug-ins. Choose Plugin Development > Plugin Development > Newly Developed Codec Plugin. On the Newly Developed Codec Plugin page, click **Download **in the upper right corner to export the codec plug-in created online.
.png "creating-a-plug-in-(for-creating-data-reporting-messages)")
.png "creating-a-plug-in-(for-adding-fields)")
When adding devices to OceanConnect, use an application server to invoke the API for registering devices on OceanConnect.
OceanConnect provides application simulators to simulate scenarios where application servers are used to register devices on OceanConnect. When using an application simulator to register a device, select the profile of the to-be-registered device to associate the device with the profile. In other words, using an application simulator to register a device is to use an application server to register a device and modify device information on OceanConnect. This section describes how to register a device using an application simulator.
-
Choose** My Devices > Register Device** > Profile of the device to be registered. On the Profile page of the device to be registered, enter the device name and verifyCode, and click Register.
Figure 1 Profile of the device to be registered
After a device is registered, OceanConnect returns the device ID and PSK. Keep the device ID and PSK properly. The status of the newly registered device is not bound.
When connecting a device to OceanConnect, ensure that the device has been registered and the device applications have been deployed on OceanConnect. After the device has been connected, OceanConnect can manage it. This section describes how to connect device-side devices to OceanConnect using device-cloud interconnect components. The following figure shows the general diagram of connecting device-side devices to OceanConnect.
Figure 1 General diagram of connecting device-side devices to OceanConnect
The information to be obtained before development is as follows:
- Huawei LiteOS and LiteOS SDK source code. The general project architecture is as follows:
├── arch //Architecture-related files
│ ├── arm
│ └── msp430
├── build
│ └── Makefile
├── components //Various LiteOS components
│ ├── connectivity
│ ├── fs
│ ├── lib
│ ├── log
│ ├── net
│ ├── ota
│ └── security
├── demos //Sample programs
│ ├── agenttiny_lwm2m //All sample programs listed in this chapter are from the agent_tiny_demo.c file in this directory.
│ ├── agenttiny_mqtt
│ ├── dtls_server
│ ├── fs
│ ├── kernel
│ └── nbiot_without_atiny
├── doc //Documents
│ ├── Huawei_LiteOS_Developer_Guide_en.md
│ ├── Huawei_LiteOS_Developer_Guide_zh.md
│ ├── Huawei_LiteOS_SDK_Developer_Guide.md
│ ├── LiteOS_Code_Info.md
│ ├── LiteOS_Commit_Message.md
│ ├── LiteOS_Contribute_Guide_GitGUI.md
│ ├── LiteOS_Supported_board_list.md
│ └── meta
├── include //Header files required by projects
│ ├── at_device
│ ├── at_frame
│ ├── atiny_lwm2m
│ ├── atiny_mqtt
│ ├── fs
│ ├── log
│ ├── nb_iot
│ ├── osdepends
│ ├── ota
│ ├── sal
│ └── sota
├── kernel //System kernels
│ ├── base
│ ├── extended
│ ├── include
│ ├── los_init.c
│ └── Makefile
├── LICENSE //Licenses
├── osdepends //Dependencies
│ └── liteos
├── README.md
├── targets //BSP projects
│ ├── Cloud_STM32F429IGTx_FIRE
│ ├── Mini_Project
│ ├── NXP_LPC51U68
│ └── STM32F103VET6_NB_GCC
└── tests //Test cases
├── cmockery
├── test_agenttiny
├── test_main.c
├── test_sota
└── test_suit
To obtain the source code, visit https://github.com/LiteOS/LiteOS.
- Integration development tools:
- MDK 5.18 or later, which can be downloaded from http://www2.keil.com/mdk5
- MDK packages
The licenses for MDK tools can be obtained from http://www2.keil.com/mdk5.
To connect the LiteOS SDK device-cloud interconnect component Agent Tiny to OceanConnect, create an entrypoint function agent_tiny_entry().
Entrypoint function for LiteOS SDK device-cloud interconnect components. This function can be used to initialize Agent Tiny, create report tasks, and call the main function body of Agent Tiny. |
Based on the task mechanism provided by the LiteOS kernel, a developer can create a main task main_task, and call the entrypoint function agent_tiny_entry() in the main task to enable the Agent Tiny workflow.
UINT32 creat_main_task()
{
UINT32 uwRet = LOS_OK;
TSK_INIT_PARAM_S task_init_param;
task_init_param.usTaskPrio = 0;
task_init_param.pcName = "main_task";
task_init_param.pfnTaskEntry = (TSK_ENTRY_FUNC)main_task;
task_init_param.uwStackSize = 0x1000;
uwRet = LOS_TaskCreate(&g_TskHandle, &task_init_param);
if(LOS_OK != uwRet)
{
return uwRet;
}
return uwRet;
}
Call the atiny_init() function in the entrypoint function to initialize Agent Tiny.
The input parameter atiny_params needs to be set based on specific services. Developers can set the parameter by the following code:
#ifdef CONFIG_FEATURE_FOTA
hal_init_ota(); //To define the FOTA functions, perform FOTA-related initialization.
#endif
#ifdef WITH_DTLS
device_info->endpoint_name = g_endpoint_name_s; //Encrypted device verification code
#else
device_info->endpoint_name = g_endpoint_name; //Unencrypted device verification code
#endif
#ifdef CONFIG_FEATURE_FOTA
device_info->manufacturer = "Lwm2mFota"; //Unencrypted device verification code
device_info->dev_type = "Lwm2mFota"; //Device type
#else
device_info->manufacturer = "Agent_Tiny";
#endif
atiny_params = &g_atiny_params;
atiny_params->server_params.binding = "UQ"; //Binding mode
atiny_params->server_params.life_time = 20; //Life cycle
atiny_params->server_params.storing_cnt = 0; //Number of cached data packets
atiny_params->server_params.bootstrap_mode = BOOTSTRAP_FACTORY; //Boot mode
atiny_params->server_params.hold_off_time = 10; //Waiting latency
//pay attention: index 0 for iot server, index 1 for bootstrap server.
iot_security_param = &(atiny_params->security_params[0]);
bs_security_param = &(atiny_params->security_params[1]);
iot_security_param->server_ip = DEFAULT_SERVER_IPV4; //Server address
bs_security_param->server_ip = DEFAULT_SERVER_IPV4;
#ifdef WITH_DTLS
iot_security_param->server_port = "5684"; //Encrypted device port number
bs_security_param->server_port = "5684";
iot_security_param->psk_Id = g_endpoint_name_iots; //Encrypted device verification
iot_security_param->psk = (char *)g_psk_iot_value; //PSK password
iot_security_param->psk_len = sizeof(g_psk_iot_value); //PSK password length
bs_security_param->psk_Id = g_endpoint_name_bs;
bs_security_param->psk = (char *)g_psk_bs_value;
bs_security_param->psk_len = sizeof(g_psk_bs_value);
#else
iot_security_param->server_port = "5683"; //Unencrypted device port number
bs_security_param->server_port = "5683";
iot_security_param->psk_Id = NULL; //No PSK-related parameter setting for unencrypted devices
iot_security_param->psk = NULL;
iot_security_param->psk_len = 0;
bs_security_param->psk_Id = NULL;
bs_security_param->psk = NULL;
bs_security_param->psk_len = 0;
#endif
After setting the atiny_params parameter, initialize Agent Tiny based on the set parameter.
if(ATINY_OK != atiny_init(atiny_params, &g_phandle))
{
return;
}
After setting the atiny_params parameter, initialize Agent Tiny based on the set parameter.
After initializing Agent Tiny, create a data reporting task function app_data_report() by calling the creat_report_task() function.
UINT32 creat_report_task()
{
UINT32 uwRet = LOS_OK;
TSK_INIT_PARAM_S task_init_param;
UINT32 TskHandle;
task_init_param.usTaskPrio = 1;
task_init_param.pcName = "app_data_report";
task_init_param.pfnTaskEntry = (TSK_ENTRY_FUNC)app_data_report;
task_init_param.uwStackSize = 0x400;
uwRet = LOS_TaskCreate(&TskHandle, &task_init_param);
if(LOS_OK != uwRet)
{
return uwRet;
}
return uwRet;
}
In the app_data_report() function, assign a value to the reported data structure data_report_t, including the data buffer address buf, callback function callback called after the ACK response is received from a platform, data cookie, data length len, and data reporting type type (set to APP_DATA by default).
uint8_t buf[5] = {0, 1, 6, 5, 9};
data_report_t report_data;
int ret = 0;
int cnt = 0;
report_data.buf = buf;
report_data.callback = ack_callback;
report_data.cookie = 0;
report_data.len = sizeof(buf);
report_data.type = APP_DATA;
After a value is assigned to the report_data parameter, data can be reported by calling the atiny_data_report() function.
The implementation method of a report task in the sample code is as follows:
while(1)
{
report_data.cookie = cnt;
cnt++;
ret = atiny_data_report(g_phandle, &report_data); //Data reporting function
ATINY_LOG(LOG_DEBUG, "data report ret: %d\n", ret);
(void)LOS_TaskDelay(250 * 8);
}
All commands delivered by OceanConnect are executed by calling the atiny_cmd_ioctl() function.
The atiny_cmd_ioctl API is a universal extensible API defined by device-cloud interconnect components. The command word of this API is defined by referring to the enumerated type atiny_cmd_e. Users can implement or extend this API based on respective requirements. The following table lists common APIs. Each API corresponds to an enumerated value of the atiny_cmd_e API.
A developer needs to make a command response by calling the atiny_write_app_write() function based on site services.
int atiny_write_app_write(void* user_data, int len)
{
(void)atiny_printf("write num19 object success\r\n");
return ATINY_OK;
}
After creating the data reporting task and implementing the command processing function, call the atiny_bind() function.
The atiny_bind() function can be used to create and register the LwM2M client based on the LwM2M protocol, send the data reported in the data reporting task creation function app_data_report() to OceanConnect through communication modules, receive and parse commands delivered by OceanConnect, and submit the parsed commands to the command processing function atiny_cmd_ioctl() for unified processing. Similar to the atiny_init() function, the atiny_bind() function does not need to be modified by developers.
For details about the LWM2M protocol, see the appendix.
LiteOS SDK device-cloud interconnect components continuously report data and process commands through the main function body. When calling the deinitialization function atiny_deinit() for LiteOS SDK device-cloud interconnect components, exit the main function body.
- Enumerated type of commands delivered by OceanConnect
typedef enum
{
ATINY_GET_MANUFACTURER, /*Obtain the manufacturer name.*/
ATINY_GET_MODEL_NUMBER, /*Obtain device models defined and used by the manufacturer.*/
ATINY_GET_SERIAL_NUMBER, /*Obtain the device SN.*/
ATINY_GET_FIRMWARE_VER, /*Obtain the firmware version number.*/
ATINY_DO_DEV_REBOOT, /*Deliver device resetting commands.*/
ATINY_DO_FACTORY_RESET, /*Restore factory resetting.*/
ATINY_GET_POWER_SOURCE, /*Obtain power supplies.*/
ATINY_GET_SOURCE_VOLTAGE, /*Obtain device voltage.*/
ATINY_GET_POWER_CURRENT, /*Obtain device current.*/
ATINY_GET_BATERRY_LEVEL, /*Obtain the battery level.*/
ATINY_GET_MEMORY_FREE, /*Obtain idle memory.*/
ATINY_GET_DEV_ERR, /*Obtain the device status, such as used-up memory and low battery level.*/
ATINY_DO_RESET_DEV_ERR, /*Obtain the device resetting status.*/
ATINY_GET_CURRENT_TIME, /*Obtain the current time.*/
ATINY_SET_CURRENT_TIME, /*Set the current time.*/
ATINY_GET_UTC_OFFSET, /*Obtain the UTC difference.*/
ATINY_SET_UTC_OFFSET, /*Set the UTC difference.*/
ATINY_GET_TIMEZONE, /*Obtain the time zone.*/
ATINY_SET_TIMEZONE, /*Set the time zone.*/
ATINY_GET_BINDING_MODES, /*Obtain the binding mode.*/
ATINY_GET_FIRMWARE_STATE, /*Obtain the firmware upgrade status.*/
ATINY_GET_NETWORK_BEARER, /*Obtain the network bearer type, such as GSM and WCDMA. */
ATINY_GET_SIGNAL_STRENGTH, /*Obtain the network signal strength.*/
ATINY_GET_CELL_ID, /*Obtain the network cell ID.*/
ATINY_GET_LINK_QUALITY, /*Obtain network link quality.*/
ATINY_GET_LINK_UTILIZATION, /*Obtain network link usage.*/
ATINY_WRITE_APP_DATA, /*Write command words delivering service data.*/
ATINY_UPDATE_PSK, /*Update PSK command words.*/
ATINY_GET_LATITUDE, /*Obtain device latitude.*/
ATINY_GET_LONGITUDE, /*Obtain device longitude.*/
ATINY_GET_ALTITUDE, /*Obtain device height.*/
ATINY_GET_SPEED, /*Obtain device running speed.*/
ATINY_GET_TIMESTAMP, /*Obtain timestamp.*/
} atiny_cmd_e;
- Enumerated type of key events
This enumerated type is used to notify users of the statuses of LiteOS SDK device-cloud interconnect components.
typedef enum
{
ATINY_REG_OK, /*Device registration successful*/
ATINY_REG_FAIL, /*Device registration failed*/
ATINY_DATA_SUBSCRIBLE, /*Starting data subscription. Devices allow to report data */
ATINY_DATA_UNSUBSCRIBLE, /*Canceling data subscription. Devices stop reporting data*/
ATINY_FOTA_STATE /*Firmware upgrade status*/
} atiny_event_e;
- LwM2M parameter structure
typedef struct
{
char* binding; /*U or UQ is currently supported.*/
int life_time; /*LwM2M protocol life cycle, which is set to 50000 by default.*/
unsigned int storing_cnt; /*Number of LwM2M cache data packets*/
} atiny_server_param_t;
- Security and server parameter structure
typedef struct
{
bool is_bootstrap; /*Whether the bootstrap server is used.*/
char* server_ip; /*Server IP address, which can be represented by character strings and supports IPv4 and IPv6.*/
char* server_port; /*Server port number.*/
char* psk_Id; /*PSK ID.*/
char* psk; /*PSK*/
unsigned short psk_len; /*PSK length*/
} atiny_security_param_t;
- Enumerated type of reported data
Type of data reported by users, which can be expanded based on users' applications.
typedef enum
{
FIRMWARE_UPDATE_STATE = 0， /*LWM2M protocol life cycle, which is set to 50000 by default.*/
APP_DATA /*User data*/
} atiny_report_type_e;
- Server parameter structure
typedef struct
{
atiny_server_param_t server_params;
atiny_security_param_t security_params[2]; /*One IoT server and one bootstrap server are supported.*/
} atiny_param_t;
- Device parameter structure
typedef struct
{
char* endpoint_name; /*Device ID generated for northbound application*/
char* manufacturer; /*Manufacturer name generated for northbound application*/
char* dev_type; /*Device type generated for northbound application*/
} atiny_device_info_t;
- Reported data structure
The following enumerated values indicate user data types. For example, data is sent successfully; data has been sent but is not acknowledged. The specific information is as follows:
typedef enum
{
NOT_SENT = 0, /*To-be-reported data has not been sent.*/
SENT_WAIT_RESPONSE, /*To-be-reported data has been sent and is waiting for response.*/
SENT_FAIL, /*To-be-reported data sending failed.*/
SENT_TIME_OUT, /*To-be-reported data has been sent and waiting for response times out.*/
SENT_SUCCESS, /*To-be-reported data sending successful.*/
SENT_GET_RST, /*To-be-reported data has been sent but the receiver sends an RST packet.*/
SEND_PENDING, /*To-be-reported data is waiting for sending.*/
} data_send_status_e;
//Users can use the following data structure to report data:
typedef struct _data_report_t
{
atiny_report_type_e type; /*Reported data type, such as service data and remaining battery level.*/
int cookie; /*Data cookie, which is used to distinguish data during ACK callback.*/
int len; /*Data length, which must be not greater than MAX_REPORT_DATA_LEN.*/
uint8_t* buf; /*First address of the data buffer.*/
atiny_ack_callback callback; /*ACK callback, whose value is data_send_status_e.*/
} data_report_t;
This chapter describes the development process of device-cloud interconnect components in detail from the cloud side and the device side based on the process of connecting devices to OceanConnect. On the cloud side, this chapter describes how to create applications and profiles, deploy codec plug-ins, and register devices. On the device side, this chapter introduces the entrypoint function for LiteOS SDK device-cloud interconnect components. Developers can connect LiteOS SDK device-cloud interconnect components to OceanConnect only by implementing data reporting tasks and command response APIs based on site services and through APIs provided by the components.
if(ATINY_OK != atiny_init(atiny_params, &g_phandle)) //Initialization
{
return;
}
uwRet = creat_report_task(); //Create a data reporting task.
if(LOS_OK != uwRet)
{
return;
}
(void)atiny_bind(device_info, g_phandle); //Main function body
This chapter helps developers master the development process of LiteOS SDK device-cloud interconnect components for developing and commissioning IoT applications.
LiteOS SDK device-cloud interconnect components can be connected to OceanConnect through the Ethernet or wireless methods including Wi-Fi, GSM, and NB-IoT. This chapter describes how to configure LiteOS SDK device-cloud interconnect components based on the development environment and connect the components to OceanConnect in the preceding two types of ways. In addition, this chapter briefly introduces concepts related to the AT framework.
- Codes for LiteOS SDK device-cloud interconnect components:
https://github.com/LiteOS/LiteOS
- Hardware devices: wildfire STM32F429 development boards, debug downloaders (such as J-Link and ST-Link), network cables, and routers
This guide uses the wildfire STM32F429IG development board as an example. To obtain details about the development board, visit http://www.firebbs.cn/forum.php.
Figure 1 STM32F429IG development board peripherals
-
Connect the network port of the development board to the router through a network cable.
-
Set the local IP address.
Change the IP address of the LAN to which devices connect in the sys_init.c file. Currently, demo programs use the static IP address. If the DHCP mode is required, add the DHCP header file at the top of the main.c file and define the USE_DHCP macro.
void net_init(void) { /* IP addresses initialization */ IP_ADDRESS[0] = 192; IP_ADDRESS[1] = 168; IP_ADDRESS[2] = 0; IP_ADDRESS[3] = 115; NETMASK_ADDRESS[0] = 255; NETMASK_ADDRESS[1] = 255; NETMASK_ADDRESS[2] = 255; NETMASK_ADDRESS[3] = 0; GATEWAY_ADDRESS[0] = 192; GATEWAY_ADDRESS[1] = 168; GATEWAY_ADDRESS[2] = 0; GATEWAY_ADDRESS[3] = 1;Before calling the Agent Tiny entrypoint function agent_tiny_entry(), call the net_init() function to complete initialization related to the lwIP protocol.
The sys_init.c file is stored in the LiteOS/targets/Cloud_STM32F429IGTx_FIRE/Src directory.
-
Change the MAC address of the network port.
Change the values of MAC_ADDR0 to MAC_ADDR5 to the actual MAC addresses. Ensure that the MAC addresses are unique.
static int8_t eth_init(struct netif* netif) { HAL_StatusTypeDef hal_eth_init_status; MACAddr[0] = 0x00; MACAddr[1] = 0x80; MACAddr[2] = 0xE1; MACAddr[3] = 0x00; MACAddr[4] = 0x00; MACAddr[5] = 0x00;
NOTICE:
The eth_init() function contained in the net_init() function in step 2 is called. The eth.c file is stored in the LiteOS/targets/Cloud_STM32F429IGTx_FIRE/Src directory. -
Set the IP address for logging in to OceanConnect and the device EP Name and PSK.
Relevant configuration parameters need to be set. These parameters are imported to the atiny_init() function as input parameters to initialize LiteOS SDK device-cloud interconnect components. Endpoint name is the unique verification code set when developers register devices with OceanConnect. PSK is used to encrypt data transmission. The following uses the agent_tiny_demo.c file as an example:
#define DEFAULT_SERVER_IPV4 "192.168.0.5" char * g_endpoint_name = "44440003"; #ifdef WITH_DTLS char *g_endpoint_name_s = "11110006"; unsigned char g_psk_value[16] = {0xef,0xe8,0x18,0x45,0xa3,0x53,0xc1,0x3c,0x0c,0x89,0x92,0xb3,0x1d,0x6b,0x6a,0x96}; #endifThe agent_tiny_demo.c file is stored in the LiteOS/demos/agenttiny_lwm2m directory.
-
Compile and run a program.
-
View the device status.
Log in to the OceanConnect portal, click My Device, and view the device status in the device list. If the device status is bound, the device has been successfully connected to OceanConnect.
Figure 1 Viewing the device status
Chapter 4 describes the data reporting process of LiteOS SDK device-cloud interconnect components in detail. Developers only need to obtain and report sensor data to the reported data structure report_data by calling the app_data_report() function. The specific commissioning process is as follows:
-
On the device side, execute the app_data_report function to enable the device to report data.
Modify the app_data_report function in the agent_tiny_demo.c file as follows:
struct Led_Light { uint8_t lightvalue; … }; extern get_led_lightvalue (void);//Obtain sensor data. void app_data_report(void) { struct Led_Light light; data_report_t report_data; int ret; int cnt = 0; report_data.buf = (uint8_t *)&light; report_data.callback = ack_callback; report_data.cookie = 0; report_data.len = sizeof(struct Led_Light); report_data.type = APP_DATA; while(1) { report_data.cookie = cnt; cnt++; ret = atiny_data_report(g_phandle, &report_data); printf("report ret:%d\n",ret); (void)LOS_TaskDelay(250*8); } }The agent_tiny_demo.c file is stored in the LiteOS/demos/agenttiny_lwm2m directory.
-
View the device status.
Log in to the OceanConnect portal, and click My Device. In the device list on the My Device page, select the device that reports data, and click** Historical Data** to view data reporting results.
Figure 1 Process for IoT devices with device-cloud interconnect components to report data
Figure 2 Viewing data reporting results
Commands can be delivered in either of the following two modes: immediate delivery and cached delivery.
- Immediate delivery: OceanConnect immediately sends the received commands to devices. If devices are offline or do not receive the commands, the delivery fails. This delivery mode applies to any scenario that has a high requirement on real-time command execution, such as switch lamps for street lamps and gas valves. During immediate delivery, an application server must deliver commands at a correct time.
Figure 1 Immediate delivery of commands
- Cached delivery: After receiving commands, OceanConnect writes them into queues. When a device goes online, OceanConnect successively delivers the commands from queues to the device. This delivery mode applies to any scenario that has a relatively low requirement on real-time command execution, such as configuring water meter parameters. OceanConnect provides different solutions based on power saving modes of devices.
Figure 2 Cached delivery of commands
When delivering commands to OceanConnect, an application server has expireTime configured. expireTime is TTL for short, which means the maximum cache time. If expireTime is not configured, the default value is 48 hours.
expireTime = 0: indicates the immediate delivery of commands.
expireTime > 0: indicates the cached delivery of commands.
To deliver commands, perform the following steps:
-
Log in to the OceanConnect portal.
The URL, account, and password for logging in to the OceanConnect portal must be applied to the OceanConnect service provider.
-
In the device list on the My Device page, select the device that receives commands and click Commond deliever. （</>).
In the dialog box that is displayed, configure the parameters of commands delivered to the device.
-
In the device list on the My Device page, select the device that receives commands and click Historical Command to view information in the Status column.
Figure 4 Viewing the command delivering status
Status description is as follows:
-
Overdue: Commands have not been delivered to devices in the cache time specified by OceanConnect.
-
Success: OceanConnect has delivered commands to devices and received the command execution results from devices.
-
Fail: The codec plug-in parsing is empty, or the execution results contain ERROR CODE.
-
Timeout: It is timed out that OceanConnect waits for an ACK response.
-
Cancel: Command delivering has been canceled on the application side.
-
Waiting: Commands are cached on OceanConnect and have not been delivered to devices.
-
Sent: OceanConnect has delivered commands to devices.
-
Arrived: OceanConnect has delivered commands to devices and received an ACK response from devices.
-
-
LiteOS SDK device-cloud interconnect components obtain and parse the message code stream from the message cache. Call the atiny_write_app_write() function of the atiny_cmd_ioctl() function in the agent_tiny_cmd_ioctl.c file to process the parsed message code stream..
int atiny_write_app_write(void* user_data, int len) { int i; uint8_t cmd_data[len]; memcpy(cmd_data, user_data, len); for(i=0;i<len;i++) { printf("######## %d",cmd_data[i]);//Print the delivered commands. Users can process the delivered commands. //Control hardware devices using specific commands. } (void)atiny_printf("write num19 object success\r\n"); return ATINY_OK; }agent_tiny_cmd_ioctl.c位于 LiteOS/demos/agenttiny_lwm2m。
Wireless access modes include Wi-Fi, GSM, NB-IoT, Zigbee, and Bluetooth. This guide describes the Wi-Fi and GSM (GPRS) access modes. For IoT developers, Wi-Fi or GSM just likes an independent module. Device-cloud interconnect components running on MCUs can use Wi-Fi or GSM network services after passing serial port AT instructions, as shown in the following figure. ESP8266 is Espressif's Wi-Fi module. SIM900A is SIMCom's GSM/GPRS module.
Figure 1 Wireless access to device-cloud interconnect components
An instruction set is sent from a TE or a DTE to a TA or a DCE. A TE manages the functions of the mobile station (MS) and interacts with GSM network services by sending AT instructions to a TA. Users can manage calls, short messages, phonebooks, data services, and faxes by invoking AT instructions.
In most scenarios, both ESP8266 and SIM900A can be accessed using the AT+UART mode. The difference lies in specific AT instructions. Device-cloud interconnect components provide an AT framework (also called AT template) for users to complete the porting of different serial port communications modules. Such modules support the TCP/IP protocol stack. The following figure shows the AT framework.
In the figure, AT Socket, similar to the posix socket, adapts to Atiny Socket. AT Send calls the at_cmd function to send AT instructions. AT Recv helps users receive Post messages from queues using AT Analyse Task. AT Analyse Task parses messages from serial ports, including user data and command responses. The serial port (USART) receives data in interrupt or direct memory access (DMA) mode. AT API Register provides the API function for registering device modules.
In the preceding figure, codes in the public part are in dark blue, and users do not need to modify them. Device codes are in light blue, and users need to compile the corresponding device codes. Based on the definition of the at_api_interface.h file, users only need to implement the following APIs.
typedef struct {
int32_t (*init)(void); /*Initialization: Initializing serial port and IP networks*/
int8_t (*get_localmac)(int8_t *mac);/*Obtaining local MAC address*/
int8_t (*get_localip)(int8_t *ip, int8_t * gw, int8_t * mask);/*Obtaining local IP address*/
/*Establishing TCP- or UDP-based connection*/
int32_t (*connect)(const int8_t * host, const int8_t *port, int32_t proto);
/*Send: After a command is sent, if the receiver has not received the command request in a period, an error will be returned.*/
int32_t (*send)(int32_t id , const uint8_t *buf, uint32_t len);
int32_t (*recv_timeout)(int32_t id , int8_t *buf, uint32_t len, int32_t timeout);
int32_t (*recv)(int32_t id , int8_t *buf, uint32_t len);
int32_t (*close)(int32_t id);/*Disconnecting*/
int32_t (*recv_cb)(int32_t id);/*Handling events, which is not implemented*/
int32_t (*deinit)(void);
}at_adaptor_api;
The at_api.h file is stored in the LiteOS/include/at_frame directory.
The previous section briefly introduces the AT framework. Developers need to implement the APIs defined in the at_api.h file, and then register the APIs through AT API Register for the upper-layer Agent Socket to call. This section uses the Wi-Fi module ESP8266 as an example to help developers for porting.
-
Connect the serial port Wi-Fi module ESP8266 to the STM32F429 development board, as shown in the following figure.
-
Define the API structure in the esp8266.c .
at_adaptor_api at_interface = { .init = esp8266_init, .get_localmac = esp8266_get_localmac, /*get local MAC*/ .get_localip = esp8266_get_localip,/*get local IP*/ /*build TCP or UDP connection*/ .connect = esp8266_connect, .send = esp8266_send, .recv_timeout = esp8266_recv_timeout, .recv = esp8266_recv, .close = esp8266_close,/*close connection*/ .recv_cb = esp8266_recv_cb,/* operation for events, not implements yet */ .deinit = esp8266_deinit, };The esp8266.c file is stored in the LiteOS/components/net/at_device/wifi_esp8266 directory.
-
Add the following codes to the main.c file :
#elif defined(WITH_AT_FRAMEWORK) && (defined(USE_ESP8266) || defined(USE_SIM900A)) extern at_adaptor_api at_interface; at_api_register(&at_interface); //Register functions defined by developers. agent_tiny_entry(); #endifThe main.c file is stored in the LiteOS/targets/Cloud_STM32F429IGTx_FIRE/Src directory.
-
Check that the compilation macro is enabled.
Figure 1 Global macro containing WITH_AT_FRAMEWORK and USE_ESP8266
-
Implement a specific device API in the esp8266.c file.
An example of initializing the demo program is as follows:
int32_t esp8266_init() { at.init(); at.oob_register(AT_DATAF_PREFIX, strlen(AT_DATAF_PREFIX), esp8266_data_handler); #ifdef USE_USARTRX_DMA HAL_UART_Receive_DMA(&at_usart,&at.recv_buf[at_user_conf.user_buf_len*0],at_user_conf.user_buf_len); #endif esp8266_reset(); esp8266_echo_off(); esp8266_choose_net_mode(STA); while(AT_FAILED == esp8266_joinap(WIFI_SSID, WIFI_PASSWD)) { AT_LOG("connect ap failed, repeat..."); }; esp8266_set_mux_mode(at.mux_mode); static int8_t ip[32]; static int8_t gw[32]; static int8_t mac[32]; esp8266_get_localip(ip, gw, NULL); esp8266_get_localmac(mac); AT_LOG("get ip:%s, gw:%s mac:%s", ip, gw, mac); return AT_OK; }To implement other APIs, refer to the preceding method. The macro defined by the AT instructions for the ESP8266 module is defined in the esp8266.h file . For details, see the ESP8266 official manual. Moreover, users need to change the Wi-Fi SSID and password in the esp8266.h file.
#define AT_CMD_RST "AT+RST" #define AT_CMD_ECHO_OFF "ATE0" #define AT_CMD_CWMODE "AT+CWMODE_CUR" #define AT_CMD_JOINAP "AT+CWJAP_CUR" #define AT_CMD_MUX "AT+CIPMUX" #define AT_CMD_CONN "AT+CIPSTART" #define AT_CMD_SEND "AT+CIPSEND" #define AT_CMD_CLOSE "AT+CIPCLOSE" #define AT_CMD_CHECK_IP "AT+CIPSTA_CUR?" #define AT_CMD_CHECK_MAC "AT+CIPSTAMAC_CUR?"The esp8266.h file is stored in the LiteOS/components/net/at_device/wifi_esp8266 directory.
The porting method of SIM900A is similar to that of ESP8266. Only the AT instructions are slightly different.
-
Connect the serial port GSM module SIM900A to the STM32F429 development board, as shown in the following figure.
-
Define the API structure in the sim900a.c file.
at_adaptor_api at_interface = { .init = sim900a_ini, /*TCP or UDP connect*/ .connect = sim900a_connect, /*send data, if no response, retrun error*/ .send = sim900a_send, .recv_timeout = sim900a_recv_timeout, .recv = sim900a_recv, .close = sim900a_close,/*close connect*/ .recv_cb = sim900a_recv_cb,/*receive event handle, no available by now */ .deinit = sim900a_deinit, };The sim900a.c file is stored in the LiteOS/components/net/at_device/gprs_sim900a directory.
-
Add the following codes to the main.c file:
#elif defined(WITH_AT_FRAMEWORK) && (defined(USE_ESP8266) || defined(USE_SIM900A)) extern at_adaptor_api at_interface; at_api_register(&at_interface); agent_tiny_entry(); #endif -
Check that the compilation macro is enabled.
Figure 1 Global macro containing WITH_AT_FRAMEWORK and USE_SIM900A
-
Implement a specific device API in the sim900a.c file.
The function for sending and receiving the demo program is as follows:
int32_t sim900a_recv_timeout(int32_t id, int8_t * buf, uint32_t len, int32_t timeout) { uint32_t qlen = sizeof(QUEUE_BUFF); QUEUE_BUFF qbuf = {0, NULL}; printf("****at.linkid[id].qid=%d***\n",at.linkid[id].qid); int ret = LOS_QueueReadCopy(at.linkid[id].qid, &qbuf, &qlen, timeout); AT_LOG("ret = %x, len = %d, id = %d", ret, qbuf.len, id); if (qbuf.len){ memcpy(buf, qbuf.addr, qbuf.len); atiny_free(qbuf.addr); } return qbuf.len; } int32_t sim900a_send(int32_t id , const uint8_t *buf, uint32_t len) { int32_t ret = -1; char cmd[64] = {0}; if (AT_MUXMODE_SINGLE == at.mux_mode) { snprintf(cmd, 64, "%s=%d", AT_CMD_SEND, len); } else { snprintf(cmd, 64, "%s=%d,%d", AT_CMD_SEND, id, len); } ret = at.write((int8_t *)cmd, "SEND OK", (int8_t*)buf, len); return ret; }The macro defined by the AT instructions for the SIM900A module is defined in the sim900a.h file. For details, see the SIM900A official manual.
#define AT_CMD_AT "AT" #define AT_CMD_CPIN "AT+CPIN?"//check sim card #define AT_CMD_COPS "AT+COPS?"//check register network #define AT_CMD_CLOSE "AT+CIPCLOSE" #define AT_CMD_SHUT "AT+CIPSHUT" #define AT_CMD_ECHO_OFF "ATE0" #define AT_CMD_ECHO_ON "ATE1" #define AT_CMD_MUX "AT+CIPMUX" #define AT_CMD_CLASS "AT+CGCLASS"//set MS type #define AT_CMD_PDP_CONT "AT+CGDCONT"//configure pdp context #define #defineAT_CMD_PDP_ATT "AT+CGATT"//pdp attach network #define AT_CMD_PDP_ACT "AT+CGACT"//active pdp context #define AT_CMD_CSTT "AT+CSTT"//start task #define AT_CMD_CIICR "AT+CIICR"//start gprs connect #define AT_CMD_CIFSR "AT+CIFSR"//get local ip #define AT_CMD_CIPHEAD "AT+CIPHEAD" #define AT_CMD_CONN "AT+CIPSTART" #define AT_CMD_SEND "AT+CIPSEND" #define AT_CMD_CLOSE "AT+CIPCLOSE"The sim900a.h file is stored in the LiteOS/components/net/at_device/gprs_sim900a directory.
The message receiving API with the timeout mechanism must be used because sending messages to and receiving messages from a device-cloud interconnect component belong to the same task. The API int32_t (*recv_timeout)(int32_t id , int8_t *buf, uint32_t len, int32_t timeout) must be used. The receiving timeout period is 10 seconds (implemented by #define BIND_TIMEOUT (10)).
If sending messages to and receiving messages from a user-designed application belong to different tasks, the blocking API int32_t (*recv)(int32_t id , int8_t *buf, uint32_t len) can be used.
After the device has been connected, OceanConnect can manage it.
OceanConnect provides a device simulator to simulate the scenario where a real device is connected to OceanConnect. This section describes how to connect a device simulator to OceanConnect.
-
Choose Simulator -> NB Device Simulator-> Binding Device. On the Binding Device page, enter the verification code, and click OK.
The verifyCode must be the same as that used during device registration.
-
Click My Device. On the My Device page, view the device status in the device list. If the device status is bound, the device has been successfully connected to OceanConnect.
Figure 2 Viewing the device status
After receiving a command or resource subscription message from OceanConnect, a device reports a command response or resource subscription message. OceanConnect pushes the message to the application server or subscribed address. If the southbound device that reports data is an NB-IoT device or a device integrated with device-cloud interconnect components, OceanConnect invokes codec plug-ins to parse the message before pushing the message to the application server or subscribed address.
OceanConnect provides a device simulator to simulate the scenario where a real device reports data. This section describes how to use the NB device simulator to report data. The NB device simulator can also simulate the data reporting of device-cloud interconnect components.
-
Log in to the OceanConnect portal.
The URL, account, and password for logging in to the OceanConnect portal must be applied to the OceanConnect service provider.
-
Choose Simulator > NB Device Simulator. On the NB Device Simulator page, enter the code stream to be reported, and click Send.
View data reporting information by choosing Log Information > Data Send.
View data reporting response information by choosing Log Information > Data Reception.
Figure 1 Simulating data reporting
-
In the device list on the My Device page, select a device that reports data and click Historical Data to check whether codec plug-ins can parse the reported data.
Figure 2 Viewing data reporting results
The following uses the codec plug-in of an LED lamp device as an example. The device includes the LightControl service. The setting method is applicable to multiple services containing attributes and commands.
LightControl: Contains the light attribute (the indicator is on or off) and the command (for setting the indicator to on or off).
After the hexadecimal code stream 01 reported by the device simulator is used, the result decoded by codec plug-ins in Historical Data is as follows:
LightControl: { "light": 1 }
-
In the device list on the My Device page, select a device that reports data and click Historical Data to check data reporting information.
Click Historical Data to view results parsed by codec plug-ins.
An application server needs to invoke the command delivery API of OceanConnect before delivering commands to a device. If the device that receives commands is an NB-IoT device or a southbound device integrated with device-cloud interconnect components, OceanConnect invokes codec plug-ins to decode the commands sent by the application server and sends the decoded commands to the device.
OceanConnect provides the application simulator to simulate scenarios where an application server delivers commands. This section describes how to use the application simulator to deliver commands.
-
In the device list on the My Device page, select the device that receives commands and click Command Delivery（</>).
In the dialog box that is displayed, configure the parameters of commands delivered to the device.
-
In the device list on the My Device page, select the device that receives commands and click Historical Command to view information in the status column.
Figure 2 Viewing the command delivering status
Status description is as follows:
- Overdue: Commands have not been delivered to devices in the cache time specified by OceanConnect.
- Success: OceanConnect has delivered commands to devices and received the command execution results from devices.
- Fail: The codec plug-in parsing is empty, or the execution results contain ERROR CODE.
- Timeout: It is timed out that OceanConnect waits for an ACK response.
- Cancel: Command delivering has been canceled on the application side.
- Waiting: Commands are cached on OceanConnect and have not been delivered to devices.
- Sent: OceanConnect has delivered commands to devices.
- Arrived: OceanConnect has delivered commands to devices and received an ACK response from devices.
-
Choose “Simulator->“NB Device Simulator”->“Device Log Information”->“Data Reception”. On the Data Reception page, view the command information received by the device simulator.
Figure 3 Viewing command receiving information
----End
LWM2M is a lightweight, standard, and general-purpose IoT device management protocol developed by the Open Mobile Alliance (OMA). It can be used to quickly deploy IoT services in client or server mode.
In addition, LWM2M provides a set of standards for the management and application of IoT devices. It supports small and portable security communications APIs and efficient data models to implement M2M device management and service support.
LWM2M supports the following features:
-
Simple objects based on resource models
-
Resource operations including creation, retrieval, update, deletion, and attribute configuration
- Resource observation or notification
-
Data formats including TLV, JSON, plain text, and opaque
-
Transport layer protocols including UDP and SMS
-
DTLS
-
NAT or firewall solution — queue mode
-
Multiple LWM2M Servers
-
Basic M2M functions including LWM2M Server, Access Control, Devices, Connectivity Monitoring, Firmware, Location, and Connectivity Statistics
The following figure shows the system architecture of LWM2M.
Figure 1 System architecture of LWM2M
An object is a collection of resources that are logically used for specific purposes. For example, firmware upgrade. The object includes all resources used for firmware upgrade, such as firmware packages, firmware URLs, upgrade execution, and upgrade results.
Before using the functions of an object, instantiate the object. An object can have multiple instances, which are numbered from 0 in ascending order.
LWM2M has defined fixed IDs for the standard objects defined by the OMA. For example, the ID of the firmware upgrade object is 5. The object includes eight types of resources, which are numbered from 0 to 7. The ID of the firmware package name is 6. Therefore, URI 5/0/6 represents the firmware package name of instance 0 of the firmware upgrade object.
The OMA LWM2M specifications define the following seven standard objects.
Device-cloud interconnect components match OceanConnect capabilities and support the following LWM2M APPDATA with the object ID of 19.
Includes application service data on LWM2M servers, such as water meter data. |
For details about other common objects defined by the OMA, see http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html.
LWM2M defines a resource model. In this resource model, all information can be abstracted and accessed as resources. An object includes resources. An LWM2M Client can have a large amount of resources. Like an object, a resource can have multiple instances.
The following figure shows the relationship among the LWM2M Client, objects, and resources.
Figure 1 Relationship among the LWM2M Client, objects, and resources
The LWM2M Enabler consists of two components: LWM2M Server and LWM2M Client. LWM2M designs the following four types of APIs for the interaction between the two components:
- API for device discovery and registration
- Bootstrap API
- API for device management and service enablement
- Information reporting API
The following figure shows an API model defined by LWM2M.
Figure 1 API model defined by LWM2M
The following figure shows the message interaction process defined by LWM2M.
Figure 2 Message interaction process defined by LWM2M
Each type of LWM2M APIs represents a type of functions. The API for device management and service implementation is one of the four types of APIs defined by LWM2M.
The functions of the four types of APIs are implemented by the following two operations:
- Upstream operation: LWM2M Client –> LWM2M Server
- Downstream operation: LWM2M Server –> LWM2M Client
LWM2M Server accesses object instances and resources of the LWM2M Client through the API for device management and service enablement. This API implements seven operations including create, read, write, delete, execute, write attributes, and discover.
Figure 3 Operations implemented by the API for device management and service enablement
Create, read, write, delete, execute, write attributes, and discover |
The following figure shows the interaction process implemented by the API for device management and service enablement.
Figure 4 Interaction process implemented by the API for device management and service enablement
Figure 5 Creating and deleting an object
The firmware upgrade object makes it possible for users to manage the firmware upgrade. The firmware upgrade objects include installing the firmware package, updating the firmware, and other actions. After the firmware is successfully upgraded, the corresponding device must be restarted to make the new firmware take effect.
Before the device is restarted, values related to the upgrade results must be saved.
After the device is restarted, if the Packet resource contains a valid but uninstalled firmware package, the State resource must be in the downloaded state. Otherwise, it must be in the idle state.
The following figure shows the firmware upgrade status mechanism.
Figure 1 Firmware upgrade status mechanism
The following figure shows the firmware upgrade flowchart.
