PoC to Production in IIoT: Using UNS and HiveMQ Cloud MQTT Platform

Industrial IoT requires efficient testing and development to enable real-time monitoring and data analysis to improve processes and performance. Alejandro Simó and Diederik Vermeersch, experts from Mayker, have harnessed the power of HiveMQ Cloud to streamline these processes, transforming their approach to various projects. Mayker, a leading service company specializing in Industrial IoT solutions, leverages HiveMQ to deliver cutting-edge technology and expertise to clients across various industries. In this blog, Alejandro and Diederik share their experience with HiveMQ and how they use the MQTT platform to provide clients with a Unified Namespace (UNS) to improve data accessibility.

‍

Rapid Prototyping with HiveMQ Cloud Serverless

At Mayker, we frequently undertake PoC projects to explore new technologies and solutions for our clients. HiveMQ Cloud Serverless has become an invaluable tool in these efforts. Its rapid setup and high performance are perfect for the time-sensitive environments in which we operate.

For instance, Alejandro recently used HiveMQ Cloud Serverless to set up an InfluxDB PoC with Node-RED and Grafana. This setup enabled seamless data collection and visualization, which is crucial for monitoring and analyzing industrial processes. The ease and efficiency with which this solution was implemented underscored the power of HiveMQ Cloud Serverless in streamlining complex tasks.

Achieving interoperability is important in industrial settings as diverse systems need a way to communicate and share information. Diederik found HiveMQ Cloud Serverless to be incredibly user-friendly, particularly for projects requiring the integration of different protocols. In one project, he utilized HiveMQ Cloud Serverless to establish bidirectional communication with MQTT using Modbus and Node-RED.

‍

Transitioning to Fully Managed Solutions

While HiveMQ Cloud Serverless is excellent for testing, a fully managed solution is often necessary as projects scale. At Mayker, we frequently transition clients from PoC setups to HiveMQ Cloud. In some cases we choose HiveMQ Cloud over on-premises solutions to eliminate the overhead of maintaining Kubernetes clusters, a significant advantage for clients who lack the internal resources to manage such infrastructure.

One notable example was when we helped a client in the manufacturing sector move from an on-premise setup to HiveMQ Cloud. This shift not only reduced their operational burden but also enhanced their system's scalability and reliability, allowing them to focus on their core business operations.

‍

Unified Namespace (UNS) Approach to Improve IIoT Data Accessibility

A key strategy we employ at Mayker is the UNS approach. This method significantly enhances data integration across various systems, making it easier to manage and analyze data from different sources.

We spearheaded several projects where UNS was implemented to great effect. For example, we implemented HiveMQ Cloud at a manufacturing company with multiple sites in Western Europe. Using HiveMQ as the central component of the new architecture, we helped the client create a scalable UNS to break down silos and make data accessible inside the business.

‍

MQTT and Kafka Integration for Real-time Data Analysis and Monitoring

ntegrating MQTT data with IT systems is crucial for comprehensive data analysis and monitoring. Diederik extensively used the Kafka extension in HiveMQ Cloud Serverless due to its straightforward configuration, which simplifies the process of connecting MQTT data to the Cloud.

For instance, in a project involving an automotive manufacturer, we used the Kafka extension to integrate data from various factory locations into a central system. This integration allowed for real-time data analysis and improved decision-making processes.

Monitoring is another critical aspect of our work. Prometheus monitoring has been invaluable in identifying issues, such as message size limits in the Kafka extension. We have observed that the Prometheus monitoring endpoint in HiveMQ Cloud Professional could benefit from a broader set of metrics. Expanding these metrics would further enhance our ability to perform detailed monitoring and troubleshooting.

‍

Feedback and Recommendation

Our ongoing experience with HiveMQ Cloud has provided us with valuable insights, which we regularly share with the HiveMQ team. We believe that increasing access to extensions in HiveMQ Cloud Serverless would greatly benefit our testing processes. While the Enterprise version of HiveMQ includes a comprehensive set of features, including Prometheus monitoring, adding this feature to the free tier could significantly enhance the fully-managed cloud MQTT broker’s monitoring capabilities.

‍

Conclusion

HiveMQ Cloud Serverless has revolutionized the way we approach testing and PoC projects in Industrial IoT. Its quick setup, ease of use, and high performance make it an indispensable tool for our team at Mayker. As we continue to explore its capabilities, HiveMQ Cloud is poised to play a pivotal role in the future of Industrial IoT development.

For those working on IT and OT integrations in the Industry 4.0 domain, we highly recommend considering HiveMQ Cloud for your testing and development needs. It simplifies processes, enhances data integration, and provides a robust platform for PoC projects, paving the way for innovative advancements in Industrial IoT.

‍

Get in touch with our experts

Diederik Vermeersch
Diederik Vermeersch is a Digital Manufacturing Consultant specializing in (Industrial) Internet of Things (IIoT/IoT). Currently working at the Belgian scaleup Mayker, he brings machines into the digital world with his expertise in OT and IT. His combination of technical skills and professional experience makes him well-suited for bridging the gap between traditional manufacturing and digital technologies.

‍
Alejandro Simó
Alejandro Simó is a results-driven digital manufacturing consultant and systems integrator with expertise in IIoT. Currently at Mayker, he specializes in bridging OT and IT to bring factory floors into the digital world. Passionate about developing and implementing process improvements through automation and data science to realize the factory of the future.

Practical lessons from manufacturing sites: when standalone Node-RED is enough and when you need FlowFuse

‍

‍

Many factories start with Node-RED and do great. One use case, one engineer, one site — it just works. Then a year passes. A second site gets added. A third engineer joins the team. A compliance audit lands on the desk. And suddenly, things get messy.

At Mayker, we work with both every day. We're not selling either product, we're integrators who need to make it work on the factory floor. After dozens of implementations, we've developed a clear sense of when standalone Node-RED is enough, and when FlowFuse becomes the better choice.

This is what we've learned.

‍

What does Node-RED actually do?

Node-RED is an open-source integration tool. Visual, low-code and event-driven. You connect blocks: if this, then that.

But "if this, then that" can be surprisingly powerful. Take a sensor counting products on a production line. On its own, that's just a number. But calculate the time between products, and suddenly you're detecting micro-stops. Add a threshold, and you're flagging anomalies before anyone notices. Combine it with operator data, and you know who was on shift when something went wrong.

That's what Node-RED does: it takes raw data from machines and sensors, enriches it with context, and turns it into something useful. From "a product passed" to "the line stopped for 5 seconds during operator X's shift."

It's free, flexible, and great for prototyping. For a single use case or proof of concept, it's excellent.

‍

What is FlowFuse  and how does it relate to Node-RED?

FlowFuse is built by the initial core team behind Node-RED, but designed for production environments. Same Node-RED engine underneath, but wrapped in everything you need when you're no longer prototyping:

• Version control: see who changed what, when, and roll back if needed
• Role-based access: operator X can view dashboards, engineer Y can edit flows, manager Z approves deployments
• Central management: one overview of all your instances across sites
• Audit trails: essential for NIS2 and other compliance requirements
• Fleet deployment: update dozens of instances at once instead of one by one

Think of it this way: Node-RED is the engine. FlowFuse is the garage, the maintenance schedule, and the fleet manager,  all in one.

Node-RED and FlowFuse in practice: four use cases

We've implemented both tools across different customers and situations. Sometimes FlowFuse was the obvious choice, sometimes standalone Node-RED still does the job.

‍

Detecting micro-stops with FlowFuse across 7 sites

A food producer wanted better visibility into their packaging lines. Sensors were already counting products, but the raw numbers didn't tell them much.

We designed a standardized flow that calculates the time between products passing. If that gap exceeds a threshold, it's flagged as a micro-stop. We enrich each anomaly with timestamp, production batch, and operator on shift,  turning a simple count into an actionable insight.

This now runs across 7 sites worldwide: Belgium, Thailand, the US, and more. Same code, developed once, deployed centrally. When we improve the logic, it rolls out everywhere. With standalone Node-RED on each site, we'd be managing 7 separate versions with no guarantee they're in sync. FlowFuse made central deployment and version control possible.

‍

Multi-site harvest workflow with FlowFuse

Harvest season at a vegetable processor means two months of trucks arriving non-stop. Farmers want to dump their load and get back to the field, fast.

We built an operator app on the weighbridge. The farmer enters their ID, the system captures weight and license plate automatically, and assigns a silo based on product type and available capacity. What used to be chaos — trucks waiting, wrong silos, lost paperwork — became a structured flow.

This app runs on three sites. Updating one means updating all three. With standalone Node-RED, that's three manual interventions and three chances for version drift. With FlowFuse, we deploy once and push to all locations. We see at a glance that all three run identical code  and when harvest season ends, we know exactly what version ran where.

‍

Energy monitoring across sites with FlowFuse

A vegetable processor operates two freezer warehouses, each with its own energy bill but no way to compare consumption patterns or spot inefficiencies across sites.

We stream energy data from both locations to a central FlowFuse instance in the cloud, where it's aggregated and visualised. The insight that emerged: running freezers at -13°C costs nearly twice as much as -12°C. For most products, that one degree doesn't affect quality  but it cuts the energy bill significantly.

You could run a standalone Node-RED instance in the cloud for this. But then you're back to manual management: no central overview of what's running where, version control or SSO. FlowFuse gives us a managed environment where cloud instances and edge devices are visible and controllable from one dashboard.

‍

ERP-to-machine integration with Node-RED

At one food processor, Node-RED handles the translation between ERP and machines. Purchase orders come in, get translated into production instructions, and the line runs.

They're not using FlowFuse here. Why? They have a dedicated IT/OT person who manages all instances. One person, full overview, no handovers.

It works  but it's fragile. That knowledge sits in one head. When that person is on holiday, nobody touches the system. When they leave, there's a problem. We see this pattern often: Node-RED works fine until it doesn't, and by then migration becomes urgent rather than planned.

‍

Signs your Node-RED setup is reaching its limits

Over time, we've noticed a few recurring situations that push teams towards FlowFuse:

"Who changed this?" At one customer, this question comes up every single day. Someone modified something, something stopped working, and there's no trace. In standalone Node-RED, there's no version control, no audit trail, no way to look back three months and see what happened. With FlowFuse, every change is logged: who, what, when.

Overwriting each other's work Multiple people working on the same flows. Someone deploys, someone else was also editing. Work gone. In Node-RED, you can't even see that someone else is online. We've seen this happen daily at manufacturing clients. With FlowFuse, you see each other's cursors in real-time, and deployments require approval.

Manual updates across sites One building materials company ran Node-RED on over 100 sites worldwide. Every software change had to be executed manually — a hundred times. That's not scalable. With FlowFuse, you deploy to development, test, approve, and roll out to all production instances in one action.

Access through jumpservers and RDP Excuse us for going a little technical here. At one customer, engineers needed a jumpserver and RDP session before they could even reach their Node-RED instances. Key users couldn't access anything without IT support. FlowFuse offers SSO integration and browser-based access — the right people get to the right instances directly.

We've seen this go wrong firsthand. At one customer, two sites were running different Node-RED flow versions for months, different alarm thresholds and nobody was aware. It caused significant inconsistency in quality comparisons across plants. The kind of problem that's invisible until it does real damage.

‍

Node-RED vs FlowFuse: when to choose what

Our rule of thumb:

• One instance, one person, one goal? Standalone Node-RED is fine.
• Multiple people, multiple sites, or compliance requirements? FlowFuse saves you time and frustration.
• Not sure how many instances you'll have in a year? Start with Node-RED, but standardise from day one with consistent naming conventions, units and topic structures. That makes a future migration to FlowFuse straightforward rather than a rebuild.

‍

See it yourself

In our demo factory in Ghent, FlowFuse runs on 20+ instances. If you want to see what this looks like when it's actually running, you're welcome to pay us a visit.

Let us know!

‍