Subscribing data to in built MQTT Server and sending data to Cloud Platform (Kapua)

This is still in development phase!!

Documentation (to create a program) which could help in the below :

1. Connect/ subscribe to the in-built MQTT Server (or any MQTT Server) from Kura.
2. Subscribe to the specific topics.
3. Convert the messages to Kura-payload
4. Send the kura-payload to Kapua (Probably, Example Publisher can be referred here).
5. Create a application to receive on any topic and standardize it to Kapua format?

1. Connect/ subscribe to the in-built MQTT Server:

We can use two Cloud Connection Factor PID:

• "org.eclipse.kura.cloud.CloudService" and
• "org.elclipse.kura.cloudconnection.eclipseiot.mqtt.ConnectionManager"

Both two factories can be used to connect to Mqtt brokers. The difference between them is that they use different mqtt namespaces. Also, Eclipse IoT integration connection does not support custom subscriptions which is why, we would not see Subscriber available when Eclipse IoT integration connection is selected as cloud connection.

To connect to the internal broker, we have to instantiate a new cloud connection. For example

• A new instance of "org.eclipse.kura.cloud.CloudService" (Cloud Connections -> New Connection --> Cloud Connection Factory PID)
• Point it to mqtt://127.0.0.1:1883 (Cloud Connections --> Your.CC.Service.PID --> MqttDataTransport)

2. Subscribe to the specific topics

• To get messages from that connection, you'll have to instantiate a new subscriber
• Then you can use, for example, wire components to process the message and publish it to another cloud service.

Something missing here; How to see the messages in Java Program? or Wires? or Database?

2a Data Format:

Data which is sent to the MQTT Server has to be of a certain format. Default cloud connection supports both KuraProtobuf and simple JSON. The choice between the two is done in CloudService configuration.

Format Accepted by Kura

[Question] Does the format sent from the Sensor (constrained device) always have to be in the above format? If so, all constrained device have to follow a standard which is not the case. If no, How we can have accept the message other than the above format? Because as of now, if the format specification is not met, application throws Parse Exception?

2b MQTT Topic Format?

MQTT-Namespace

The format for the topics is account_name/client_id/app_id/resource_id ?

where

• account_name Identifies a group of devices and users. (Possibly Kapua userid?)
• client_id Identifies a single gateway device within an account (Possibly your Kura Gateway Name)
• app_id Identifies an application running on the gateway device.
• resource_id Identifies a resource(s) that is owned and managed by a particular application.

account_name and client_id (Set in org.eclipse.kura.cloud.CloudService -> MQTTDataTransport -> Topic Context Account Name and Client-Id).

app_id and resource_id (Set in org.eclipse.kura.cloud.publisher.CloudPublisher or org.eclipse.kura.cloud.subscriber.CloudSubscriber -> Application Id/ Application Topic)

[Question] Does the topic format always have to be like "account_name/client_id/app_id/resource_id"? How can we receive MQTT data from different topics? Considering constrained devices don't have the buffer to set a large topic? and just send like /data/random.identifer(ABCD)/metrics?

5. Java Application?

• In Kura 4.0, we have to use the API : org.eclipse.kura.cloudconnection

• org.eclipse.kura.cloudconnection

• org.eclipse.kura.cloudconnection.listener

• CloudConnectionListener

• CloudDeliveryListener

• org.eclipse.kura.cloudconnection.message

• KuraMessage

• org.eclipse.kura.cloudconnection.publisher

• CloudNotificationPublisher

• CloudPublisher

• org.eclipse.kura.cloudconnection.subscriber

• CloudSubscriber

• org.eclipse.kura.cloudconnection.subscriber.listener

• CloudSubscriberListener