Selectively ignore some measures

[fgalan]

Support selective ignore of measures so the IOTA doesn't progress for instance the measure on m when it receives {"n": 044.7, "m": 30}.

[fgalan]

Twin issue in IOTA-UL: telefonicaid/iotagent-ul#372

[chandradeep11]

Hi @fgalan,
Please confirm if there is anyone working on this issue?

[fgalan]

Hi @fgalan,
Please confirm if there is anyone working on this issue?

No, as far as I know. Thanks!

[Madhu-NEC]

Hi @fgalan ,

As per my understanding, the feature development is about when one or more attributes set as ignored then these attributes should not be updated at Context Broker.

Following are the possible cases by which we can implement above feature:
Case 1: Set attributes to be ignored at the time of device registration. The sample payloads for device registration can be:
Approach 1: An ignoredAttrs key is added to ignore the attributes.

"devices": [{
                "device_id": "hhr_device",
                "entity_name": "data_raw",
                "entity_type": "data",
                "protocol":"IoTA-JSON",
                "attributes": [{
                        "object_id": "A",
                        "name": "A",
                        "type": "string"
                },{
                        "object_id": "B",
                        "name": "B",
                        "type": "string"
                },{
                        "object_id": "C",
                        "name": "C",
                        "type": "int"
                }],
		"ignoredAttrs": ["A","C"]
		}]

OR
Approach 2: A flag ignored is added to each attribute to ignore the attribute.

"devices": [{
                "device_id": "hhr_device",
                "entity_name": "data_raw",
                "entity_type": "data",
                "protocol":"IoTA-JSON",
                "attributes": [{
                        "object_id": "A",
                        "name": "A",
                        "type": "string",
			"ignored": "true"
                },{
                        "object_id": "B",
                        "name": "B",
                        "type": "string",
                        "ignored": "false"
                },{
                        "object_id": "C",
                        "name": "C",
                        "type": "int",
			"ignored": "true"
                }]
		}]

Case 2: Set attributes to be ignored while sending measure to the IOTA. The sample payload for sending measure is:

  -d '{
        "A": "a",
	"B": "b",
	"C": "c",
	"ignoredAttrs": ["A","C"]
}'

As per my understanding, Case 1-Approach 1 will be the good approach to solve this.
Please confirm my understanding.

[fgalan]

The current behavior is that any measure sent by the device progresses toward Orion, no matter if it is part of "attributes" field or not ("attributes" field is only used to apply a mapping, a transformation expression, etc.).

I'd suggest to implement this using a flag. For instance, "explicitAttrs": true|false. If true, only the attributes declared in "attributes" will be progressed, the rest will be ignored.

This explicitAttrs flag could be defined at three levels:

• Agent configuration (i.e. config.js and corresponding env var), default setting if explicitAttrs is not defined at cgroup or device provisioning time. Default (i.e. if "explicitAttrs" is omitted in this configuation) should be false (in order to keep backward compatibility).
• "explicitAttrs" field in the JSON payload in POST /iot/services provision operation, overriding the setting at agent level.
• "explicitAttrs" field in the JSON payload in POST /iot/devices provision operation, overriding the setting at service level.

Does it make sense? Please, don't hesitate to ask if you have doubts about this proposal.

[fgalan]

Note that the provisioning API is part of the functionality provided by iotatent-node-lib so maybe this functionality needs modification to that library (and not to the agents code) to be implemented.

[Madhu-NEC]

Hi @fgalan

The current behavior is that any measure sent by the device progresses toward Orion, no matter if it is part of "attributes" field or not ("attributes" field is only used to apply a mapping, a transformation expression, etc.).

As per my understanding, the current behavior is different for 'v1'.
For instance:
Device is provisioned using below request. Only measure c is part of "attributes" field:

Below are the two cases for sending measure if it is not part of "attributes".
Case 1: When ngsiVersion is not set in config.js. The measure is sent using v1 and it gives 404 DEVICE_NOT_FOUND error but attribute c gets updated at Orion as well. Below is the screenshot

Case 2: When ngsiVersion: 'v2' is set in config.js. The measure is sent using v2 and it gives 200 OK and both measures are progressed toward Orion. Below is the screenshot

So, as per above explanation, the feature will be implemented for v2 only.
Please confirm.

[Madhu-NEC]

Hi @fgalan ,
Could you please share your opinion?

[fgalan]

NGSIv1 is a deprecated API so I'd suggest to focus in the NGSIv2 case.

As far as I understand by your test, in NGSIv2 the behaviour

The current behavior is that any measure sent by the device progresses toward Orion, no matter if it is part of "attributes" field or not ("attributes" field is only used to apply a mapping, a transformation expression, etc.).

happens, so my proposal of soultion

I'd suggest to implement this using a flag. For instance, "explicitAttrs": true|false. If true, only the attributes declared in "attributes" will be progressed, the rest will be ignored.

This explicitAttrs flag could be defined at three levels:

• Agent configuration (i.e. config.js and corresponding env var), default setting if explicitAttrs is not defined at cgroup or device provisioning time. Default (i.e. if "explicitAttrs" is omitted in this configuation) should be false (in order to keep backward compatibility).

• "explicitAttrs" field in the JSON payload in POST /iot/services provision operation, overriding the setting at agent level.

• "explicitAttrs" field in the JSON payload in POST /iot/devices provision operation, overriding the setting at service level.

would be applicable.

Does it makes sense to you? Do you agree in implementing that solution?

Please tell me what you think. Thanks!

[fgalan]

By the way, I think this issue has relation with this other: telefonicaid/iotagent-node-lib#654. In particular, this issue seems to correspond to "case 2" of telefonicaid/iotagent-node-lib#654.

[chandradeep11]

@fgalan
Please assign this issue to @Madhu-NEC

Thanks :)

[fgalan]

Done!

[fgalan]

Fixed by PR #458 (and telefonicaid/iotagent-node-lib#873)