Inter-process/target MQTT Communication with Local Broker and Bridge

[Jordan Kuehn]

I have an application where I have a handful of windows and linux cRIOs (and potentially RPis) that all need to talk to each other and (already) communicate to an existing remote MQTT AWS instance. Some of the discussion at the end of this topic is relevant as I've looked at DDS, but I didn't want to resurrect that post and take it further off topic. The licensing for DDS is quite expensive and they don't have a "LabVIEW toolkit" pricing package, rather a mix of product line pricing per project and developer licenses. The speed and "determinism" of the databus is attractive, but perhaps unnecessary for this application. The built in LabVIEW options aren't as flexible as I would like in regard to automatic discovery and establishing connections (and NSVs are not supported on RPi, but streams might be?), but I would be happy to have my mind changed.

This all is to say I keep coming back to the concept of using MQTT locally as well as remotely and bridge the brokers, much of the logic is in place or could expand to fit the local requirements. The local communication would handle commands and tags/current values between systems and the brokers would package a subset of that to be sent remotely. This blog post from 2017 gave me some inspiration.

Has anyone gone down this road and has any feedback or suggestions pro/con?

 

Edited May 28, 2020 by Jordan Kuehn

[G-CODE]

The two people who gave this presentation might be able to point you in the right direction.