Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SensiNact/Bridge MQTT"

Line 1: Line 1:
 
== Description ==
 
== Description ==
  
This bridge allows sensiNact to subscribe to a MQTT topic, and materializes a sensiNact device based on the messages. The devices are displayed just after its configuration (once the <code>.cfg</code> file is deployed, check below) but the value will be update upon the message arrivals.
+
This bridge allows sensinact to subscribe to a topic, and materialize a sensinact device based on this topic messages. The devices will be display just after its configuration (once the ''.cfg'' file is deployed, check below) but the value will be update upon the message arrivals.
 +
 
 +
== Sensinact version ==
 +
 
 +
This bridge is available in version ''1.5-SNAPSHOT''
  
 
== Requirements ==
 
== Requirements ==
  
 
* '''mqtt-sb''' bridge activated (via <code>sensinact -c</code>)
 
* '''mqtt-sb''' bridge activated (via <code>sensinact -c</code>)
* A MQTT server  
+
* A mosquitto server running
  
== How to use it ==
+
== Capability ==
  
Create a file <code>mqtt-X.cfg</code> where <codeX</code> is a number that will stand as OSGi service PID (for more details, checks Felix '''Configuration Manager''').
+
* Create a sensinact provider from a message receveid from a MQTT broker topic.
 +
* Instantiate multiple providers, as many as there are configuration files respecting the pattern “mosquitto-*.cfg“, the content format example can be seen below
 +
* Pre-process the message content from the MQTT topic, check the section about <code>processors</code>
  
The fields in this file are defined as in a regular property file. The mandatory fields are '''id''' and '''topic'''. In case any of the other fields '''host''' and '''port''' are not specified their defaults values are assumed, which are `127.0.0.1` and `1883` respectively.
+
== How to instantiate ==
  
The '''id''' becomes the '''provider''' into sensiNact (the name of the sensor), the '''topic''' corresponds to the topic in which the provider is attached to. It means that when a new message on the assigned topic is received, the value associated with the device defined in '''id''' is updated.
+
=== Declarative file ===
  
One example of file (named <code>mqtt-1.cfg</code>) content is shown below:
+
The declarative file allow you to create at runtime a device mapped to a mosquitto topic. According to the <code>topic</code> information added in the file (that will be explained below) you will have a device connected directly to your MQTT broker topic.
+
<source lang="html4strict">
+
host=127.0.0.1
+
port=1883
+
id=counter
+
topic=/camera
+
</source>
+
  
In order to be taken into account, this file '''MUST''' be deployed in the directory <code>$SENSINACT_HOME/cfgs</code>.
+
In order to create the instance of your device inside sensinact platform you have to create a file that respect the certain pattern <code>mqtt-*.cfg</code> where <code>*</code> can be any string that identify your rule, this will be assigned as your OSGi service PID (for more details check felix ''Configuration Manager''). This configuration file '''MUST''' be deployed in the directory ''$SENSINACT_HOME/cfgs''.
  
If the message sent to the MQTT does not correspond to clear text, but some other format (e.g., JSON), you can specify two properties, '''payload.format''' and '''payload.sensorValue''':
+
The fields in this file are define as in a regular property file, that by definition contains a list of <code>key</code> and <code>values</code> pairs separated by <code>=</code>. The allowed fields are specified in the list in BNF extended format below .
* The '''payload.format''' supports the value 'json' at this moment ;
+
* You MUST specify '''payload.sensorValue''' to indicate which element from the JSON you want to use.
+
  
You can as well specify the location of the device, this is an optional information, case this information is not provided the location assumes will be the same as the gateway location.
+
<pre>id=ALPHA; mandatory
 +
host=ALPHA;default=127.0.0.1
 +
port=ALPHA;default=1883
 +
protocol=[&quot;ssl&quot;|&quot;tcp&quot;];default=tcp
 +
topic=ALPHA; mandatory
 +
topic.type=[&quot;mqtt&quot;|&quot;smarttopic&quot;];default=mqtt
 +
processor=([PROCESSOR[&quot;$&quot;[PROCESSOR_EXPRESSION]][&quot;,&quot;])*
 +
location.latitude=DIGIT
 +
location.longitude=DIGIT
 +
auth.username=ALPHA
 +
auth.password=ALPHA
 +
discovery.firstMessage=[&quot;false&quot;|&quot;true&quot;];default=false</pre>
 +
Some processors do not require a PROCESSOR_EXPRESSION, refer to the processor specific topic to get more details
 +
 
 +
One example of file (named <code>mqtt-1.cfg</code>) content is shown below:
  
<source lang="html4strict">
+
<source lang="text">id=counter
host=127.0.0.1
+
topic=/camera</source>
port=1883
+
=== SmartTopic ===
id=counter
+
topic=/camera
+
discovery.firstMessage=false
+
location.latitude=44.5
+
location.longitude=55.8
+
</source>
+
  
== Limitations ==
+
Using regular <code>topic</code> you can only attach one device to one topic and you cannot define the service and resource name in which this information will be attached. For this reason the smarttopic was created, its is an language inside a regular MQTT topic that allows the user to specify which portion of the topic will be considered as provider, which as service and so on.
  
* The topic message is considered as <code>String</code> value, although the SNA generic performs automatic conversion to numeric types. It means that even <code>String</code> values can use numeric operators, e.g., "more than", "less than", etc. The conversion will be performed automatically in SNA.
+
In smarttopic only the <code>{provider}</code>tag is mandatory, case <code>service</code> or <code>resource</code> are not specified the values <code>info</code> and <code>value</code> will be adopted. You can also indicate the value defined for your sensinact devices in the topic using the tag <code>{value}</code>, case

Revision as of 12:52, 15 March 2018

Description

This bridge allows sensinact to subscribe to a topic, and materialize a sensinact device based on this topic messages. The devices will be display just after its configuration (once the .cfg file is deployed, check below) but the value will be update upon the message arrivals.

Sensinact version

This bridge is available in version 1.5-SNAPSHOT

Requirements

  • mqtt-sb bridge activated (via sensinact -c)
  • A mosquitto server running

Capability

  • Create a sensinact provider from a message receveid from a MQTT broker topic.
  • Instantiate multiple providers, as many as there are configuration files respecting the pattern “mosquitto-*.cfg“, the content format example can be seen below
  • Pre-process the message content from the MQTT topic, check the section about processors

How to instantiate

Declarative file

The declarative file allow you to create at runtime a device mapped to a mosquitto topic. According to the topic information added in the file (that will be explained below) you will have a device connected directly to your MQTT broker topic.

In order to create the instance of your device inside sensinact platform you have to create a file that respect the certain pattern mqtt-*.cfg where * can be any string that identify your rule, this will be assigned as your OSGi service PID (for more details check felix Configuration Manager). This configuration file MUST be deployed in the directory $SENSINACT_HOME/cfgs.

The fields in this file are define as in a regular property file, that by definition contains a list of key and values pairs separated by =. The allowed fields are specified in the list in BNF extended format below .

id=ALPHA; mandatory
host=ALPHA;default=127.0.0.1
port=ALPHA;default=1883
protocol=["ssl"|"tcp"];default=tcp
topic=ALPHA; mandatory
topic.type=["mqtt"|"smarttopic"];default=mqtt
processor=([PROCESSOR["$"[PROCESSOR_EXPRESSION]][","])*
location.latitude=DIGIT
location.longitude=DIGIT
auth.username=ALPHA
auth.password=ALPHA
discovery.firstMessage=["false"|"true"];default=false

Some processors do not require a PROCESSOR_EXPRESSION, refer to the processor specific topic to get more details

One example of file (named mqtt-1.cfg) content is shown below:

id=counter
topic=/camera

SmartTopic

Using regular topic you can only attach one device to one topic and you cannot define the service and resource name in which this information will be attached. For this reason the smarttopic was created, its is an language inside a regular MQTT topic that allows the user to specify which portion of the topic will be considered as provider, which as service and so on.

In smarttopic only the {provider}tag is mandatory, case service or resource are not specified the values info and value will be adopted. You can also indicate the value defined for your sensinact devices in the topic using the tag {value}, case

Back to the top