mqtt: subscribing to a topic could subscribe to the corresponding Context Entity

[marcc-orange]

It would be useful if it was possible to subscribe from a device to a MQTT topic for any Context Entity available on Orion CB (or at least to attributes of the entity associated to the provisioned device) ?

• Device subscribes to a topic TOKEN/device_id/attribute_name.
• IoTAgentCpluplus reacts by subscribing to Orion for device_id / attribute_name using a subscribeContext request.
• Orion notifies IoTAgentCpluplus on updates to attribute_name by using a notifyContext.
• IoTAgentCpluplus publishes the update back to the device using the TOKEN/device_id/attribute_name topic.

In the preparation of a hackathon, we currently have a usecase requiring this feature. Do you think it is relevant ?

[dadivx]

Thanks for your feedback. We think it's interesting so we have included it in our backlog (but with low priority as of now). The only thing that looks challenging it's how to detect that a device is subscribed to a particular topic (as devices and IoTAgent subscribe to the MQTT broker). In the meantime, we already covered the scenario where devices receive messages from ContextBroker. It works slightly different to your proposal, as we call them "commands". So devices must subscribe to an already known topic (including /cmd/ in between) and that "topic" that is the command must be provisioned in the API. We have documented this here: https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus/blob/develop/doc/commands.md and here (the particular case of MQTT): https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus/blob/develop/doc/MQTT_protocol.md#8-commands

[marcc-orange]

Yes I am aware of the commands (and are already using them!). But the commands are a dedicated mechanism (transmitting commands to device, sending back ack to broker).

The IoTAgent would not have to monitor if a device has subscribed or not. It could just subscribe to Orion for given Context Entities (defined during provisioning) and publish on the corresponding topic to MQTT broker. Configuration of a device could take a special subscriptions (I let you find a better name) like this:

{
  "devices": [
    {
      "device_id": "myEdison",
      "entity_name": "myEdison",
      "entity_type": "edison",
      "protocol": "PDI-IoTA-MQTT-UltraLight",
      "attributes": [
        {
          "object_id": "l",
          "name": "lux",
          "type": "string"
        },
        {
          "object_id": "p",
          "name": "button",
          "type": "string"
        }
      ],
      "commands": [
        {
          "name": "SET",
          "type": "command",
          "value": "myEdison@ledr|%s"
        }
      ],
      "subscriptions": [
        {
          "name": "lora_position",
          "type": "geo:point"
        },
        {
          "name": "lora_mode",
          "type": "string"
        }
      ]
    }
  ]
}

This would allow a device to subscribe to topics TOKEN/myEdison/lora_mode and TOKEN/myEdison/lora_position.

[marcc-orange]

To more points :

• commands are using the forward mechanism (the IoTAgent "owns" the Context Entity it has registered to CB)
• the subscriptions mechanism I propose use the NGSI sub/notify flow which allows to subscribe to Context Entity not managed/registered by the IoTAgent.

This leads me to think my proposed format above is missing a way to indicate we want to subscribe to attributes of other entities, like having optional id/idPattern fields :

      "subscriptions": [
        {
          "id": "Lora1",
          "type": "Lora",
          "attributes": [ "position" ]
        },
        {
          "idPattern": "Lora.*",
          "type": "Lora",
          "attributes": ["mode"]
        }
      ]

would let the device register to /TOKEN/Lora1/position and to /TOKEN/Lora.*/mode.

A last point, I feel the proposed modification is not the "NGSI way" of doing things: Usualy, NGSI components do not specify their relations by configuration (look at how STH interacts with Orion: its the responsibility of the third party app to subscribe STH to Orion not STH itself). Maybe IoTAgent could just support a /{device_id}/notifyContext endpoint and propagate the content of the notify payload to the topics corresponding to the updated context entities/attributes.