Energy management with Etex

‍

Introducing Etex

Started in 1905, Etex has been pioneering to become a global leader in lightweight construction solutions. Founded and still headquartered in Brussels, Belgium, Etex quickly expanded throughout Europe and the world. Major acquisitions in fire protection, plaster technology, modular construction and engineering have allowed Etex to contribute to the transformation of the construction industry, building on its purpose to Inspire ways of living.

Etex inspires the world to build safe, sustainable, smart, and beautiful living spaces with a wide spectrum of lightweight solutions. From innovative modular systems to leading fibre cement and plasterboard systems. From applications for cladding, façade, roofing and terrace to high-performance fire protection and insulation for construction and OEM applications.

Read also how Etex introduced low-code as part of its Industry 4.0 Program.

‍

Process of optimization

Etex is looking to reduce energy costs and improve its operations by using data to make more informed decisions. Their data teams are tasked with collecting and analyzing data from various sources within the company, such as energy usage data from equipment and facilities, and external data sources like weather data and market trends. The goal is to identify patterns, trends, and opportunities for improvement in the company's energy usage and management

• Data collection

The first step to tackle an energy optimization problem is to collect data. To collect this data, Etex uses a, sensors, meters, and data management tools, both on premise and in the cloud. These tools allow us to track and monitor energy usage in real-time, providing data that can be used to identify patterns, trends, and opportunities for improvement. External data such as weather forecasts are used to complement energy management decisions.

• Exploring and visualizing the data

To understand the characteristics of the data, such as its distribution, patterns, and trends. Visualization tools are used. These tools also help communicate the data in a clear and intuitive way. At Etex, data scientists typically begin by exploring the data and gaining an understanding of the production process. Subject matter experts also provide valuable input at this stage by giving context and setting energy reduction targets. As the exploration progresses, patterns between operational regimes and energy consumption become clearer. The team is able to identify the energy consumption per operational regime. For example, production facilities often have periods of downtime when energy is not being consumed. The startup phase after a downtime is typically highly energy-intensive and is a target for optimization efforts. The normal operation regime is the period when most energy is consumed. Improving energy consumption during normal operation can be complex due to its potential impact on product quality. However, even minor improvements in this regime can yield large absolute gains.

• Model Development

To optimize energy efficiency, algorithms that model patterns and make predictions from the data are developed. Typically, the algorithms used are clusters, classifiers, regressors, and anomaly detectors. Collaboration between data science teams, process engineers and shop floor workers are also critical to guarantee the relevance of algorithms. Equipment settings are often decided by operators based on their experience. An experienced operator may outperform a model. However, the strength of a model lies in its consistency over time. Furthermore, experienced operators may not always be available. As a result, a well-developed model can be a valuable tool for optimizing energy efficiency.

• Trials

Testing different models over extended periods of time is a critical step in the pre-implementation process. This allows the team to compare the performance of different algorithms and identify the ones that are most effective. The team can then iterate through tests to improve the performance of algorithms. Iterations are key. They allow the team to refine and improve the models over time. In addition to testing and iterating on the models, the team may also need to collect additional data and incorporate new insights from subject matter experts to further improve the models. This can help to ensure that the models are based on the most up-to-date and relevant information and are able to provide accurate and useful predictions.

‍

‍

Etex case of downtime analysis

We provided advice to Etex on reducing energy consumption at their plants. Through our analysis, we found that after every downtime, there was an excessive consumption of energy. Corrective actions were taken to mitigate these losses. As Etex continues their energy optimization journey, they will also work with teams of data experts and process experts, as previously mentioned. Investing in the growth of these teams internally will provide significant returns.

The primary goal of the use case with Etex was to reduce the energy consumption of the plasterboard production dryer. The main contributor to energy consumption was gas, so our analysis focused on gas consumption during the production process.

We took the following steps:

• Understanding the data to determine which features were useful and the meaning behind the values.
• Examining the correlation between different parameters and determining the significance and usefulness of these relationships.
• Labeling the data according to different segments of the process.
• Examining the consumption during "stops," or periods of time where there is no production, but the plant is still active.
• Concluding that providing more insight into the process for all stakeholders in the production process would be more effective in the short term.

‍

Next steps for Etex

Next steps for Etex in their energy management roadmap include collecting data from more equipment, implementing higher level dashboards, focusing on continuous improvement, engaging with stakeholders, and monitoring and evaluating progress. These steps can help the company gain a more comprehensive view of their energy usage, make more informed decisions, and drive progress in their energy management efforts.

‍

Conclusion

Energy Management is the systematic use of digital technology to manage and improve the energy consumption of the organisation, and it’s a useful exercise not only for those in the manufacturing industry, but for all companies, big and small. It’s a quick, effective, practical way of determining points for improvement, reducing costs, increasing energy efficiency, and becoming a more sustainable organisation!

Curious on how Mayker helped other customers, or ready to optimise your energy use? We can help you every step of the way - from first analysis to identifying opportunities and implementing the right solutions. Get in touch to discuss energy management in more detail!

Alejandro Simó

Digital Manufacturing Consultant

“Seeking to guide manufacturing companies on their road to digitalization”

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!

‍