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

223 lines
6 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"
net: lwm2m: move to flat buffers As part of the migration from net_app APIs to socket APIs, let's stop referencing the net_pkt fragments throughout the LwM2M library. Establish a msg_data flat buffer inside lwm2m_message and use that instead. NOTE: As a part of this change we remove the COAP_NET_PKT setting. The COAP library reverts to COAP_SOCK behavior. This doesn't mean we use sockets in LwM2M (yet), it only means we use the socket-compatible COAP library which parses flat buffers instead of net_pkt fragments. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 14:13:07 -08:00
select COAP
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: migrate LwM2M library to BSD-sockets API This commit removes the net_app layer from the LwM2M library and replaces it with BSD-sockets APIs. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-28 11:55:23 -08:00
select NET_SOCKETS
select NET_SOCKETS_POSIX_NAMES
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
net: Make Kconfig template variables prettier Adding spaces around "=" when definining Kconfig template so that is more consistent with overall style of these template variables. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-10-05 15:14:58 +03:00
module = LWM2M
module-dep = LOG
module-str = Log level for LWM2M library
net: lwm2m: Convert to new logging system Use new logging system instead of SYS_LOG. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-09-19 11:22:19 +03:00
source "subsys/net/Kconfig.template.log_config.net"
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
net: lwm2m: create DTLS config layer for LwM2M Currently, this will select the needed configs for LwM2M and net_pkt. During the migration to socket APIs, the net_pkt selections will change to socket-based selects. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-24 15:49:31 -08:00
config LWM2M_DTLS_SUPPORT
bool "Enable DTLS support in the LwM2M client"
select MBEDTLS
select MBEDTLS_ENABLE_HEAP
net: lwm2m: migrate LwM2M library to BSD-sockets API This commit removes the net_app layer from the LwM2M library and replaces it with BSD-sockets APIs. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-28 11:55:23 -08:00
select TLS_CREDENTIALS
select NET_SOCKETS_SOCKOPT_TLS
select NET_SOCKETS_ENABLE_DTLS
net: lwm2m: create DTLS config layer for LwM2M Currently, this will select the needed configs for LwM2M and net_pkt. During the migration to socket APIs, the net_pkt selections will change to socket-based selects. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-24 15:49:31 -08:00
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_STACK_SIZE
int "LWM2M engine stack size"
net: lwm2m: Convert to new logging system Use new logging system instead of SYS_LOG. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-09-19 11:22:19 +03:00
default 1536 if NET_LOG
Kconfig: Use the first default with a satisfied condition Up until now, Zephyr has patched Kconfig to use the last 'default' with a satisfied condition, instead of the first one. I'm not sure why the patch was added (it predates Kconfiglib), but I suspect it's related to Kconfig.defconfig files. There are at least three problems with the patch: 1. It's inconsistent with how Kconfig works in other projects, which might confuse newcomers. 2. Due to oversights, earlier 'range' properties are still preferred, as well as earlier 'default' properties on choices. In addition to being inconsistent, this makes it impossible to override 'range' properties and choice 'default' properties if the base definition of the symbol/choice already has 'range'/'default' properties. I've seen errors caused by the inconsistency, and I suspect there are more. 3. A fork of Kconfiglib that adds the patch needs to be maintained. Get rid of the patch and go back to standard Kconfig behavior, as follows: 1. Include the Kconfig.defconfig files first instead of last in Kconfig.zephyr. 2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of last in arch/Kconfig. 3. Include arch/<arch>/soc/*/Kconfig first instead of last in arch/<arch>/Kconfig. 4. Swap a few other 'source's to preserve behavior for some scattered symbols with multiple definitions. Swap 'source's in some no-op cases too, where it might match the intent. 5. Reverse the defaults on symbol definitions that have more than one default. Skip defaults that are mutually exclusive, e.g. where each default has an 'if <some board>' condition. They are already safe. 6. Remove the prefer-later-defaults patch from Kconfiglib. Testing was done with a Python script that lists all Kconfig symbols/choices with multiple defaults, along with a whitelist of fixed symbols. The script also verifies that there are no "unreachable" defaults hidden by defaults without conditions As an additional test, zephyr/.config was generated before and after the change for several samples and checked to be identical (after sorting). This commit includes some default-related cleanups as well: - Simplify some symbol definitions, e.g. where a default has 'if FOO' when the symbol already has 'depends on FOO'. - Remove some redundant 'default ""' for string symbols. This is the implicit default. Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and BT_L2CAP_TX_MTU (caused by confusing inconsistency). Piggyback some fixes for style nits too, e.g. unindented help texts. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
default 1024
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 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: move to flat buffers As part of the migration from net_app APIs to socket APIs, let's stop referencing the net_pkt fragments throughout the LwM2M library. Establish a msg_data flat buffer inside lwm2m_message and use that instead. NOTE: As a part of this change we remove the COAP_NET_PKT setting. The COAP library reverts to COAP_SOCK behavior. This doesn't mean we use sockets in LwM2M (yet), it only means we use the socket-compatible COAP library which parses flat buffers instead of net_pkt fragments. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 14:13:07 -08:00
config LWM2M_COAP_BLOCK_SIZE
int "LWM2M CoAP block-wise transfer size"
default 256
range 64 1024
help
CoAP block size used by LWM2M when performing block-wise
transfers. Possible values: 16, 32, 64, 128, 256, 512 and 1024.
config LWM2M_ENGINE_MESSAGE_HEADER_SIZE
int "Room for CoAP header data"
default 48
range 24 128
help
Extra room allocated to handle CoAP header data
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: lower default maximum observes from 20 to 10 In an effort to reduce the footprint of the LwM2M client, let's lower the default # of observes handled by the client from 20 to 10. This saves ~640 bytes of SRAM. Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-07 16:04:51 -07:00
default 10
net: lwm2m: reduce LwM2M footprint via lower defaults in Kconfig Let's use conservative defaults for the LwM2M library to enable hardware with constrained resources. Users can increase where necessary. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-01 13:29:23 -07:00
range 5 200
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 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"
net: lwm2m: default LWM2M_LOCAL_PORT to 0 (random) Due to a bug where LWM2M_LOCAL_PORT was not being honored, all outgoing traffic from the LwM2M client was coming from a random port determined during initialization. Now that this bug bas been fixed, let's default the client to the behavior that most users are expecting, and let new users customize the outgoing port if needed (which should be rarely). Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-16 15:57:46 -07:00
default 0
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
net: lwm2m: default LWM2M_LOCAL_PORT to 0 (random) Due to a bug where LWM2M_LOCAL_PORT was not being honored, all outgoing traffic from the LwM2M client was coming from a random port determined during initialization. Now that this bug bas been fixed, let's default the client to the behavior that most users are expecting, and let new users customize the outgoing port if needed (which should be rarely). Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-16 15:57:46 -07:00
This is the client port for LWM2M communication. The default
setting of 0 sets a random port for the client to be used for
outgoing communication.
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_SECURITY_INSTANCE_COUNT
int "Maximum # of LWM2M Security object instances"
net: lwm2m: reduce LwM2M footprint via lower defaults in Kconfig Let's use conservative defaults for the LwM2M library to enable hardware with constrained resources. Users can increase where necessary. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-01 13:29:23 -07:00
default 1
net: lwm2m: support for LwM2M bootstrap Now that the security data can be loaded into and used from the security / server objects, we can add support for LwM2M bootstrap. This is a mode where initially a connection can be made to a server which can update several LwM2M (including security and server data) and then trigger a "bootstrap complete". Once this happens the client will start it's connection process over but now with the new information. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 22:36:47 -08:00
default 2 if LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP
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
range 1 10
help
This setting establishes the total count of LWM2M Security instances
available to the client.
net: lwm2m: update security obj with DTLS data For bootstrap support, we need to store connection credentials in the security object. This way the client can start a connection at index 0 and after bootstrapping, move to the next connection. Let's add the needed fields and a config item to set the key length. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 16:01:39 -08:00
config LWM2M_SECURITY_KEY_SIZE
int "Buffer size of the security key resources"
default 16
range 16 256
help
This setting establishes the size of the key (pre-shared / public)
resources in the security object instances.
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_SERVER_INSTANCE_COUNT
int "Maximum # of LWM2M Server object instances"
net: lwm2m: reduce LwM2M footprint via lower defaults in Kconfig Let's use conservative defaults for the LwM2M library to enable hardware with constrained resources. Users can increase where necessary. Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-01 13:29:23 -07:00
default 1
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
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)
net: lwm2m: support for LwM2M bootstrap Now that the security data can be loaded into and used from the security / server objects, we can add support for LwM2M bootstrap. This is a mode where initially a connection can be made to a server which can update several LwM2M (including security and server data) and then trigger a "bootstrap complete". Once this happens the client will start it's connection process over but now with the new information. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 22:36:47 -08:00
config LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP
bool "Enable bootstrap support"
help
Enabling this setting allows the RD client to support bootstrap mode.
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_PEER_PORT
int "LWM2M server port"
depends on LWM2M_RD_CLIENT_SUPPORT
default 5683
help
net: lwm2m: support for LwM2M bootstrap Now that the security data can be loaded into and used from the security / server objects, we can add support for LwM2M bootstrap. This is a mode where initially a connection can be made to a server which can update several LwM2M (including security and server data) and then trigger a "bootstrap complete". Once this happens the client will start it's connection process over but now with the new information. Signed-off-by: Michael Scott <mike@foundries.io>
2019-01-25 22:36:47 -08:00
This is the default server port to connect to for LWM2M communication
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_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 LWM2M_FIRMWARE_UPDATE_PULL_LOCAL_PORT setting This allows a user to customize the port used for downloading firmware via the pull method of the LwM2M client. It's default value of 0 will select a random port during initialization. NOTE: If set, this value should not be the same port as the LWM2M_LOCAL_PORT setting. Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-16 16:07:03 -07:00
config LWM2M_FIRMWARE_UPDATE_PULL_LOCAL_PORT
int "LWM2M client firmware pull local port"
default 0
depends on LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT
help
This is the client port for LWM2M firmware download. The default
setting of 0 sets a random port for the client to be used for
outgoing communication.
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
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.
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
net: lwm2m: add max device power source config option The code in the LwM2M "Device" object was checking for this max power source config value, except that it was never added as a Kconfig option. Let's go ahead and add it so apps can set the value appropriately. Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-01-11 09:45:24 -08:00
config LWM2M_DEVICE_PWRSRC_MAX
int "Maximum # of device power source records"
default 5
range 1 20
help
This value sets the maximum number of power source data that a device
can store. These are displayed via the "Device" object /3/0/6,
/3/0/7 and /3/0/8 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
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 write-attribute WRITE support Implement write-attribute on obj/obj_inst/res according to LwM2M spec 20170704-A, sec 5.1.2. Support pmin/pmax/st/gt/lt parameters on WRITE operation. The basic idea is to add sys_slist_t to obj/obj_inst/res structure. And attach struct lwm2m_attr to the list when attributes are written from server side (implement lwm2m_write_attr_handler accordingly) Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
2017-11-24 18:47:00 +08:00
config LWM2M_NUM_ATTR
int "Maximum # of LWM2M attributes"
default 20
help
This value sets up the maximum number of LwM2M attributes that
we can handle at the same time.
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