Commit Graph

2 Commits

Author SHA1 Message Date
Michael Scott aef5ee4582 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-08-09 10:55:53 +03:00
Michael Scott c46c206f8c 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-08-09 10:55:53 +03:00