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"

(Blanked the page)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== 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 <code>sensinact -c</code>)
 
* 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 <code>processors</code>
 
 
== How to instantiate ==
 
 
=== Declarative file ===
 
 
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.
 
 
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''.
 
 
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 .
 
 
<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="text">id=counter
 
topic=/camera</source>
 
=== SmartTopic ===
 
 
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.
 
 
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
 

Latest revision as of 12:24, 19 March 2018

Back to the top