EdgeX in Action, Part 2: Provisioning

This is the second article in series “EdgeX in Action”, and in this article we will cover system provisioning — configuration of the system in order to make it ready for device management and IoT messaging.

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 first article, “EdgeX in Action, Part 1: Installation”, we have covered the system installation and initial set-up. If you have followed these easy steps, that means that you have EdgeX system up and running.

Now we can move to the next phase — system provisioning. What is provisioning exactly?

In order to configure the system and prepare it for usage, we need to perform a series of tasks and tell to the system how we want to use it. EdgeX is an IoT platform for the edge that can cover a big number of use-cases. As a system architects and developers of the vertical IoT application that uses EdgeX platform as a middleware, we must allocate and describe our specific use-case so that EdgeX know how and where to route the messages and connections.

This initial configuration of the system is called “provisioning”, and is a common procedure in telecom systems. As an other example of provisioning procedure for IoT system, you can take a look at Mainflux System Provisioning.

Update: To get an overview of EdgeX provisioning process you can take a look at training video.

EdgeX provisioning is not very simple, as EdgeX is very powerful system that tries to be very generic. This means that there is lot of things to be configured. A procedure of this configuration is explained in details in EdgeX official documentation, under the chapter “EdgeX Demonstration API Walk Through”.

However, in order to make this process easy (as a Sunday morning), I have created a (not so) small script:

As you can see — this script sends a bunch of HTTP requests to certain configuration REST endpoints of the EdgeX system services. Requests are sent to several services that need to be configured: core_metadata, core_command, core_data and export_registration.

Just download the script and make it executable:

chmod +x edgex_provision.sh

But before executing the script you will need to download one more file that this script uses — camera_monitor_profile.yml that can be found here alongside with explanations, but I pasted it as a gist for easier inspection:

Now that you have both files one next to other in the same directory, and that edgex_provision.sh is an executable, we can provision the system just by executing this script:

./edgex_provision.sh

Of course, for this you must have EdgeX system up and running, ready to accept HTTP requests for configuration that will be sent from our provisioning script.

Let’s now check if everything went fine. But before we start sending HTTP requests to EdgeX services, obtain jsonpp tool for nice JSON formatting on the command line:

curl -s -L http://t.co/tYTq5Pu | jsonpp

To see if Value Descriptors were configured properly, execute:

curl http://localhost:48080/api/v1/valuedescriptor | jsonpp

To check Device Service provisioning:

curl http://localhost:48081/api/v1/deviceservice | jsonpp

To check Device provisioning:

curl http://localhost:48081/api/v1/device

And so on, and so on. You will find more examples in the official EdgeX documentation.

It’s important to notice that EdgeX REST API can be inspected via RAML files in the official egdex-go repo. There you will find how to do standard CRUD operations and for example DELETE some of the provisioned entities by id or by name (previously you can execute GET on this REST endpoint to find the id of a particular entry you want to delete). Note that these RAML files can be imported directly into the Postman (if you are GUI kind of person).

Great — now you have EdgeX system provisioned and ready to accept commands and events from various devices connected to it. Now what?

Next step will be to send some commands and events to our provisioned EdgeX system. We’ll do this in the next part of this series, “EdgeX in Action, Part 3: Sending Commands and Events”. Stay tuned.

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!