Clients

A program that is connected to an MQTT broker is called a client.  Most of the clients in LabTime were written specifically for LabTime by me, James, and they follow the same basic design.  

In addition to the LabTime clients there are Telegraf loaders and clients that are used for development.

LabTime Clients

All LabTime clients have the same base functionality

  • requestConfig - upon startup the client connects to MQTT broker and publishes a requestConfig message to the broker.  The administrator client builds a configuration specific to that client and publishes it.  The client receives  the configuration, installs it and begins executing. 
  • requestStatus - at anytime any client can request the status of a specific client or of all clients.  The client(s) respond with their name, mqttid, uptime, connection status, etc.
  • requestReset - a client can be requested to reset itself.  Depending on the client this might be a simple restart of the code, or it can force the client to reboot.
  • setDebugLevel - set the debug level for a client.  Clients use this to determine what code debug messages are published to the broker to help with debugging.
  • setEnable - enable and disable clients - this turns on and off the clients functions - if its an edge device it will stop reading sensors.

Administrator client

The administrator client is the heart of LabTime.  It centralizes the administration and configuration of all other LabTime clients.  There can only be one administrator client running for each LabTime installation.  The administrator program can execute multiple projects simultaneously.

All the configuration information for a client is generated and managed by the administrator.  Upon startup a client requests it's configuration from the broker.  The administrator generates a configuration specific to that client and publishes it.  The client receives the configuration, initializes and begins executing.  This means that all configuration information for clients is saved in a single set of files the administrator uses.  One point administration.

The administrator also keeps track of values for all metrics.  This is used to initialize clients with the current value.  The administrator also checks new values against alarm and range values and publishes an alarm message.  In addition every 15 seconds it checks all values to see if they are stale - they haven't been updated recently.  If a value is stale then a message is published notifying other clients.  

The administrator is the only LabTime client that has access to disc space.  All other clients use the MQTT broker to get their configuration, metric values, etc.  

  • Supplies clients with their configuration
  • Keep history of metric values
    • Check for out of alarm and range conditions
    • Periodically check for stale values

MQTT Monitor Client

I realized when starting this project that to develop and support an MQTT solution, it is imperative you know everything going through the MQTT broker.  .  

The MQTT Monitor client displays all messages and provides filters for clients and actions.  It uses colors to easily distinguish what client a message is about and what action the message is for.  

The client filter also has buttons which when pressed send messages to the client.  You can reset a client, request it's status, set a debug level, enable or disable it, and more.

Controller client - SCADA

The Controller client is under development and not ready for prime time.

LabTime was developed to control the SAFIRE vacuum plasma reactor, an experimental reactor attempting to study the Sun.  The procedures we are working to automate are:

  • Perform nightly pump down and leakback tests.
  • Vent the chamber and start nitrogen purge
  • Close chamber and perform pumpdown, bake-out and cool-down automatically
  • Ignite plasma
  • Execute DOE recipe (Design of Experiments)

There is one controller program running for each project.

HMI, GUI clients

The HMI runs from anywhere in the world in your browser.  This means you can follow an experiment or monitor your factory on your phone or computer while on vacation.  Multiple HMI clients can be started simultaneously for each project.  These clients communicate with each other through the MQTT broker.

Any change a person makes to a slider, value, or button will immediately updated for all users.  

Real-time users can chat and/or write notes.  All messages are saved to the Historian so they can be plotted on time-series charts. 

The LabTime HMI uses JavaScript React to create and operate the web pages.  

Edge Devices

arduino

Arduino's run their own version of C++.  Bottom end arduinos don't have enough memory to load the MQTT library.  Use an 8266 or I recommend the ESP32.  

Raspberry PI, Opto22 RIO and EPIC - Each of these can be communicated with using the same basic node.js code.  The EPIC and RIO use a REST interface to read and write values to channels.  The labtime code can be running either on the device or remotely on a server. 

Historian Telegraf Clients

For each project, two telegraf loaders are started and subscribed to these topics: (Substitute your project ID for "pj_")
          +/+/+/+/pj_edge            metric values in InfluxDB format
          +/+/+/+/pj_msg              chat and notes messages from HMI in JSON format

 

MQTT Debug Clients

The Mosquitto broker comes with two programs that let you publish and subscribe to a MQTT broker.  These two programs were essential in this program and I run them all the time.  

mosquitto_sub - subscribe to some or all messages going through the broker and display them.

mosquitto_pub - publish a message.  I have a bash script that generates the topics and payloads needed to test many of the MQTT messages used in LabTime.  This is how I test receiving a message before I developed the client that would normally publish it.  I also have cron shell scripts that look for problems with the installation and if found publish a warning message to the broker where is goes to users and the historian.