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.
Early February, you will find on the EnCo marketplace the next evolution of our event hub capability, called CloudEngine (CloE). While keeping the same principle at the core, ie making it easier to connect EnCo’s, partners’ and 3rd party assets together, we believed it was time to add powerful data manipulation and programmatic capabilities.
Graphical User Interface
With CloudEngine, you still have the ability to create and manage your channels with a graphical user interface or with APIs. Sharp or experienced eyes will see directly, as shown on the picture below, that next to a major UI overhaul there are already a few new features visible, such as the ability to take SMS as inbound events (this will require that you have a dedicated number or registered keywords on our shared short number) or a new mail outbound endpoint.
As with CloudChannel, CloudEngine lets you define the associated data structure coming from your inbound endpoints (“Parser”) as well as simple rules (“Logic”) to trigger a desired outbound endpoint.
In CloudEngine, Inbound endpoints have a new tagging capabilities, as shown below for the HTTP inbound endpoint configuration. The tag is just a parameter added to the endpoint URL. This means for you that the same flow can be designed and used to support multiple desired scenarios, potentially drastically reducing the number of Flows that will need to be created on the platform. Take this to LoRa, and it means a Flow can address all of your LoRa devices at once, instead of having to create individual CloudChannels for each and every individual LoRa device as it is the situation today.
See this little “Script” icon on the bottom left of the screen in the CloudEngine Flow UI? Here is where the major upgrade comes into play:
- A need to decode binary payloads from your LoRa devices and compare newly received sensor values with the previous ones before taking a decision about where to send your restructured payload to? Yes sir no problem!
- A need to monitor devices geofencing which will trigger a chatbots session via SMS to a designated person? Yep, can do.
- Taking inputs from multiple IP sources over HTTP and MQTT to consolidate it all in a single data structure to be pushed to your cloud? Sure, why not?
On top of this, each Flow can independently be designated as “high” or “eco” priority, whether your flows should run immediately without any queuing to support real-time applications or can afford slight queuing before being processed.