Some of the objects redefined reusable resources IDs, while others used
a common header which defines resource IDs. Unify the approach and use
the header in every object.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
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>
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>
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>
We are pre-allocating a storage variable for the application type
resource in the IPSO Timer object. This is an optional resource
which won't always be set by samples.
Let's leave out the pre-allocated variable and let the sample set
this reference if needed (it's optional).
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>
