EdgeX in Action, Part 4: Exporting Messages to Cloud

This is the forth article in series “EdgeX in Action”, and in this article we will see how to export messages from IoT edge gateway to the remote server in the cloud.

We at Mainflux are building one of the world’s first EdgeX-compliant IoT gateways called MFX-1. Our vision is producing end-to-end open-source IoT system — from the edge to the cloud — where fleets of MFX-1 EdgeX gateways are connected to Mainflux IoT cloud and managed via web applications.

In the previous article, “EdgeX in Action, Part 3: Sending Commands and Events”, we have took a examined how gateway talks to devices (south interface). In this article we’ll see how it talks to the cloud (north interface).

In order to send messages to the cloud, EdgeX Foundry system uses Export Services — a set of services living on the top of the EdgeX stack that is used to send data to remote servers via HTTP or MQTT protocol. You can learn more about Export services from project’s official documentation.

Main actors in Export Services layer are Export Registration and Export Distribution microservices.

Export Registration is simple — it provides an API for the user to input the data that are needed for sending messages to the cloud — like to which MQTT topic to shoot the data or which credentials to use for access. Export Distribution service will later use this data.

Export Distribution has another role: to push the data to the cloud, either by issuing HTTP POST or MQTT PUB. It gets the necessary metadata (which topic/URL, which API key, TLS or not, etc.) from Export Registration. In order to to increase performance, Export Data keeps it’s own cache of this information which is updated by events coming from Export Registration.

Registering Export Client

In order to configure (provision) the system for exporting messages, we must talk to Export Registration via API it exposes and register an export client:

As you can see, in this example we are telling Export Services to publish messages using MQTT protocol, to MQTT test server on the standard 1883 port and on the topic edgex/data.

Let’s see if this went well by querying Export Registration service:

drasko@Marx:~$ curl -sS http://localhost:48071/api/v1/registration | jsonpp 
[
  {
    "id": "5b8af59d6b950a5e3ff92ea5",
    "created": 1535833501733,
    "modified": 0,
    "origin": 0,
    "name": "myMqttPublisher",
    "addressable": {
      "created": 0,
      "modified": 0,
      "origin": 0,
      "id": null,
      "name": "myMqttBroker",
      "protocol": "tcp",
      "method": null,
      "address": "test.mosquitto.org",
      "port": 1883,
      "path": null,
      "publisher": "EdgeXExportPublisher",
      "user": null,
      "password": null,
      "topic": "edgex/data",
      "baseURL": "tcp://test.mosquitto.org:1883",
      "url": "tcp://test.mosquitto.org:1883"
    },
    "format": "JSON",
    "filter": {},
    "encryption": {
      "encryptionAlgorithm": "NONE"
    },
    "compression": "NONE",
    "enable": true,
    "destination": "MQTT_TOPIC"
  }
]

Now we are ready to test the set-up.

Testing Message Publishing

As we saw in the previous post, Events are sent by issuing POST on http://loclahost:48080/api/v1/event. But before issuing these events let’s subscribe to test.mosquitto.org on the topic export/data:

drasko@Marx:~$ mosquitto_sub -h test.mosquitto.org -t export/data

Now, let’s try shooting some events from EdgeX running on local PC:

You should see messages coming to your subscribed MQTT client, something like this:

drasko@Marx:~$ mosquitto_sub -h test.mosquitto.org -t edgex/data
{"id":"5b9312386b950a6f6edd5d04","pushed":0,"device":"countcamera1","created":1536365112681,"modified":0,"origin":0,"schedule":null,"event":null,"readings":[{"id":"5b9312386b950a6f6edd5d05","pushed":0,"created":1536365112681,"origin":0,"modified":0,"device":"countcamera1","name":"humancount","value":"5"},{"id":"5b9312386b950a6f6edd5d06","pushed":0,"created":1536365112681,"origin":0,"modified":0,"device":"countcamera1","name":"caninecount","value":"3"}]}
{"id":"5b93123c6b950a6f6edd5d07","pushed":0,"device":"countcamera1","created":1536365116372,"modified":0,"origin":1471806386919,"schedule":null,"event":null,"readings":[{"id":"5b93123c6b950a6f6edd5d08","pushed":0,"created":1536365116372,"origin":1471806386919,"modified":0,"device":"countcamera1","name":"humancount","value":"1"},{"id":"5b93123c6b950a6f6edd5d09","pushed":0,"created":1536365116372,"origin":1471806386919,"modified":0,"device":"countcamera1","name":"caninecount","value":"0"}]}

That’s it. Easy, isn’t it?

Now that we saw how to send messages from devices, though the EdgeX IoT gateway all the way to the remote MQTT server in the cloud and then to our application on the top of this cloud (mosquitto_sub in this case), we are ready for creating ultimate end-to-end open-source IoT solution: EdgeX and Mainflux combo — an IoT match made in heaven! And this is what we will cover in the next article, “EdgeX in Action, part 5: Connecting to Mainflux”.

To learn more about Mainflux and how we’re building the world’s most sophisticated open-source Industrial IoT cloud, visit our website and follow us on Twitter!