SAP has an IoT platform within its rich portfolio that offers strong data analysis & reporting (e.g. with the leonardo solutions). The platform manages devices from multiple origins and consolidates sensor & meta data.
Proximus offers theMy Things API as part of the LoRa network. MyThings allows you to administrate the LoRa sensors (f.e. with decoding profiles and auto activation of sensors) and basic data sending. Proximus EnCo makes LoRa data integration possible in your own applications via easy scripting.
Therefore EnCo’s CloudEngine is extended with different modules and a pattern that allows you to integrate on both platforms. Of course, without loosing the flexibility and still matching the security requirements of both systems. To support this, we have added 2 modulesto CloudEngine that allows you to script your engine based on the input of data coming from MyThings.
In our first article about bridging IoT with legacy systems, we saw that CloudEngine now provides a simple and convenient way to accumulate incoming IoT data in a temporary storage structure. And then send the data as a CSV attachment when you have reached a defined number of records. We are adding as of today a new CloudEngine capability that allows you to trigger script executions based on schedules.
Throughout our experience as a major player of the Internet of Things in Belgium, we worked on projects where every single element of the IoT value chain was at the tip of the arrow of the ICT evolution : modern low power sensors, low power networks such as LoRa and Narrowband IoT, cloud-based platforms from Microsoft, SAP or other big players, advanced use cases for automation leveraging machine learning, … However we also support projects where we need to help bridging legacy systems, which may reside of both extremes of the value chain:
industrial devices using “historical” data protocols such as RS-232, RS-432, ModBus, etc require connection to newer modern data & application platforms leveraging LoRaWAN and narrowband IoT transport. Proximus works with gateways and bridges providers whose devices help interconnect these worlds;
newer IoT devices and sensors using modern IoT networks need to send their data to legacy applications with limited data ingestion capabilities (csv files, ftp file transfer or email-based data ingestion, …);
a combination of 1 and 2 above, ie leveraging LoRaWAN or NBIoT networks to receive data from legacy industrial sensors and machinery and let legacy applications ingest this data
Among all scarce resources on this planet, meeting rooms should definitely be considered one of them. Even if you have a room reservation system, it can be cumbersome to use whatever web site or application to check if a room is available right now, as you need it (open the laptop, wait for it to connect on the network, open Outlook, check the meeting room status, etc). On top of this, a room may be flagged as booked in a reservation system while being actually free, as the people who booked it changed their plans (hello co-working spaces ?).
The EnCo CloudChannel has been available to users since the launch of the EnCo platform. Its goal has always been to help connect various assets together from our platform as well as to the outside world without the complication or the programming skills required to master a tool like an ESB.
At the very start, CloudChannel was especially developed to support collecting data sent by LoRa devices, and evolved over time to include more inbound (HTTP and MQTT) as well as outbound capabilities (HTTP, MQTT, SMS, MS Azure Event Hub, WayLay, AllThingsTalk Maker, …). In parallel, we also gave users the ability to extend from monoChannel to multiChannels definitions, a capability especially useful when different routing decisions were to be applied to source events.