You cannot log in without being assigned a valid TSI role.
By Ryan David, TSI Software Engineer
In Part 1 of this article, I introduced our TSI software platforms:
I also talked about our connectivity protocol of choice, MQTT, or Message Queuing Telemetry Transport. MQTT is a publish/subscribe machine-to-machine protocol. What is MQTT? [LINK TO PART 1]. In Part 2, I’ll explain how we use MQTT to provide TSI instruments with IoT capabilities.
When using MQTT, there is always at least one “broker,” essentially a server. There is also at least one “client” on any connection. The client connects to the broker, and the broker handles messages from multiple clients if need be.
In our case, Fusion.net runs on one of our newest instruments, the Q-Trak XP, and uses a broker called Mosquito to handle connections and messages. MQTT is able to run on any “lossless” communication link, such as TCP/IP. We have the Mosquito broker configured to run on a web socket due to the nature of the clients we are using to connect to it.
The fun doesn’t stop there, though. We can’t forget about Fusion.SaaS, our cloud platform. While we have not yet completed cloud integration with a Fusion.web app or a Fusion.net instrument, MQTT will make this much easier for us. Here’s how it will work:
With familiarity and uniformity, developing for platforms gets much easier. Using MQTT is helping us reach our development goals.
In Part 1 of this article, we covered how information is currently moved around within the TSI Fusion ecosystem. In Part 2, we explained a little bit about what the future might hold. It’s worth mentioning that many other IoT devices and services also use MQTT. Our adoption of the technology will make such services and devices easier for TSI to integrate with them should the need arise. When trying something new, there is always some uncertainty involved, but MQTT has proven to be an excellent choice for transferring data between our software platforms.