Cloud Modules
Google Cloud Injector Anchor |
---|
| Google Cloud Injector |
---|
| Google Cloud Injector |
---|
|
- Q: Why am I seeing "Connection Lost: Connection lost, attempting to reconnect" errors coming from the GoogleMqttIngestService in my Ignition logs every ~15 minutes?
Example:
GoogleMqttIngestService 14May2019 13:08:01 Connection Lost: Connection lost, attempting to reconnect
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:164)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.EOFException: null
at java.io.DataInputStream.readByte(DataInputStream.java:267)
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:116)
... 1 common frames omitted
- A: Google automatically closes our injector connection after 15 minutes. This is expected behavior. We automatically reestablish the connection to the Google Cloud and resume pushing messages.
MQTT Modules
General
Chariot MQTT Server
...
- A: Chariot MQTT Server can be installed as a virtual machine by following this tutorial.
...
- Q: What do each of the MQTT Modules do in simple terms?
- A: The MQTT modules for Ignition each have very specific functions. The very high level overview of each is listed below. For more detailed information see this page.
- MQTT Distributor - A MQTT v3.1.1 compliant MQTT Server.
- MQTT Engine - A module which acts as a MQTT to Ignition Tag Bridge. This module listens for and captures incoming MQTT messages and creates/updates Ignition tags based on those messages. In addition it listens for tag writes in Ignition and converts those to MQTT messages to send/update data and I/O on the remote MQTT devices. This module can be thought of as a tool to receive and visualize MQTT data in Ignition.MQTT Injector - A simulation tool for creating MQTT clients which represent edge gateways and field devices
- MQTT Transmission - An Ignition Tag to MQTT Bridge. This module listens for tag change events in Ignition and converts those to outgoing Sparkplug MQTT messages. In addition, it listens for incoming MQTT messages and updates tag values based on those incoming messages. This module can be thought of as a tool to MQTT enable Ignition Tag providers and push that data to an MQTT Server and MQTT Engine.
...
UDTs
- Q: What is Sparkplug in a nutshelldo I do if my UDT definition changes at the edge?
- A: Sparkplug is a set of definitions on top of MQTT to serve the following purposes:
- Define a set of topics to ensure state/quality of data be ensured in a backend MQTT client application
- Define a standard payload format that allows an edge node/device client to communicated with a backend application
- Define a flow of messages to ensure the state/quality of data.
Q: What is the difference between MQTT Engine will ignore any received UDT definitions that share the same name as an existing definition. In order to change or update a UDT definition within MQTT Engine the old definition must first be manually deleted.
- Q: If I delete and update a UDT definition in MQTT Engine will all of the existing instance's member Tags lose their custom properties and configurations (such as history)?
- A: Yes, if a UDT definition is deleted and recreated, any existing UDT instances will lose any custom properties and/or configuration.
MQTT Distributor:
MQTT Engine:
- Q: What is the Primary Host ID and why should I set it?
- A: The 'Primary Host ID' is used for client state notifications to ensure MQTT clients are notified of a loss of connectivity to the primary host which is often MQTT Engine. For example, the 'Primary Host ID' must be set in order for the MQTT Distributor/Server to detect a disconnect between itself and the MQTT Engine and then publish a retained message for all connected clients stating that the MQTT Engine is offline. When MQTT Transmission sees this message stating the Engine/PrimaryHost is offline, it will then go offline itself and begin to store messages locally (assuming Store and Forward is enabled) to be sent once the Engine/PrimaryHost is back online.
MQTT Transmission:
Anchor |
---|
| MQTTTransmission |
---|
| MQTTTransmission |
---|
|
- Q: What does the MQTT 'Transmission Control/Refresh' in the MQTT Transmission tag provider do?
- A: This tag is used to 'refresh' the MQTT client(s) associated with MQTT Transmission. By default, any new tags added to a transmitter definition will not be published to the MQTT server. By writing to the 'Transmission Control/Refresh' tag any newly added tags will be detected and published.
- Q: What is the MQTT Client (Transmission) Keep Alive setting?
- A: The Keep Alive setting controls how often the MQTT client (Transmission) is expected to ping the MQTT Server (Distributor) so the MQTT Server can verify the client is still connected. If the server hasn't seen a ping or control packet from the client in 1.5 x 'Keep Alive', it will forcefully close the socket connection and publish the LWT (which for a Sparkplug client is the NDEATH message) for that client denoting it as offline.
- Q: What is the Primary Host ID and why should I set it?
- A: The 'Primary Host ID' is used for client state notifications to ensure MQTT clients are notified of a loss of connectivity to the primary host which is often MQTT Engine. For example, the 'Primary Host ID' must be set in order for the MQTT Distributor/Server to detect a disconnect between itself and the MQTT Engine and then publish a retained message for all connected clients stating that the MQTT Engine is offline. When MQTT Transmission sees this message stating the Engine/PrimaryHost is offline, it will then go offline itself and begin to store messages locally (assuming Store and Forward is enabled) to be sent once the Engine/PrimaryHost is back online. Sparkplug A and Sparkplug B?The 'A' and 'B' qualifiers differentiate payload encoding formats. The following points show the similarities and differences between the two:
- Both A and B use the same topic format with a qualifier as the first token in the topic namespace to denote the payload encoding format
- The message flow of both A and B is the same
The only difference is the payload encoding format.
- Both formats are open source
- Both are based on Google Protobuf definitions
- Sparkplug A uses Eclipse Kura's payload definition found here: https://raw.githubusercontent.com/eclipse/kura/develop/kura/org.eclipse.kura.core.cloud/src/main/protobuf/kurapayload.proto
Sparkplug B uses an expanded definition allowing for more metadata found here: https://raw.githubusercontent.com/Cirrus-Link/Sparkplug/master/sparkplug_b/sparkplug_b.proto