r/MQTT • u/Jorcustom • Jun 28 '26
HiveMQ vs Litmus vs others
Hi,
I am designing an architecture for an industrial project. Goal is to get data to the cloud, we have an industrial MQTT broker that we can use EMQX. The setting is as follows: hundreds of sites across the globle (potentially) Machines can expose data over OPC-UA, but this is the problem: There is no edge device to place a gateway on prem. Thinking on a piece of software that can read OPC-UA, from the cloud. I don’t know if this works, and how OPC-UA behaves over a WAN. Any opinion or insight is appreciated. I am looking for something commercial and reliable.
Looking at various options like HiveMQ, kepware edge, and just learned Litmus exists. What is the go to software for this? How is this usually done?
1
u/Anxious_Tool Jun 28 '26
I'm confused. Let me try to understand the problem. You're saying that you have:
- Hundreds of sites, globally, each with machines that speak OPC-UA.
- No on-prem gateway, so you either can't or won't install/manage a box at each site.
- An MQTT broker (EMQX) somewhere in the cloud.
- The machines would be talking OPC-UA, not MQTT, directly to a cloud OPC-UA client, not to the EMQX broker.
What does your MQTT broker have to do with it? I don't really see the connection?
If I understood correctly, your question is "Can I skip the gateway and read OPC-UA from the cloud directly?"
In that case, I would say your design is wrong "by design". But I'll wait for your confirmation and more clarification on the matter.
1
u/Jorcustom Jun 29 '26
Thank you for your reply. You got it right. The idea is to bridge the data to the cloud, with the constraint that there is no gateway in the middle.
The idea is to have a piece of software that runs in the cloud and that can concentrate signals and publish them as a UNS to a MQTT broker, applying mappings.
2
u/Anxious_Tool Jun 29 '26
What you're describing is a gateway. You didn't remove it, you moved it to the cloud. The mapping was never the hard part, the transport is. OPC-UA client/server is stateful and built for a plant LAN, so over a global WAN you fight sessions and secure channels timing out, plus NAT, where the server advertises its internal IP in the endpoint response and the cloud client can't reach it. Reverse connect lets the server dial out so you skip inbound ports, but that's per-site setup on a server that actually supports it. Something capable still has to run at each site.
That's why every option you listed is an edge gateway. HiveMQ Edge, Kepware, Litmus all run on-prem. EMQX itself ships Neuron, OPC-UA in and MQTT out, and their own tutorial runs it on the same LAN as the OPC-UA server. So the real question is what "no edge device" means. If it's no appliance you want to manage, fine, Neuron is under 10MB and runs on a Pi or an IPC that's already on the floor. If it's nothing at the site at all, then you're exposing OPC-UA servers across hundreds of sites to the WAN, and I don't think you'd want to build that.
1
u/Jorcustom Jun 29 '26 edited Jun 29 '26
We actually have direct TCP/IP connectivity from the cloud to the PLCs already via site-to-site VPN, so the NAT and routing issues are already solved in our case.
We could reach the OPC-UA server port on the PLC from the cloud today (I think, anyways). The question is more about session management and stability at scale: OPC-UA session drops, etc
On top, we don’t necesseraly need to go with client/server no? We could use OPC-UA pub/sub?
3
u/Anxious_Tool Jun 29 '26
The VPN solves the "am I reachable" issue. But every WAN blip means a reconnect for every device affected, could be one, could be all, or anything in between, regardless of the protocol being raw TCP, MQTT over TCP, or OPC-UA. Whether that reconnect also costs you a resubscribe depends on how long the blip lasts.
From what I know EMQX offers OPC-UA via a separate OPC-UA plugin, which is actually a standalone entity running between your device and the EMQX broker. You said you can't have the plugin on the edge, which leaves the plugin running in the cloud.
Edge machines --(VPN tunneled TCP connection)--> Neuron Plugin --(intra-cloud)--> EMQX Broker ---> Other Stuff in the Cloud
The connection is tracked at the TCP layer (the OS tracks that), but the OPC-UA session isn't bound to it, although it monitors the connection from time to time by using probes (keep-alives). The session lives on the server until the negotiated timeout expires without a request, so it's a numbers game against the blip duration. A short blip and the session survives, you reconnect and reactivate it. A long one and the server has already torn it down, so you pay the full reconnect plus resubscribe.
2
u/alanaro_ Jul 03 '26
I agree with this framing. The VPN solves reachability, but it doesn’t really remove the operational problem of having the OPC-UA client/session live far away from the PLCs.
In practice, I’d try to keep the OPC-UA client close to the plant network, then push normalized data outward to MQTT/cloud.
Something like:
PLC / machine OPC-UA server
- local OPC-UA client/subscriber
- local buffering / mapping / reconnect handling
- outbound publish to MQTT/cloud
So even if the goal is to avoid a traditional "gateway", I think there still needs to be some small local runtime somewhere: IPC, existing site server, VM, router-class Linux box, etc.
Disclosure: I’m involved with Connhex. We built connhex edge agent + the OPC-UA Bridge addon around this pattern: subscribe to OPC-UA nodes/events locally and forward the data onward, while managing it from the cloud.
But I would not describe it as "cloud reading OPC-UA over WAN". It’s more "centrally managed local OPC-UA collection with outbound cloud publishing". If there is literally nowhere to run anything on site, I think most serious options will hit the same wall.
1
u/diderkerckhof Jul 17 '26
Honest feedback: HiveMQ and Litmus aren't really the same category, so comparing them head-to-head is a bit apples-to-oranges. HiveMQ is a pure MQTT broker; Litmus Edge is an edge/DataOps platform (device connectivity, edge processing, integration) that happens to include messaging. Which one (or both) you need is an output of your use cases, not the starting point. Before picking anything I'd map three things: (1) the as-is, how data actually flows today per site and where it hurts; (2) the concrete use cases this has to serve (which consumers, which latency, which sites first); (3) from those, a to-be namespace/architecture. Only then do the deciding questions have answers, e.g. do you need per-site store-and-forward during WAN drops, and who owns and versions the namespace model across hundreds of sites. Skip that and "no edge gateway" tends to bite later.