Each object now have to specify the object version it implements.
Based on this information the LwM2M engine can decide whether it's
needed to report the object version during Registration/Discovery
operations or not.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
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>
Multi-instance resources shall report its dimension (number of
resource instances) on discovery. Since it was not possible to tell
simply on the instance count whether the resource is multi-instance or
not (there could be a multi-instance resource with only one instance
avaialble) add a new parameter to the structure representing resource,
indicating whether it's multi-instance or not.
Add dimension information to the discovery result.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
A dedicated LwM2M execute callback type has been implemented which
supports execute arguments. The lwm2m engine, lwm2m_client sample and
lwm2m objects have been updated accordingly. Also the API change has
been documented, and the lwm2m engine reference has been updated.
Fixes#30551.
Signed-off-by: Maik Vermeulen <maik.vermeulen@innotractor.com>
According to LwM2M specfication v1.0.2, par. 5.3.2, the LwM2M client
MUST send an “Update” operation to the LwM2M Server whenever the
lifetime parameter of the Server object changes the server). The same
applies for the object instances created/deleted. The changes in objects
seem to already be handled, but the lifetime was not.
Additionally, the "Update" message shall only contain these parameters
which changed since the last update (including objects). As it's
straightforward to determine if the liftime changed but it's not easy
to tell if there were updates in the object instances, add an
additional parameter to the engine_trigger_update() function, indicating
that new object information shall be sent in the "Update" message.
Eventually add a proper error checking in `sm_send_registration` as the
function is reworked anyway.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
A proper way to match a Security object instance with a Server object
instance is via Short Server ID resource. Both coupled object instances
should carry the same value of this resource in order to me considered
matched.
This was not implemented in the LwM2M library and it was incorrectly
assumed that the Security object instance index corresponds to the
Server object instance index. While such apporach works is simple
scenario, it might yield incorrect results when bootstrap is used.
Fix this, by verifyng the Short Server ID resource in the Secuirty
instance used, and finding a matching Server instance. The server object
instance is stored for future use in the engine.
Additionally, remove an extra Server object instance that was created
when the bootstrap procedure was used. Since the boostrap Security
object instance does not have the corresponding Server object, it's
enough to have a single Server instance.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This should be boolean according to specification. It makes difference
when JSON encoding is used.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
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>
Several problems with memset usage in the LwM2M subsystem were
identified:
- Every single object that can have multiple instances is using
memset to initialize static resource data during init. This data
will already be set to 0 because it is static, so the memset
statements are unneeded.
- Instead of using memset during object init which is only called
one time during kernel startup, let's add a memset to the
object create function to ensure the resource data is cleared out.
It could have been used prior and then released via a DELETE op.
- the IPSO Timer object was setting a lot of data structure members
to 0 in the create function. Let's do 1 memset on the entire
structure and then only the non-zero values afterward.
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>
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>
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>
The return of memset is never checked. This patch explicitly ignore
the return to avoid MISRA-C violations.
The only directory excluded directory was ext/* since it contains
only imported code.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The ARRAY_SIZE() utility macro will actually test the parameter types,
and ensure that it is only called with arrays, and not arrays decayed
to pointers.
Changes were performed with a simple Coccinelle script.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Using OMA Technical Specification LwM2M Enabler 1.0.2 dated
Feb. 9, 2018, let's mark the OPTIONAL resources for an LwM2M
Server object (Section E.1 "LwM2M Object: Server")
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
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>
