lightweightm2m-iotagent

lightweightm2m-iotagent copied to clipboard

First of all, I'd like to point that this issue is directly connected with issue #14, although my idea is to focus on a few specific aspects.

Let's say you have a device which provides several instances of multiple types. Something like this (2x3-PhasePM): </10242/0>,</10242/1>

In case you wanted to set all the attributes as active for all the instances, you should have to define multiple types (something like 3-PhasePM-0 for instance 0 and 3-PhasePM-1 for instance 1) in the config file, because each attribute in the "lwm2mResourceMapping" section is directly linked to a specific instance (that is, you have to set the "objectInstance" field), otherwise it won't send the observe requests. A way to solve this could be to establish the instance number dynamically, depending on the instances of this type that have been registered, without being forced to set it in the mapping.

Yes, you're right about the instances, it doesn't have a lot of sense to make that mapping static. I'll try to figure out the best way to change this, and I'll try to find time to implement it (I'm really busy lately, but I need to take some time to clean bugs in the LWM2M implementations). I'll flag this as a bug as it seems to be the proper way to go.

Linking it back with issue #14, and regarding the point of setting all attributes as passive by default, this is a good moment to rethink the format of the config file.

In order to reconfigure all the attributes as active I had to set all the configuration of this type (10242, with 51 attributes) manually, therefore ignoring the DDF file. Actually I had to remove all the references to 10242 in the omaRegistry.json file so as to avoid conflicts.

Personally I don't see that reasonable, as it is forcing you to ignore the DDF "standard" files. My suggestion is to allow the config file to "tweak" an existing type definition, overwriting only the config parameters set in the file, but continue using those loaded from the DDF file. To be more specific:

• If there is a DDF file you'll have the set of attributes in omaRegistry.json, set as passive by default.
• If after loading it you find the same type in the config file, overwrite only the fields set in this file, which could include only a subset of the parameters.

So, take a look at this: types: { '3-PhasePM': { "service": "service", "subservice": "subservice", "active": [ { "name": "Manufacturer", "type": "String", "operations": "R" }, { "name": "Model Number", "type": "String", "operations": "R" } } }

If omaRegistry.json provides the whole set of attributes of this type and you wanted to establish the values for "service", "subservice" and configure only 2 attributes as "active", you could do it this way. Once this is a well-know type (according to omaRegistry.jon) the agent knows about the 51 attributes as well as their ResourceIDs, and just needs to change a few of them (change from passive to active).