According to LWM2M specification, when Queue Mode is used, the LWM2M
client should keep the reciever on for specified time after sending A
CoAP message. This commit adds a new LWM2M event,
`LWM2M_RD_CLIENT_EVENT_QUEUE_MODE_RX_OFF`, to facilitate the process by
notifying the application when it's safe to turn the receiver off.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add new RD Client API of lwm2m_rd_client_stop() for this
Fix issues of de-register and event reporting in RD Client
Signed-off-by: Jun Qing Zou <jun.qing.zou@nordicsemi.no>
This Object is used to report the state of a momentary action push
button control and to count the number of times the control has
been operated since the last observation.
Signed-off-by: Michael Scott <mike@foundries.io>
LwM2M allows for multiple instance resources such the power source
resources in the device object. These types of resources have
always been very hard to work with, and frankly were poorly
implemented.
This led to other issues where it was very hard to have
non-sequential resource instances, and each resource of this type
needed special getter / setter methods such as:
lwm2m_device_add_pwrsrc()
lwm2m_device_set_pwrsrc_voltage_mv()
Going forward, as more LwM2M objects are implemented this just
doesn't scale well.
To fix this:
- split the resource instance data out from the resource data.
This includes the data pointer information and resource
instance id.
- add resource id and resource instance id to the event callback
functions so user's can see in more detail what resources and
resource instances are being handled.
- allow generic functions like lwm2m_engine_get_*() and
lwm2m_engine_set_*() to access resource instance data.
- adjust object resource initialization macros to map resource
instances to resources at the time of object instance
creation.
- fix up the lwm2m_client as a reflection of all of these changes.
Signed-off-by: Michael Scott <mike@foundries.io>
- Several of the functions use "path" as the parameter name for the
string-based LwM2M path. Let's clarify by using "pathstr".
- Recent updates to the LwM2M engine now support resource instances
when parsing the LwM2M path. Let's update descriptions accordingly.
Signed-off-by: Michael Scott <mike@foundries.io>
Current implementation of LwM2M engine doesn't allow users a way
of overriding TLS credential load with custom function. This
would be needed by an offloaded TLS stack where we don't want
to use standard Zephyr functions.
Let's add a load_credential function pointer to the LwM2M client
context which will be called when it's available.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17408
Signed-off-by: Michael Scott <mike@foundries.io>
The LwM2M public APIs were never well documented. Let's fix
that by adding the needed information to include/net/lwm2m.h
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/12958
Signed-off-by: Michael Scott <mike@foundries.io>
Initial implementation of IPSO Timer object #3340
Based on: http://www.openmobilealliance.org/tech/profiles/lwm2m/3340.xml
"This IPSO object is used to time events and actions, using patterns
common to industrial timers. A POST to the trigger resource or On/Off
input state change starts the timing operation, and the timer
remaining time shows zero when the operation is complete. The
patterns supported are One-Shot (mode 1), On-Time or Interval
(mode 2), Time delay on pick-up or TDPU (tmode 3), and Time Delay
on Drop-Out or TDDO (mode 4). Mode 0 disables the timer, so the output
follows the input with no delay. A counter is provided to count
occurrences of the timer output changing from 0 to 1. Writing a value
of zero resets the counter. The Digital Input State resource reports
the state of the timer output."
NOTE: Only One-Shot Mode (mode 1) is implemented in this patch.
Signed-off-by: Michael Scott <mike@foundries.io>
During the initial work on LwM2M, the float32/64 code was
basically stubbed out. Float32 sent only whole values and
float64 was completely broken.
Let's clean up the OMA TLV formatting code by moving the float
processing code into a separate file: lwm2m_util.c.
Then using public definitions for binary32 and binary64, let's
fix the processing code to correctly fill the float32_value_t
and float64_value_t types.
Signed-off-by: Michael Scott <mike@foundries.io>
As we are removing net_app and net_pkt based libraries and
applications, CoAP legacy based libraries and apps are moved
to socket based implementations. So removing legacy CoAP.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
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>
In order to support bootstrap mode, we need to store server data
in the security / server objects. Once the connection to the
bootstrap server is made, it will clear these objects and add
new server connection data.
Signed-off-by: Michael Scott <mike@foundries.io>
net_app contexts save the remote address and we use this during
observe notifications and pending handling. If we move to another
network layer such as sockets, then the remote address becomes
harder to reference. Let's save it as a part of the client
context.
Signed-off-by: Michael Scott <mike@foundries.io>
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>
CONFIG_NET_CONTEXT_NET_PKT_POOL is used by Zephyr's TCP stack as
a way of keeping the original packet data when compression and
other l2 specific actions make the data unusable for retries.
LwM2M uses UDP and this option was never used.
Signed-off-by: Michael Scott <mike@foundries.io>
Any word started with underscore followed by and uppercase letter or a
second underscore is a reserved word according with C99.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Due to a change in the company name, the LwM2M copyrights need
to be changed from "Open Source Foundries Limited" ->
"Foundries.io".
Signed-off-by: Michael Scott <mike@foundries.io>
LwM2M engine now supports optional resources that may need to be
setup or torn down in user-based code during object instance
creation / deletion.
Let's provide callbacks that can be used for this purpose.
Signed-off-by: Michael Scott <mike@foundries.io>
Let's rename lwm2m_engine_exec_cb_t to lwm2m_engine_user_cb_t so that
future user-code callbacks can make use of the same definition.
Signed-off-by: Michael Scott <mike@foundries.io>
This patch introduces several changes to support OPTIONAL resources.
The primary indicator for this behavior is to assign FLAG_OPTIONAL
to the object field's permission flags.
These resources are not setup by the LwM2M object code. They are
left up to the user-based code for initialization via the following
functions:
lwm2m_engine_set_res_data()
lwm2m_engine_get_res_data()
When assigning const-based data as a data buffer, user-based code can
also specify the following data flag: LWM2M_RES_DATA_FLAG_RO
The FLAG_OPTIONAL flag also affects the LwM2M engine in the following
ways:
- CREATE operations won't generate an error if optional resources are
not included.
- Object instance READ operations won't complain about missing
optional resources.
- In the future, BOOTSTRAP operations can have different handling
based on optional resources.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
In the future, we will have optional resources that may or may
not be assigned a buffer for data storage. When these resources
are queried we need to be able to return an error code if the
buffer isn't set.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
- Add needed settings for DTLS support to the lwm2m_ctx structure.
- Add initialization of MBEDTLS to the LwM2M lib based on the
user application settings in lwm2m_ctx.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Previously, post_write and execute callbacks returned 1 when handled
and 0 for error condition. However, this wasn't detailed enough and
the engine can't propagate any sort of error back to users -- so it
doesn't even check the return values in many cases!
Let's adjust the resource callback functions of all objects and the
lwm2m_client sample to return 0 for success or a valid error code.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
With the change to support multi-fragement buffers in the LwM2M subsys,
the OPAQUE data type was direct write methods were broken.
Let's fix OPAQUE handling by using the newly introduced getter methods
which can use multiple user callbacks (depending on the size of the
user provided buffer). Let's also add public methods for users to set
/ get OPAQUE data in resources for future use with DTLS key data.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This patch moves from the ZoAP API in subsys/net/lib/zoap to
the CoAP API in subsys/net/lib/coap which handles multiple
fragments for sending / receiving data.
NOTE: This patch moves the LwM2M library over to the CoAP APIs
but there will be a follow-up patch which re-writes the content
formatter reader / writers to use net_pkt APIs for parsing
across multiple net buffers. The current implementation assumes
all of the data will land in 1 buffer.
Samples using the library still need a fairly large NET_BUF_DATA_SIZE
setting. (Example: CONFIG_NET_BUF_DATA_SIZE=384)
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Applications may want to be notified when various events
happen in the LwM2M rd client. Let's implement an event
callback which sends: connect, disconnect and update events.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
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>
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>
This is the final stage of moving the LwM2M library internals to
the net_app APIs. This means we can support DTLS and other
built-in features in the future. All of the logic for
establishing the network connection is removed from the sample
app.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This allows use to associate easily the replies / pending operations
with a specific network connection.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
The LwM2M library does not use net_app APIs internally. To help
this effort let's establish a user facing structure "lwm2m_ctx"
(similar to http_client_ctx and mqtt_ctx) and start it off by
wrappering the net_context structure.
Future patches will add user setup options to this structure and
eventually remove the net_context structure in favor of a net_app_ctx.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
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>
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>
