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

484 lines
14 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"
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: Update security object to 1.1 Add 1.1 version of the LWM2M security object. Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
2021-12-23 12:08:49 +02:00
choice
prompt "LwM2M Security object version"
default LWM2M_SECURITY_OBJECT_VERSION_1_0
help
Select which version of the security object should be used.
config LWM2M_SECURITY_OBJECT_VERSION_1_0
bool "Security object version 1.0"
config LWM2M_SECURITY_OBJECT_VERSION_1_1
bool "Security object version 1.1 [EXPERIMENTAL]"
select EXPERIMENTAL
endchoice
net: lwm2m: Update LwM2m server object to v1.1 Added Kconfig configurable choise option for enable Server object version 1.0 or 1.1. Server Object v1.1 enable by default server initiated bootstrap trigger when CONFIG_LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP is enabled. Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
2021-12-14 04:10:36 -08:00
choice
prompt "LwM2M Server object version"
default LWM2M_SERVER_OBJECT_VERSION_1_0
help
Select which version of the Server object should be used.
config LWM2M_SERVER_OBJECT_VERSION_1_0
bool "Server object version 1.0"
config LWM2M_SERVER_OBJECT_VERSION_1_1
bool "Server object version 1.1 [EXPERIMENTAL]"
select EXPERIMENTAL
endchoice
net: lwm2m: Add config to enable DNS support Add new config option `LWM2M_DNS_SUPPORT` to the LWM2M library, instead of relying on `DNS_RESOLVER` which is only compatible with native network stack. This allows to use DNS with offloaded interfaces seamlessly. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2019-10-15 09:56:03 +02:00
config LWM2M_DNS_SUPPORT
bool "Enable DNS support in the LWM2M client"
default y if DNS_RESOLVER
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: raise stack sizes Occasionally we see a stack crash in LwM2M. This may have been due to the swap from net_app APIs to socket-based APIs. Let's raise the default stack by 1k. Signed-off-by: Michael Scott <mike@foundries.io>
2019-02-18 21:57:56 -08:00
default 2560 if NET_LOG
default 2048
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
kconfig: Global whitespace/consistency cleanup Clean up space errors and use a consistent style throughout the Kconfig files. This makes reading the Kconfig files more distraction-free, helps with grepping, and encourages the same style getting copied around everywhere (meaning another pass hopefully won't be needed). Go for the most common style: - Indent properties with a single tab, including for choices. Properties on choices work exactly the same syntactically as properties on symbols, so not sure how the no-indentation thing happened. - Indent help texts with a tab followed by two spaces - Put a space between 'config' and the symbol name, not a tab. This also helps when grepping for definitions. - Do '# A comment' instead of '#A comment' I tweaked Kconfiglib a bit to find most of the stuff. Some help texts were reflowed to 79 columns with 'gq' in Vim as well, though not all, because I was afraid I'd accidentally mess up formatting. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-01 10:24:07 +01:00
Set the stack size for the LWM2M library engine (used for handling
OBSERVE and NOTIFY events)
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: 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
net: lwm2m: Fix Kconfig help about allowed... ...range for LWM2M_COAP_BLOCK_SIZE. The range has been set to start from 64 bytes and now the help text has been brought up to date. Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
2021-09-29 09:38:47 +03:00
transfers. Possible values: 64, 128, 256, 512 and 1024.
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_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: Decouple CoAP message- and block size If blockwise transfer is not in use it must be possible to send bigger CoAP messages than what is the block size used with blockwise transfers. To compensate for the increased memory usage number of in-flight packets allowed could be decreased. Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
2021-09-29 08:23:18 +03:00
config LWM2M_COAP_MAX_MSG_SIZE
int "LWM2M CoAP maximum message size"
default LWM2M_COAP_BLOCK_SIZE
help
CoAP message size used by LWM2M. Minimum is the block size used
in blockwise transfers.
net: lwm2m: Add data validation callback Add a data validation callback to the resource structure, which can be registered by an application. It allows to verify the data before actually modifying the resource data. If the callback is registered for a resource, the data is decoded into a temporary buffer first, and only copied into the actual resource buffer if the validation is successfull. If no validation is required (and thus no callback registered) the resource value is decoded directly into the resource buffer, as it used to be. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2021-02-17 15:47:28 +01:00
config LWM2M_ENGINE_VALIDATION_BUFFER_SIZE
int "Size of the validation buffer for the incoming data"
default 64
help
LwM2M will use the validation buffer during the write operation, to
decode the resource value before validating it (applies for resources
for which validation callback has been registered). Set this value to
the maximum expected size of the resources that need to be validated
(and thus have validation callback registered).
net: lwm2m: Make validation cb support optional Add option to disable validation callback support by setting the validation buffer size to 0, which allows to save some memory in case it's not needed. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2021-03-10 13:14:31 +01:00
Setting the validation buffer size to 0 disables validation support.
net: lwm2m: Add data validation callback Add a data validation callback to the resource structure, which can be registered by an application. It allows to verify the data before actually modifying the resource data. If the callback is registered for a resource, the data is decoded into a temporary buffer first, and only copied into the actual resource buffer if the validation is successfull. If no validation is required (and thus no callback registered) the resource value is decoded directly into the resource buffer, as it used to be. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2021-02-17 15:47:28 +01: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_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.
net: lwm2m: Allow cancel-observe to match path The specification states that the server can cancel observations "at any moment, by sendinga GET request with Observe option=1, the LwM2M Server cancancel an “Observe”operation on a specified Resource, or specified Object Instance(s)." It does not mention any token matching requirement, but RFC 7641 does. The correct interpretation is not obvious. The EMQx LwM2M implementation uses a new token for instance, which does not work with Zephyrs token matching cancel-observe. This commit introduces cancel-observe via path matching as a Kconfig option. This could hypothetically introduce problems when we are connected to multiple peers simultaneously, but since that is not likely to be supported for a long time (if ever), this change should be fairly uncontroversial since path matching is only used as a fallback. Signed-off-by: Benjamin Lindqvist <benjamin.lindqvist@endian.se>
2021-03-03 11:43:05 +01:00
config LWM2M_CANCEL_OBSERVE_BY_PATH
bool "Use path matching as fallback for cancel-observe"
help
Some ambiguous language in the LwM2M spec causes some LwM2M server
implementations to implement cancel-observe by specifying the resource
path rather than the token of the original observe request. Without
this option, cancel-observe may not work properly when connecting to
those servers.
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_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
net: lwm2m: Make Registration Update ahead time configurable Allow to configure, how long before registration timeout should the Registration Update be sent. The fixed 6 seconds used so far, might not be enough in slower networks (like NB-IoT), resulting in frequent re-registrations at LWM2M level. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2020-06-16 15:09:17 +02:00
config LWM2M_SECONDS_TO_UPDATE_EARLY
int "LWM2M Registration Update transmission time before timeout"
default 6
range 1 65535
help
Time in seconds before the registration timeout, when the LWM2M
Registration Update is sent by the engine. In networks with large
round trip times (like NB-IoT), it might be needed to set this value
higher, in order to allow the response to arrive before timeout.
net: lwm2m: Add option to register in UDP queue mode Add Kconfig option to enable Queue Mode binding. With this option enabled, the LWM2M client will register with `UQ` binding, instead of `U`. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2020-02-20 16:49:14 +01:00
config LWM2M_QUEUE_MODE_ENABLED
bool "Enable Queue Mode UDP binding"
help
Set the transport binding to UDP with Queue Mode (UQ).
config LWM2M_QUEUE_MODE_UPTIME
int "Specify time the LWM2M client should stay online in queue mode."
default 93
help
This config specifies time (in seconds) the device should stay online
after sending a message to the server. Note, that LWM2M specification
recommends this to be CoAP MAX_TRANSMIT_WAIT parameter (which
defaults to 93 seconds, see RFC 7252), it does not forbid other
values though.
net: lwm2m: Kconfig: move RD_CLIENT settings above dependencies LwM2M boostrap support is enabled via the config option: LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP. If enabled, this config sets the default # of server and security instances. However, this is not working correctly because LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP is defined below it's uses in the Kconfig file. Let's move the RD_CLIENT configs higher in the Kconfig to fix this behavior. Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-17 09:54:53 -07:00
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_SUPPORT_BOOTSTRAP
bool "Enable bootstrap support"
help
Enabling this setting allows the RD client to support bootstrap mode.
net: lwm2m: make max client endpoint name configurable support longer name like urn:dev:ops:{OUI}-{ProductClass}-{SerialNumber} or urn:imei-msisdn:###############-############### Signed-off-by: Pascal Brogle <pascal.brogle@husqvarnagroup.com>
2020-09-10 13:22:42 +02:00
config LWM2M_RD_CLIENT_ENDPOINT_NAME_MAX_LENGTH
int "Maximum length of client endpoint name"
depends on LWM2M_RD_CLIENT_SUPPORT
default 33
help
Default: room for 32 hexadeciaml digits (UUID) + NULL
net: lwm2m: Notify the application on network error Add a simple backoff mechanism between consecutive registration attempts in case of registration failures. Finally, notify the application in case the registration failed several times. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2020-09-08 11:54:31 +02:00
config LWM2M_RD_CLIENT_MAX_RETRIES
int "Specify maximum number of registration retries"
default 5
help
Specify maximum number of registration retries, before the application
is notified about the network failure. Once application is notified,
it's up to the application to handle this situation in a way
appropriate for the specific use-case (for instance by waiting for
LTE link to be re-established).
net: lwm2m: Kconfig: move RD_CLIENT settings above dependencies LwM2M boostrap support is enabled via the config option: LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP. If enabled, this config sets the default # of server and security instances. However, this is not working correctly because LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP is defined below it's uses in the Kconfig file. Let's move the RD_CLIENT configs higher in the Kconfig to fix this behavior. Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-17 09:54:53 -07:00
config LWM2M_PEER_PORT
int "LWM2M server port"
depends on LWM2M_RD_CLIENT_SUPPORT
default 5683
help
net: lwm2m: Add default firmware update port If a firmware update is fetched from a server, and no port number is set in the URI (e.g. coap://example.com/fw_update), the client will try to connect on the port specified by CONFIG_LWM2M_PEER_PORT. If a port different from the peer port is to be used for firmware update, this has to be set explicitly in the URI: coap://example.com:5683/fw_update. This fix adds CONFIG_LWM2M_FIRMWARE_PORT, which will be used when fetching a firmware update without specifying the port number in the URI. Signed-off-by: Tjerand Bjornsen <tjerand.bjornsen@nordicsemi.no>
2021-09-23 13:00:46 +02:00
This is the default server port to connect to for LWM2M communication.
config LWM2M_FIRMWARE_PORT_NONSECURE
int "LWM2M firmware server port non-secure"
default 5683
help
This is the default server port to connect to for LwM2M firmware downloads over coap.
config LWM2M_FIRMWARE_PORT_SECURE
int "LWM2M firmware server port secure"
default 5684
help
This is the default server port to connect to for LwM2M firmware downloads over coaps.
net: lwm2m: Kconfig: move RD_CLIENT settings above dependencies LwM2M boostrap support is enabled via the config option: LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP. If enabled, this config sets the default # of server and security instances. However, this is not working correctly because LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP is defined below it's uses in the Kconfig file. Let's move the RD_CLIENT configs higher in the Kconfig to fix this behavior. Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-17 09:54:53 -07: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_SECURITY_INSTANCE_COUNT
int "Maximum # of LWM2M Security object instances"
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: Kconfig: fixup default instance counts for bootstrap - LWM2M_SECURITY_INSTANCE_COUNT wasn't following the standard of having the unconditional default in the last position - LWM2M_SERVER_INSTANCE_COUNT needs another instance when bootstrap is enabled. Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-17 10:01:58 -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 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: Update security object to 1.1 Add 1.1 version of the LWM2M security object. Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
2021-12-23 12:08:49 +02:00
config LWM2M_SECURITY_DTLS_TLS_CIPHERSUITE_MAX
int "Maximum # of DTLS/TLS ciphersuite resource instances"
default 5
range 0 20
depends on LWM2M_SECURITY_OBJECT_VERSION_1_1
help
This setting sets the maximum number of the resource instances of
a security object defined in LWM2M version 1.1. Affects the resource
0/X/16, where X is the object instance number.
net: lwm2m: use server record to set default observe notify timing Server records contain the default PMIN and PMAX settings for how often we can send observe notifications. We are currently using arbitrary defaults which cannot be changed when compiled or during runtime. Let's add Kconfig settings for the default settings to use and also lookup the current values in the active server record when an observe is added. The actual PMIN/PMAX values can still be set via WRITE_ATTRIBUTE operation. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:00:00 -07:00
config LWM2M_SERVER_DEFAULT_PMIN
int "Default server record PMIN"
net: lwm2m: Made pmin and pmax attributes optional Made the LwM2M engine checks for pmin and pmax optional to adhere to the LwM2M specificattion. We now first check that pmin and pmax are actually set. Also changed the default CONFIG values for the attributes pmin and pmax to 0 to indicate that they are not active by default. Fixes #34329. Signed-off-by: Maik Vermeulen <maik.vermeulen@innotractor.com>
2021-04-16 13:47:58 +02:00
default 0
net: lwm2m: use server record to set default observe notify timing Server records contain the default PMIN and PMAX settings for how often we can send observe notifications. We are currently using arbitrary defaults which cannot be changed when compiled or during runtime. Let's add Kconfig settings for the default settings to use and also lookup the current values in the active server record when an observe is added. The actual PMIN/PMAX values can still be set via WRITE_ATTRIBUTE operation. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:00:00 -07:00
help
Default minimum amount of time in seconds the client must wait
between notifications. If a resource has to be notified during this
minimum time period, the notification must be sent after the time
period expires.
config LWM2M_SERVER_DEFAULT_PMAX
int "Default server record PMAX"
net: lwm2m: Made pmin and pmax attributes optional Made the LwM2M engine checks for pmin and pmax optional to adhere to the LwM2M specificattion. We now first check that pmin and pmax are actually set. Also changed the default CONFIG values for the attributes pmin and pmax to 0 to indicate that they are not active by default. Fixes #34329. Signed-off-by: Maik Vermeulen <maik.vermeulen@innotractor.com>
2021-04-16 13:47:58 +02:00
default 0
net: lwm2m: use server record to set default observe notify timing Server records contain the default PMIN and PMAX settings for how often we can send observe notifications. We are currently using arbitrary defaults which cannot be changed when compiled or during runtime. Let's add Kconfig settings for the default settings to use and also lookup the current values in the active server record when an observe is added. The actual PMIN/PMAX values can still be set via WRITE_ATTRIBUTE operation. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:00:00 -07:00
help
Default maximum amount of time in seconds the client may wait
between notifications. When this time period expires a notification
must be sent.
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: Kconfig: fixup default instance counts for bootstrap - LWM2M_SECURITY_INSTANCE_COUNT wasn't following the standard of having the unconditional default in the last position - LWM2M_SERVER_INSTANCE_COUNT needs another instance when bootstrap is enabled. Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-17 10:01:58 -07:00
default 2 if LWM2M_RD_CLIENT_SUPPORT_BOOTSTRAP
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).
net: lwm2m: add Connection Monitoring object support This core LwM2M Object enables monitoring of parameters related to network connectivity. This is only the basic object structure. More work will be needed to set the various resources based on connectivity. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:13:00 -07:00
config LWM2M_CONN_MON_OBJ_SUPPORT
bool "Connectivity Monitoring object support"
help
Include support for LWM2M Connectivity Monitoring Object (ID 4)
net: lwm2m: Update connectivity monitor object Update the connectivity monitor object to version 1.2. OMA core specification for the object adds 2 optional resources. Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
2021-12-27 15:01:44 +02:00
choice
prompt "LwM2M Connectivity Monitor object version"
default LWM2M_CONNMON_OBJECT_VERSION_1_0
depends on LWM2M_CONN_MON_OBJ_SUPPORT
help
Select Which version of the Connectivity Monitor object should be used.
config LWM2M_CONNMON_OBJECT_VERSION_1_0
bool "Connectivity monitor object version 1.0"
config LWM2M_CONNMON_OBJECT_VERSION_1_2
bool "Connectivity monitor object version 1.2 [EXPERIMENTAL]"
select EXPERIMENTAL
endchoice
net: lwm2m: add Connection Monitoring object support This core LwM2M Object enables monitoring of parameters related to network connectivity. This is only the basic object structure. More work will be needed to set the various resources based on connectivity. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:13:00 -07:00
config LWM2M_CONN_MON_BEARER_MAX
int "Maximum # of available network bearer resource instances"
depends on LWM2M_CONN_MON_OBJ_SUPPORT
default 1
help
This value sets the maximum number of available network bearer
resource instances. These are displayed via the
"Connection Monitoring" object /4/0/1.
config LWM2M_CONN_MON_APN_MAX
int "Maximum # of APN resource instances"
depends on LWM2M_CONN_MON_OBJ_SUPPORT
default 1
help
This value sets the maximum number of APN resource instances.
These are displayed via the "Connection Monitoring" object /4/0/7.
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)
net: lwm2m: separate FW update object instances - /5/* This is a proof-of-concept implementation. A device might have multiple firmware images which needs to be updated separately. For example a single device might have * A bootloader image * An application image * External firmware image Instead of pushing all these updates through the object instance 0 - /5/0 - here a split to multiple has been made possible. Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
2021-06-15 16:05:56 +03:00
config LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT_MULTIPLE
bool "Support multiple firmware update objects [EXPERIMENTAL]"
depends on LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT
select EXPERIMENTAL
help
Support multiple instances of LWM2M Firwmare Update Object (ID 5)
config LWM2M_FIRMWARE_UPDATE_OBJ_INSTANCE_COUNT
int "Maximum # of LWM2M Firmware update object instances"
default 1
depends on LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT_MULTIPLE
help
This setting establishes the total count of LWM2M Firmware update
object instances available to the 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_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 object 9 software management Adds support for LWM2M object 9 Software management. This is implemented according to this release: http://openmobilealliance.org/release/LWM2M_SWMGMT/V1_0_1-20200616-A/ Note that the XML is lacking some resources and for that reason those resources are not included. This is a known problem by OMA and will be fixed in a later releases. This uses the lwm2m_pull_context to pull binaries in case FIRMWARE_PULL_SUPPORT is enabled Signed-off-by: Michal Ciesielski <michal.m.ciesielski@voiapp.io>
2021-12-09 11:13:49 +01:00
config LWM2M_SWMGMT_OBJ_SUPPORT
bool "Software management object support"
help
Include support for LWM2M Software Management Object (ID 9)
config LWM2M_SWMGMT_MAX_INSTANCE_COUNT
int "Maximum # of object instances"
depends on LWM2M_SWMGMT_OBJ_SUPPORT
default 1
config LWM2M_SWMGMT_PACKAGE_NAME_LEN
int "Maximum size of the software management object's name string"
depends on LWM2M_SWMGMT_OBJ_SUPPORT
default 64
config LWM2M_SWMGMT_PACKAGE_VERSION_LEN
int "Maximum size of the software management object's version string"
depends on LWM2M_SWMGMT_OBJ_SUPPORT
default 64
config LWM2M_SWMGMT_PACKAGE_URI_LEN
int "Maximum size of the software management object's download URI string"
depends on (LWM2M_SWMGMT_OBJ_SUPPORT || LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT)
default 128
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.
config LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_ADDR
string "CoAP proxy network address"
kconfig: Replace some single-symbol 'if's with 'depends on' I think people might be reading differences into 'if' and 'depends on' that aren't there, like maybe 'if' being needed to "hide" a symbol, while 'depends on' just adds a dependency. There are no differences between 'if' and 'depends on'. 'if' is just a shorthand for 'depends on'. They work the same when it comes to creating implicit menus too. The way symbols get "hidden" is through their dependencies not being satisfied ('if'/'depends on' get copied up as a dependency on the prompt). Since 'if' and 'depends on' are the same, an 'if' with just a single symbol in it can be replaced with a 'depends on'. IMO, it's best to avoid 'if' there as a style choice too, because it confuses people into thinking there's deep Kconfig magic going on that requires 'if'. Going for 'depends on' can also remove some nested 'if's, which generates nicer symbol information and docs, because nested 'if's really are so simple/dumb that they just add the dependencies from both 'if's to all symbols within. Replace a bunch of single-symbol 'if's with 'depends on' to despam the Kconfig files a bit and make it clearer how things work. Also do some other minor related dependency refactoring. The replacement isn't complete. Will fix up the rest later. Splitting it a bit to make it more manageable. (Everything above is true for choices, menus, and comments as well.) Detected by tweaking the Kconfiglib parsing code. It's impossible to detect after parsing, because 'if' turns into 'depends on'. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 03:45:50 +01:00
depends on LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT
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
help
Network address of the CoAP proxy server.
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: Fix ExtDevInfo field in Device object The field used incorrect type (s32 instead of ObjLnk) and was not initialized properly. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2020-05-21 12:33:03 +02:00
config LWM2M_DEVICE_EXT_DEV_INFO_MAX
int "Maximum # of device obj external device info to store"
default 5
range 1 20
help
This value sets the maximum number of external device info 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 Location object support This core LwM2M object provides a range of location telemetry related information. Signed-off-by: Michael Scott <mike@foundries.io>
2019-07-29 10:14:00 -07:00
config LWM2M_LOCATION_OBJ_SUPPORT
bool "Location object support"
help
Include support for LWM2M Location Object (ID 6)
net: lwm2m: Add LwM2M gateway object Add support for the gateway object [EXPERIMENTAL] used by the MG100, BT510, and BT610 LwM2M demo. Signed-off-by: Andrew Hedin <andrew.hedin@lairdconnect.com>
2021-10-06 08:47:06 -05:00
config LWM2M_GATEWAY_OBJ_SUPPORT
bool "Enable LwM2M Gateway Object (25) [EXPERIMENTAL]"
if LWM2M_GATEWAY_OBJ_SUPPORT
config LWM2M_GATEWAY_MAX_INSTANCES
int "Maximum number of bridged devices"
default 1
help
This setting establishes the total count of LwM2M Gateway
instances available to the LWM2M client.
config LWM2M_GATEWAY_DEFAULT_DEVICE_ID
string "Identifies the IoT Device bridged to the LwM2M Gateway"
default "Node"
config LWM2M_GATEWAY_DEVICE_ID_MAX_STR_SIZE
int "Maximum string size for device ID"
default 32
config LWM2M_GATEWAY_DEFAULT_DEVICE_PREFIX
string "Used for access to LwM2M Objects of this IoT Device"
default "n"
help
Defaults are n0, n1, n2, ..., n<max instances - 1>
config LWM2M_GATEWAY_PREFIX_MAX_STR_SIZE
int "Max string size for prefix"
default 32
config LWM2M_GATEWAY_DEFAULT_IOT_DEVICE_OBJECTS
string "Contains the Objects and Object Instances exposed by Gateway"
default ""
help
It uses the same CoreLnk format as Registration Interface.
This must be populated by Gateway.
Example:
</3>;ver=1.0,</3/0>,</4>;ver=1.0,</4/0>,
</5>;ver=1.0,</5/0>,</9>;ver=1.0,</9/0>,</3303/0>
config LWM2M_GATEWAY_IOT_DEVICE_OBJECTS_MAX_STR_SIZE
int "Maximum string size for IoT device objects"
default 128
endif # LWM2M_GATEWAY_OBJ_SUPPORT
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: add uCIFI Battery object (3411) Add the uCIFI Battery object to support monitoring a devices battery. Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
2022-01-13 09:49:37 -06:00
menu "uCIFI Alliance Object Support"
source "subsys/net/lib/lwm2m/Kconfig.ucifi"
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