Integrate your IoT data in your environments or tap into our mobile statistic big data to count people in geographic regions.

Connect your LoRaWAN, M2M and NBIoT devices to your own or public applications

Ingest data from various sources and transform it using scripting before sending out to your on-prem or in the cloud systems 

Proximus CloudEngine is a data integration hub that accepts incoming data streams from Proximus and non-Proximus sources and connects to your application environment using multiple well-known and widely used communication protocols. Proximus CloudEngine includes a serverless scripting engine to help you process your data flows before they reach your application environment. 

cloe principles

Integrate and process data streams

Integrate data coming from multiple IoT and telco solutions from Proximus with a wide variety of on-premise or cloud-hosted customer environments

Integration flexibility

Using the powerfull EnCoScript, incoming data streams can be transformed, enriched, cleaned or consolidated before sending them to your application environments. For IoT projects, you can use EnCoScript to decode binary payloads, thereby offloading your application servers from this low level task.

Data transformation

CloudEngine script executions that are triggered by a supported Proximus solution (see our [detailled pricing](https://api.enco.io/images/marketing/PricingCloE.pdf "CloudEngine detailed pricing")) are not being charged. By offloading basic data transformation or integration work to CloudEngine, you can optimize your total cost of ownership.

Optimize your costs

CloudEngine allows you to

Sign up on the Trial plan and process up to 1500 script executions per day, or select the Premium Plan for unlimited usage.

Create simple data handling flows using the Visual Mode, ideal for incoming JSON data packets that require no transformation. Apply simple filtering rules to decide what and when to send data over to its destination. 

Switch to the CloudEngine scripting mode to handle more complex data structures, develop your own data handling functions or enrich data using REST API queries to external systems.

How it works

IoT equipment was installed on propane tanks and the data was available via tools provided by Proximus.  However, the last step was missing : making this data available to our customers and integrating it into our own applications. Thanks to the API Solutions platform and CloudEngine, the data is now seamlessly integrated on a daily basis. Satisfied customers and, thanks to the optimization of our logistics, a satisfied manager.

Testimonials

Do you need more information, a demo? Would you like us to help you get started, or even develop the complete solution for you? Don’t hesitate to contact us by filling in the form on our [contact us page](https://proximusapi.enco.io/contact-us "Contact us").

More information

Integrating data flows in your applications

In most cases, an IoT Telco operator allows you access the data from your sensors by pushing this data to your application over HTTP. We have seen in previous articles that Proximus CloudEngine makes it possible to benefit from other integration capabilities, ranging from Microsoft Azure and SAP IoT Cloud down to various protocols such as sFTP and mail. To the already existing CloudEngine&#8217;s ability to use its own MQTT client to connect to your MQTT broker, we add now the ability for your MQTT client to connect to the CloudEngine&#8217;s broker.

Using the CloudEngine&#8217;s MQTT Broker simple and straightforward.
<h4>Step 1 &#8211; Define your client&#8217;s credentials</h4>
The first step is to create the credentials for your MQTT client. In the CloudEngine&#8217;s microsite, click on Settings then select &#8220;MQTT&#8221; in the Inbound Endpoint type list. Add a new configuration item and give it a name and password. Be careful and take a note of that password as it won&#8217;t be displayed once the item uis saved.
<figure id="attachment_4500" aria-describedby="caption-attachment-4500" style="width: 598px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-4500 size-full" src="/wp-content/uploads/2019/12/cloemqttsettings.png" alt="" width="598" height="296" srcset="/wp-content/uploads/2019/12/cloemqttsettings.png 598w, /wp-content/uploads/2019/12/cloemqttsettings-300x148.png 300w" sizes="(max-width: 598px) 85vw, 598px" /><figcaption id="caption-attachment-4500" class="wp-caption-text">CloudEngine MQTT settings</figcaption></figure>
<h4>Step 2 &#8211; Integrate our MQTT Broker module in your script</h4>
The second step is to integrate the MQTT Broker outbound module in your CloudEngine visual flow or script. In the creator of the MQTT Broker object, you include the reference to the credentials that we just created in the step above (&#8220;mqttbrotest&#8221; in the example below) and the MQTT topic to which the data will be published (&#8220;lorasensors/pxsmythings&#8221; in the example below). Topics can have several levels if needed, such as &#8220;mytopic/level2/level3&#8243;. You must also specify the <a href="https://stackoverflow.com/questions/33480730/understanding-mqtt-subscriber-qos" target="_blank" rel="noopener noreferrer">MQTT QoS</a> (0 for best effort delivery, 1 for at least one or 2 for exactly once).
<figure id="attachment_4503" aria-describedby="caption-attachment-4503" style="width: 799px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-4503 size-full" src="/wp-content/uploads/2019/12/cloescriptmqttbroker.png" alt="" width="799" height="535" srcset="/wp-content/uploads/2019/12/cloescriptmqttbroker.png 799w, /wp-content/uploads/2019/12/cloescriptmqttbroker-300x201.png 300w, /wp-content/uploads/2019/12/cloescriptmqttbroker-768x514.png 768w" sizes="(max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 984px) 61vw, (max-width: 1362px) 45vw, 600px" /><figcaption id="caption-attachment-4503" class="wp-caption-text">CLOE script including the MQTT Broker module</figcaption></figure>
<h4>Step 3 &#8211; Connect your MQTT client to our broker</h4>
The final step is obviously to connect your MQTT client to our broker and start receiving your messages. The URL of our broker is simply &#8220;mqtt.enco.io&#8221;, using a secured connection on port 8883, or unsecured on port 1883. Credentials for your client have been defined as first step and the topic to which it should register must include the username, so in our example lorasensors/pxsmythings becomes mqttbrotest/lorasensors/pxsmythings.
Enjoy more secure &amp; reliable data transfer 
Now it&#8217;s your turn to leverage our new MQTT Broker and leverage the reliability, security and flexibility of the MQTT protocol !

How to retrieve your IoT data with a MQTT client ?

In this article, you will discover how Proximus makes it easier to automate the integration of LoRaWAN sensors connected to our national public LoRa network with the Microsoft Azure IoT Hub. We will indicate that this integration can go far beyond just forwarding messages to an event hub.

<h4>The Azure IoT Hub</h4>
The Azure IoT Hub has become a very popular service to ingest IoT data over the last years. At least, for companies or developers who want to leverage Microsoft’s cloud capabilities in building their IoT solution. The IoT Hub is basically the standard cloud entry point in Microsoft’s own IoT Reference Architecture. It comes with several key additional features over the Azure Event Hub, such as:
<ul>
<li>Concept of device and device twins, with associated device capabilities, reported and desired properties</li>
<li>Support of both device-to-cloud and cloud-to-device messaging</li>
<li>Access right management at device level</li>
</ul>
As Microsoft states in this <a href="https://energizedanalytics.com/en/azure-iot-hub-vs-event-hub/">comparison article of IoT Hub and Event Hubs</a> :
“the IoT Hub includes features that enrich the relationship between your devices and your backend systems. Bi-directional communication capabilities mean that while you receive data from devices you can also send commands and policies back to devices”
<h4>LoRaWAN devices and Azure IoT Hub</h4>
Some questions will arise when including LoRaWAN devices and sensors in an IoT project leveraging Microsoft’s IoT Reference Architecture:
<ul>
<li>How do I prevent to double my device management activities?</li>
<li>How do I get my LoRaWAN device data into the right IoT Hub device?</li>
<li>Is there any way to make use of the IoT Hub’s device twin feature?</li>
</ul>
This means, when considering a tighter integration of Proximus LoRaWAN and the Azure IoT Hub, we want to solve these challenges:
<ul>
<li>Integrate device management end-to-end: when a device is created or deleted on the LoRa network, the same action should be taken on the IoT Hub. Depending on the device’s provisioning status on the network, we will want the corresponding IoT Hub device’s status set as active or inactive.</li>
<li>Sensor data must flow to the right IoT Hub device: when new sensor data is generated and sent over the LoRaWAN network, it should be forwarded to the corresponding IoT Hub device. This instead of being just sent to “the hub”, like it would be with the Azure Event Hub.</li>
<li>Leverage “desired” and “reported” properties: it is perfectly possible to leverage an IoT Hub device twin’s &#8220;desired and reported&#8221;. For instance, setting a desired property like “report interval” to 60 (minutes) may trigger a LoRa downlink message to configure the device accordingly.</li>
</ul>
<h4>Proximus MyThings and CloudEngine to the rescue</h4>
MyThings is the device management platform from Proximus to connect, configure Things. But, also to connect the data from LoRaWAN devices to our national network. This web-driven management platform also exposes all its device management functionalities via REST API and can forward device data to an HTTP endpoint (your application). These are not the features we will leverage to implement the scenarios above. We will leverage the <a href="https://proximusapi.enco.io/asset/cloe/overview">Proximus CloudEngine</a> which comes with 2 dedicated modules to deal with Azure IoT Hub integrations:
<ol>
<li>The Azure IoT Manage Device module: to manage the lifecycle of IoT Hub devices by creating, updating and deleting devices, reading or setting device keys and setting a device status.</li>
<li>The Azure IoT Device module: for device to cloud messaging and dealing with device twin properties.</li>
</ol>
These modules support various transport protocols to address the IoT Hub: HTTPS, MQTT and AMQPS.
<h5>Integration CloudEngine and the MyThings platform</h5>
The CloudEngine comes with a standard integration with the MyThings platform, implemented as 2 input endpoints:
<ol>
<li>MyThings – Things: MyThings sends events to CloudEngine for every add, delete, update, provision or deprovision on a device. These events can either come from the MyThings UI or the MyThings REST API.</li>
<li>MyThings – Data: all incoming data from the connected LoRaWAN devices. This inflow can be further filtered based on tags, device address or other such attributes.</li>
</ol>
Putting all these components together, our implementation will look as the schema below.
<img loading="lazy" decoding="async" class="aligncenter size-full wp-image-4472" src="/wp-content/uploads/2019/09/Untitled-1.png" alt="" width="700" height="250" srcset="/wp-content/uploads/2019/09/Untitled-1.png 700w, /wp-content/uploads/2019/09/Untitled-1-300x107.png 300w" sizes="(max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 984px) 61vw, (max-width: 1362px) 45vw, 600px" />
In this implementation, using the standard components listed above and the scripting capability of the Proximus CloudEngine:
<ul>
<li>Every time CloudEngine receives an event from MyThings about a new device being created, deleted, provisioned or deprovisioned on the network, a CloudEngine script is triggered to reflect the very same operation on the IoT Hub</li>
<li>Every time sensor data is forwarded by MyThings to CloudEngine, a script identifies which IoT Hub device should be matched with that physical LoRaWAN device, and sends the sensor data to it as a device-to-cloud message (D2C)</li>
<li>Changes to the device conditions (like its battery level or radio signal quality) are reported as &#8220;reported properties&#8221; on the matching device twin.</li>
</ul>
<h4>Now it’s your turn!</h4>
In our <a href="https://github.com/Enabling">Github</a>, you will find <a href="https://github.com/Enabling/CloudengineScripts/tree/master/MyThings%20Scripts/Azure%20IoT%20Hub">two sample scripts</a> reflecting this implementation scenario. One script is dealing IoT Hub device CRUD (create, update, delete) operations. The second script handles device-to-cloud messaging. Once you are all set up with your scripts and IoT Hub, you’re ready for the next steps. You can start to leverage storage, analytics and machine learning capabilities of Azure.
With the CloudEngine, Proximus makes it easier than ever to address more complex IoT integration scenarios. This goes far beyond capabilities offered by other network operators. Next to the Azure IoT Hub, we also provide integration modules for Azure Event Hub, SAP IoT Leonardo, HTTP(S), sFTP, MQTT client and MQTT broker.

Integrating LoRaWAN devices in the Azure IoT Reference Architecture

A lot of new features have been brought to the EnCo CloudEngine since the beginning of 2019. We thought it might be a good moment to pause for a second and quickly summarize all what we have added as well as give you a sneak peek at what’s coming next.
<h3>HTTP module : explicit support of OAUTH2 and internal EnCo API calls</h3>
<img loading="lazy" decoding="async" class="alignleft wp-image-4254" src="/wp-content/uploads/2019/03/3.png" alt="" width="108" height="72" />Next to basic authentication and Authorization header, the HTTP module now explicitly supports OAUTH2. It is now also possible to make API calls, using the HTTP CloE module, to any EnCo API. You can use your permanent bearer tokens in Authorization headers as well as <a href="https://docs.enco.io/docs/authentication-1">OAUTH2</a>.
Why might you find this useful?
<ul>
<li>Push your <a style="color: #808080;" href="https://proximusapi.enco.io/asset/cloe/documentation#usinggoogleapifromencoscript">IoT data to Google Sheets</a>, like <a style="color: #808080;" href="https://proximusapi.enco.io/blogs/updates/proximus-enco-helps-goodplanet-to-measure-the-impact-of-their-activities">GoodPlanet</a> does</li>
<li>Use MyThings API in a script to send a downlink message to a LoRaWAN device</li>
<li>Create a simple monitoring script to check for CloE script execution errors and warn you by email or SMS</li>
<li>Use our Address AutoComplete or Address Scoring API from within your scripts</li>
</ul>
<h3>Loopback inbound &amp; outbound modules: calling a CloE script from within a script</h3>
<img loading="lazy" decoding="async" class="wp-image-4258 alignleft" src="/wp-content/uploads/2019/03/1-2.png" alt="" width="108" height="72" />We make it now possible to call a CloE script from within another script using 2 new inbound and outbound modules. The Loopback outbound module is used to call another CloE script. This module is qualified with user-defined tags and can pass data to the script being called. The Loopback inbound module is the trigger for called scripts. Scripts are triggered based on the associated user-defined tags.
Why might you find this useful?
<ul>
<li>You may have a script performing payload decoding, integration to external platforms or specific data conversion used as a “meta function” by your other scripts</li>
</ul>
<h3>CRON inbound module: triggering scripts based on predefined schedules</h3>
<img loading="lazy" decoding="async" class="alignleft wp-image-4255" src="/wp-content/uploads/2019/03/4.png" alt="" width="108" height="72" />Using the new CRON inbound module, CloE scripts can be triggered based on predefined schedule(s). The schedule definition is done in the CloE Settings page, using common CRON notation. The CRON inbound endpoint on CloE is then configured with tags corresponding to the name of your defined schedule(s). For instance, a schedule such as “*/5 8-18 * * 1-5” could trigger a script at every 5th minute past every hour from 8 through 18 on every day-of-week from Monday through Friday.
Why might you find this useful?
<ul>
<li>Checking log status at predefined moment</li>
<li><a style="color: #808080;" href="https://proximusapi.enco.io/blogs/tutorials/bridging-iot-and-legacy-systems-with-cloudengine-2-scheduled-scripts">Send accumulated IoT sensor data as a CSV file to an external system</a></li>
<li>Trigger a script to poll data via a HTTP GET to an external system – until now CloE scripts could only be triggered based on incoming events</li>
</ul>
<h3>IoT Store module : storing data in csv structures</h3>
A <img loading="lazy" decoding="async" class="alignleft wp-image-4259" src="/wp-content/uploads/2019/03/2-1.png" alt="" width="108" height="72" />module that allows you to persist and retrieve multiple value lines from within your scripts (only string values are supported). Multiple values can be stored with the same key and retrieved as a single concatenated string. This allows for example to store CSV lines when data is received and to retrieve them concatenated with line separators as a CSV file.
Why might you find this useful?
<ul>
<li>Accumulate IoT sensor data in <a style="color: #808080;" href="https://proximusapi.enco.io/blogs/tutorials/bridging-iot-and-legacy-systems-with-cloudengine-2-scheduled-scripts">CSV files</a></li>
<li>Manage multiple data and data keys cross scripts</li>
</ul>
<h3>sFTP outbound module</h3>
<img loading="lazy" decoding="async" class="alignleft wp-image-4256" style="margin-top: 0.857143rem; margin-right: 1.71429rem; margin-bottom: 0.857143rem;" src="/wp-content/uploads/2019/03/5.png" alt="" width="108" height="72" />
A simple new transport module allowing you to push files – which you can generate with the IoT Store module for instance &#8211; onto an SFTP server.
Why might you find this useful?
Integrate IoT data into legacy systems not supporting modern transport protocols such as HTTP or MQTT.
Are you not using CloudEngine yet, but are you interested? Register on <a href="http://www.enco.io">proximusapi.enco.io</a>, read our documentation and get started!
________________________________
<h3>What’s coming next?</h3>
Over the next sprints we intend to bring you the following new capabilities.
<ul>
<li>Script Collections : instead of a flat list of scripts in the CloE overview, we will allow you to group scripts into Collections (think of it as “folders”)</li>
<li>RTCM Inbound module : receive data from <a href="https://proximusapi.enco.io/asset/rtcm/overview">Real Time Crowd Management</a> straight into CloE, and leverage its outgoing modules to stream your audience data to even more platforms.</li>
<li>Microsoft Azure IoT Hub : make it easier to integrate your IoT sensor data flows and device management with the Microsoft’s leading solution.</li>
</ul>
We have other things considered for our menu but we’ll tell you later about these… Let’s keep a bit of surprise for later. In the meantime, don’t hesitate to share your new feature desires or requirements with us, by dropping a note to <a href="mailto:enco@proximus.com">enco@proximus.com</a>

Discover the latest CloudEngine features

These cookies are important to the proper functioning of a site. To improve your experience, we use functional and anonymous analytical cookies. Click Agree and Proceed to accept cookies and go directly to the site.

About Cookies On This Site

All rights reserved. © 2020 Proximus | [Cookie policy](https://www.proximus.be/en/id_cr_cookie/personal/products/orphans/cookie-policy.html "Cookie policy")

This site was created and is managed in accordance with Belgian law.

Proximus API Solutions - powered by ClearMedia NV. Merksemsesteenweg 148, B-2100 Deurne.

BE 0831.425.897

CloudEngine