All Systems Operational 

Why we built the Hark Cloud MQTT Broker

We recently released a feature called the Hark Cloud MQTT broker, you can find it labelled as “Virtual Gateway” in the Hark Platform and it is now available! Let’s give a little bit of context into why we began developing this tool…
code on a screen

MQTT has become a de-facto protocol for sending and receiving data from sensors and gateways. Typically, MQTT is used to collect data from sensors, analyse said data and then create meaningful applications. While there are many devices that use MQTT (and this continues to increase every day as new devices hit the market), we are also seeing building management systems support MQTT and those companies purchasing building management systems specifically requesting “MQTT” and “open communication.” With these sorts of devices and systems, accessing data can help increase efficiency in a plethora of ways such as reduced downtime and increased device life. Let’s look into some more of the critical motivations for creating the Hark Cloud MQTT Broker…

By standardising on MQTT we can significantly reduce the time and effort spent developing integrations with other protocols and devices, this is now done by creating MQTT to protocol adapters e.g. the Hark BACnet to MQTT adapter which is currently in use with a customer trial.  Prior to this, we would spend significantly more time getting the data into The Hark Platform, rather than working on the solution specifics at hand.

Additionally, this choice has set a robust foundation for sending control signals or updates to devices connected to the Hark Platform. This is important because we’re often asked about controlling or updating properties on assets such as set-points of buildings or more complex applications.

MQTT requires a server for these devices to connect to and, prior to building our Cloud MQTT broker, we had to host our own server for each customer using MQTT devices with our platform. There is an additional time and money cost to running individual servers as well as the added time and effort for managing them (it also required a Hark Engineer to set each individual server up with exclusive configuration) – all of this combined meant that a new solution was a must.

That said, the primary motivation for building our cloud broker is to provide a built-in MQTT server that is always on for every organisation in the Hark Platform without the need for our team to set up any additional infrastructure on a customer-by-customer basis. Every organisation on the Hark Platform gets an MQTT server that can be used to connect their devices and sensors and this can be managed by non-developer users who can set up the necessary items within the broker via the user interface in a self-service fashion.

Finally, we will add more in-depth integrations with other areas of the Hark Platform such as protocol adapters and the automation features within the Twin Engine; an example of this could be automatically creating models (the representation of an asset) based on BACnet/IP devices or Modbus/TCP devices.

If you’d like to learn more about The Hark Cloud MQTT Broker, just get in touch today.

Carlos Nisbet
Carlos Nisbet
Share on twitter
Share on linkedin

Related Content

Would you like to find out more about the Hark Platform?

Subscribe to Our Newsletter

Stay up to date with the latest industry news, platform developments and more.