Software, IoT and TSI Instruments: Part 1 - Moving Information in the TSI Fusion Ecosystem

By Ryan David, TSI Software Engineer

A shared goal at TSI is to supply customers with accurate measurements and great experiences when using our products. To this end, we have developed several new software platforms, each designed to provide value to our customers in different ways.  

The new TSI software platforms are 

• Fusion.saas, our cloud platform
• Fusion.web, our application platform for desktop and mobile, and 
• Fusion.net, our on-instrument software platform.

These three platforms tackle different aspects of our users’ interactions with their measurement data. They, must work seamlessly together, which means that they must communicate with one another. 

With this in mind, we set out to find the best possible method of transferring information across our software products. Previously, TSI has used proprietary TCP-based and serial-based methods of communication. These worked well enough, but in this new era of software at TSI, the teams decided to use a technology that has already been proven and widely adopted for use in IoT applications: Message Queuing Telemetry Transport, more commonly known as MQTT.

What is MQTT?

MQTT is a publish/subscribe machine-to-machine messaging protocol. That means  that every operation is either a publish or a subscribe. From the mqtt.org website, MQTT is “ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.”

MQTT uses “topics” structured with parts that are separated with forward slash (“/“) characters: this/is/how/a/topic/might/look.  

MQTT also offers the ability to do wildcards when subscribing to topics, the "#" character representing any number of additional topic parts, while the “+” character means any value can be used in the position in which it appears. For example, one could subscribe to our previously defined topic using "this/is/how/a/topic/#" or "this/+/how/+/topic/might/look."  Both of these are valid topic strings to subscribe to, and both would get publishes from our example topic.  

Additionally, if another topic was created with a different ending, the subscription ending in "#" would also receive publishes for that topic. Clear as mud? It is intuitive compared to some other protocols out there, believe it or not!

Advantages of MQTT messaging protocol

There are a couple other aspects of the protocol worth mentioning.

• Quality of service (QoS) can be assigned when publishing an MQTT message, which essentially dictates how hard the message sender will work to get the message to all subscribed parties.  Messages can be sent with varying importance in this way, although we generally use QoS 0, the most relaxed mode of publishing messages.  
• A “retain” flag can be set on a message so that the last publish is saved for any future subscribers.  This is useful for things like hardware information, which rarely or never changes. An IoT instrument can publish once and then never again, and the message will be retained and given to any new subscriber.

In Part 2, Ryan will explain how TSI uses MQTT connectivity protocol to enable IoT capabilities and communications with our instruments. 

Visit mqtt.org to learn more about Message Queuing Telemetry Transport or MQTT