But wait… why do we need MES in this pipeline at all? Some might argue that tools like Node-RED or n8n are enough to build this kind of integration pipelines.

Suppose we want to generate Equipment State topics and publish them to MQTT as UNS topic.

The construction of UNS topics follows a set of rules. A UNS topic has a structure aligned with ISA‑95: Facility → Site → Area → Resource → Event. From there, it can be enriched with additional information relevant to the event being observed.

In simple scenarios like the one under analysis, the complementary information could be retrieved from an external source, such as a centralized equipment database maintained by an EAM - Enterprise Asset Management system for example.

But imagine the event you want to publish is a TrackIn. How do you enrich the raw data coming from the equipment? That contextual layer is precisely what MES provides. Pulling all this context into an external pipeline like Node‑RED is certainly possible — but at some point, it becomes counter‑productive.

A more straightforward and robust approach is to bring the flow of information into MES and let the Data Platform pipelines naturally enrich it:

• The equipment state‑model change along with other common shop-floor operations are core IoT Events in MES, and they already carry rich contextual information that can directly support UNS requirements and any additional needs.

• For more advanced scenarios, MES can be extended — for example, sending an alert whenever a machine parameter is out of the control limits.

So, let’s unfold this journey from MQTT to UNS topics in the next sections and take a few stops along the way to admire what we will earn in the voyage.

Introduction

We’ll start by demoing how to design a simple simulator with behavior closer to real equipment, capable of generating MQTT topics. Then we’ll define the ConnectIoT workflows to capture and observe how information naturally flows through MES while being enriched. Finally, we’ll explore how MES out-of-the-box functionality generates the corresponding UNS topics. Of course, we’ll also demonstrate extensibility through our Discord integration.

MQTT Simulator

The same plugin used in the test orchestrator can be used to simulate our MQTT Broker in a simple .NET project. This can be easily achieved with a few steps.

Let’s start from the beginning, step by step.

Create a directory to hold your project and initialize a .NET console application.

dotnet new console -n MQTTSimulator

This will create the scaffolding for your project.

To fetch the MQTT plugin from CM repository, configure the nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="CMF" value="https://criticalmanufacturing.io/repository/nuget-hosted/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <disabledPackageSources />
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
</configuration>

Copy all the libraries needed to our simulator to the libs directory:

In the project MQTTSimulator.csproj, include all the packages we need for our simulator:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Cmf.ConnectIoT.TestOrchestrator.Core.Common" Version="11.2.0-alpha24" />
    <PackageReference Include="Cmf.ConnectIoT.TestOrchestrator.Core.ScenarioBuilder"
      Version="11.2.0-alpha09" />
    <PackageReference Include="Cmf.ConnectIoT.TestOrchestrator.Plugin.Simulator.MQTT"
      Version="11.2.0-alpha08" />
    <PackageReference Include="Cmf.ConnectIoT.TestOrchestrator.Plugin.StartMode.Local"
      Version="11.2.0-alpha10" />
  </ItemGroup>

  <ItemGroup>
    <Reference Include="Cmf.LightBusinessObjects">
      <HintPath>Libs\Cmf.LightBusinessObjects.dll</HintPath>
    </Reference>
    <Reference Include="Cmf.LoadBalancing">
      <HintPath>Libs\Cmf.LoadBalancing.dll</HintPath>
    </Reference>
    <Reference Include="Cmf.MessageBus.Client">
      <HintPath>Libs\Cmf.MessageBus.Client.dll</HintPath>
    </Reference>
    <Reference Include="Newtonsoft.Json">
      <HintPath>Libs\Newtonsoft.Json.dll</HintPath>
    </Reference>
    <Reference Include="SuperSocket.ClientEngine">
      <HintPath>Libs\SuperSocket.ClientEngine.dll</HintPath>
    </Reference>
    <Reference Include="System.Configuration.ConfigurationManager">
      <HintPath>Libs\System.Configuration.ConfigurationManager.dll</HintPath>
    </Reference>
    <Reference Include="System.Data.OleDb">
      <HintPath>Libs\System.Data.OleDb.dll</HintPath>
    </Reference>
    <Reference Include="System.Net.Http.Formatting">
      <HintPath>Libs\System.Net.Http.Formatting.dll</HintPath>
    </Reference>
    <Reference Include="WebSocket4Net">
      <HintPath>Libs\WebSocket4Net.dll</HintPath>
    </Reference>
  </ItemGroup>

  <ItemGroup>
    <Folder Include="Objects\" />
  </ItemGroup>

</Project>

The first steps to design the Simulator are complete.

Next, the classe ScenarioRunner.cs will implement all the logic of our simulator:

using IoTTestOrchestrator;
using MQTT;
using MQTT.Plugin;
using ScenarioBuilder.Implementations.Configuration;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Text.RegularExpressions;

namespace MQTTSimulator
{
    public class ScenarioRunner
    {
        private TestScenario? _scenario;

        public ScenarioRunner()
        {
        }

        public async System.Threading.Tasks.Task RunAsync(string[]? args = null)
        {
            var scenario = new ScenarioConfiguration()
                .WriteLogsTo("c:/temp/MQTT-Simulator.log")
                .ManagerId("MQTTManager")
                .ConfigPath("C:\\IOT\\AutomationManager\\AutomationManagerDemo\\config.full.json")
                .AddSimulatorPlugin<MQTT.PluginMain>(new SettingsBuilder()
                    .Address("localhost", 1883)
                    .StartBroker(true)
                    .Build());

            _scenario = new TestScenario(scenario);
            var context = _scenario.Context();
            MQTT.PluginMain? mqttSimulator = context.Simulators["MQTT"] as MQTT.PluginMain;
            using var cts = new CancellationTokenSource();
            try
            {
                _scenario.Start();
                _scenario.StartSimulators();
                Console.WriteLine("[CNC] Waiting for MQTT broker...");
                await WaitForMqttReadyAsync(mqttSimulator!, cts.Token);
                Console.WriteLine("[CNC] MQTT ready.");
                Console.WriteLine("Press 'q' to quit...");
                while (!cts.IsCancellationRequested)
                {
                    //Publish a simple topic
                    string topic = "test/topic";
                    string value = "Hello, MQTT! " + DateTime.Now.ToString("O", CultureInfo.InvariantCulture);
                    mqttSimulator!.Publish(topic, value);

                    if (Console.KeyAvailable)
                    {
                        var key = Console.ReadKey(true);
                        if (key.KeyChar == 'q')
                        {
                            cts.Cancel();
                        }
                    }
                    await Task.Delay(1000, cts.Token);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"[ERROR] {ex.Message}");
            }
            finally
            {
                _scenario.ShutdownSimulators();
                _scenario.Shutdown();
            }
        }

        private static async Task WaitForMqttReadyAsync(PluginMain mqtt, CancellationToken ct)
        {
            // Probe TCP port 1883 until the embedded broker is actually accepting connections,
            // then allow a short stabilisation window for the MQTT client to authenticate.
            while (!ct.IsCancellationRequested)
            {
                try
                {
                    using var tcp = new System.Net.Sockets.TcpClient();
                    await tcp.ConnectAsync("localhost", 1883, ct);
                    // Broker is listening — give the MQTT client time to finish its handshake.
                    await Task.Delay(800, ct);
                    return;
                }
                catch (OperationCanceledException) { throw; }
                catch
                {
                    await Task.Delay(200, ct);
                }
            }
        }
    }
}

In Program.cs run the Scenario.

namespace MQTTSimulator
{
    internal class Program
    {
        private static async Task Main(string[] args)
        {
            Console.WriteLine("Starting Scenario Run");
            await new ScenarioRunner().RunAsync(args);
            Console.WriteLine("Finished Scenario Run");
            
        }
    }
}

There are a few things I would like to highlight.

The Simulator implements an MQTT Broker using the plugin provided by the Test Orchestrator. It needs the config.full.json file from the Automation Manager connected to MES and the address and port where the Broker will be published. Unlike what is typically needed in a test scenario, the Broker should keep running until it is no longer necessary, so I use a simple console polling loop that keeps the process alive and terminates only when the Q key is pressed.

Finally, build the solution:

dotnet build

The project should be something like this:

To execute run the following command:

dotnet run

Using MQTT Explorer, we can connect to the MQTT Broker at localhost port 1883.

This is our Minimum Viable Project (MVP). But our challenge is to go further and implement additional functionality that brings us closer to the behavior of a real machine, like a CNC for example.

A vast amount of documentation exists on the internet explaining how a real CNC actually works, which you can reference. Or a simple prompt in your favorite LLM will do the trick too.

For our example, we’ve implemented the following functionalities in our CNC simulator:

• Loading a real G‑code file
• Interpolating the tool path and moving the CNC head according to the provided G‑code file
• Simulating the head temperature
• Starting the simulation with S
• Triggering an anomaly by pressing the A key
• Quitting the simulation with Q

ConnectIot Workflows

With our equipment simulated and pushing topics to our MQTT Broker, let’s continue our journey.

Now, we need to create a protocol that understands MQTT, with the address and port being the only things we need to configure:

For the driver, 3 topics receive the values the equipment publish:

Also, 3 events will listen to detect when each topic changes:

The driver looks like this:

The controller responsible for handling the pipeline starts, as usual, with the setup phase.

In our example, the address and port are already defined in the protocol itself, so there’s no need to configure them in the controller. In real‑world scenarios, however, it’s far more common to store all required parameters in a Configuration Entry and apply them during the OnSetup phase.

Temperature Event

The first topic we will handle is temperature. For this type of data that is not directly related to any MES entities, MES provides the ability to collect data points using a special IoT Event called PostTelemetry, you can check all the APIs here.

Under the Data Platform area in MES, you can find all IoT Events implemented by MES, including the option to create new ones:

This PostTelemetry follows a standard format and is commonly used to ingest high‑cadence process parameters such as temperatures, vibration levels, speed, and other signals. These values are stored directly in the Data Platform for analytics, dashboards and to train Data Mining models for example.

The workflow is triggered by the temperature_change event and publishes the data using PostTelemetry.

If you look closely, you’ll notice that a few additional transformations and enrichment were applied. The resource information is passed along and the temperature topic arrives as a JSON payload that includes several fields not relevant to our use case.

{"temperature": 80.5, "setpoint":80, "state":"at_temperature"}

To extract the temperature value, I used the Get Object Property

Status Event

The next ingestion we want to perform is the change of equipment status caused by an anomaly.

To simulate this event, pressing A in the simulator causes the equipment to gradually increase the temperature until it reaches the defined limit. This will trigger the Change of Status of the equipment and also a notification with a pop up, alerting that the machine has entered a fault state.

The status topic value is a string, so no further transformation is needed.

The status can assume also other values, depending on which phase the equipment is:

Using the SEMI-E10 model the resource State will be adjusted accordingly:

Position Event

For the position_event, the topic is also an object, making a Get Object Property converter necessary to extract the correct information.

{"x":0,"y":0,"z":5,"feedrate":3000,"mode":"home"]

For demonstration purposes, this information is only dumped to the log.

Data Enrichment and Visualization

After instantiating the Controller in our Automation Manager we can start the simulator and observe MES ingesting the data:

The head’s coordinates were logged (1), the PostTelemetry event was successfully published to the Data Platform (2) and the anomaly behaved exactly as expected: the trigger fired, the corresponding event was raised, and the equipment transitioned into a Non‑Scheduled state (3).

But there are also other interesting things happening under the hood.

Each data point published through PostTelemetry is stored in the Data Platform. By inspecting the PostTelemetry dataset, you can view these values in the Data Folder, already enriched with the contextual information provided by MES and explicitly implemented in the Status Workflow.

The status changes from the machine were also sent to the Data Platform data lake.

For each change in the Resource Status the following happens:

The CDM IoT Event ResourceStateChange is triggered:

And a new record is saved to the correspondent CDM DataSet :

Both datasets can be explored in several ways: as Dashboards in Grafana, as reports in Stimulsoft, or consumed externally as an OData data source in tools like Power BI or Excel, or even used to train machine learning models.

OOB UNS Integration

To generate the UNS topics, MES uses a special type of workflow designed specifically for the Data Platform. These workflows are triggered differently: instead of being invoked by a standard event, they listen to an IoT Event. When that event is raised, the workflow executes the corresponding logic within the context of the data that triggered it.

As previously explained, a Change Status operation raises the ResourceStateChange IoT Event. This means that if this IoT Event is configured as the trigger for a Data Platform workflow, the associated logic will be executed automatically.

What we need to construct the UNS topic is simply to extract the Resource from the context and then derive the remaining ISA‑95 levels required for the topic structure.

But you don’t need to worry about designing this workflow yourself — the transformation into a UNS topic is provided out of the box. With the Automation Controller window open the Cortex will guide design the right logic.

With all set the topic is published in the configured MQTT Broker with the ISA-95 tree-structured, with the value enriched with all the context MES has associated with the event.

But you don’t need to worry about designing this workflow yourself — the transformation into a UNS topic is provided out of the box. With the Automation Controller window open, Business Scenario guides you through the design.

Customized Automation Task Libraries

One last destination is missing before we conclude our journey: the possibility to extend Connect IoT with complementary capabilities to enrich the pipeline even further. The perfect example is the ability to send notifications to Discord.

This kind of extensibility is possible using the Automation Task Libraries.

In any customization project, under the /Cmf.Custom.IoT/Cmf.Custom.IoT.Packages directory where the cmfpackage.json resides, run the command

cmf new iot tasklibrary

A new package is created. Under the package directory run the command to create your task:

cmf new iot task 

At least an input parameter named message and two output parameters called success and error to provide feedback are necessary. Also a setting called webhookUrl to configure the webhook URL should be defined too.

After answering a few questions, the scaffold for the Task is created and ready to be customized:

The project tree should be something like this:

All the magic happens in the method OnChange of our task, that will make a POST to the Web hook of your discord server.

To obtain the webhook, navigate to your Discord Server and under Settings/Integrations/Webhooks, you can copy the value:

The value should be pasted later in the Send to Discord Settings page:

The complete code for the task is this:

import { Task, System, TaskBase } from "@criticalmanufacturing/connect-iot-controller-engine";
import * as https from "https";
import * as http from "http";
import { URL } from "url";

/** Default values for settings */
export const SETTINGS_DEFAULTS: SendDiscordMessageSettings = {
	webhookUrl: "",
};

/**
 * @whatItDoes
 *
 * Sends a message to a Discord channel via a configured webhook URL.
 *
 * @howToUse
 *
 * Configure the `webhookUrl` setting with your Discord webhook URL.
 * Connect a string value to the `message` input and trigger `activate`.
 *
 * ### Inputs
 * * `any`    : **activate** - Activate the task
 * * `string` : **message**  - The message content to send to Discord
 *
 * ### Outputs
 *
 * * `bool`  : **success** - Triggered when the message is sent successfully
 * * `Error` : **error**   - Triggered when the task failed for some reason
 *
 * ### Settings
 * See {@see SendDiscordMessageSettings}
 */
@Task.Task()
export class SendDiscordMessageTask extends TaskBase implements SendDiscordMessageSettings {

    /** **Inputs** */
    /** Message to send to the Discord channel */
    public message: string = "";

    /** **Outputs** */

    /** Properties Settings */
    /** Discord webhook URL */
    webhookUrl: string;

    /**
     * When one or more input values is changed this will be triggered,
     * @param changes Task changes
     */
    public override async onChanges(changes: Task.Changes): Promise<void> {
        if (changes["activate"]) {
            // Reset activate to allow re-triggering without value change
            this.activate = undefined;

            try {
                await this._sendDiscordMessage(this.webhookUrl, this.message);
                this._logger.info(`SendDiscordMessage: Message sent successfully to Discord: ${this.message}`);
                this.success.emit(true);
            } catch (error) {
                this._logger.error(`SendDiscordMessage: Failed to send message: ${error}`);
                this.error.emit(error);
            }
        }
    }

    /** Sends a POST request to the Discord webhook URL with the given message */
    private _sendDiscordMessage(webhookUrl: string, message: string): Promise<void> {
        return new Promise((resolve, reject) => {
            const body = JSON.stringify({ content: message });
            const parsedUrl = new URL(webhookUrl);
            const options = {
                hostname: parsedUrl.hostname,
                path: parsedUrl.pathname + parsedUrl.search,
                method: "POST",
                headers: {
                    "Content-Type": "application/json",
                    "Content-Length": Buffer.byteLength(body),
                },
            };

            const transport = parsedUrl.protocol === "https:" ? https : http;
            const req = transport.request(options, (res) => {
                if (res.statusCode && res.statusCode >= 200 && res.statusCode < 300) {
                    resolve();
                } else {
                    reject(new Error(`Discord API responded with status ${res.statusCode}`));
                }
                res.resume();
            });

            req.on("error", reject);
            req.write(body);
            req.end();
        });
    }

    /** Right after settings are loaded, create the needed dynamic outputs. */
    public override async onBeforeInit(): Promise<void> {
    }

    /** Initialize this task, register any event handler, etc */
    public override async onInit(): Promise<void> {
        this.sanitizeSettings(SETTINGS_DEFAULTS);
    }

    /** Cleanup internal data, unregister any event handler, etc */
    public override async onDestroy(): Promise<void> {
    }
}

/** SendDiscordMessage Settings object */
export interface SendDiscordMessageSettings extends System.TaskDefaultSettings {
    /** Discord webhook URL */
    webhookUrl: string;
}

To prepare the package to be imported to MES, run in the package directory the following commands:

# Install dependencies
npm install

# Build
npm run build

# Pack into .tgz
npm pack

In MES navigate to the Automation Repository and add your new Package.

Finally in your workflow we can add our new task to send a Discord Message:

Now MES also send a message to a Discord Server channel when the machine enter in fault.

More details on how to implement customized tasks can be found in the documentation

For more detailed information on creating and implementing custom Automation Task Libraries, refer to the Customization Task Library.

Conclusion

As any passionate voyager will tell you, the best part of any journey isn’t the destination, but the path you take to get there. And we’ve seen just how much richer that path becomes when MES is on board. This journey, from raw MQTT data to MES enriched UNS topics highlights the true power of integrating equipment directly into MES. We’ve shown also how a simple simulator can approximate a near‑real data pipeline prepared to captures real‑time equipment data and enriches them with contextual information ready to be used in dashboards, reporting, and even model training.

Author

Hello, my name is Rodrigo Cordeiro. I’m passionate about machine integration, automation and transforming industrial data into clear, useful, decision‑ready insights.

You can reach me on LinkedIn

Skills: ConnectIoT | Data Analyst | Data Scientist

If the coffee machine has IoT capabilities, you can go even further. The entire lifecycle of the coffee cup can be fully integrated into Critical Manufacturing MES, from material consumption to machine events, creating a complete digital thread for your morning espresso.

A recent international industrial exposition (Hannover Messe), where CM will participate with a booth, provided the perfect opportunity to revisit this project, upgrade it to Version 11 of MES and demonstrate how far this simple idea can go.

The original sin

Let me start from the beginning. A few years ago the ConnectIoT team was challenged to integrate a Nespresso machine with MES in version 6. At that time, the only information available was that the equipment communicated via the BLE protocol and through the official mobile application, the machine could be instructed to brew coffee and several relevant information could be retrieved too.

After extensive investigation, using not always “official” tools and methods — we were able to extract all the necessary information to enable full integration.

For the specific Nespresso model used in this Proof of Concept, the following parameters are required to configure the BLE communication protocol:

In the BLE protocol, data points of the equipment are exposed as BLE Characteristics. The Nespresso machine is no different:

Likely in other protocol, the Events are a key element in the communication with the equipment. An Event is triggered when something changes in the machine, in our case we need:

In MES, the driver used to integrate the Nespresso machine looked like this:

If you want a deeper understanding of how the Nespresso machine works and the reverse‑engineering techniques involved, consult the documentation below. These resources provide additional insights and practical examples how similar process were carried out:

• https://github.com/brandtoliver/brew-api
• https://gist.github.com/farminf/94f681eaca2760212f457ac59da99f23

Modelling

The modelling itself can be as simple as brew me a coffee with a button click or as sophisticated and complex as you want. A more robust modelling could allow the measuring of water and energy in each of the brews using for example BOMs and Consumable Feeds. Nevertheless, by default MES gives you the daily production of coffee by type with just the TrackIn/Trackout logic and the timeline of production/standby from the resource state, or even the OEE. But let’s not overcomplicate things.

The intention is to demonstrate how this type of integration can be achieved, focusing primarily on the ConnectIoT perspective. Once the communication layer is in place, the possibilities for building visually appealing dashboards, feature‑rich functionalities or technically challenging scenarios are virtually endless.

A flow with two steps allows the Nespresso to be fully integrated in the MES logic. A set of Coffee Materials, based in the CoffeeCapsule Product, is created in the step Nespresso with state Queued whenever a new box of capsules is put at the disposal of the machine. When the machine starts brewing the material coffee is Dispatched and TrackedIn and stays in process till the machine informs MES that the brew is finished. Considering the brew selected the Material Type changes to (Lungo, Espresso or Ristretto). Then a Trackout and MoveNext sends the material to the next step - The Trash. Additionally, the machine informs us of the water consumed during the process and, considering the quantity last refilled, allows us to calculate the Water Level by taking into consideration what each brew level takes and the full tank capacity (750ml):

• Lungo - 110ml
• Espresso - 40ml
• Ristretto - 25ml

Controller Workflows

Setup and initial configurations

Before communication is enabled and fully bidirectional, the Bluetooth device Prodigio_F8BA112E9F70 must be paired with the computer.

Two BLE characteristics must be assigned specific values for MES to be allowed to read from and write to the equipment:

• TxLevel = 1
• ClubIdMember = 88022c152c030494

This configuration can be easily applied in the Controller Setup, during the OnSetup phase:

SEMI E10 State

Manipulating the Slider in the machine, the Event OnSliderStateChange changes the Resource state, based on the SEMI E10 model of the equipment:

• Slide Open - Resource goes to Standby
• Slide Close- Resource goes to Productive

The MachineSpecificParameters property of the event, assumes 3 distinct values:

Some buffer operations are needed to implement this logic, namely:

• Applying a Logic AND 2
• Shift Right of 1
• Convert to Unsigned Integer

Capsule Handling

The equipment is capable of reporting the number of capsules consumed and the CapsuleStock event is triggered whenever this value changes. However, this functionality was not implemented in this Proof of Concept. Instead, capsule stock is managed directly in MES, which provides a more robust and reliable approach.

Coffee Management

To brew a coffee, some logic on the MES side triggers the Action Group brew. This can be achieved using a DEE that will be executed in a button click for example with the CoffeeType as input. To trigger each of the following Coffee types, the corresponding code should be written in the BLE Characteristic of the Nespresso equipment:

The response will trigger the OnCommandResponseChange event. The CommandResponse Event Property gives the status in buffer position (3,1):

In case of error, the bit (4,1) could be:

A notification is created with popup of the error.

Event Handling

During the brew process the OnMachineStatusChange event is triggered, giving the status of the equipment:

The OnMachineStatusChange event exposes the machine state through buffer positions that indicate engine activity and water consumption levels.

Engine State

The buffer bits(1,1) give you the state of the engine during the brew:

The Status commutes following this pattern:

State Transitions:

• 2 → 130: Idle to Starting
• 130 → 132: Starting to Brewing
• 132 → ...... → 132: Brewing continues
• 132 → 130: Brewing to Stopping
• 130 → 2: Stopping to Idle

The Material TrackIn and TrackOut are done in the following transitions:

• 130 → 132: TrackIn of material
• 132 → 130 or 132 → 2: TrackOut of in-process material

Notifications in case of error are sent, as well as a notification of successful brewing.

Water Level

Bits 6 and 7 provide the Water Level. In fact, what the equipment provides is a counter for the descaling of the machine, meaning that when the countdown value reaches zero, the machine needs maintenance and decalcification. To calculate the water level, when the tank is refilled, a value in ml is persisted and for each decrement, an estimated value is subtracted, giving the real ml value at each moment.

The calculated Water Level is then written to the Water level KPI.

Conclusion

A Nespresso machine brewing espresso is about as far from a factory floor as you can get, and yet, with ConnectIoT and Critical Manufacturing MES, it fits naturally into the same integration model used for industrial equipment.

The BLE communication layer handles the protocol specifics, the Controller workflows manage the machine lifecycle, and MES takes care of the rest: material tracking, resource state, and production records. The coffee machine becomes, effectively, just another resource on the shop floor.

The exercise has a practical point. If MES can track a capsule from the moment it drops into the machine to the moment it ends up in the bin, it can track anything. The same patterns, event-driven state transitions, material dispatch and trackout, water consumption as a production variable, apply directly to real manufacturing scenarios.

The Nespresso PoC is a useful demonstration precisely because it is simple enough, yet covers enough ground to validate the integration approach. Next time someone asks you what ConnectIoT can do, the answer might just be: “It can make a coffee”.

Author

Hello, my name is Rodrigo Cordeiro. I’m passionate about machine integration, automation and transforming industrial data into clear, useful, decision‑ready insights.

You can reach me on LinkedIn

Skills: ConnectIoT | Data Analyst | Data Scientist