Cumulocity IoT Feedback Portal
Extend Cumulocity IoT to be able to integrate any MQTT device independendly of its message format.
Currently it is not possible to integrate an MQTT enabled device which sends payloads differntly from what Cumulocity expects or expects downstream messages to be in a particular format.
As of today the only solution around this problem is to integrate such devices using an externally hosted MQTT broker.
0
Planning / planned
Hi Thomas,
this is possible with the Telekom MQTT Broker: https://support.ram.m2m.telekom.com/apps/docs/device-sdk/mqttuserguide/index.html
BR
Hi Thomas,
persisting data in the database is already optional. It is possible to forward data to the CEP engine without persisting it by choosing the transient mode.
However, this can get problematic when there are issues while forwarding data or the CEP engine is overloaded. We are currently working on a feature called "Reliable Data Forwarding" which is in its essence about adding a messaging infrastrutcture to Cumulocity which will solve this problem in future.
Hi Nikolaus���.
Again thanks for looking into this feature,
To your questions, I can make assumptions and agree in some sense, but I could also say it depends considering the architecture or how you will solve it.
I generally believe the inbound (or even outbound) translation is important, and that regardless of protocol etc but as I start I would believe having the possibility to create a endpoint in MQTT which is linked to my ���translationservice��� so that it can translate the message before putting it into Cumulocity. Your second statement makes me worried although, feels like you are considering the translationservice as a ���Post Processing��� after storing the data, maybe you have a point here or maybe not, I do believe we need to have the translation as a ���pre processing��� since we then can always work with common formats in Apama/Cumulocity and not pollute MongoDB with all kinds of formats.
Apologies if my assumptions are wrong���
/Thomas.
Thomas Lundstr��m
Principal Solution Architect
M: +46 702 51 3571
E: thomas.lundstrom@softwareag.com
Hi Thomas, thanks for the feedback on this. We have had an internal discussion on this idea.
We have seen other requests which are related to be able to send any MQTT messages to Cumulocity IoT without requiring the MQTT device to adhere to the Cumulocity IoT data model.
Do you agree that this is mainly related to MQTT? Do you also agree that once you have the MQTT data in Cumulocity (e.g. as Events), the post processing (e.g. through Apama rules) is the smaller problem?
Hi!!!
The reason for raising this is that today we have a metamodel within Cumulocity and we do have protocols to send that information in according to our metamodel, but what we have seen at prospect is that a lot of them has done some pilots or built some agents already and want to ���reuse��� these and not rebuild a whole infrastructure just because they swap to cumulocity.
So what I would like is a simple way to achieve a inbound translation of a device data (not in cumulocity format) to cumulocity model so that cumulocity understand this,
As an example:
For SKF which has 32000 sensor out there and they wanted us to prove that they could only change the endpoint of those sensors to our MQTT endpoint and that cumulocity could consume that. To be able to do this we had to setup a Universal messaging exposing the MQTTendpoint and have IS consuming this and translate it before sending it in to Cumulocity. ( I know the standard answer is always build a microservice for it, which is basically what we did)
I do however believe this is cumbersome and not a generic solution���
As I see it, we should have inbound (as well as outbound) translation so that Cumulocity can easily be plugged into an existing infrastructure���
This would enable us to:
* Faster perform POC:s where we can leave and layer on existing infrastructure
* Steal revenue from our competitors since we can easily be on top of anything the customers done with them
* Be more agile and flexible for Cumulocity to play anywhere since we can have different information models both in and out
I just did a quick scan of nodeRed and yes it looks promising if it does translation with performance
Please reach out if this is not clear enough���
Thomas Lundstr��m
Principal Solution Architect
M: +46 702 51 3571
E: thomas.lundstrom@softwareag.com
Hi Thomas, can you give some examples here? It is not really clear to us what you refer to with inbound translation. Do you envision something similar to NodeRED?