search

telefonicaid / lightweightm2m-iotagent

IoT Agent accepting COAP requests. Designed to be a bridge between the OMA Lightweight M2M protocol and the NGSI interface.
https://fiware-iotagent-lwm2m.rtfd.io/
GNU Affero General Public License v3.0
24 stars 31 forks source link

Attribute name collision #66

Open mamonetti opened 8 years ago

mamonetti commented 8 years ago

In order to support some devices I need, I've registered a new ObjectID in LWM2M, which is available here: http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry (urn:oma:lwm2m:x:10242 3-PhasePM)

First of all, if I run the downloadOmaRegistry.js process I can get this ObjectID in the omaRegistry.json file. However, there are no attributes, even though the DDF file is available in this website. Apparently it has to do with the parsing method used to download the .xml files, because for X-ObjectID (Objects defined by vendors or individuals) there is an extra column named "Company", which makes the script think that the .xml file is not available, while in this case it is.

Second, there is a problem with omaInverseRegistry.json. Each element of this file is related to the name of an attribute, and in case two DDF files have an attribute in common one of them disappears. In this case /10242/x/0 is named "Manufacturer", exactly as /3/0/0. So, take a look at this output:

time=2016-03-23T11:39:55.180Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.ContextServer | msg=Handling received set of attributes: ["Manufacturer","Model Number","Serial Number","Description","Tension R","Current R","Active Power R","Reactive Power R","Inductive Reactive Power R","Capacitive Reactive Power R","Apparent Power R","Power Factor R","THD-V R","THD-A R","Tension S","Current S","Active Power S","Reactive Power S","Inductive Reactive Power S","Capacitive Reactive Power S","Apparent Power S","Power Factor S","THD-V S","THD-A S","Tension T","Current T","Active Power T","Reactive Power T","Inductive Reactive Power T","Capacitive Reactive Power T","Apparent Power T","Power Factor T","THD-V T","THD-A T","3-Phase Active Power","3-Phase Reactive Power","3-Phase Inductive Reactive Power","3-Phase Capacitive Reactive Power","3-Phase Apparent Power","3-Phase Power Factor","3-Phase phi cosine","Active Energy","Reactive Energy","Inductive Reactive Energy","Capacitive Reactive Energy","Apparent Energy","Tension R-S","Tension S-T","Tension T-R","Frequency"] {"op":"IOTAgent.NGSIHandlers","time":"2016-03-23T11:39:55.180Z","lvl":"DEBUG","msg":"Handling device data query from the northbound for device [1234:3-PhasePM] of type [3-PhasePM]"} {"op":"IOTAgent.NGSIHandlers","time":"2016-03-23T11:39:55.180Z","lvl":"DEBUG","msg":"New attributes;\nManufacturer,Model Number,Serial Number,Description,Tension R,Current R,Active Power R,Reactive Power R,Inductive Reactive Power R,Capacitive Reactive Power R,Apparent Power R,Power Factor R,THD-V R,THD-A R,Tension S,Current S,Active Power S,Reactive Power S,Inductive Reactive Power S,Capacitive Reactive Power S,Apparent Power S,Power Factor S,THD-V S,THD-A S,Tension T,Current T,Active Power T,Reactive Power T,Inductive Reactive Power T,Capacitive Reactive Power T,Apparent Power T,Power Factor T,THD-V T,THD-A T,3-Phase Active Power,3-Phase Reactive Power,3-Phase Inductive Reactive Power,3-Phase Capacitive Reactive Power,3-Phase Apparent Power,3-Phase Power Factor,3-Phase phi cosine,Active Energy,Reactive Energy,Inductive Reactive Energy,Capacitive Reactive Energy,Apparent Energy,Tension R-S,Tension S-T,Tension T-R,Frequency"} time=2016-03-23T11:39:55.180Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.MongoDBDeviceRegister | msg=Looking for entity with name [1234:3-PhasePM]. {"time":"2016-03-23T11:39:55.183Z","lvl":"DEBUG","msg":"Selecting ID from the stored device data"} time=2016-03-23T11:39:55.184Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.DeviceManagement | msg=Reading value from resource /3/0/0 in device [1] time=2016-03-23T11:39:55.184Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.DeviceManagement | msg=Reading value from resource /3/0/1 in device [1] time=2016-03-23T11:39:55.184Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.DeviceManagement | msg=Reading value from resource /3/0/2 in device [1] time=2016-03-23T11:39:55.184Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.ContextServer | msg=There was an error handling the query: [object Object]. time=2016-03-23T11:39:55.185Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NorthboundServer | msg=Error [OMA_MAPPING_NOT_FOUND] handing request: No OMA to NGSI Mapping found for this device or type

To summarize, I'm trying to register a 3-PhasePM (ObjectID 10242) with endPoint = 1234, and it receives a request for /3/0/0 (Device:Manufacturer), /3/0/1 (Device:Model Number) and /3/0/2 (Serial Number), which don't exist, as expected.

In case you intend to guarantee each attribute to be unique, you'll probably have to use a pair "Type:Attribute" in the file omaInverRegistry.json, because otherwise sooner or later you're bound to find the same attribute name in different types (or any similar syntax, as long as it guarantees the uniqueness). For this example you should have "Device:Manufacturer" and "3-PhasePM:Manufacturer" as different names.

dmoranj commented 8 years ago

Completely right; this is a bug in the implementation. We'll have to slightly change how the mapping works to overcome that issue.

mamonetti commented 8 years ago

Actually this would solve another problem I detected with this configuration, which can be seen here: time=2016-03-23T11:39:55.186Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.DeviceManagement | msg=Reading value from resource /3318/null/0 in device [1]

In this case there is a resource named "Frequency", exactly the same name as another ObjectID (3318 as you can see), so this is a collision between a type and an attribute. Fortunately using a name based on the pair "Type:Attribute" would avoid this as well.