michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/subsys/net/lib/lwm2m/Kconfig

204 lines
5.3 KiB
Text
Raw Normal View History

net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
#
# Copyright (c) 2017 Linaro Limited
#
# SPDX-License-Identifier: Apache-2.0
#
menuconfig LWM2M
bool "OMA LWM2M protocol stack"
default n
net: lwm2m: move to using the new multi-packet CoAP API This patch moves from the ZoAP API in subsys/net/lib/zoap to the CoAP API in subsys/net/lib/coap which handles multiple fragments for sending / receiving data. NOTE: This patch moves the LwM2M library over to the CoAP APIs but there will be a follow-up patch which re-writes the content formatter reader / writers to use net_pkt APIs for parsing across multiple net buffers. The current implementation assumes all of the data will land in 1 buffer. Samples using the library still need a fairly large NET_BUF_DATA_SIZE setting. (Example: CONFIG_NET_BUF_DATA_SIZE=384) Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-09-19 16:04:32 -07:00
select COAP
select COAP_EXTENDED_OPTIONS_LEN
net: lwm2m: select NET_APP_CLIENT automatically No need for samples to make sure they have this configured in their .conf files. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-08-23 21:18:35 -07:00
select NET_APP_CLIENT
net: lib: lwm2m: use stand-alone URL parser With future patches we will need to parse URLs in the registration client and firmware object. Enable it by default when LWM2M is enabled. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-16 15:15:37 -07:00
select HTTP_PARSER_URL
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
help
This option adds logic for managing OMA LWM2M data
if LWM2M
config SYS_LOG_LWM2M_LEVEL
int "LWM2M log level"
depends on SYS_LOG
default 1
range 0 4
help
Set the log level for the LWM2M library.
config LWM2M_ENGINE_STACK_SIZE
int "LWM2M engine stack size"
default 1024
help
Set the stack size for the LWM2M library engine (used for handling
OBSERVE and NOTIFY events)
net: lwm2m: refactor engine to use lwm2m_message structure Sending an lwm2m message is too difficult. It requires pending / reply and other structures to be configured and set by various portions of the library. There is also no way to know if a pending message ever encounters a timeout. Let's fix this by simplifying the internal LwM2M engine APIs for handling lwm2m messages: 1. A user calls lwm2m_get_message(lwm2m_ctx) which returns the first available lwm2m message from an array of messages (total # of messages is set via CONFIG_LWM2M_ENGINE_MAX_MESSAGES). 2. Next the user sets all of the fields in the message that are required (type, code message id, token, etc) 3. Then the user calls lwm2m_init_message(msg). This initializes the underlying zoap_packet, pending and reply structures. 4. Once initialized, the user creates their payload in msg->zpkt. 5. When the user is ready to send, the call lwm2m_send_message(msg). 6. And if for some reason an error occurs at any point, they can free up the entire set of structures with: lwm2m_release_message(msg). Included in the refactoring is a timeout_cb field which can be set in the LwM2M messages. If a pending structure ever expires the engine will call the timeout_cb passing in the msg structure before it's automatically released. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-09-01 01:11:43 -07:00
config LWM2M_ENGINE_MAX_MESSAGES
int "LWM2M engine max. message object"
default 10
help
Set the maximum message objects for the LWM2M library client
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
config LWM2M_ENGINE_MAX_PENDING
int "LWM2M engine max. pending objects"
default 5
help
Set the maximum pending objects for the LWM2M library client
config LWM2M_ENGINE_MAX_REPLIES
int "LWM2M engine max. reply objects"
default 5
help
Set the maximum reply objects for the LWM2M library client
config LWM2M_ENGINE_MAX_OBSERVER
doc: fix misspellings and missing EOF newlines Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-08-16 14:16:02 -07:00
int "Maximum # of observable LWM2M resources"
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
default 50
range 10 200
help
This value sets the maximum number of resources which can be
added to the observe notification list.
config LWM2M_ENGINE_DEFAULT_LIFETIME
int "LWM2M engine default server connection lifetime"
default 30
net: lwm2m: set range for client lifetime config Due to timeout checking the minimum lifetime must be 15 seconds, and we're storing the lifetime as an unsigned short so set the maximum to 65535. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-08-25 14:04:51 -07:00
range 15 65535
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
help
Set the default lifetime (in seconds) for the LWM2M library engine
config LWM2M_LOCAL_PORT
int "LWM2M client port"
default 5683
help
This is the client port for LWM2M communication (0 = random, defaults
to 5683)
config LWM2M_SECURITY_INSTANCE_COUNT
int "Maximum # of LWM2M Security object instances"
default 3
range 1 10
help
This setting establishes the total count of LWM2M Security instances
available to the client.
config LWM2M_SERVER_INSTANCE_COUNT
int "Maximum # of LWM2M Server object instances"
default 3
range 1 10
help
This setting establishes the total count of LWM2M Server instances
available to the client (including: bootstrap and regular servers).
config LWM2M_RD_CLIENT_SUPPORT
bool "support for LWM2M client bootstrap/registration state machine"
default y
help
Client will use registration state machine to locate and connect to
LWM2M servers (including bootstrap server support)
config LWM2M_RD_CLIENT_STACK_SIZE
int "LWM2M RD client stack size"
default 1024
net: lwm2m: increase rd client stack size when NET_LOG_GLOBAL=y The stack of rd client is exhausted while running lwm2m client w/ IPv6 and network log global enabled. Increase the stack size to 1536 when NET_LOG_GLOBAL is enabled. Detail described at #4424 Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
2017-10-19 16:27:03 +08:00
default 1536 if NET_LOG_GLOBAL
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
help
Set the stack size for the LWM2M RD client
config LWM2M_RD_CLIENT_INSTANCE_COUNT
int "Maximum # of LWM2M RD client instances"
default 2
help
This setting establishes the total count of LWM2M RD client instances
available.
config LWM2M_PEER_PORT
int "LWM2M server port"
depends on LWM2M_RD_CLIENT_SUPPORT
default 5683
help
This is the server port to connect to for LWM2M communication
config LWM2M_BOOTSTRAP_PORT
int "LWM2M bootstrap port"
depends on LWM2M_RD_CLIENT_SUPPORT
default 5684
help
This is the bootstrap port to connect to for security configuration
config LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT
bool "Firmware Update object support"
default y
help
Include support for LWM2M Firmware Update Object (ID 5)
config LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT
bool "Firmware Update object pull support"
default y
depends on LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT
net: lwm2m: add state machine for firmware pull update 1. Parse firmware pull URI 2. Add lwm2m_firmware_get/set_update_cb() for application to register callback. This is because we want to check the update_state before we pass to the application 3. Add lwm2m_firmware_get/set_update_result() and lwm2m_firmware_get/set_update_stat() to manage the state transition as well as the sanity check Signed-off-by: Robert Chou <robert.ch.chou@acer.com> [michael.scott@linaro.org: rebased on net_app framework and lwm2m_message refactoring.] Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-05 23:07:41 +08:00
depends on (HTTP_PARSER || HTTP_PARSER_URL)
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
help
Include support for pulling a file from a remote server via
block transfer and "FIRMWARE PACKAGE URI" resource. This option
adds another UDP context and packet handling.
net: lwm2m: add firmware push support 1. Add handling block1 option in handle_request(). The basic idea is to declare structure block_context at compiled time and use "token" as a key to pick up the on-going block cotext. It should be able to support multiple blockwise transfer concurrently 2. Use write callback implemented in lwm2m_obj_firmware to deal w/ the update state transition and than call the callback registered by the application 3. move default_block_size to lwm2m_engine.c to share between lwm2m_engine and lwm2m_obj_firmware_pull Signed-off-by: Robert Chou <robert.ch.chou@acer.com> [michael.scott@linaro.org: rebased on LwM2M net_app changes.] Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-25 16:54:25 +08:00
config LWM2M_COAP_BLOCK_SIZE
int "LWM2M CoAP block-wise transfer size"
net: lwm2m: firmware: add Kconfig option for CoAP block size CoAP block size might be adjusted for a faster firmware download process. Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
2017-07-07 20:48:18 -03:00
default 256
default 64 if NET_L2_BT
default 64 if NET_L2_IEEE802154
range 16 1024
help
net: lwm2m: add firmware push support 1. Add handling block1 option in handle_request(). The basic idea is to declare structure block_context at compiled time and use "token" as a key to pick up the on-going block cotext. It should be able to support multiple blockwise transfer concurrently 2. Use write callback implemented in lwm2m_obj_firmware to deal w/ the update state transition and than call the callback registered by the application 3. move default_block_size to lwm2m_engine.c to share between lwm2m_engine and lwm2m_obj_firmware_pull Signed-off-by: Robert Chou <robert.ch.chou@acer.com> [michael.scott@linaro.org: rebased on LwM2M net_app changes.] Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-25 16:54:25 +08:00
CoAP block size used by LWM2M when performing block-wise
net: lwm2m: firmware: add Kconfig option for CoAP block size CoAP block size might be adjusted for a faster firmware download process. Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
2017-07-07 20:48:18 -03:00
transfers. Possible values: 16, 32, 64, 128, 256, 512 and 1024.
net: lwm2m: add firmware push support 1. Add handling block1 option in handle_request(). The basic idea is to declare structure block_context at compiled time and use "token" as a key to pick up the on-going block cotext. It should be able to support multiple blockwise transfer concurrently 2. Use write callback implemented in lwm2m_obj_firmware to deal w/ the update state transition and than call the callback registered by the application 3. move default_block_size to lwm2m_engine.c to share between lwm2m_engine and lwm2m_obj_firmware_pull Signed-off-by: Robert Chou <robert.ch.chou@acer.com> [michael.scott@linaro.org: rebased on LwM2M net_app changes.] Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-25 16:54:25 +08:00
config LWM2M_NUM_BLOCK1_CONTEXT
int "Maximum # of LWM2M block1 contexts"
default 3
help
This value sets up the maximum number of block1 contexts for
CoAP block-wise transfer we can handle at the same time.
net: lwm2m: firmware: add support for firmware pull over CoAP proxy CoAP allows a proxy to be used when transferring data (CoAP-CoAP and/or CoAP-HTTP) by creating request on a specific URI path and by using the Proxy URI CoAP option. Create specific Kconfig options for the proxy server address and port, until a parser gets implemented. Code tested with Californium acting as CoAP proxy. Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org> [michael.scott@linaro.org: rebased on net_app + lwm2m_message refactoring + firmware update changes.] Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-27 18:30:44 -03:00
config LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT
bool "Firmware Update object pull via CoAP-CoAP/HTTP proxy support"
depends on LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT
default n
help
Include support for pulling firmware file via a CoAP-CoAP/HTTP proxy.
if LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT
config LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_ADDR
string "CoAP proxy network address"
help
Network address of the CoAP proxy server.
config LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_URI_PATH
string "CoAP URI path element used by the proxy"
default "coap2http"
help
CoAP URI path element exported by the CoAP proxy server.
Defaults to coap2http, which is the URI path used by the
Californium CoAP-HTTP proxy.
endif # LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
config LWM2M_RW_JSON_SUPPORT
bool "support for JSON writer"
default y
help
Include support for writing JSON data
config LWM2M_DEVICE_ERROR_CODE_MAX
int "Maximum # of device obj error codes to store"
default 10
range 1 20
help
This value sets the maximum number of error codes that the device
object will store before ignoring new values.
net: lwm2m: add IPSO support w/ temperature sensor object IPSO Smart Objects are a set of template objects based on the LwM2M object framework which are designed to represent standard hardware such as temperature and humidity sensors or light controls. Let's add a place for these objects to live as well as an initial temperature sensor object. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:05 -07:00
menu "IPSO Alliance Smart Object Support"
source "subsys/net/lib/lwm2m/Kconfig.ipso"
endmenu
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-07 11:04:03 -07:00
endif # LWM2M
Copy permalink