Prepend MQTT protocol to MQTT topics

[jason-fox]

Related

• Support protocol specific topic (/ul/<apiKey>/<deviceId>) tutorials.IoT-over-MQTT#25
• [WIP] remove support to send mqtt topic to agent without protocol telefonicaid/iotagent-json#633

This can only be merged once JSON and Ultralight IoT Agents have been updated to support the new path.

@mapedraza

[mapedraza]

Support for new path was included here telefonicaid/iotagent-json#374 and here telefonicaid/iotagent-ul#287.

telefonicaid/iotagent-json#633 is for removing the support without the protocol at the beginning.

[jason-fox]

1) Expected MQTT topic for a command

@mapedraza - I'm testing updates to the tutorial test harness, I can now successfully send measures under /ul/<apiKey>/<deviceId>/attrs, but commands are still being sent under <apiKey>/<deviceId>/cmd - if you look at MQTTBinding.js you can see the commandTopic is not prefixed by the protocol ul - is this expected behaviour?

I would expect that an actuator would be listening on the ul/<apiKey>/<deviceId>/cmd topic, not the <apiKey>/<deviceId>/cmd topic.

2) Align entity-type

Secondly am I correct in thinking that I need to align entity_type as shown when provisioning an actuator?

curl -L -X POST 'http://localhost:4041/iot/services' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
--data-raw '{
 "services": [
   {
     "apikey":      "4jggokgpepnvsb2uv4s40d59ov",
     "cbroker":     "http://orion:1026",
     "entity_type": "Bell",
     "resource":    ""
   }
 ]
}'

curl -L -X POST 'http://localhost:4041/iot/devices' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
--data-raw '{
  "devices": [
    {
      "device_id": "bell001",
      "entity_name": "urn:ngsi-ld:Bell:001",
      "entity_type": "Bell",
      "protocol": "PDI-IoTA-UltraLight",
      "transport": "MQTT",
      "commands": [ 
        {
          "name": "ring",
          "type": "command"
        }
       ],
       "static_attributes": [
         {"name":"refStore", "type": "Relationship","value": "urn:ngsi-ld:Store:001"}
    	]
    }
  ]
}'

If the Device's "entity_type": "Bell" doesn't align with an existing service, then the default TEF apiKey is used.

[jason-fox]

telefonicaid/iotagent-ul#400 changes the topics for sensor measuremens, but doesn't alter the location of commands - maybe this has been dealt with in another PR?

[mapedraza]

Hi @jason-fox. Let me give you info about this points

1) Expected MQTT topic for a command

It is true. It is different the topic expected in the case of commands and measures. There are different reasons:

• When sending the data, the device have to explicitly idenfy the agent that process the data. For that reason, it is needed to add the prefix with the protocol, otherwise there is no way to define which agent is processing the measure since multiples agent can be subscribed to the same topic.
• When sending the commands from the agent to the device, you do not need to explicitly defines a specific endpoint to the device since you already configure the protocol and the command in the agent through the device or group provision. The devices always expect the data on their own topics and does not need to be multiplexed. Otherwise, a "standard" "FIWARE Ready" device that is intend to be compatible with multiples protocols, need to be subscribed to as many topics as agents available (UL, JSON, Sigfox, LWM2M, OPC-UA, XML...)

Probably is a bit confusing for the developers and need to be clarified and documentation in the agent need to be improved in that way. That is the reason why it works in that way but feedback and suggestion is welcome.

2) Align entity-type

This part of the code is a bit complex and error-prone due to a not strong relationship between groups and devices when the IoT-Agent was designed and because of giving backward compatibility. In fact, there were some work done in the last week related with this part of the code (telefonicaid/iotagent-node-lib#1211, telefonicaid/iotagent-node-lib#1212, telefonicaid/iotagent-node-lib#1214).

This problematic is well explained in this comment. As a resume, since there is not a strong relationship between the groups and the devices, (i.e. having a groupID parameter both in the config group and in the device), the best way is to add the APIKEY on the device provision with the same value of the APIKEY of the service group "attached".