LLExec MQTT Engine: Difference between revisions

From Axel Public Wiki
Jump to navigation Jump to search
(aggiornamento per i nuovi nomi dei field)
(aggiornamento per nuova modalita' di publish)
Line 40: Line 40:
= Publish tab =
= Publish tab =
[[Image:Screenshot03_PublishTab.png]]
[[Image:Screenshot03_PublishTab.png]]
In the publish tab, variables engaged to be published to the selected broker can be selected,<br>
 
also many publish parameters can be selected.<br>
In the publish tab you can select the variables to publish to the selected broker, also many other publish parameters can be chosen.
With the <b>Add</b>, <b>Remove</b> and <b>Assign</b> the variables can be selected,<br>
 
the engine manage to publish cyclically the value or on variataion.<br>
Whith the "Add" button you can add a new topic to publish to. Each topic has as default values those defined in the Connection tab.
All the parameters take the default value expressed in the Connection tab.<br>
 
The columns and parameters are:
The columns and parameters are:
* <b>Variable name</b>: it can be any global variable or expression (ie a member of a global variable structure).
* '''Variable name''': clicking on this column will open a wizard that helps you to configure published variabiles. Depending on the paylod you selected, it will ask you different informations:
* <b>Topic</b>: the name of the topic related to this variable values - the name of the topic is composed by the prefix and the variable name. The name of the topic can be changed if desired.
** For '''bin''' paylod you only have to specify the variable, the '''Send on variation''' flag and the '''Threshold''' value (which are explained right below)
* <b>Read only</b>: this flag is true by default, if this field is false then an addictionally topic is implicitally created: the main topic name plus “/set” . The engine subscribe itself to this implicit topic, doing so an external mqtt client can write the variable publishing a value to the set topic.<br>
** For '''JSON''' paylod you must also select the field name, that is the name to assign to the value
For example if the variable main topic is <b> /myPrefix/cnt </b> a client can write the cnt value publishing a value to the topic <b> /myPrefix/cnt/set </b>
*** '''Send on variation''': if selected the variable value is published to the broker in case a variation greater than a specified threshold has been detected
* <b>QoS (Quality of Service)</b>: MQTT allow three quality of service:
*** '''Threshold''': is the threshold for the “Send on variation” mode.
* '''Topic''': the name of the topic related to this variable values - the name of the topic is composed by the prefix and an incrementing number. The name of the topic can be changed if desired.
* '''Read only''': this flag is true by default, if this field is false then an addictionally topic is implicitally created: the main topic name plus “/set” . The engine subscribes itself to this implicit topic, doing so an external MQTT client can write the variable publishing a value to the set topic.<br>For example if the variable main topic is ''' /myPrefix/cnt ''' a client can write the cnt value publishing a value to the topic ''' /myPrefix/cnt/set '''.
* '''QoS (Quality of Service)''': MQTT allow three quality of service:
** 0 – every message is sent without confirmation from the broker
** 0 – every message is sent without confirmation from the broker
** 1 – for every message sent, the broker sends a confirmation
** 1 – for every message sent, the broker sends a confirmation
** 2 – also the confirmation is acknoledged to the broker, this guaratees that only one value is written for the topic, no packets duplication.<br>
** 2 – also the confirmation is acknoledged to the broker, this guaratees that only one value is written for the topic, no packets duplication.
The quality of service is bundled to every message and impacts the communication from the publisher to the broker as well as the communication from the broker to the subscriber.<br>
 
In this latter case the behaviour is what is specified for the less value of QoS between the message and the subscription.<br>
The quality of service is bundled to every message and impacts the communication from the publisher to the broker as well as the communication from the broker to the subscriber.
 
In this latter case the behaviour is what is specified for the less value of QoS between the message and the subscription.
 
As an example:  
As an example:  
  publisher A send a message to the broker with QoS 2:
  A publisher A send a message to the broker with QoS 2: this means that the brocker will confirm the message and the publisher will acknoledge the confirmation as well.
  this mean that the brocker will confirm the message and the publisher will acknoledge the confirmation as well.
  A subscriber B suscribes to that topic with QoS zero.
  A subscriber B suscribes to that topic with QoS zero.
  The message has e QoS 2 but the subscribtion has QoS 0, so the zero policy is selected since is the lower value.
  The message has a QoS 2 but the subscribtion has QoS 0, so the zero policy is selected since is the lower value.
  The broker so will send the message to the subscriber B without expecting any   confirmation, as specified by the QoS
  The broker so will send the message to the subscriber B without expecting any confirmation, as specified by the QoS
* <b>Retain</b>: this specifies if the messages have the attribute retain. If a message has this attribute, when a subscriber subscribes to a topic, a message with the last value is sent to the subscriber. Otherway a message is sent to the subscriber only at the time a value is published.
* '''Retain''': this specifies if the messages have the attribute retain. If a message has this attribute, when a subscriber subscribes to a topic, a message with the last value is sent to the subscriber. Otherway a message is sent to the subscriber only at the time a value is published.
* <b>Payload</b>: the payload can be binary or json. If binary is selected then the raw binary value of the variable is sent, if json is selected the value is sent in human readable json format, with two fields:
* '''Payload''': the payload can be binary or json. If binary is selected then the raw binary value of the variable is sent, if json is selected the value is sent in human readable json format, with two fields: one specifying the value, the other specifitying a timestamp. The names of the two fields can be selected as desired.
one specifying the value, the other specifitying a timestamp. The names of the two fields can be selected as desired.<br>
 
At the moment no structured type is allowed to be sent with json payload.
* '''Inhibit time''': this prevents too message will be sent if a too fast variation occours.
* <b>Send on variation</b>: if selected the variable value is published to the broker in case a variation greater than a specified threshold has been detected.
* '''Send period''': this can set a period after which the value is sent, despite its variation.
* <b>Threshold</b>: is the threshold for the “Send on variation” mode.
* <b>Inhibit time</b>: this prevents too message will be sent if a too fast variation occours.
* <b>Polling time</b>: this can set a period after which the value is sent, despite its variation.
* <b>JSON value name</b>: Is the name to the value field, if json payload format has been selected.
* <b>JSON timestamp name</b>: Is the name to the timestamp field, if json payload format has been selected.


= Subscribe tab =
= Subscribe tab =

Revision as of 15:13, 21 October 2021

The Axel Plc Runtime integrated MQTT Engine allows PLC Programs to publish automatically variable values to any MQTT broker.
It also allows to subscribe the PLC to some Topic on MQTT Broker and updates automatically variable values.
No coding effort is required, it can be interely configured in the LogicLab resources View.

Screenshot01.png

Right clicking on the MQTT icon is possible to add an MQTT Broker to which publish the variables, or to to subscribe to for Topics.

Any PLC application can connect to any number of broker.

Connection Tab

Screenshot02 ConnectionTab.png

This tab is organized in two sections: Configuration and Defaults.

Defaults reppresents default values for every entry in the other tabs, which options will be shown later.

The Configuration has many fields, as follow:

  • Client id: is the name with which the runtime presents itself to the broker, must be unique for any broker
  • Broker address: is the IP address, or full qualified name of the broker
  • Broker port: is the TCP port of the broker
  • Username: for the connection to the broker
  • Password: for the connection to the broker
  • TLS: it specify if the connection to the broker is secure and encrypted
  • Common name server: can be the full qualified name of the server, or the common name in the server’s certificate

Note on TLS: with TLS option enabled all the communication will be encrypted.

Another feature of the TLS is that both Broker and client should present itselves with a certicate issued from a Certificate Authority. This ensures the identity of both broker and PLC, but the PLC may not have a valid certificate.

In this case a self provided certificate can be used, it shuould be installed in the runtime folder:

  • ca.cert.pem: it’s the Certificate Authotity’s certificate
  • client.cert.pem: it’s the PLC’s certificate
  • client.key.pem: it’s the privare key of the PLC

For more information please refer to the online documentation of OpenSSH.

If you are using a self signed certificate for the PLC, the broker may be required to allow unsecured connections.

Publish tab

Screenshot03 PublishTab.png

In the publish tab you can select the variables to publish to the selected broker, also many other publish parameters can be chosen.

Whith the "Add" button you can add a new topic to publish to. Each topic has as default values those defined in the Connection tab.

The columns and parameters are:

  • Variable name: clicking on this column will open a wizard that helps you to configure published variabiles. Depending on the paylod you selected, it will ask you different informations:
    • For bin paylod you only have to specify the variable, the Send on variation flag and the Threshold value (which are explained right below)
    • For JSON paylod you must also select the field name, that is the name to assign to the value
      • Send on variation: if selected the variable value is published to the broker in case a variation greater than a specified threshold has been detected
      • Threshold: is the threshold for the “Send on variation” mode.
  • Topic: the name of the topic related to this variable values - the name of the topic is composed by the prefix and an incrementing number. The name of the topic can be changed if desired.
  • Read only: this flag is true by default, if this field is false then an addictionally topic is implicitally created: the main topic name plus “/set” . The engine subscribes itself to this implicit topic, doing so an external MQTT client can write the variable publishing a value to the set topic.
    For example if the variable main topic is /myPrefix/cnt a client can write the cnt value publishing a value to the topic /myPrefix/cnt/set .
  • QoS (Quality of Service): MQTT allow three quality of service:
    • 0 – every message is sent without confirmation from the broker
    • 1 – for every message sent, the broker sends a confirmation
    • 2 – also the confirmation is acknoledged to the broker, this guaratees that only one value is written for the topic, no packets duplication.

The quality of service is bundled to every message and impacts the communication from the publisher to the broker as well as the communication from the broker to the subscriber.

In this latter case the behaviour is what is specified for the less value of QoS between the message and the subscription.

As an example:

A publisher A send a message to the broker with QoS 2: this means that the brocker will confirm the message and the publisher will acknoledge the confirmation as well.
A subscriber B suscribes to that topic with QoS zero.
The message has a QoS 2 but the subscribtion has QoS 0, so the zero policy is selected since is the lower value.
The broker so will send the message to the subscriber B without expecting any confirmation, as specified by the QoS
  • Retain: this specifies if the messages have the attribute retain. If a message has this attribute, when a subscriber subscribes to a topic, a message with the last value is sent to the subscriber. Otherway a message is sent to the subscriber only at the time a value is published.
  • Payload: the payload can be binary or json. If binary is selected then the raw binary value of the variable is sent, if json is selected the value is sent in human readable json format, with two fields: one specifying the value, the other specifitying a timestamp. The names of the two fields can be selected as desired.
  • Inhibit time: this prevents too message will be sent if a too fast variation occours.
  • Send period: this can set a period after which the value is sent, despite its variation.

Subscribe tab

This tab allow to specify topic to subscribe to, exept the read/write variables already published in the Publish tab.
It exibits less flags than the Publish tabs and they are:

  • Variable name: the name of the variable into which subscribed messages values will be written to.
  • Topic: the topic name to subscribe to.
  • QoS: this is the Quality of Service of the subscribtion – see the Publish QoS for more details.
  • Payload: can be binary or json like the bublished values.
  • JSON value name: Is the name to the value field, if json payload format has been selected.
  • JSON timestamp name: Is the name to the timestamp field, if json payload format has been selected.