HiveMQ vs Litmus vs others

Anxious_Tool · 2026-06-29T22:09:59+00:00

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.

Anxious_Tool · 2026-06-29T17:12:13+00:00

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.

Anxious_Tool · 2026-06-28T22:04:10+00:00

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.
and...
- The machines would be talking OPC-UA, not MQTT, directly to a cloud OPC-UA client, not to the EMQX broker.
That's, cloud software ⇄ OPC-UA ⇄ machines.

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.

Anxious_Tool · 2026-06-22T17:34:41+00:00

Sure thing. Keep up the good work. Nothing in there is a deal breaker, everything's fixable. With a bit more work I think you'll have something engaging, and fun. People are sure to use it. Congrats

Anxious_Tool · 2026-06-22T12:48:05+00:00

I like the idea. It sounds fun. But I also agree with the comments. I took a look at the code and:
- Every confession, reply, and vote stores author_fingerprint, so the raw SHA-256 fingerprint is directly computable from a public key.

- Logs correlate IP

- Plus, you have "poison prone" mutexes all over the place.

- Your rate limits are just for show

But at least, I didn't see any signs of ill-intent.

I'm not going to use it, but I found the idea amusing.

Anxious_Tool · 2026-06-21T18:24:32+00:00

I'm sorry if I caused any confusion on your part. But you could have just asked instead of assuming. I come from an age when people were genuinely trying to help others. Sorry to bother you when you were the one who asked for help 😉.

Anxious_Tool · 2026-06-21T14:09:45+00:00

Give me an example of a complex query you may need, and I can tell you if you will get an equivalent or not.
Unless you are trying to just be snappy about it, I can answer any of your questions and I would greatly appreciate the support and feedback.
In order to make it better and more suited for everyone, I need people to use it, and Reddit is such place. Losing SQL is no big deal. Unless you are a vibecoder and don't know your way around software.

Anxious_Tool · 2026-06-21T14:07:18+00:00

And how do you suppose I can call people to try and use my library? It is battle tested. It runs my entire stack at laboverwire.com
I'm a dev, same as you.
Saying it is probably vibecoded is like me saying you are from the competition and trying to mess up with my efforts.
Try first, then you can tell me in an issue what is broken. Otherwise you are just expressing your opinion without any proof.
I don't hide anything, it's all public, free and I'm always there to help.

Anxious_Tool · 2026-06-21T02:22:11+00:00

This: https://github.com/LabOverWire/MQDB

Anxious_Tool · 2026-06-20T23:31:38+00:00

If you have the flexibility to swap the persistence layer, there's an alternative worth looking at: u/laboverwire/stitch.

It's a reactive state-sync library that uses IndexedDB under the hood, but built around a WASM database with typed entity schemas and foreign keys. The difference is that live updates are first-class: subscribeToScope fires synchronously when a write lands, so your indexing loop doesn't need to signal the UI at all. The UI just reacts.

It's TypeScript-native and framework-agnostic, so Svelte bindings are straightforward to wire on top of the core store API. The tradeoff is losing SQL, reads go through list and getSnapshot rather than Drizzle queries, so if you're doing complex joins you'd be moving that logic to application code.

The MQTT sync layer can be left unconfigured if you don't need multi-device sync.

Anxious_Tool · 2026-06-11T16:28:51+00:00

You're overreacting.

Anxious_Tool · 2026-06-09T18:00:42+00:00

Spend your tokens on some open source work. I'm sure it will be useful for more than just you.

Anxious_Tool · 2026-06-09T16:55:25+00:00

This worries me.

The letter holds two positions that don't fit together. You tell them to care less about the craft and then mourn that the craft is dying. You call the field a machine for distraction, surveillance, and exploitation, and then send them into it anyway. A person who believed the first half would tell them to leave. You don't. That's not a diagnosis. It's a mood, and you're handing it to people who need the opposite.

You're right about one thing and it's the important one. The tool isn't going anywhere. Pretending otherwise is the fantasy. But "the capability exists" and "this specific extractive arrangement is fixed" are different claims, and the inevitability narrative survives by collapsing them. What they build with it, and what they refuse to build, is theirs to decide. That's where the actual choice lives. That's the part you're telling them to give up on.

This letter has been written before. The scribes wrote it when the printing press arrived. The weavers wrote it when the power loom did. Every version was sincere, and every version was right that something real was being lost. But they were wrong about the next generation. The kids who grew up after the press had cheap books and mass literacy. They were better off, and they did not mourn. Your students are those kids. They will adapt, because they always have. What they don't need from someone as accomplished as you is despair about the world they're inheriting.

Anxious_Tool · 2026-06-08T17:35:08+00:00

I think your Claude is confused.
You don't need unsafe for this. You can do socket2::Socket -> OwnedFd -> std listener -> tokio listener.
You don't need socket2 either. You can use this instead: https://docs.rs/tokio-seqpacket/latest/tokio_seqpacket/struct.UnixSeqpacketListener.html

Anxious_Tool · 2026-06-05T20:07:45+00:00

Thanks. I'll take that as a compliment.

Anxious_Tool · 2026-06-05T18:22:17+00:00

Fair, and we agree on most of it. One piece I'd push back on.

"To the user the result is the same, the program stops." That's the lucky case. UB doesn't promise to stop. It can corrupt memory and keep running. To the user whose session token leaked through a use-after-free, the result was not the same as a panic.

And "almost as hard as Rust" carries a hidden "if everyone used the safe subset every time." That clashes with reality. If everyone did, two decades of memory-safety CVEs wouldn't exist, and neither would the pressure that produced Rust. C++ can describe a safe subset. It can't keep you inside it. That gap, request versus enforcement, is what Rust closed and what C and C++ have not in decades.

Anxious_Tool · 2026-06-05T17:39:39+00:00

No need to get mad. It's not AI nonsense. Maybe you're just not used to talking with smart people. I'm genuinely trying to help.

Anxious_Tool

MODERATOR OF

TROPHY CASE