Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Demystifying the various MQTT options available with ThingWorx


Demystifying the various MQTT options available with ThingWorx

Hi Community,


I've recently had a number of questions from colleagues around architectures involving MQTT and what our preferred approach was.  After some internal verification, I wanted to share an aggregate of my findings with the ThingWorx Architect and Developer Community.


PTC currently supports four methods for integrating with MQTT for IoT projects.

  • ThingWorx MQTT Extension
  • Protocol Adapter Toolkit
  • ThingWorx Azure IoT Hub Connector
  • ThingWorx Kepware Server

Choice is nice, but it adds complexity and sometimes confusion.  The intent of this article is to clarify and provide direction on the subject to help others choose the path best suited for their situation.


ThingWorx MQTT Extension

The ThingWorx MQTT extension has been available on the marketplace as an unsupported “PTC Labs” extension for a number of years.  Recently its status has been upgraded to “PTC Supported” and it has received some attention from R&D getting some bug fixes and security enhancements.  Most people who have used MQTT with ThingWorx are familiar with this extension.  As with anything, it has advantages and disadvantages.  You can easily import the extension without having administrative access to the machine, it’s easy to move around and store with projects, and can be up and running quite quickly.  However it is also quite limited when it comes to the flexibility required when building a production application, is tied directly to the core platform, and does not get feature/functionality updates.


The MQTT extension is a good choice for PoCs, demos, benchmarks, and prototypes as it provides MQTT integration relatively quickly and easily.  As an extension which runs with the core platform, it is not a good choice as a part of a client/enterprise application where MQTT communication reliability is critical.


Protocol Adapter Toolkit

The Protocol Adapter Toolkit (PAT) is built on the Connection Server and provides developers/integrators the ability to create their own codec (protocol translator) to tie into ThingWorx.  PAT natively supports multiple endpoints, with MQTT being one of them (+HTTP/S).  Meaning that you can use examples to create a codec to map between your MQTT messages/payload to the Thing Model.


I know what you’re thinking; this sounds more complex than simply importing and using an extension – and it is, but with good reason.  Scalability, flexibility, redundancy, maintainability are core tenets when building enterprise IoT solutions.  This is why the Connection Server (CX server) was developed in the first place; to remove device connections and communications from the core platform, and to make them redundant and horizontally scalable.  Put behind a load balancer, you can have multiple CX servers connected to ThingWorx and do things like restarting/upgrading them without touching the platform.  You can’t do that with an extension which is running inside the same JVM as the platform.


So although it slightly complicates things, for an enterprise solution it is the wise choice which supports building a scalable solution which can be more seamlessly monitored and maintained.


ThingWorx Azure IoT Hub Connector

Although Azure IoT Hub is not a fully functional MQTT broker, Azure IoT does support MQTT endpoints on both IoT Hub and IoT Edge.  This can be an interesting option to have MQTT devices publish to Azure IoT and be integrated to ThingWorx using the Azure IoT Hub Connector without actually requiring an MQTT broker to run and be maintained.  The Azure IoT Hub Connector works similarly to the PAT and is built on the Connection Server, but adds the notion of device management and security provided by Azure IoT.


When using Azure IoT Edge configured as a transparent gateway with buffering (store and forward) enabled, this approach has the added benefit of being able to buffer MQTT device messages at a remote site with the ability to handle Internet interruptions without losing data.


ThingWorx Kepware Server

As some will note, KepWare has some pretty awesome MQTT capabilities: both as north and southbound interfaces.  The MQTT Client driver allows creating an MQTT channel to devices communicating via MQTT with auto-tag creation (from the MQTT payload).  Coupled with the native ThingWorx AlwaysOn connection, you can easily connect KepWare to an on-premise MQTT broker and connect these devices to ThingWorx over AlwaysOn.


The IoT Gateway plug-in has an MQTT agent which allows publishing data from all of your KepWare connected devices to an MQTT broker or endpoint.  The MQTT agent can also receive tag updates on a different topic and write back to the controllers.  We’ve used this MQTT agent to connect industrial control system data to ThingWorx through cloud platforms like Azure IoT, AWS, and communications providers.


ThingWorx Product Segment Direction

A key factor in deciding how to design your solution should be aligned with our product development direction.  The ThingWorx Product Management and R&D teams have for years been putting their focus on scalable and enterprise-ready approaches that our partners and customers can build upon.  I mention this to make it clear that not all supported approaches carry the same weight.  Although we do support the MQTT extension, it is not in active development due to the fact that out-of-platform microservices-based communication interfaces are our direction forward.


The Protocol Adapter Toolkit or Azure IoT Hub Connector, both being built on the Connection Server are currently the way forward for MQTT communications to the ThingWorx Foundation.




Greg Eva