FIWARE Orion: servicePath of a subscription

Question

I'm trying to create a subscription to inform me on the change of some sensors values.

curl broker.waziup.io/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service:watersense' --header 'Fiware-ServicePath:/#' -d @- <<EOF
{
  "description": "Send XXX when YYY",
  "subject": {
    "entities": [
      {
        "id": "WS_UPPA_Sensor2",
        "type": "SensingDevice"
      }
    ],
    "condition": {
      "attrs": [
        "SM1"
      ],
      "expression": {
        "q": "SM1>400"
      }
    }
  },
  "notification": {
    "httpCustom": {
      "url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
      "headers": {
        "Content-type": "application/json",
        "Authorization": "Basic XXX"
      },
      "method": "POST",
      "payload": "{ %22src%22: %2200393806412092%22, %22dst%22: %2200393806412093%22, %22text%22: %22WaterSense: Field is too dry. \${id} humidity value is \${SM1} %22}"
    },
    "attrs": [
      "SM1"
    ]
  },
  "expires": "2040-05-24T20:00:00.000Z",
  "throttling": 1
}
EOF

First question, what is the use of ServicePath in subscriptions? It seems that it is used when retrieving the entities related to that subscription. So /# is valid. Is it correct (I don't find it in the docs)?

Secondly, say you want to create a subscription based on the values of several entities attributes. If those entities attributes have the same name (it's often the case), how do you reference them? Can you do something like:

"q": "Sensor1.SM1>100, Sensor2.SM1>100"

And something similar for the payload?

Answer 1

Regarding first question, using Fiware-Service: /# means that the subscription covers entities in any service path. In other words, any entity (no matter its service path within the service) would potentially trigger the subscription (as long as other conditions, such as entity id/type, attributes, filters, etc. match, of course).

Regarding second question, take into account that a given subscription is triggered by an update on a single entity. In other words, Orion recieves an update on a given entity and, if it match the conditions of the subscription, the subscription is triggered and a notification containing that entity is sent. Thus, the q filter refers always to the entity being updated (and in somecases notified, if the q filter and other conditions are met).

The role of the subject.entities field is to define the subset of entities to which the subscription refer. For instance, you could use { "idPattern": ".*", "type": "TempMeter" } to refer to all entities of type TempMeter. However, if Orion gets an update for entity id Meter1 of type TempMeter then the q filter refers only to that entity.

With regards to operations that "pack" several entity updates in one (e.g. POST /v2/update) they are decomposed in several single-entity updates, to which the above rules apply.

Exception: the initical notification sent at subscription creation time will include all the entities covered by subject.entities. However, this is a very special case (closer to the syncrhonous query operation than to the regular subscription behaviour) so it is not very meaningful. In this case the q filter adds to the set covered by subjects.entities in order to select which entities will be included in the initial notification.