Is there an updated client for VB6 (COM/OCX-type) that I can use with the HiveMQ broker?

HiveMQ Client Library
1

Hello!
I’m working on updating a project that requires connecting a process from a VB6-based system to the Node-RED or Flowfuse platform. This is also motivated by the upcoming first stable release of TwinBasic (https://twinbasic.com/), a modernized, fully compatible successor to VB6, which looks very promising.

My question:
Is there an updated client for VB6 (COM/OCX-type) that I can use with the HiveMQ broker?

Thank you!

2

Hi @lfeche

Thanks for reaching out! Welcome aboard to the HiveMQ Community! It’s fantastic that you’re interested in MQTT and the HiveMQ broker. We’re thrilled to have you as part of our community.

At the moment, HiveMQ officially offers MQTT client libraries for Java and C#. Unfortunately, we don’t provide a COM/OCX-type MQTT client specifically for VB6 or TwinBasic.

If you’re exploring ways to connect a VB6-based system to HiveMQ, you might consider using an external MQTT client as a bridge (e.g., via a lightweight script or service in C# or Python) that communicates with your VB6 application through standard inter-process communication methods.

Best regards,
Dasha from HiveMQ Team

1 Like
3

Hi Dasha and the HiveMQ Team,

Thank you for the warm welcome and for outlining the current options!
While the bridge approach via external scripts/services is a practical workaround, I’d like to propose an alternative path that could benefit both legacy systems and the HiveMQ ecosystem: developing a native VB6 MQTT client, potentially as an open-source initiative.

Why a Native VB6 Client?

  1. Legacy System Relevance:
    Many industries (manufacturing, healthcare, logistics) still rely on VB6 for mission-critical applications. A direct MQTT client would simplify modernization efforts, eliminating the need for complex IPC bridges.

  2. Performance & Simplicity:
    A native client would reduce latency and overhead compared to multi-layer solutions, while offering VB6 developers a seamless “out-of-the-box” experience with HiveMQ.

  3. Community-Driven Opportunity:
    This could spark collaboration across developers who maintain legacy systems. An open-source project on GitHub would allow the community to contribute, test, and refine the client, ensuring long-term sustainability.

Proposed Next Steps:

  • Proof of Concept:
    Start with a minimal VB6 MQTT client (e.g., TCP/IP socket implementation with HiveMQ’s MQTT 3.1.1/5.0 support). Focus on core features like connect, publish, and subscribe.

  • GitHub Repository:
    Create a public repo under the HiveMQ Community umbrella (or an independent org) to invite contributors. Documentation, sample code, and issue tracking would accelerate development.

  • Leverage Existing Libraries:
    Adapt lightweight MQTT logic from C#/Python libraries (e.g., message serialization) into VB6-compatible code, ensuring compliance with HiveMQ’s broker features.

Why HiveMQ Should Consider Supporting This:

  • Expand Reach: Tap into legacy markets that are often overlooked but represent a significant user base.
  • Community Engagement: Foster goodwill by addressing niche needs, reinforcing HiveMQ’s commitment to diverse MQTT adoption.
  • Future-Proofing: As TwinBASIC (a VB6-compatible modern compiler) gains traction, this client could bridge legacy and future projects.

Call to Action:

If HiveMQ is open to endorsing or promoting such an initiative, I’d gladly help draft specifications or collaborate on the initial architecture. Let’s discuss how to align this with community goals!

Looking forward to your thoughts.

Best regards,